Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

fwd: DLL Forwarder and Checksum Corrector

- - - - -

  • Please log in to reply
20 replies to this topic

#1
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 474 posts
  • OS:98SE
  • Country: Country Flag

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

Attached File  fwd.03.zip   2.89KB   30 downloads

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 Files


Edited by jumper, 06 April 2012 - 03:18 AM.
removed excessive formatting

Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs


How to remove advertisement from MSFN

#2
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 474 posts
  • OS:98SE
  • Country: Country Flag

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. :)
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#3
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,091 posts
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#4
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 474 posts
  • OS:98SE
  • Country: Country Flag
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?
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#5
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,091 posts
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#6
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag

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.

#7
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag
Hi jumper,

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

Joe.

#8
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 474 posts
  • OS:98SE
  • Country: Country Flag
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, 08 March 2012 - 02:56 AM.

Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#9
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag

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.

#10
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag

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.

#11
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 474 posts
  • OS:98SE
  • Country: Country Flag

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.
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#12
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag


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.

#13
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 474 posts
  • OS:98SE
  • Country: Country Flag

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.
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#14
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag


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.

#15
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag


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.

#16
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 474 posts
  • OS:98SE
  • Country: Country Flag

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.
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#17
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag


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' : http://www.msfn.org/...post__p__995491

Joe.

#18
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 474 posts
  • OS:98SE
  • Country: Country Flag

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
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#19
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag


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.

#20
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 474 posts
  • OS:98SE
  • Country: Country Flag

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:
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#21
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,091 posts
  • OS:98SE
  • Country: Country Flag


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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN