jumper

fwd: DLL Forwarder and Checksum Corrector

37 posts in this topic

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

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:

fwd.01.exe

fwd.02.zip

Edited by jumper
removed excessive formatting
0

Share this post


Link to post
Share on other sites

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. :)

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

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.)

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?

0

Share this post


Link to post
Share on other sites

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.

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.)

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.

0

Share this post


Link to post
Share on other sites

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. :thumbup

Joe.

0

Share this post


Link to post
Share on other sites

Hi jumper,

Does this mean 'fwd' can't work (yet)? :

Joe.

0

Share this post


Link to post
Share on other sites

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.

Edited by jumper
0

Share this post


Link to post
Share on other sites

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 ... B)

Joe.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

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.
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

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! :o

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

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.