Kext: DIY KernelEx extensions

[Giant2011]

opera 12.50.1497 starts on my computer the plugin wrapper gives a problem though. I have windows 98 SE and kernelex 4.5.2

[jumper]

My first try failed.

I couldn't start Opera 12.5 builds 1513 and higher, except build 1578 (12.02). Message: "Opera Error - Failed to load Opera.dll because: A device attached to the system is not functioning." The setting W2k+t5 wasn't kept. The comp mode window changed to default mode. I'll try it again.

I've been having trouble with core.ini processing, also. It doesn't always work they way it appears it should. Even cloning existing profiles isn't reliable.

One thing I learned about core.ini mods several months ago is that a full system reboot is necessary between every change--restarting Windows isn't enough. Naturally this greatly slows down the trial-and-error testing!

I looked in the source code at how the property sheet changes the mode and think I can write a utility to test each and all profiles to see which will stick if selected after modification (and reboot). Kex changes the mode to default if it doesn't like something about the selected mode.

It's been a few months since I looked at the source code for the Core.ini loader. Until I do that again, instead of using a new profile we'll have to stick to modifying the Kexstubs.ini definition on-demand:

GetAdaptersAddresses can be changed between r50s5 and t5 immediately before launching an app that needs the other definition.

Edit: struck Kex from stubs.ini

Edited February 4, 2013 by jumper

[jumper]

iphlpapi.zip

• Unzip iphlpapi.dll into app folder
  
• remove HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs\IPHLPAPI entry
  
• remove definitions for GetAdaptersAddresses and/or GetPerAdapterInfo from Kexstubs.ini
  
• stubs returning E_NOTIMP (0x80004001) for GetAdaptersAddresses and GetPerAdapterInfo will be added to IPHLPAPI in sysdir for just this app.
  

Edit: struck Kex from stubs.ini

Edited February 4, 2013 by jumper

[jds]

It's been a few months since I looked at the source code for the Core.ini loader. Until I do that again, instead of using a new profile we'll have to stick to modifying the Kexstubs.ini definition on-demand:

GetAdaptersAddresses can be changed between r50s5 and t5 immediately before launching an app that needs the other definition.

I wish now that I'd not suggested the 50 return code for GetAdaptersAddresses before checking what was documented. Sure, it works fine for SAPGUI, but perhaps the 232 return code would be more appropriate for other applications (and it works fine too for SAPGUI).

iphlpapi.zip

• Unzip iphlpapi.dll into app folder
  
• remove HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs\IPHLPAPI entry
  
• remove definitions for GetAdaptersAddresses and/or GetPerAdapterInfo from Kexstubs.ini
  
• stubs returning E_NOTIMP (0x80004001) for GetAdaptersAddresses and GetPerAdapterInfo will be added to IPHLPAPI in sysdir for just this app.
  

Hi jumper,

I notice that all but three functions in this DLL have the same entry point. Given that different functions will have different stack fix-up requirements, I presume that these other functions don't actually do this (properly). So, if any of these other functions are called (eg. HoverIP uses a bunch of functions from IpHlpApi), this DLL would be unsafe. Is that correct?

Joe.

[jumper]

>I wish now that I'd not suggested the 50 return code for GetAdaptersAddresses before checking what was documented. Sure, it works fine for SAPGUI, but perhaps the 232 return code would be more appropriate for other applications (and it works fine too for SAPGUI).

//
// MessageId: ERROR_NO_DATA
//
// MessageText:
//
//  The pipe is being closed.
//
#define ERROR_NO_DATA                    232L

A pipe error probably won't work universally, either. If you have a solution for your apps, don't worry about others--this is just temporary anyway. I'm working on a real implementation derived from the Wine sources.

>I notice that all but three functions in this DLL have the same entry point. Given that different functions will have different stack fix-up requirements, I presume that these other functions don't actually do this (properly). So, if any of these other functions are called (eg. HoverIP uses a bunch of functions from IpHlpApi), this DLL would be unsafe. Is that correct?

No!

You may also have noticed that it doesn't require that the original DLL be copied to another name. It also doesn't require KnownDLL tricks (another way to access the system DLL of the same name).

What it does is rewrite its export table at load time to redirect the standard functions to the originals in sysdir.

In addition to the stubs (currently) for GetAdaptersAddresses and GetPerAdapterInfo, it also exports a KernelEx-compatible get_api_table. This make it a hybrid Kext DLL that can also be used by KernelEx non-users.

I now have a partial implementation of GetPerAdapterInfo working and hope to release it soon. The test plan is to build the MSDN sample code for each API and run it on various platforms, with and without my extension DLL, comparing results.

[jds]

What it does is rewrite its export table at load time to redirect the standard functions to the originals in sysdir.

Neat! Thanks for the clarification, jumper.

Joe.

[jds]

iphlpapi.zip

• Unzip iphlpapi.dll into app folder
  
• remove HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs\IPHLPAPI entry
  
• remove definitions for GetAdaptersAddresses and/or GetPerAdapterInfo from Kexstubs.ini
  
• stubs returning E_NOTIMP (0x80004001) for GetAdaptersAddresses and GetPerAdapterInfo will be added to IPHLPAPI in sysdir for just this app.
  

Hi jumper,

FYI, here are the results of testing the 2012/12/04 edition :

HoverIP produces the following error message, then seems to work normally :

HoverIP v1.0

Une fonction de l'API Win32 a échoué.

SAPGUI produces the following error when trying to connect to the server, doesn't work :

Connection failed

Error: internal error

Tue Dec 11 14:26:27 2012

Release 710

Component NI (network interface), version 39

rc = -1, module ninti.c, line 214

Detail NiPGetNodeAddrList03

System Call GetAdaptersAddresses

Error No -2147467263

'E_NOTIMPL: Not implemented'

Joe.

[jumper]

> A function of the Win32 API failed

This could be a general failure message, or it could mean that HoverIP v1.0 is import-table-linked to iphlpapi.dll.

> Error No -2147467263

> 'E_NOTIMPL: Not implemented'

SAPGUI is definitely delay-loading iphlpapi.dll via LoadLibrary / GetProcAddress.

Let me explain....

The technique of rewriting the DLL export tables at load time works great when the DLL is delay loaded: LoadLibrary loads the DLL into memory and activates the export-table rewriting code; then GetProcAddress reads from the rewritten export table.

The normal loader merges these steps and accesses the DLL's export table before executing the entry function. Why? Because it's still checking dependencies and hasn't decided yet whether to execute the parent app!

What this means: This technique can be used to implement two different functions with the same name based upon how the DLL is linked or loaded by an app!

...It also means it won't work for our purposes at this time.

Stay tuned for the exciting backup plan.

[jds]

> Error No -2147467263

> 'E_NOTIMPL: Not implemented'

SAPGUI is definitely delay-loading iphlpapi.dll via LoadLibrary / GetProcAddress.

Agreed. Also, evidence to date is that SAPGUI doesn't accept any negative return values for this function.

Joe.

[jumper]

An HRESULT is a long int. Using t/-1 is a convenient way of setting the "error" (most sig.) bit. Perhaps SAPGUI treats >0 as recoverable errors and <0 as fatal errors?

---

I was able to add a 6-byte stub (jump to address in jump-table) for each API in my wrapper, so it now can be imported in the standard way. The extra jump table is trivial to create in the loader, and still allows this wrapper implementation to access the original sysdir DLL without needing any file renaming/duplication, etc.

iphlpapi.zip

• GetAdaptersAddresses returns ERROR_NOT_SUPPORTED.
  
• GetPerAdapterInfo attempts to function, but probably just returns SUCCESS and an empty list. (see below)
  
• GetTcpTable2 returns ERROR_NOT_SUPPORTED.

---

I've been studying the Wine 2003 and 2006 sources for iphlpapi as well as the ReactOS fork (off Wine 2003). With the help of some Wine header files plus a winetypes.h of my own creation, I've been able to extend my VC++5 build environment to handle the Winsock2 and IP Helper API's. I couldn't find an iphlpapi.lib to link with, so I created my own.

I've built the MSDN examples for the following seven iphlpapi.dll functions:

• GetAdaptersAddresses
  
• GetAdaptersInfo
  
• GetIpAddrTable
  
• GetIpForwardTable
  
• GetTcpStatistics
  
• GetTcpTable
  
• GetTcpTable2

Yesterday I searched Google for "getadaptersaddresses sample output" and found a webpage that has the same MSDN GetAdaptersAddresses example along with the (XP?) output.

Unfortunately, this site doesn't contain any GetPerAdapterInfo info. I already have a partial implementation for GetPerAdapterInfo, but the Wine/ReactOS sources call upon their own system internals that I had to stub. As a result there is no meaningful data returned yet....

But now I can get to crafting a GetAdaptersAddresses replacement.

[jumper]

Merry Christmas!

Version 3 of the Iphlpapi wrapper (2.55K) is now available with near XP-level support for GetAdaptersAddresses and partial support for GetPerAdapterInfo. (There is also a stub for GetTcpTable2.)

To use with KernelEx, copy to iphlpapi3.dll in your Windows\KernelEx folder and activate in one of these ways:

• • add New > String Value to registry: not working yet

    
    HKEY_LOCAL_MACHINE\Software\KernelEx\KnownDLLs
    IPHLPAPI=IPHLPAPI.DLL 

  • add to core.ini contents: (with or without Kstub822) not working yet

    
    contents=std,iphlpapi3,Kstub822,kexbases,kexbasen 

  [*] add individual function(s) to Kstub822.ini:

  
  [Iphlpapi.dll] ;any or all of the following:
  GetAdaptersAddresses=>iphlpapi3:
  GetPerAdapterInfo=>iphlpapi3:
  GetTcpTable2=>iphlpapi3: 

To use without (or with) KernelEx:

1. place (a copy of) iphlpapi.dll in the folder with any app that needs it.
   
2. Disable KnownDLLs redirection for Iphlpapi.dll by deleting this key in the registry:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs\IPHLPAPI

Edit: First method not working yet; Last method most tested and working both with and without KernelEx.

Edit2: Needs to be named iphlpapi3.dll in KernelEx folder.

Edit3: Second method not working yet. Non-working methods hidden in Spoiler.

Edited January 5, 2013 by jumper

[MiKl]

Merry Christmas!

Version 3 of the Iphlpapi wrapper (2.55K) is now available with near XP-level support for GetAdaptersAddresses and partial support for GetPerAdapterInfo. (There is also a stub for GetTcpTable2.)

Unfortunately SeaMonkey 2.0.14 does not start with iphlpapi running.

[jumper]

Unfortunately SeaMonkey 2.0.14 does not start with iphlpapi running.

What Iphlpapi dependencies does Dependency Walker list for SeaMonkey? GetAdaptersAddresses was written with Firefox in mind--I studied the 1.9.1 source code (nsNotifyAddrListener.cpp) and looked at the latest as well.

And what method did you use? Try using Kstub822.ini to add the functions one-by-one.

Note: Kexstubs definitions will override the local copy method. (In case you already have definitions from previous tests.)

[MiKl]

Unfortunately SeaMonkey 2.0.14 does not start with iphlpapi running.

What Iphlpapi dependencies does Dependency Walker list for SeaMonkey? GetAdaptersAddresses was written with Firefox in mind--I studied the 1.9.1 source code (nsNotifyAddrListener.cpp) and looked at the latest as well.

And what method did you use? Try using Kstub822.ini to add the functions one-by-one.

Note: Kexstubs definitions will override the local copy method. (In case you already have definitions from previous tests.)

Hi Jumper,

unfortunately I am not that much into all this great stuff so I can only hope that I give you some good infos.

- I don't see Iphlpapi listed at all in DependencyWalker for SeaMonkey 2.0.14 !! I will try a later version asap because I seem to remember that they switched then to the Firefox gecko so it may work. Will report back but I have to set up a test machine again ...

DW lists however many other problems for 2.0.14 - especially in ntdll.dll.

- Did used the core.ini method.

Thx

Edit: Also the latest version 2.14.1 of SeaMonkey seem to not like iphlpapi.

Edited January 2, 2013 by MiKl

[jumper]

I checked the SeaMonkey 2.6.1 package and didn't find any iphlpapi dependencies or even raw text references. I looked at the SeaMonkey sources and the only reference to iphlpapi is in nsNotifyAddrListener.cpp, the same version as used by FF2..20 and the 1.9.1 core, and the one I have already been using for reference. Apparently that file isn't linked into the 2.x builds of SeaMonkey.

So, any problem should also show up in FF2..20. But I've been running with no problems for the last week using the Core.ini method:

contents=std,iphlpapi,Kstub822,kexbases,kexbasen 

You can try using the Kstub822.ini method and only add definitions for GetAdaptersAddresses and GetPerAdapterInfo as needed for other apps:

[Iphlpapi.dll] ;any or all of the following:
GetAdaptersAddresses=>iphlpapi:
GetPerAdapterInfo=>iphlpapi: 

Iphlpapi.dll can also be renamed for testing in methods other than the local-app-directory method.

Edited January 8, 2013 by jumper