Hello all.

I am in need of advice.
My goal is to find which module loaded in any process memory space exports particular function(API).
I see two ways of doing it.
First would be to inspect exports table of a every module loaded in other process memory by using ReadProcessMemory...
Second one is to retreive path of every module, load it with LoadLibrary and
simply look by GetProcAddress.

Which way is to go or is there maybe other way?

You can get loaded modules information by toolhelp32 functions so ReadProcessMemory is not needed and that way you get also dynamically loaded modules. '-'

Hm, i can't find any info on how can toolhelp32 functions retreive other process module exported functions...

Am i wearing sunglasses?

Do you want to know specifically what another process uses (imports) from those exports or do you want to know ALL the functions that are exported?

In the second case, you just have to parse the export table of the module.

You can get fancy, but this will work: From your own process' context, you get the module's name then you could load the module from disk or LoadLibrary() on it and then in both cases parse the export table. For each of the exported entry, you will get an RVA. To that RVA, you add the image base that toolhelp function returned.

(Your GetProcAddress approach will not work directly. The VA returned by your GetProcAddress call is in your process' context. You probably want the VA in the other process' context)

Also, depending on what you want to do, you might have to be careful about forwarded exports.

Disclaimer: I don't know dbghelp/imagehlp/psapi functions. I don't know if this feature is provided already, but this do-it-yourself isn't very hard.

If you content yourself with static imports, then you may want to use a tool like 'Depends'. It will tell you what your module (executable or dll) imports from every other module it depends on.

Peres

I want to find out which module exports one(or two) particular function. Let's say i wan't to know who exactly exports CloseHandle function.


That is exactly what i' am doing now... And yes, i calculate address of function correctly...

As said before I am in dilema, which metod to use...
Should I parse PE(exports table ) of module from its own memory in another process or load it in mine, GetProcAddress and do the math... Or mybe read it from HDD...



I did not think of that. But function i am looking for should never be forwarded...


Thanks, i look at this promptly...

toolhelp32 was to retrieve the loaded dll name without going throught ReadProcessMemory

Hello:

Another way to have a look of the exported functions is in a static mode:

- Using Wdasm32 tool, it lets you examine which the exported functions are.
- Using iczelion tuts; exactly pe-tut07.exe shows you the exported funtions of an exe/dll. Get it at:
hxxp://win32asm.cjb.net/ (http://)

Cheers


Nacho_dj

I didn't mention that before but what about a packed dll?

Even if packed export directory should be available i think '-'

Just read the DLL from the disk and parse the exports table. Search on *.DLL if you want to look through all of them.

OK, then you should use OllyDbg to load it.
When loaded, it has to appear uncompressed. Then go to the 'Memory' contextual menu option.
Then, go to 'PE Header' of the module with the name of the DLL.
Click twice on it to open.
Look for the export data there and go to see which the exported functions are.

It is a very little complicated, but with a little of care you should find out all the exported functions name.

Cheers

Nacho_dj

I thought the point of this was to have a method to do it automatically. I don't think that if you have to open olly dbg and select the file & menus that it is any useful.

----
Traditionally, packers have avoided tampering with the export table of DLLs (and I guess EXEs as well). It probably has to do with the unpredictable nature of when DLLs are actually loaded in memory. I've never seen any example of a packer modying the export table.

I think the best a packer could do is to modify the entry point addresses to its own protected functions (but the entrypoints would still be valid no matter what). I don't think there is much more it can do.

I totally agree.

I have given you a just-in-time way of doing what was asked for in this Thread.

But of course, if required usually, it is better building a tool for this task.

Not very difficult. It must consist of a loader, and when the process is totally loaded, you only need to examine (with that tool) which the exported function names are. You can find out where the export table is in the PE header.

Cheers

Nacho_dj

I've done it little bit different. My tool is now enumerating all processes and their modules. Then with ReadProcessMemory I read
exports table and look for what i'am searching for... It's working.

Let me say one thing i encountered while my tool was loading every module
of other process in it's own context(loadlib) and looking for function with getprocadd. While testing it happend to me that my app will just terminate while doing FreeLibrary on just loaded module.
Debugging with olly that dll I saw a strange thing, in some point of time(because of some exception) dll will call ExitProcess.
As i saw no way of stoping it from doing that i asked here for advice...

Now, I read exports table and everything is working fine.

Thank you all for your eforts.

REgards

Hello:

Congratulations! You did it!

As you have seen, always there are lots of ways to do a certain thing when programming.

Anyway, I show a way to stop the appli in OllyDbg before ExitProcess can execute.

In the "Debugging Options" window, go to "Exceptions" and Check all the options.
Now, go to "Events" and check "Break on new module (DLL)".

OK, load the application and run it with F9. It has to stop in every new module loaded. You could have the control of the debugging.


Cheers

Nacho_dj

I am aware of that doing that with olly, it's not strange to me; I am using it for pretty much time now.
But still, if I want not to allow any dll to call ExitProcess on me, my tool would need to be a debugger... Than i would need to process every module imports
table and look for ExitProcess.
Than I would need to somehow disallow dll to call it(is it BP on ExitProcess, or all references to it or something).
Anyway just knowing that DLL is loaded is NOT enough in any case, mine(remember, I am the one who is intentionally loading DLL with LoadLibrary) or doing it with OD like you said...

OK, while you are finding how this ExitProcess api is reached, you could test removing Freelibrary of all the loaded DLL, and when the tool has finished its work, do the Freelibrary for all of them.

What do you think about it?

Cheers

Nacho_dj