views:

167

answers:

4

I use Madshi's madCodeHook components to Inject a DLL in a process, and then hook a procedure/function. The problem is each time a new version of the EXE comes out the address of the functions may change. Currently the way I do it is to use Ollydbg and then hard code the address in the DLL that I inject into the process, this is very ugly and unsafe. Just wondering if there is a way knowing the the procedure's definition if I can do it dynamically.

Please note, this is not for malicious intent, I merely hook a few procedures in the target EXE for logging purposes.

A: 

It depends. By default, Delphi compiles to native machine code. There's no metadata like that for most cases. (A lot of people see that as a security feature; it keeps people from doing exactly what you're trying to do here, which can be used for evil purposes.) But any method with RTTI available will have its address in the RTTI tables. This includes all published methods, and all public methods (by default, at least) in D2010 and Delphi XE. These RTTI tables can be read, but it takes a lot of low-level knowledge to find them.

Also, some programs come with some variety of map file either in the install folder or embedded as a resource, to facilitate error reporting when something goes wrong. If this program has one, and you can figure out its format, you might be able to get method addresses from there.

Mason Wheeler
+3  A: 

Without cooperation from the program you're hooking, there's no easy way to do what you need.

Usually, that cooperation comes in the form of the module's export table, but it could also come from the program providing an API to use to ask it for the addresses of its functions.

Even if you update your DLL for every release of the hooked program, there's still no guarantee your code will work. What you're doing is exactly the sort of thing that address space layout randomization is supposed to protect against. The program might be loaded at a different address every time it runs.

I think your best bet is if you can somehow automate whatever process you use to find the functions in Ollydbg. Then you can incorporate that into your DLL so it can search for the functions itself.

Rob Kennedy
+3  A: 

If the function itsself doesn't change (a lot) you can search for the code that you need (search for the opcodes or the hex bytes) or use Madshi's disasm unit for the same purpose.

Remko
This sounds like the most logical way to do it really.I forgot about madDisasm. I'll give that a try. Thanks for the responses!
kdunlapmo
A: 

if you are using a dll u can use getprocaddress inside the dll to retrive the adress of function

Tavi
You can only do that for exported functions, which Kdunlapmo said is not the case here.
Rob Kennedy