HookAllAPI /Import Table Patching ?

[dcabale]

[Newbie /visitor to madCodeHook]
Hello,
My goal is to instrument a program binary, for understanding it.
On the program's execution, for each method called, I want the OnEnter /OnExit event of each method to be logged as "my_method_name enter /exit".
1. According the documentation, function HookAPI (module, api: PAnsiChar;...) expects a API name.
So for each API that must be hooked, an individual call to HookAPI must occur. -> This solution is not suitable for me.
2. The http://help.madshi.net/ApiHookingMethods.htm is talking about "Import Table Patching". How to do that with madCodeHook ?
Or are there other means to achieve my goal?
Thanks for your help

[madshi]

madCodeHook is built with the concept in mind that you have to create a separate hook callback function for each API. That's the way it was designed, and it doesn't work any other way.

Hooking a big list of APIs without even knowing which parameters or calling convention they have is a completely different topic. It might be possible by using clever assembler code, but you would have to be very careful to not overwrite the stack, nor change any registers.

Whether you use API code overwriting or API import table patching doesn't have anything to do with the above.

[dcabale]

@madshi, Thanks for your quick reply !

[iconic]

1. According the documentation, function HookAPI (module, api: PAnsiChar;...) expects a API name.
So for each API that must be hooked, an individual call to HookAPI must occur. -> This solution is not suitable for me.

HookCode() does not need a module name or API function name at all, it uses an untyped/dumb pointer to the function. If you have an address to
hook this can be called instead of HookApi()

2. Let madCodeHook determine the best suitable way for it to hook internally, no user intervention is needed by default

--Iconic

[dcabale]

@iconic, thanks for your reply
Would you know some tool /framework that would allow to hook *all the methods* all at once?
PS: referring to "import table patching" from http://help.madshi.net/ApiHookingMethods.htm, I can read: "Each win32 module (application/DLL) has a so-called "import table", which is basically a list of all APIs, which this module calls"

[iconic]

Please explain more about what you mean here:

Would you know some tool /framework that would allow to hook *all the methods* all at once

If you mean a HookAllAPIs() call in code, no. If you want a tool that has predefined function prototypes that captures thousands of Win32 API then try API Monitor from Rohitab.com

http://www.rohitab.com/apimonitor

Also, you'll see virtually every other popular and/or common API hook library does it like madCodeHook including Microsoft Detours. There's a very good reason (stability primarily)

--Iconic

[dcabale]

1. Thanks for your answer
2.

Please explain more about what you mean here:
Would you know some tool /framework that would allow to hook *all the methods* all at once

well, guess of a madCodeHook method named HookAllAPIs() (or HookAllCode()) that could trap /hook all the methods of the module. It could look like this:

Code: Select all

var OriginalFunction : method(const aMethodName: String; aArguments: Array of const) of Object;

function HookAllCallback(const aMethodName: String; const aArguments: Array of const);
begin
	Log('enter method: ' + aMethodName)
	OriginalFunction(const aArguments: Array of const);
	Log('exit method: ' + aMethodName)
end;

initialization
  HookAllAPI('Mymodule.exe', @HookAllCallback, @OriginalFunction);
end.

This way, in logging each enter /exit of any functions, I could end up having a call tree of my module in execution.
I hope I'm clearer..

Note that Rohitab "Call Tree" feature seems to do that

calltree.png (57.38 KiB) Viewed 12558 times

[iconic]

In order for API Monitor to be able to build a call tree is due to the fact that over 13,000 API definitions are available to it and each function is internally hooked one-by-one, same as you would achieve with madCodeHook, Detours, mHook, Easy Hook and others. You can't avoid this since each function does not have the exact same function prototype - param list, param count, return value (if any), calling convention (x86 only) etc. You'd need to do it exactly the way the 3rd party tool does this and if you read the information about it on the official site it clearly mentions how this is achieved (predefined API prototypes are needed for each hooked API). How else would you make sense of a function call and param output? Guesswork doesn't happen there.

The tool's page tells you this below:

API Monitor comes with API Definitions for over 13,000 API’s from almost 200 DLL’s and over 17,000 methods from 1,300+ COM Interfaces (Shell, Web Browser, DirectShow, DirectSound, DirectX, Direct2D, DirectWrite, Windows Imaging Component, Debugger Engine, MAPI etc). API’s are organized into categories and sub-categories (as specified in MSDN). The API Capture filter enables you to to select API’s for monitoring.

--Iconic

[dcabale]

Thanks @Iconic for your precisions.
Now that RADStudio builds with MSBuild, I finally found a MSBuild compilation option, that should allow me to do what I'm looking for: adding a custom function to the OnEnter and OnExit event of each function.
https://learn.microsoft.com/en-us/previ ... (v=vs.100)
https://learn.microsoft.com/en-us/previ ... (v=vs.100)

CompilerOptions.png (13.96 KiB) Viewed 12501 times

=> I would probably spend some time to configure this adequately now
Though, this solution should not be considered as binary code hooking, but rather as compilation configuration.

[dcabale]

hmm.. , it seems these /Gh switches /options are not allowed in the MSBuild for Delphi projects

CompilerOptions#2.png (20.52 KiB) Viewed 12478 times

[iconic]

Hello,

I was aware of the config flag /Gh and /GH respectively but I've never needed to use them because AFAIK it's only for YOUR program where you have control over the config/linking stages and not other software. Also, it's more of a profiling aid where you might want to see how many times a call is made or how long each call is internally taking to improve performance.

A few things I was reading online about this is that you'd need to write a "naked" function for _penter/exit and preserve all the registers (used or not) as well as register flags (MS dropped the ball in their example, it's DEFINITELY needed) as well as restore the regs/flags afterwards. The problems you'd run into are mainly trying to identify how many params are used and what each register contains for any useful output but params can also be stack-based so that adds to the tall order you'd have to attempt to decipher what is what for meaningful output. That's not very easy to do and IMHO harder for supporting x86.

Since MSVC does not support inline assembly (x64) you'd also need to write an external .asm file with the _penter/exit code and link this in, less convenient here since you now have to do any useful logging in pure asm to support x64 builds.

Also, AFAIR modern Delphi versions that switched over to MSBuild only use a very small subset of MSBuild switches and flags so I am not surprised that Delphi does not support this configuration feature. Bummer

Here's a decent article on the whole /GH[h] subject here that mentions just some of the caveats and challenges:

https://www.codeproject.com/Articles/80 ... filer-on-x

--Iconic

[dcabale]

Also, AFAIR modern Delphi versions that switched over to MSBuild only use a very small subset of MSBuild switches and flags so I am not surprised that Delphi does not support this configuration feature. Bummer

I'm afraid the Delphi personality is not concerned by the MSVC compiler options
https://learn.microsoft.com/en-us/cpp/b ... w=msvc-170

2024-05-02 11_06_32-MSVC Compiler Options _ Microsoft Learn - Work - Microsoft​ Edge.png (88.95 KiB) Viewed 12323 times

Thus this has nothing to do with the MSBuild compiler switches I was referring previously
Anyway, many thanks for your inputs

[iconic]

Hello,

Yes, Delphi is very limited when it comes to MS* anything really, they're still partially competitors

The only MSBuild documentation I've seen (via Delphi's official source) is below and not overly informative:

http://docwiki.embarcadero.com/RADStudi ... ld_Command

API hooking has its advantages (in many areas) but it also requires work, such as API Monitor has done for def/prototypes.
IIRC there is a GitHub with the used definitions so that would ease the work a lot, parse them out and make sense of it
to the best of your ability. Good luck and wish you the best!



--Iconic