|
|
Thanks!
Hope is the negation of reality - Raistlin Majere
|
|
|
|
|
You can use NetShareEnum API
AJay
|
|
|
|
|
I have created a custom message for one of my windows. For the sake of argument lets call it CUSTOM_MESSAGE. So I use the sendmessage code as follows:
char *text;
SendMessage(hwnd, CUSTOM_MESSAGE, 0, (LPARAM)text);
In the destination window's message procedure, I want it to set the value of text (the LPARAM value), and make this value availible to the previous bit of code, as shown below
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
...
switch(msg)
{
...
case CUSTOM_MESSAGE:
//Set the value of the LPARAM and allow the previous bit of code to receive and use this value
break;
...
}
...
}
So, once SendMessage() has been called, the other bit of code can use the text variable, which has been set by the destination window's window procedure, as shown:
char *text;
SendMessage(hwnd, CUSTOM_MESSAGE, 0, (LPARAM)text);
MessageBox(NULL, text, "Message", MB_OK);
How would I go about doing this?
Thanks for your help!
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
You should allocate memory for the LPARAM parameter before sending message,because you can't access to NULL pointer.
char *text;
SendMessage(hwnd, CUSTOM_MESSAGE, 0, (LPARAM)text);//text==NULL
|
|
|
|
|
Good point. Thanks 
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
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?
|
|
|
|
|
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
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
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?
|
|
|
|
|
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
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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  I'm currently working on my own implementation though I doubt it would be up to the real thing.
|
|
|
|
|
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
|
|
|
|
|
It's a shame boost didn't include this. That MadCodeHook you mentioned is no longer open source either
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.
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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?
|
|
|
|
|
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.
|
|
|
|
|
ok. Anyway best wishes for your research. Will be waiting for your article. 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
