SetProcAddress?

Started by
5 comments, last by Kwizatz 19 years, 8 months ago
Hey everyone! I am trying to find out a way to set the address of a DLL function to a different one in a dll of my own, which would pretty much act as a proxi for the original one. The idea is similar to some code floating around for a Socket Spy, in that code you compile a wsock32.dll which wraps all the functions so that you can monitor what comes in and comes out. Now I dont really need to monitor each single function, just recv and send, so that approach seems really messy, I started looking for a way to do it, and found some hints to the obscure SetProcAddress function, which aparently does exists but is undocumented. Anyway, instead of chasing ghosts, I decided to think about how would I implement the function, I thought that it should be posible by overwriting the import table of a process with the address of my function where the address of the other function is, and then call the address of the original function from within mine, think WndProc and SetWindowLong ;). problem is how do I find the import table? will this work anyway? A HMODULE handle in WinAPI is the address to the memory mapped module, so I have a starting point to look for the table in memory, and that's as far as I got :) has anyone ever done such thing before? does anyone know how to access the import table ina process? does anyone know anything about SetprocAddress? Cheers!
Advertisement
You must learn the layout of the PE file format header.

Google is your friend.
daerid@gmail.com
This is not using setprocaddress but doing the exact same thing you want to do:
http://www.nocturnalnetwork.com/redirect.htm

Ive never tried it myself, just stumbeled upon it the other day
@daerid

I kind of figured that, however I am dealing with the PE in memory, its not quite the same as manipulating it cold in the HD, I usually google all I can before posting here, thats how I found out there is the urban legend of a SetProcAddress, as well as how I found an article on virii which kind of gave me some hope as to change the import table, not the lack of googling, but perhaps using the wrong search keywords is my sin :)

@keen

Thanks!, I'll check that out.
Run "dumpbin /exports wsock32.dll"

I wrote a Perl script that would generate all the wsock32.dll stubs necessary to fully stub it out. Unfortuantely, it was on company time so I can't give it out. But you have to redirect 40-50 functions or so.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
Microsoft's Detours library might be the kind of thing you're looking for. I haven't actually used it yet, but I've looked into it some and it seems specifically designed for the kind of functionality you want.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Thanks,

I am looking into changing the exports table in the DLL instead of the imports on the EXE, makes more sence, now the problem is that the address stored there is relative to the image base, and different DLL's have different image bases :(.
On the HD you can redirect a call to a function by placing the address of a string representing a DLLname.function pair instead of the the entrypoint of the function, but I think the loader converts that into the relative,indirect or direct address of the function on the other DLL when mapping to memory.

I really want to avoid stubing wsock32.dll because 1) what happens when a new version is released with more functions? and 2, the solution would only fit wsock32.dll API monitoring, what if I want to monitor a different DLL?

That nocturnalnetwork site gave me ideas, but the approach feels a bit messy too (overwriting the first bytes of the function to call your function and then execute the nibbled bites there)

This topic is closed to new replies.

Advertisement