[jumper]

fwd: DLL forwarder
For inserting new exports into a primary DLL that forward to a secondary DLL
Also: Correct the Link Checksum of any PE file

 fwd.03.zip (2.89K)
Number of downloads: 20
Features:

• Displays Export Table and corrects Link Checksum of primary DLL or PE file.
  
• Adds forwarders to the primary DLL for all functions exported by name from the secondary DLL.
  
• Original primary file is backed up if changed.
  
• TimeDateStamp and MinorVersion fields of IMAGE_EXPORT_DIRECTORY are bumped by one per function added.

Usage:

fwd primary.dll [secondary.dll]

Outputs:

primary.dll, fwd.log, primary.<nnn>

Notes:

• For drag-and-drop launching, select one or two DLLs and then drag the primary onto fwd.exe.
  
• For SendTo launching, select one or two DLLs and then right-click on the primary DLL.

To do:

• Expand size of physical section containing export table when needed.
  
• Append ".DLL" to filenames when needed for easier command-line launching.
  
• Dialog box for interactive selection of functions by name or ordinal, with renaming option.

---

Older versions:

Attached File(s)

•  fwd.01.exe (4K)
  Number of downloads: 22
•  fwd.02.zip (2.75K)
  Number of downloads: 10

This post has been edited by jumper: 06 April 2012 - 03:18 AM
Reason for edit: removed excessive formatting

[jumper]

jumper, on 26 February 2012 - 03:19 AM, said:

I've written a new tool that will add additional functions to an existing DLL; the export table is expanded to include functions that get forwarded to a secondary DLL.

Early yesterday morning, the tool successfully added forwarders for the four functions of a secondary DLL into the export table of a primary DLL that already had nine functions for a total of thirteen exported functions. Dependency Walker and PEinfo both reported valid entries with no errors.

A subsequent test with comdlg32.dll also worked, but with several oddities. Once I get these final issues resolved, it should be possible for any programmer to write a stub (or better) function, build it into a DLL, and inject it into the system DLL of their choice for testing.

The number of export functions in a DLL is usually the same as the number of export names. Fwd.01 adjusts all the pointers correctly if this is true. Comdlg32.dll has one more function address pointer than name address and name address ordinal pointers, thus the current issue.

Fwd.01 is also limited by the amount of slack space in the logical section following the existing export table. These two issues will be addressed in the next version.

In addition to providing an API expansion solution that is complementary to KernelEx for applications, it should also be complementary to WDMSTUB for drivers.

[rloew]

jumper, on 26 February 2012 - 04:25 PM, said:

I've written a new tool that will add additional functions to an existing DLL; the export table is expanded to include functions that get forwarded to a secondary DLL.
....
In addition to providing an API expansion solution that is complementary to KernelEx for applications, it should also be complementary to WDMSTUB for drivers.

Unlike DLLs, the Module Names in the WDM Namespace are not owned by individual Modules. Anyone can add new Entry points to any Module. Replacement only requires that the newer code Entry point be loaded after the older one. So there is no need for a driver Patching tool, just additional WDMSTUB like Drivers. Also WDM Exports are not in the Modules Export table.

[jumper]

SYS drivers are PE files and can be updated with fwd.01: WDMAUD.SYS imports from KS.SYS; just now I was able to use fwd.01 to add two new functions to KS.SYS.

VXD drivers are LE files. I don't know how their imports work, but if they import from any PE files (others drivers or DLLs) they are also supported.

rloew, on 26 February 2012 - 04:57 PM, said:

So there is no need for a driver Patching tool, just additional WDMSTUB like Drivers.

Or vice versa, perhaps. Actually, it looks like the two methods will be complementary. (BTW, fwd does not patch drivers, it is a DLL extender.)

rloew, on 26 February 2012 - 04:57 PM, said:

Also WDM Exports are not in the Modules Export table.

Dependency Walker seems to think so for KS.SYS exports (imported by WDMAUD.SYS). Or maybe those are only standard exports. Where might I find documentation for "WDM Exports" so I can add support?

[rloew]

jumper, on 26 February 2012 - 09:32 PM, said:

SYS drivers are PE files and can be updated with fwd.01: WDMAUD.SYS imports from KS.SYS; just now I was able to use fwd.01 to add two new functions to KS.SYS.

VXD drivers are LE files. I don't know how their imports work, but if they import from any PE files (others drivers or DLLs) they are also supported.

rloew, on 26 February 2012 - 04:57 PM, said:

So there is no need for a driver Patching tool, just additional WDMSTUB like Drivers.

Or vice versa, perhaps. Actually, it looks like the two methods will be complementary. (BTW, fwd does not patch drivers, it is a DLL extender.)

rloew, on 26 February 2012 - 04:57 PM, said:

Also WDM Exports are not in the Modules Export table.

Dependency Walker seems to think so for KS.SYS exports (imported by WDMAUD.SYS). Or maybe those are only standard exports. Where might I find documentation for "WDM Exports" so I can add support?

I did some checking. It turns out the truth is a little of both.

WDM Modules can Export Functions, in their own Module Name, through their Export Tables as you observed. In addition, they can Export functions under arbitrary Module Names using a VXDLDR Call. WDMSTUB.SYS is a prime example of this. It provides core NT style functionality under the Module Name NTOSKRNL.EXE.
Imports are handled similarly to Executables, but the "WDM Imports" come from a database managed by VXDLDR.VXD.

VXD Files do not have named Import or Export tables. They can only Export Named Functions through the VXDLDR Call used by WDM Modules. They can do a WDM equivalent of GetProcAddress through another VXDLDR Call. VXDs can share functions though DynaCalls and Win32 Functions, but these are numbered, not named, and are not part of the Windows Driver Model (WDM).

As fas as documentation, I would start with VXDLDR.

[jds]

jumper, on 26 February 2012 - 03:19 AM, said:

fwd: DLL forwarder
For inserting new exports into a primary DLL that forward to a secondary DLL
......DLLforwarder
...DLLforwarder...
DLLforwarder......

Wow! 2012 really is the year of code!

This sounds like just what the doctor ordered ... time to dig out those applications where KernelEx wasn't quite enough.

Great work, jumper.

Joe.

[jds]

Hi jumper,

Does this mean 'fwd' can't work (yet)? : http://www.msfn.org/...post__p__991882

Joe.

[jumper]

I tried to do too much in one big step without enough testing. The good news is that I was able to reverse the direction and get the small DLL to forward exports to all the functions in the big DLL. This shows that DLL forwarding does work in Win9x and that fwd is indeed a viable project.

I've compared binaries produced by the VC5 linker of a small DLL with and without a single forwarded export and think I can account for every changed bit. I will need to do some more small tests to determine what I am overlooking before progressing to larger tests and then to updating fwd.

This post has been edited by jumper: 08 March 2012 - 02:56 AM

[jds]

jumper, on 08 March 2012 - 02:54 AM, said:

I tried to do too much in one big step without enough testing. The good news is that I was able to reverse the direction and get the small DLL to forward exports to all the functions in the big DLL. This shows that DLL forwarding does work in Win9x and that fwd is indeed a viable project.

Hey, that's great news! I'll keep in mind to try augmenting a small DLL when it comes time to try this out (at least until you've resolved the issues with the more complex DLL's).

I'm considering if this tool might help me get "SAPGUI for Java 7.10rev5" working ...

Joe.

[jds]

jumper, on 08 March 2012 - 02:54 AM, said:

I tried to do too much in one big step without enough testing. The good news is that I was able to reverse the direction and get the small DLL to forward exports to all the functions in the big DLL. This shows that DLL forwarding does work in Win9x and that fwd is indeed a viable project.

Q1: Does this mean the instructions in the first post need to be revised?
eg. "Usage: fwd big.dll my.dll" becomes "Usage: fwd my.dll big.dll"?

Q2: Is 'IPStub.dll' suitable as the "small DLL"?

BTW, I haven't had any luck getting "SAPGUI for Java 7.10rev5" working. I used 'fwd' to make a special version of 'IPStub.dll' (called 'netapi33.dll') which forwarded the 'Netbios' function to 'netapi32.dll' and provided the usual dummy stub functions. Then I used "Import Patcher" to substitute 'netapi33.dll' for 'netapi32.dll' and the 'o8' function for 'NetUserEnum'. It looked OK in "Dependency Walker", however gave the same "JniAgiLibAdaptor.<init>: Cannot load JNI library" error for 'JPlatin.dll' as before.

Joe.

[jumper]

jds, on 04 April 2012 - 01:28 AM, said:

Q1: Does this mean the instructions in the first post need to be revised?
eg. "Usage: fwd big.dll my.dll" becomes "Usage: fwd my.dll big.dll"?

No. "reverse the direction" refers to another method unrelated to fwd.

jds, on 04 April 2012 - 01:28 AM, said:

Q2: Is 'IPStub.dll' suitable as the "small DLL"?

Yes!

---

I finally posted fwd.02 that I was working on last month. I'm not sure what state it was left in, but it has better logging and patching.

[jds]

jumper, on 04 April 2012 - 05:52 PM, said:

jds, on 04 April 2012 - 01:28 AM, said:

Q1: Does this mean the instructions in the first post need to be revised?
eg. "Usage: fwd big.dll my.dll" becomes "Usage: fwd my.dll big.dll"?

No. "reverse the direction" refers to another method unrelated to fwd.

But ... but ... you said "I was able to reverse the direction and get the small DLL to forward exports to all the functions in the big DLL". Now, if I use command "fwd big.dll my.dll" (as per the first post currently), I will get a "big.dll" which forwards to "my.dll". So if instead "my.dll" is to forward to "big.dll", then the command needs to be reversed as "fwd my.dll big.dll", right?

An interesting thing also happened when I tried command "fwd.01.exe netapi32.dll ipstub.dll". The resultant 'netapi32.dll' showed a "Link Checksum" discrepancy in Dependecy Walker. Same thing happens with 'fwd.02.exe'.

Joe.

[jumper]

jds, on 04 April 2012 - 08:16 PM, said:

But ... but ... you said "I was able to reverse the direction and get the small DLL to forward exports to all the functions in the big DLL". Now, if I use command "fwd big.dll my.dll" (as per the first post currently), I will get a "big.dll" which forwards to "my.dll". So if instead "my.dll" is to forward to "big.dll", then the command needs to be reversed as "fwd my.dll big.dll", right?

Theoretically, yes. But don't forget that DLLs patched by fwd don't actually work yet.

However, if "my.dll" really is yours that you built from source, you can export forward to "big.dll" in the link step and don't needed fwd. That is the method unrelated to fwd that actually works.

jds, on 04 April 2012 - 08:16 PM, said:

An interesting thing also happened when I tried command "fwd.01.exe netapi32.dll ipstub.dll". The resultant 'netapi32.dll' showed a "Link Checksum" discrepancy in Dependecy Walker. Same thing happens with 'fwd.02.exe'.

Yes, fwd hacks a file without properly hiding its tracks by fixing the checksum!

All my tools face this issue. The next version will either zero the checksum, or maybe actually correct it.

[jds]

jumper, on 04 April 2012 - 11:08 PM, said:

jds, on 04 April 2012 - 08:16 PM, said:

But ... but ... you said "I was able to reverse the direction and get the small DLL to forward exports to all the functions in the big DLL". Now, if I use command "fwd big.dll my.dll" (as per the first post currently), I will get a "big.dll" which forwards to "my.dll". So if instead "my.dll" is to forward to "big.dll", then the command needs to be reversed as "fwd my.dll big.dll", right?

Theoretically, yes. But don't forget that DLLs patched by fwd don't actually work yet.

However, if "my.dll" really is yours that you built from source, you can export forward to "big.dll" in the link step and don't needed fwd. That is the method unrelated to fwd that actually works.

Sorry to still be confused, I thought "small" DLL's patched by 'fwd' did work? That's why I asked if 'IPStub.dll' was a suitable "small" DLL. If my understanding was incorrect, and patching either way with 'fwd' is non-functional, that could explain why my Java SAP Client experiment was a failure.

BTW, the checksum error in "Dependency Walker" did not occur when I used 'IPStub.dll' as the base DLL, with forwarding to 'netapi32.dll'.

Joe.

[jds]

jumper, on 04 April 2012 - 11:08 PM, said:

jds, on 04 April 2012 - 08:16 PM, said:

But ... but ... you said "I was able to reverse the direction and get the small DLL to forward exports to all the functions in the big DLL". Now, if I use command "fwd big.dll my.dll" (as per the first post currently), I will get a "big.dll" which forwards to "my.dll". So if instead "my.dll" is to forward to "big.dll", then the command needs to be reversed as "fwd my.dll big.dll", right?

Theoretically, yes. But don't forget that DLLs patched by fwd don't actually work yet.

However, if "my.dll" really is yours that you built from source, you can export forward to "big.dll" in the link step and don't needed fwd. That is the method unrelated to fwd that actually works.

Sorry to still be confused, I thought "small" DLL's patched by 'fwd' did work? That's why I asked if 'IPStub.dll' was a suitable "small" DLL. If my understanding was incorrect, and patching either way with 'fwd' is non-functional, that could explain why my Java SAP Client experiment was a failure.

BTW, the checksum error in "Dependency Walker" did not occur when I used 'IPStub.dll' as the base DLL, with forwarding to 'netapi32.dll'.

Joe.

[jumper]

jds, on 05 April 2012 - 12:11 AM, said:

Sorry to still be confused, I thought "small" DLL's patched by 'fwd' did work?
...
BTW, the checksum error in "Dependency Walker" did not occur when I used 'IPStub.dll' as the base DLL, with forwarding to 'netapi32.dll'.

Well, they should. But so far there have been no reports of success.

IPstub.dll did not have the checksum set, so modding the file goes undetected.

fwd.03 is now posted--it updates the Link Checksum after all forwarders are added. It will also correct the Link Checksum for any PE file!
See post #1 for details.

[jds]

jumper, on 06 April 2012 - 03:19 AM, said:

jds, on 05 April 2012 - 12:11 AM, said:

Sorry to still be confused, I thought "small" DLL's patched by 'fwd' did work?
...
BTW, the checksum error in "Dependency Walker" did not occur when I used 'IPStub.dll' as the base DLL, with forwarding to 'netapi32.dll'.

Well, they should. But so far there have been no reports of success.

IPstub.dll did not have the checksum set, so modding the file goes undetected.

fwd.03 is now posted--it updates the Link Checksum after all forwarders are added. It will also correct the Link Checksum for any PE file!
See post #1 for details.

Yeah, something must be wrong. I finally managed to get SAP GUI for Java to work by stubbing both 'netapi32.dll' functions, instead of using 'fwd' : http://www.msfn.org/...post__p__995491

Joe.

[jumper]

jds, on 16 April 2012 - 09:59 PM, said:

Yeah, something must be wrong. I finally managed to get SAP GUI for Java to work by stubbing both 'netapi32.dll' functions, instead of using 'fwd' : http://www.msfn.org/...post__p__995491

fwd doesn't yet support the renaming of external functions. Adding the functions in ipstub to netapi32 won't work because the new functions will not have the names we need.

Using a Win2k netapi32 as the primary and a renamed Win9x netapi32 as the secondary should yield a usable netapi32 with both the original Netbios function along with all the NT functions.

The next beta of fwd will include support for using a .def file as the secondary. That will allow for such renaming as:

NetUserEnum=IPstub.o8

[jds]

jumper, on 18 April 2012 - 06:18 AM, said:

jds, on 16 April 2012 - 09:59 PM, said:

Yeah, something must be wrong. I finally managed to get SAP GUI for Java to work by stubbing both 'netapi32.dll' functions, instead of using 'fwd' : http://www.msfn.org/...post__p__995491

fwd doesn't yet support the renaming of external functions. Adding the functions in ipstub to netapi32 won't work because the new functions will not have the names we need.

No, that's not the problem. I took care of the renaming issue by also patching the 'JPlatin.dll' file with Import Patcher. Dependency Walker was satisfied with the end result, but it didn't work.

Joe.

[jumper]

jds, on 18 April 2012 - 08:48 PM, said:

No, that's not the problem. I took care of the renaming issue by also patching the 'JPlatin.dll' file with Import Patcher. Dependency Walker was satisfied with the end result, but it didn't work.

Understood. We have a fundamental problem with export forwarders not working, plus a function renaming issue.

Using a .def file to tell fwd how to name/rename the new export will prevent the need to use ImportPatcher on every app that links to those new functions.

Export forwarding seems to the issue of the day:

• vilyathegreat and schwups are having success printing with ComDlgEx (but can they "Open File" or "Save As" using export-forwarded functions?)
  
• loblo is having trouble with the export-forwarded Netbios function in NetApiEx that is linked the same way as ComDlgEx
  
• fwd.03 produces DLLs that still don't seem to work as expected.

Looks like I'll have to review and restudy the whole concept of export forwarding and write some very targetted test apps and test cases to determine things like whether KernelEx processing affects link search paths, etc. Any programmers with experience that might be relevant are encouraged to chime in here.