|
I was just intended to avoid extra coding. I am not sure whether it is possible or not.
- NS -
|
|
|
|
|
There's an article here on CP about doing that in Vista. It mentions that it's possible (although harder) in previous OSes as well.
|
|
|
|
|
|
Thanks
- NS -
|
|
|
|
|
Thanks for the hint. I shall ofcourse try...
- NS -
|
|
|
|
|
Hello. How can I determine whether a directory is shared? I thought that traditional FindFirstFile and WIN32_FIND_DATA would provide me the answer, but it doesn't.
Thanks in advance.
Hope is the negation of reality - Raistlin Majere
|
|
|
|
|
|
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
|
|
|
|
|