• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
jumper

fwd: DLL Forwarder and Checksum Corrector

27 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

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

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

See post #1 for details.

0

Share this post


Link to post
Share on other sites

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

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

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' :

Joe.

0

Share this post


Link to post
Share on other sites

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' :

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

0

Share this post


Link to post
Share on other sites

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' :

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.

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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

DLLHOOK already can forward as well as rename exports. It also works globally so only one .INI is needed for everybody.

Unlike the Demo, the current Version is compatable with Kernelex 4.5.2. It is now listed on my Website as a separate product.

0

Share this post


Link to post
Share on other sites

Posted (edited)

IT is truely awesome.

Previously i am using flexhex , pemaker by BlackWingCat and IDA pro and a debugger

Then tried this one :: https://dl.packetstormsecurity.net/papers/win/intercept_apis_dll_redirection.pdf

It is truely awesome

EDIT : I am tring with XP kernel32.dll(Renamed to primary.dll) and Server 2008 R1 SP2  Kernel32.dll (Renamed to Secondary.dll) then draged both over fwd but no export was added. Am i doing any wrong?

fwd.log

Edited by Dibya
0

Share this post


Link to post
Share on other sites

can any one explain me how can i add all api of psapi.dll of xp to one present in 98?

I am selecting both and draging and droping but following error happening Debug : Export table not at end of section

same tring with d3d9.dll but fwd is crashing .

0

Share this post


Link to post
Share on other sites

helllo! ANY ONe here  ! I am facing following ERROR?

FWD_ERROR.JPG

0

Share this post


Link to post
Share on other sites

@Dibya: Stop being bothersome, already!

You resurrected a thread nobody has posted to since 2012 and you want an instant reply ?

You know fully well jumper is around, so he'll answer you if and when he can.

Cool down and wait, will you?

1

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.