ImportPatcher.41 - Find and fix dependency problems

[loblo]

Btw, here are some more netapi32 functions you may want to add in your dll:

NetGetAnyDCName

NetGroupEnum

NetGroupGetInfo

NetGroupGetUsers

NetShareEnum

NetUserGetGroups

Edited April 19, 2012 by loblo

[jumper]

> This one is working OK but it's not so different than mine since netbios is stubbed and not forwarded.

Right. It should be identical to yours, but with another dozen stubs as well. I wanted to avoid the forwarding problem for now, but using it globally in %system% could break other apps that need a working Netbios.

> For testing the other one I used a mixture of method 2 and 3 which is to say I did rename your dll to netapi32.dll and did put in the application folder and I also copied to it the original netapi32.dll from the system folder (renamed as NetApi00.dll of course) which theoretically should have been working for the netbios function if I am not mistaken.

Should have worked. More testing needs to be done on this front.

> Have you succesfully tested a netbios function forwarding and if so can you tell on which program so I can try it out myself?

No, I have yet to find a suitable program. The forwarding is produced by the VC5 linker from a .def file the same way that works for the ComDlgEx open and save functions.

...Okay, a brute-force search of my entire 30GB HDD just now found a program named winbox.exe that is static-linked to Netapi32.Netbios. But none linked to the NT Netapi32 functions. I'll do some testing and report back....

[jumper]

NetApiEx is only marginally related to ImportPatcher, so discussion and updates will continue in [ this Netapi32 topic ].

Thanks,

• 
  jumper.

[Drugwash]

API Parameter Count v1.0.2.0 is out. Just a few bugfixes and improvements. Enjoy!

DOWNLOAD executable + source code Homepage

[jumper]

When stubbing, in addition to parameter counts, we also need to know calling convention.

If a function uses the Pascal / WINAPI calling convention, the stub must clear the parameters off the stack. If a function uses the "C" calling convention (caller clears parameters off stack), the stub must not.

IPstub.dll has a family of WINAPI stubs. When stubbing for a "C" function, the zero-parameter form should be used.

(The FASTCALL convention usually passes the first two parameters in registers and the rest on the stack, but is not use when dynamic linking.)

[Drugwash]

Is there anything you would want me to add to the tool above? I'm not sure if an automatic parsing of the header files would yield proper results in regard to detecting calling convention and whatnot. I may need more details as my knowledge of C/C++ is pretty shallow.

[jumper]

New in ImportPatcher.37.zip:

• default option to test for API's with LoadLibrary/GetProcAddress if any DLL or API is missing
  
• iterate needed imports even if DLL is missing or has no exports
  
• "Target OS" -> "OS Subsystem Version [Ceiling]"
  
• nicer formatting of TimeDateStamps and ordinals in log
  

Detects availability of API's provided by KernelEx and DLLHOOK. Set KernelEx compatibility mode to level of desired detection.

For users of Kexstubs, blank definitions for missing functions can be copied directly from the output .ini files into the corresponding section in stubs.ini.

[schwups]

Set KernelEx compatibility mode to level of desired detection.

I also had tried to change comp. mode of the ImportPatcher.exe to see what happens. It was a bad idea. I had to reinstall KernelEX. So I have to set the comp. mode of the app only.

[jumper]

>I also had tried to change comp. mode of the ImportPatcher.exe to see what happens. It was a bad idea. I had to reinstall KernelEX.

ImportPatcher is just another app in that it doesn't know about KernelEx. It doesn't read from or write to any part of the KernelEx (or Kext) configuration. More details about what exactly you did would be helpful.

>So I have to set the comp. mode of the app only.

IP37 also doesn't read the target app's KernelEx configuration mode, and its analysis is unaffected by how it is currently set.

I recommend making a copy of IP37 and naming it IP37kex; then set the KernelEx mode of IP37kex all the way up to Win2008 and disable it on the original. That way you can easily test with and without KernelEx. (Beware that output files will collide, however, so copy them if you wish to WinDiff them.)

[jds]

Hi jumper,

I tried a little experiment recently to graft the W2K version of 'mpr.dll' into a W98 system, in an attempt to map network drives using domain-based DFS, where a fully qualified domain name (I think that's what it's called) is used instead of a NetBIOS hostname and (as if that wasn't enough) the share is on a subdirectory of the root. I don't know if 'mpr.dll' is the correct target, this was largely based on guesswork.

The plan involved also taking the W2K versions of 'NTDLL.DLL', 'rpcrt4.dll', 'advapi32.dll' and 'kernel32.dll', renamed to 'N2DLL.DLL', 'r2crt4.dll', 'a2vapi32.dll' and 'k2rnel32.dll', respectively. This was in order to satisfy all the dependencies of the W2K version of 'mpr.dll'.

Anyhow, after applying Import Patcher 37 to all these files, to substitute these DLL names, I found that 'k2rnel32.dll' (formerly 'kernel32.dll' of W2K) still had a run-time dependency on 'ntdll.dll' (instead of the renamed 'n2dll.dll'), from a call to "ntdll.RtlDeleteCriticalSection". Looking via a hex editor, I found a number of similar function calls, which I manually edited to suit the renamed (and patched) 'n2dll.dll'.

So it seems that Import Patcher doesn't detect DLLs that are called this way, when you try to do a DLL substitution. Hopefully this can be addressed in a future version of IP, when time permits, of course.

There were also one or two instances within most of these patched DLL files, where the names of DLL files such as 'ntdll.dll' remained unpatched. I don't know the significance of these strings still being present, so I manually edited these too.

BTW, this experiment was a failure. Even with the dependencies of these DLLs apparently addressed, this house of cards just crashes. So I still cannot tell if 'mpr.dll' would have helped with this newfangled drive mapping syntax.

Joe.

[jumper]

In W2K and later, many NTDLL.DLL apis are made available in Kernel32.dll via export forwarders.

Three types of dependencies are still not supported: import forwarders, export forwarders, and dynamic delay-loads. I've been learning a lot about export forwarders lately and if import forwarders work the same way, both of these should be relatively simple to implement.

I know exactly how export forwards are implemented, but it's not a small change for Import Patcher to support them. IP is architectured to patch Imports, not Exports. "It's impossible. But doable."

KernelEx 4.52 runs as an MPR service, thus it loads after MPR. I assume this is why you're trying to patch MPR instead of using Kexstubs.

NTDLL.DLL interfaces directly to drivers and the OS, so it really is an impossible substitution. Kernel32.dll is also extremely OS-centric and off-limits for substitution. Also Kernel32.dll is non-relocatable, so two versions can't be loaded at the same time.

The best solution I see is to rebuild the Wine or ReactOS sources for MPR.dll and static link the necessary functions from the other librarys.

[jds]

In W2K and later, many NTDLL.DLL apis are made available in Kernel32.dll via export forwarders.

Three types of dependencies are still not supported: import forwarders, export forwarders, and dynamic delay-loads. I've been learning a lot about export forwarders lately and if import forwarders work the same way, both of these should be relatively simple to implement.

I know exactly how export forwards are implemented, but it's not a small change for Import Patcher to support them. IP is architectured to patch Imports, not Exports. "It's impossible. But doable."

Hi jumper.

Ah, I see. And if I'm interpreting this correctly, the "ntdll.RtlDeleteCriticalSection" and similar functions seen in 'k2rnel32.dll' (W2K 'kernel32.dll') are export forwarder thingies. So what we actually need (ignoring the other issues here) is an Export Patcher tool?

KernelEx 4.52 runs as an MPR service, thus it loads after MPR. I assume this is why you're trying to patch MPR instead of using Kexstubs.

NTDLL.DLL interfaces directly to drivers and the OS, so it really is an impossible substitution. Kernel32.dll is also extremely OS-centric and off-limits for substitution. Also Kernel32.dll is non-relocatable, so two versions can't be loaded at the same time.

The best solution I see is to rebuild the Wine or ReactOS sources for MPR.dll and static link the necessary functions from the other librarys.

I didn't try the KexStubs path because there were so many missing dependencies involved and because there was no chance that they could all simply be stubs.

As regards the 'ntdll.dll' and 'kernel32.dll' OS compatibility, alas, I do believe you're right. I guess that's why the whole thing came crashing down in the end. As regards not being able to have two versions of 'kernel32.dll' loaded at the same time, does not renaming the W2K version (theoretically) make this possible?

Joe.

Edited February 15, 2013 by jds

[jumper]

> Ah, I see. And if I'm interpreting this correctly, the "ntdll.RtlDeleteCriticalSection" and similar functions seen in 'k2rnel32.dll' (W2K 'kernel32.dll') are export forwarder thingies.

I think so.

> So what we actually need (ignoring the other issues here) is an Export Patcher tool?

Today (Feb 19) is the one-year anniversary a short-lived Export Patcher project according to my folder creation date. I dropped it in favor of fwd: DLL forwarder which came out about a week later.

> As regards not being able to have two versions of 'kernel32.dll' loaded at the same time, does not renaming the W2K version (theoretically) make this possible?

The two versions both want to be loaded in overlapping address spaces, so one of them must be relocated. The 9x version is not relocatable, I don't think the NT version is either (look for a .reloc section with Quick View). The ReactOS version is, however (and also doesn't overlap)!

[jds]

> As regards not being able to have two versions of 'kernel32.dll' loaded at the same time, does not renaming the W2K version (theoretically) make this possible?

The two versions both want to be loaded in overlapping address spaces, so one of them must be relocated. The 9x version is not relocatable, I don't think the NT version is either (look for a .reloc section with Quick View). The ReactOS version is, however (and also doesn't overlap)!

Hi jumper,

Wow! I didn't realize 'kernel32.dll' has to load at a specific address. That's a fly in the ointment! Hmmm ... back to ReactOS ... I had tried a similar experiment with those DLLs in the past with the same apparent result. But I only half know what I'm doing, so another attempt may be worthwhile ...

Joe.

[jumper]

Searching the 279 files in my C:\WINDOWS\KernelEx folder (and its 5 subfolders!), I found 3 versions of Kernel32.dll that contained the text ".reloc"

• 
  + bwc13i .... 699KB ... 5.00.2195.7152
  + bwc20a .... 703KB ... 5.00.2195.7173
  + ReactOS .. 1428KB ... 42.3.14
  

I suggest trying one of the blackwingcat versions.

Edited February 22, 2013 by jumper