Does anyone have the info/idea/etc on how we
can hook an API call (say hooking the winsock

Your help is appreciated. TQ!

Posted on 2002-01-10 19:47:00 by congyuen
well at Iczelion's site he does have a hooking tutorial. take a look here and it should get you started in the right direction.
Posted on 2002-01-10 20:08:54 by smurf
Smurf dude, i think you have the wrong type of hook there :)
Posted on 2002-01-10 20:42:20 by sluggy
well at least i didnt give him a link to field and stream. :grin:
Posted on 2002-01-11 00:56:48 by smurf
You can create a proxy dll that just calls the origonal dll functions (if its not a function your intersted in you just call it since the argumants are allready on the stack). For the function you want to hook you just place your hook code in your proxy function and then call the origonal when your done.
Posted on 2002-01-11 01:30:17 by Quantum
proxy.dll is one approach, take a look at for another :)
Posted on 2002-01-11 01:40:09 by f0dder
what you suggested is okay for a quick hack, but not okay for an app that is going to have any sort of lifespan. The problem with writing a proxy dll is that the dll you are replacing can be changed/modified/updated at any time, especially if it is a MS dll that you are proxying. Also, dlls (especially MS ones) can have a large amount of undocumented exports, which may be exported by name or ordinal, try getting those right :)

There are two official ways to hook an API function: by replacing addresses in the import table of an app, or by "trampolining".

Replacing the jumps in the import table is probably the most simple/pain free way to do it, but i am unsure of some of the specifics, like how to get a pointer to that import table. Does anyone know how to do that? There has to be an API call for it some where, so that the OS can do the fixups when a module is loaded.

The other way is "trampolining". This term was coined by a guy at MS Research who invented it, and wrote the sample code (in C of course). This method involves finding the start address of the API function, then replacing the first five bytes of it with a JMP/CALL to your own function, after which you can return control to the original function, return directly to the caller, or execute your function after the original function. Getting the start address of a function is simple (GetProcAddress()), but i am not sure how he goes about replacing the first few bytes, how can he tell what he is replacing and how many bytes that instruction actually takes? I have his little project on my harddrive, i have just never taken the time to study it.

Both methods require that your hook dll be loaded into the process space containing the dll you want to hook. There is 2? 3? different ways to do this, but let's deal with that when it comes up. Of course, if it is your app in the process, you can just load the dll straight in without any problems.
Posted on 2002-01-11 03:10:36 by sluggy
Modifying the iat is very easy :). If you know the base address of
your executable (0x400000 most of the time), you in turn have access
to he MZ header. This leads you to the PE header. And from there
on, you can get all needed info from PE documentation.

The "trampolining" approach has so manny gotchas. Like, how do
you execute those first five bytes? You can't just restore it... You'll
probably end up having to write a small disassembler, and execute
some instructions out of their original place (meaning you also have
to fix up instructions).

Take a look at EliCZ' stuff, or the microsoft Detours project.
Posted on 2002-01-11 03:25:21 by f0dder
hooking some api-function is not hard at all... but you have
to take care of some things...

a dll will NEVER have a fixed base adress, Thats because
it will be mapped in some other progs adr-space and therefore
the base could be different everytime...

don't mess with the stack, one single stack fault could
cause impact...

f0dder, what do you mean with "how do you execute..." ?
if you overwrite the first 5 bytes of some api those bytes
WILL be executed... the original 5 bytes will be stored and
replaced by our patcher, the patched 5 bytes should point
to our routine... after execution we do a rollback and jump
back to the entrypoint of the real api-code...

maybe i'm wrong :)

BTW: sluggy, if you have the Intel-ref or some other
dokument about ops you can find out simply how many
bytes takes a little jump command... replacing is also
not that hard... just find out the RAW-adr of The api-code
and overwrite... oh i forgot to mention that you can't
directly write to dll's that are used by the system... but
there are a couple of tricks to skip this...
Posted on 2002-01-11 04:05:55 by mob
or the microsoft Detours project.

"Trampolining" IS the MS detours project, that is what the guy called the technique (because you bounce from the original function to your own and back again).

I am taking the time to look at it now :)

I still say there has to be some (probably undocumented) API calls to deal with the IAT, i can't imagine MS just using a fixed offset from the start of the PE header....
Posted on 2002-01-11 04:15:07 by sluggy
sluggy... you don't need undokumented api's... the base
adr is actually the start of the MZ hdr... that means if you
open the dll with the regular filehandling apis the returned
"handle" IS the module-base... from there you can scan
the export-table and retrieve the api adr...

if the dll is attached to some progs adr-space the base
will be different but thats not the problem of api-patcher.
your inserted routine must recalculate the base again
to assure that the dll get control back...
Posted on 2002-01-11 04:31:23 by mob

maybe i'm wrong

Yep :). Your method would work pretty well in a single-tasked
environment, but in a multi-tasking multi-threaded environment
it will fail sooner or later (sooner) ;).

why would there have to be an API? The PE headers are quite
flexible and well-documented, there's nothing hackish to this
approach at all. Well, not much.
Posted on 2002-01-11 04:57:45 by f0dder
ok ok but please could you to state a reason? i used to
play around with this stuff a while ago and i succesfully
inserted my code in kernel32.dll (i hooked MessageBox).
it worked fine under 9x... i couldn't test it with nt or 2k
but i guess it would fail coz kernel is protected (insn't it?).
so why the hell do you think it wouldn't work? because
of my incompetence there was a few bugs, yeah... but
i killed them and it worked perfectly... also take a look On
all this stupid viruses that use that method... code with
fully aware of all this flaws (non fixed base/stack/...) and i
don't see a reason why this method shouldn't work...
Posted on 2002-01-11 05:49:35 by mob
why would there have to be an API? The PE headers are quite flexible and well-documented, there's nothing hackish to this approach at all. Well, not much.

I was just checking out Icz's PE tutorial #6, and i have an answer to that. There are several different APIs that can be used to map a file, those APIs return ptrs to a struct, you then follow a chain of struct members to ultimately get the pointer to the IAT and its sections.
Posted on 2002-01-11 06:07:02 by sluggy
mob, what I mean is... if you want a global hook on an API, and want
it to be continous (ie, not a single-shot hook)... when you patch
the function-entry 5 bytes back and jump there, another thread
might call the function before you can re-insert your hook, and you
will thus lose a call to the function. There's also issues if a function
is less than five bytes long :).
Hm, on NT/2k there is the copy-on-write stuff to take into account...

Sluggy, I thought you meant an API to change IAT entries :). Yes,
"following pointers" (IE, using the information in the PE header) is
the way to go... never sad otherwise. Still aren't APIs for that, and
still no reason to have them. True, depending on imagebase being
0x400000 is a bit dirty... but I guess you can use PSAPI or ToolHelp
to get the base address programatically?
Posted on 2002-01-11 06:34:49 by f0dder
sluggy, if you Map a file into memory the returned value
is actually a pointer to the start of the allocated memory...
and if the executable is succesfully mapped into this mem-
block the first structure this pointer points to is the old DOS
header... the pe-header is located behind ( DOS[3Ch] )...
the last section in the pe_optional header is the data-directory
(number of rva's and sizes)... the format is:

DE_Export dd ?, ?
DE_Import dd ?, ?
DE_Resource dd ?, ?
DE_Exception dd ?, ?
DE_Security dd ?, ?
DE_BaseReloc dd ?, ?
DE_Debug dd ?, ?
DE_Copyright dd ?, ?
DE_GlobalPtr dd ?, ?
DE_TLS dd ?, ?
DE_LoadConfig dd ?, ?
DE_BoundImport dd ?, ?
DE_IAT dd ?, ?
DE_Reserved1 dd ?, ?
DE_Reserved2 dd ?, ?
DE_Reserved3 dd ?, ?

hm you always talk about the IAT... i never found a way
to manipulate it... so i still stick to DE_Export...

btw f0dder you're right... and wrong :) the only method
i know to patch a often used dll is:

1) copy kernel32.dll to Mykernel.dll
2) patch Mykernel.dll
2) create a little batchprg or something that copys the
patched dll over the kernel32.dll AT STARTUP... i guess
it was winstart.bat (don't know)... so if a prog is faster
bad luck... (btw that's impossible i think coz winstart or
whatever you use must be started BEFORE win is able
to load it's dll's)l

it worked everytime...

oh and it seems you missunderstood what i wrote... i don't
talk about writeprocessmemory... you can Use this method
(with help of psapi in 2k/nt and toolhelp in 9x) but thats
very hard to implement and error-prone...
Posted on 2002-01-11 06:36:04 by mob
Mob, according to a previous post by F0dder, modifying a system dll under nt/2k/xp will change the dll only in your process.

I would think that is the reasonable thing to do.
Posted on 2002-01-11 10:49:31 by Hel
hel, i wrote it and i'll write it again... i'm not talking about
process-patching... ok? it's clear as daylight that proc-
patching only works for a single app (...for sure, there
are ways to do it, but i don't know how)... if you want a
easy, global and reliable api-hook, the best way, as i tried
to point out, should be raw file patching...
Posted on 2002-01-12 09:43:06 by mob
a dll will NEVER have a fixed base adress

i don't really agree with that. sorry ;)
Posted on 2002-01-13 06:18:05 by lifewire
Well, in properly designed DLLs, a base address is chosen so that
the DLL will normally not have to be relocated. There's a utility to
handle the rebasing of all DLLs an application uses, I can't remember
it's name though (should either come with visual studio, or perhaps
even be in the PlatformSDK).

However, a DLL should always contain relocation information, and
thus you cannot *depend* on a DLL having a fixed base address.
Some of the system DLLs do have constant addresses, but they
can vary from platform to platform, so you shouldn't depend on
Posted on 2002-01-13 07:16:16 by f0dder