C / C++ / MFC

25-Aug-07 13:35

To those who said running an exe from within the resource section is impossible :p I did it!

But, here's a problem that is turning my hair grey. The exe I'm running ( a console app from a console app ) loads a single dll ( FooBar.dll ), This dll in turn loads kernel32. The problem is, when the loaded exe finishes execution, ExitProcess() is called from within FooBar.dll.

Now I need to trap this and return back to my main program, but everything I have tried so far just doesn't work. I'm guessing I need to set a hook and all the tuts I have read on the subject say to create and inject a dll. Is this really necessary to hook an api call for my own process?

Perspx25-Aug-07 13:48

Perspx

25-Aug-07 13:48

If the hooking you want to do is for your own process you do not need to inject a DLL (although it is pretty fun :p) - you can call it from your application using the SetWindowsHookEx() command. For your case, however, I don't believe that you can use hooking, as ExitProcess doesn't send a message to a window - check out MSDN to read up on the SetWindowsHookEx() command.

I'm slightly puzzled; ExitProcess() calls DLL_PROCESS_DETACH in your DLL. Now if FooBar.dll is yours and you have code for it.. Why can't you write some code in the DLL_PROCESS_DETACH code in the DllMain() procedure in your DLL to see why the DLL is exiting and, if so, trapping it? Might that be a way to do it?

Hope this helps!
--PerspX

Waldermort25-Aug-07 13:59

25-Aug-07 13:59

Perspx wrote:
ExitProcess doesn't send a message to a window

This is exactly the problem I am facing, even more so with a console app.

I need some method of trapping any call to ExitProcess() from anywhere within my process and redirect the call to my own handler. The catch is, my own exe loads the address, which I can alter, the app I load from the resource also links to ExitProcess, again I can edit the IAT; AND the dll it loads also links against ExitProcess, but this time I can't edit the address.

FooBar.dll is my own and editing the code would solve the problem, but what about future apps where I might not have the code.

Is there any way I could hook Kernel32.dll directly, or would having a fake kernel32.dll in the apps directory solve the problem?

Perspx25-Aug-07 14:06

Perspx

25-Aug-07 14:06

You may be able to hook Kernel32.dll directly with SetWindowsHookEx(), and use the WH_CALLWNDPROC hook ID, assuming that this works with DLL procedures. You could then trap the DLL_PROCESS_DETACH message and do what you like with it, to stop it exiting.

Note that Windows is very annoying (understatement) when it comes to its own resources. You may not be able to link Kernel32.dll at runtime, especially if it is owned by another process or in use (there are lots of annoying "security" things with Windows). I also am not too sure if you can hook Kernel32.dll, because, again, Microsoft may have considered security here and protected the kernel from being modified or used by another application, so bear this in mind also.

Hope this helps!
--PerspX

Richard Andrew x6425-Aug-07 14:32

25-Aug-07 14:32

I actually have a lot of experience with hooking api's in the fashion made famous by Microsoft's "Detours" library.

The idea is that you patch the actual first few CPU instructions of the target function itself, rather than patching the Import Address Table.

This is good because it catches EVERY call to the function no matter from where, or how it is being called.

The patching itself is made possible by a feature of Windows memory management called "COPY_ON_WRITE", which basically means that if you write to the memory containing the target function, Windows is kind enough to copy that page of memory to a new place, and assign it to your process only.

This solves problems that arise from memory that contains DLL code being shared between processes. In effect, you process receives its own private copy of the page that was altered, while all other processes continue to use the unaltered version of that particular page of memory.

I am happy to help you implement this, if you decide you want to. Please do some web searches for the Microsoft Detours Library, and see if you can pick up what you need to know, otherwise I can help you.

--------------------------------

"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke

Waldermort25-Aug-07 14:37

25-Aug-07 14:37

That sounds just about perfect for the job. I was just reading an article about overwriting the first few bytes of the function, but the article pointed out that the system dll's are protected. The library you mentioned certainly sounds worthwhile reading about, thanks.

Richard Andrew x6425-Aug-07 15:18

25-Aug-07 15:18

WalderMort wrote:
I was just reading an article about overwriting the first few bytes of the function, but the article pointed out that the system dll's are protected.

Would you be able to point me to the article you mention? I never had any trouble hooking Kernel32.dll or Advapi32.dll, or any of the others.

Were they talking about some new protections in Vista, perhaps?

--------------------------------

"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke

Waldermort25-Aug-07 15:22

25-Aug-07 15:22

Sorry, I missread the article, it was talking about win98 problems.

I just downloaded the detours library, and it's a shame that I can't use it in a commercial app without buying a licence Frown | :(

I'm currently working on my own implementation though I doubt it would be up to the real thing.

Richard Andrew x6425-Aug-07 15:25

25-Aug-07 15:25

WalderMort wrote:
I can't use it in a commercial app without buying a licence

Oh yes, I once inquired about a commercial license, and I was told it was $10,000.

Just -slightly- out of my price range!

--------------------------------

"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke

Waldermort25-Aug-07 15:29

25-Aug-07 15:29

It's a shame boost didn't include this. That MadCodeHook you mentioned is no longer open source either Frown | :(

Luckily for me, I already have a dissasembler built into my app. All I need to do now is work out which instructions I should replace and how to redirect program flow.

Richard Andrew x6425-Aug-07 15:23

25-Aug-07 15:23

Here's a link I have from long ago:

http://madshi.net/[^]

This is a general-purpose API hooking library. You may find some use for it.

I can't vouch for it because I've never used it personally, but it might be appropriate for your job.

It's called "madCodeHook".

--------------------------------

"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke

Waldermort25-Aug-07 16:27

25-Aug-07 16:27

OK, I have managed to write to the kernel32.dll, replaced the first few bytes of ExitProcess() with a JUMP to my new function, but I've hit a snag. Any call to ExitProcess() is not supposed to return. Directly after the call in the dll there is an INT 3 instruction causing a break point to be triggered.

In pseudocode:
1. Replace the call to ExitProcess
2. Run the exe from the resource
3. exe's dll calls ExitProcess
4. Return to point in code directly after call to run exe

How could I do this?

Richard Andrew x6425-Aug-07 19:22

25-Aug-07 19:22

Ah yes, that is a unique situation.

Are you saying that the thread which is calling ExitProcess() is actually the same thread that you dispatched to the entry point of the EXE from the resource section?

If that's the case, then maybe you can simplify things by creating a second thread for running the EXE, and then when that thread calls ExitProcess(), you can do your hook processing, and then have it call ExitThread() on itself?

How does that sound?

--------------------------------

"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke

Waldermort26-Aug-07 0:12

26-Aug-07 0:12

That may work, ExitThread and ExitProcess are nearly identical so I don't need to worry about the paramaters. Plus, since i'm running an exe, I don't need to worry about shared data, provided I only allow the execution of one thread at a time.

Naveen26-Aug-07 19:31

Naveen

26-Aug-07 19:31

WalderMort wrote:
To those who said running an exe from within the resource section is impossible :p I did it!

Hi WalderMort,

Can you please share us how you did that? I would like to learn that technique. what I used to do is to extract the binary in the resource and then run it either using the createprocess or shellexecute().

Thanks

nave

[OpenedFileFinder]

Waldermort26-Aug-07 19:43

26-Aug-07 19:43

When I have perfected the code I may create an article about it, but I fear it will just open the door to script kiddies. I'm not exactly sure how virus killers work, but using this method it would be possible to compress/encrypt malicious code into a resource, then decompress/decrypt and execute all from within the memory.

So far I have only been able to run console apps. Running windowed apps is proving to be a pain in the ****! I'm currently looking at methods of creating a process. The standard API's all expect file path, but I want to create an empty process and copy the code over myself. Again, this would avoid the need to first write to disk.

Naveen26-Aug-07 19:57

Naveen

26-Aug-07 19:57

So what your now doing is just create some other process( may be in suspended mode ) and then replace the code in that application with the one in your resource?

nave

[OpenedFileFinder]

Waldermort26-Aug-07 20:05

26-Aug-07 20:05

I already thought of that, but there is no saying where the thread would be suspended. In most cases it gets suspended befone winmain is called, but the thread may have already started the initialization procedure; In which case it would be impossible to copy the code over without it crashing.

I need to mimic the winapi CreateProcess, but most of the ntdll functions are undocumented and there are very few examples of their usage.