Hooking exit process
in [Win32 Kernel]
|
From: Jerome on 14 Jan 2010 12:35 Thanx Bruce, it helped me to fix the exact same problem :) After many hours i could not figure out why WriteProcessMemory worked with one EXE but not with another one. so i just used : ----------------------- BOOL res = VirtualProtect(ppfn, pfnLen, PAGE_READWRITE, &oldprotect); if(res && oldprotect != NULL) { res = WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, pfnLen, NULL); res = VirtualProtect(ppfn, pfnLen, oldprotect, 0); } ----------------------- It's probably not the good way to do it, but it works like a charm ;) Bruce. wrote: Re: Hooking exit process 20-Mar-08 "Volodymyr M. Shcherbyna" <v_scherbina(a)online.mvps.org> wrote in message news:%232yLtRqiIHA.5968(a)TK2MSFTNGP04.phx.gbl... That helped!! I'm now able to set my replacement ExitProcess from the "bad" exe. So that leaves me with the question, why did I have a "bad" exe and a "good" exe? By playing with that API I could tell that the memory for the bad exe was set to PAGE_READONLY, while the good exe was set to PAGE_READWRITE. VirtualProtect allowed me to alter the bad one to PAGE_READWRITE and then I could write it. Anyone have any idea why there would be a difference from one exe to the next exe? Thanks Roger and Volodymyr, and everyone else! Bruce. Previous Posts In This Thread: On Wednesday, March 19, 2008 6:04 PM Bruce. wrote: Hooking exit process As a continuation of my other thread here, I am now trying to hook ExitProcess() so a routine up in my dll will be called at the time the exe is unloading BEFORE the DllMain is called with DLL_PROCESS_DETACH is called. I used the example code from http://www.jamajm.com/e-books/cpprichter/HTML/ch22j.htm which shows how to hook ExitProcess. I pasted that code in a test exe and it works very nicely. MyExitProcess() code is always called when the exe exits. Perfect so far. So I pasted the code in to my dll and MyExitProcess() is never called. The registering of the hook seems to work perfectly, but it never gets called. I have tried scanning for both the exe name and the dll name, and neither works. In both cases it finds the right entry, installs the hook, but MyExitProcess in the dll is never called when the exe exits. Any idea what I'm doing wrong? Why would hooking ExitProcess in this code work in an exe but not in a dll loaded by that exe? Bruce. On Wednesday, March 19, 2008 10:07 PM Bruce. wrote: Re: Hooking exit process "Bruce." <noone(a)example.net> wrote in message news:eVZx50giIHA.5088(a)TK2MSFTNGP02.phx.gbl... The mystery deepens. I have 2 exe's. exeOld and exeNew. exeOld has been around for probably 15 years. exeNew I just made. Both call my dll that registers a ExitProcess hook in DllMain. When I run exeNew, the hook is called when the exe unloads. When I run exeOld, the hook is never called when the exe exits. Same exact dll in both cases. I now have about 99.99% of the code in both exes commented out yet the problem remains. Something is different between the 2 exe's but so far it has me stumped. Bruce. On Wednesday, March 19, 2008 11:27 PM Alexander Grigoriev wrote: See my post in the previous thread. See my post in the previous thread. You better avoid hooking; these hacks will one day bite you in the rear. In DLL_DETACH_PROCESS on ExitProcess you cannot do any meaningful teardown. You don't actually need any. You only need to tell that your DllMain is called in response to ExitProcess, and in this case just return. Your thread will die in peace then. Only in case of explicit FreeLibrary you'll need to stop your thread, which will unload the DLL. "Bruce." <noone(a)example.net> wrote in message news:eVZx50giIHA.5088(a)TK2MSFTNGP02.phx.gbl... On Thursday, March 20, 2008 5:13 AM Bruce. wrote: Re: Hooking exit process it is not dying in peace. The thread stops running as soon as DLL_DETACH_PROCESS is called and never again runs to completion. My thread never completes. Bruce. On Thursday, March 20, 2008 5:26 AM Bruce. wrote: Re: Hooking exit process On your actual question, my first try would be: - logging all the addresses patched by your hook - running under a debugger - place a breakpt at Kernel32!ExitProcess - work back up the stack to find out how you got there Thanks Riger. I am running in the debugger. How to I place a break at Kernel32!ExitProcess? I don't know what module that's in? Bruce. On Thursday, March 20, 2008 6:08 AM Volodymyr M. Shcherbyna wrote: Why in the first place you're trying to get this information using hackery Why in the first place you're trying to get this information using hackery approach? In kernel mode driver you can use documented API: PsSetCreateProcessNotifyRoutine && PsSetLoadImageNotifyRoutine to setup callback for processes creation / termination. Depends on task, but you can do a small driver to process processes creation / termination (you also is able to get notifications for threads) and pass it to user mode if neccessary. -- V. This posting is provided "AS IS" with no warranties, and confers no rights. "Bruce." <noone(a)example.net> wrote in message news:%23SUh5xmiIHA.1212(a)TK2MSFTNGP05.phx.gbl... On Thursday, March 20, 2008 9:15 AM Bruce. wrote: Re: Hooking exit process <roger.orr(a)gmail.com> wrote in message news:6f61f3f1-5f44-4568-a193-7f67a21cd66d(a)c65g2000hsa.googlegroups.com... Thanks so much Roger. There's so much of this I never would have been able to figure out on myself. That experiment yields these call stacks. Here is my program callled HookExitProcess that calls (my dll) dba32dll.dll and it installs the ExitProcess hook. When run I get this: kernal32.dll!ExitProcess dba32dll.dll!MyExitProcess HookExitProcess.exe!__crtExitProcess HookExitProcess.exe!doexit HookExitProcess.exe!exit HookExitProcess.exe!main So, you can see that dll32dll did in fact installi the hook and my routine MyExitProcess is part of the call stack. However, here is my other older program, called dba.exe. It does exactly the same thing, calling dba32dll, and I've watched it successfully install the hook. Yet my exit routine is not part of the call stack. kernal32.dll!ExitProcess dba.exe!__crtExitProcess dba.exe!doexit dba.exe!exit dba.exe!main Could someone be resetting the hook after I set it? Bruce. On Thursday, March 20, 2008 9:19 AM Bruce. wrote: Re: Hooking exit process I do appreciate your reply and suggestion, but writing a driver is WAY beyond my level of expertise. Bruce. On Thursday, March 20, 2008 9:28 AM Alexander Grigoriev wrote: You should not wait for the thread to complete. You should not wait for the thread to complete. When handling DLL_DETACH_PROCESS on ExitProcess (lpReserved!=NULL), do nothing, just return. On Thursday, March 20, 2008 9:30 AM Volodymyr M. Shcherbyna wrote: Time to fix all bugs and possible drawbacks of your current solution (imagine Time to fix all bugs and possible drawbacks of your current solution (imagine your software deployed for thousands of machines) will be less and less smaller then writing + testing a small nt driver using a documented and fully supported approach. -- V. This posting is provided "AS IS" with no warranties, and confers no rights. "Bruce." <noone(a)example.net> wrote in message news:udG88zoiIHA.5504(a)TK2MSFTNGP05.phx.gbl... On Thursday, March 20, 2008 10:26 AM Bruce. wrote: Re: Hooking exit process Whether I wait or not, the thread does not complete. I need it to complete to maintain the integrity of the objects it is accessing. Bruce. On Thursday, March 20, 2008 10:32 AM Bruce. wrote: Re: Hooking exit process <roger.orr(a)gmail.com> wrote in message news:3bdc4adb-5cac-4b67-b0ab-1a8b63d24eb6(a)i29g2000prf.googlegroups.com... On Mar 20, 1:15 pm, "Bruce." <no...(a)example.net> wrote: Roger, you're a genious. The code I "borrowed" from that web site wasn't checking the return of WriteProcessMemory(). Well, guess what, it's failing but only in 1 of my 2 exes. BOOL fStatus = WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, sizeof( pfnNew ), NULL ); if( !fStatus ) { rc = GetLastError(); } In the case of the bad exe (99.9% of which has been commented out), fStatus is false and rc is 998. 998 is: error 998, Invalid access to memory location, ERROR_NOACCESS In the good exe, fStatus is true. So why does the write succeed in one of my test programs but fail in the other? Do programs have rights? Bruce. On Thursday, March 20, 2008 11:54 AM Bruce. wrote: Re: Hooking exit process <roger.orr(a)gmail.com> wrote in message news:a8316775-e5ad-4afb-8b8f-01b78e5a8a14(a)e10g2000prf.googlegroups.com... On Mar 20, 2:32 pm, "Bruce." <no...(a)example.net> wrote: Here are the comparison between the exe that works and the one that doesn't as displayed by the debugger. doesn't work: ppfn 0x0041902c __imp__ExitProcess@4 int (void)* * does work: ppfn 0x0043a364 __imp__ExitProcess@4 int (void)* * It's looking like for some darn reason I don't have rights to write my own memory. I can't think of any other reason to get an error 998. The API says I must have PROCESS_VM_WRITE and PROCESS_VM_OPERATION access to the process. My call is simply: WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, sizeof( pfnNew ), NULL ); How can I check if I have those rights, comparing the working program with the failing program? If I don't have those rights, how do I get them? Bruce. On Thursday, March 20, 2008 12:06 PM Volodymyr M. Shcherbyna wrote: Use VirtualProtect (...)-- V. Use VirtualProtect (...) -- V. This posting is provided "AS IS" with no warranties, and confers no rights. On Thursday, March 20, 2008 1:06 PM Volodymyr M. Shcherbyna wrote: Most likely, your code did not log the errors which were returned by Most likely, your code did not log the errors which were returned by WriteMemory, so you never noticed that it fails ;) -- V. This posting is provided "AS IS" with no warranties, and confers no rights. <roger.orr(a)gmail.com> wrote in message news:53be1cb1-f2a3-4ea2-9769-506baffb3c5e(a)e10g2000prf.googlegroups.com... On Mar 20, 4:06 pm, "Volodymyr M. Shcherbyna" <v_scherb...(a)online.mvps.org> wrote: You live and learn. I've used WriteProcessMemory before and never had any problems. It worked for all the code and data I've tried it on. I've just tried - and it fails if the target is a readonly page, although it is OK for execute_read. I'd always assumed before that WriteProcessMemory() sorted the page protection out behind the scenes. Regards, Roger. On Thursday, March 20, 2008 1:36 PM Bruce. wrote: Re: Hooking exit process "Volodymyr M. Shcherbyna" <v_scherbina(a)online.mvps.org> wrote in message news:%232yLtRqiIHA.5968(a)TK2MSFTNGP04.phx.gbl... That helped!! I'm now able to set my replacement ExitProcess from the "bad" exe. So that leaves me with the question, why did I have a "bad" exe and a "good" exe? By playing with that API I could tell that the memory for the bad exe was set to PAGE_READONLY, while the good exe was set to PAGE_READWRITE. VirtualProtect allowed me to alter the bad one to PAGE_READWRITE and then I could write it. Anyone have any idea why there would be a difference from one exe to the next exe? Thanks Roger and Volodymyr, and everyone else! Bruce. On Thursday, March 20, 2008 4:17 PM Bruce. wrote: Re: Hooking exit process "Volodymyr M. Shcherbyna" <v_scherbina(a)online.mvps.org> wrote in message news:eEwngJniIHA.3400(a)TK2MSFTNGP03.phx.gbl... Would this work in my environment? We distribute an API in the form of a DLL (it's much more but let's keep it simple). Whatever solution you envision here can not entail requiring our customers to modify their programs. And we have no way of knowing what the program names of what they write are. They could be console, GUI, COM, C, VB, exe, dll, whatever. Bruce. On Thursday, March 20, 2008 9:59 PM Alexander Grigoriev wrote: After ExitProcess is called, there is no concept of "objects integrity". After ExitProcess is called, there is no concept of "objects integrity". Your process is under last rites and is about to stop breathing. Forget about the thread, it's a goner. It's as if your process was killed by TerminateProcess. "Bruce." <noone(a)example.net> wrote in message news:ObL6aZpiIHA.5088(a)TK2MSFTNGP02.phx.gbl... On Friday, March 21, 2008 6:14 AM Bruce. wrote: Re: Hooking exit process "Alexander Grigoriev" <alegr(a)earthlink.net> wrote in message news:eeLQ1hviIHA.3740(a)TK2MSFTNGP03.phx.gbl... Hooking ExitProcess did 99% of what I wanted. The counts and objects are now being cleaned up properly when normally exiting a program. If a user decides to use the task manager to kill the process, then yes, things can go wrong, but at least the normal case is handled now. Bruce. On Friday, March 21, 2008 5:40 PM Ben Voigt [C++ MVP] wrote: Bruce. Bruce. wrote: Your library would, at startup, open a device created by the driver and issue an IOCTL. The driver would then set a callback for the termination of that process. Or just forget about the process exit notify routine, leak the open handle to the driver's device. At process termination it will get closed automatically, your driver will get notified. Note that you can do the same thing in user mode using pipes or any other IPC mechanism which notifies one end when the other closes... and you don't even need admin rights for this. On Saturday, March 22, 2008 12:05 AM Pavel Lebedinsky [MSFT] wrote: In the read/execute case, WriteProcessMemory automatically changesprotection In the read/execute case, WriteProcessMemory automatically changes protection to writeable. My guess is that this was done to make life easier for debuggers (e.g. setting breakpoints). This behavior however is not documented so you should not depend on it. Just use VirtualProtect in all cases. -- This posting is provided "AS IS" with no warranties, and confers no rights. On Saturday, March 22, 2008 10:06 AM roger.or wrote: Re: Hooking exit process On Mar 20, 3:27=A0am, "Alexander Grigoriev" <al...(a)earthlink.net> wrote: I agree. What tidy up is actually needed (other than the thread itself?) There may be better ways than trying to get the thread to do it. On your actual question, my first try would be: - logging all the addresses patched by your hook - running under a debugger - place a breakpt at Kernel32!ExitProcess - work back up the stack to find out how you got there Regards, Roger. On Saturday, March 22, 2008 10:06 AM roger.or wrote: Re: Hooking exit process On Mar 20, 9:26=A0am, "Bruce." <no...(a)example.net> wrote: t I guess you're not using windbg then :-) It is bp kernel32!ExitProcess in that debugger. Format is module ! entry In VS 2005 ensure you've selected DLL exports: Tools -> Options -> Debugging -> Native Click Load DLL exports Then type: ExitProcess,,kernel32 into the breakpoint location. Regards, Roger. On Saturday, March 22, 2008 10:06 AM roger.or wrote: Re: Hooking exit process On Mar 20, 1:15=A0pm, "Bruce." <no...(a)example.net> wrote: Possibly - but unlikely. More likely is a) You're not actually successfully writing the hook b) The old program is getting the entry point another way If you disassemble the code in __crtExitProcess you should be able to see where it goes. You'll probably see something like: __crtExitProcess: push dword ptr[esp+4] call __crtCorExitProcess pop ecx push dword ptr [esp+4] call dword ptr [_imp__ExitProcess (41D1C4h)] And the contents of the word at 0x41D1C4 will be the address of ExitProcess -- this is the word you should have modified earlier. Does the instrumented patching code give you the same address? Set a data breakpoint on this address to catch writers. Regards, Roger. PS You've still not said what you need to do in the closedown. Might be better to investigate that, rather than going further along this route.. On Saturday, March 22, 2008 10:06 AM roger.or wrote: Re: Hooking exit process Yes they do, but you usually have rights on yourself... I'd carefully check the address you are trying to write to. Regards Roger. On Saturday, March 22, 2008 10:06 AM roger.or wrote: Re: Hooking exit process On Mar 20, 4:06=A0pm, "Volodymyr M. Shcherbyna" <v_scherb...(a)online.mvps.org> wrote: You live and learn. I've used WriteProcessMemory before and never had any problems. It worked for all the code and data I've tried it on. I've just tried - and it fails if the target is a readonly page, although it is OK for execute_read. I'd always assumed before that WriteProcessMemory() sorted the page protection out behind the scenes. Regards, Roger. On Saturday, March 22, 2008 10:06 AM roger.or wrote: Re: Hooking exit process On 20 Mar, 17:06, "Volodymyr M. Shcherbyna" <v_scherb...(a)online.mvps.org> wrote: I've just been lucky :-) I use it to write to:- + Read/Write memory I've allocated in the target process + Read/Execute code in target process and these both work. Still puzzled that read only doesn't work when read/execute does - may be a wierd Intel protection mask issue. Roger. On Thursday, January 14, 2010 12:33 PM Jerome wrote: VirtualProtect solution Thanx Bruce, it helped me to fix the exact same problem :) After many hours i could not figure out why WriteProcessMemory worked with one EXE but not with another one. so i just used : ----------------------- BOOL res = VirtualProtect(ppfn, pfnLen, PAGE_READWRITE, &oldprotect); if(res && oldprotect != NULL) { res = WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, pfnLen, NULL); res = VirtualProtect(ppfn, pfnLen, oldprotect, 0); } ----------------------- It's probably not the good way to do it, but it works like a charm ;) On Thursday, January 14, 2010 12:34 PM Jerome wrote: VirtualProtect solution Thanx Bruce, it helped me to fix the exact same problem :) After many hours i could not figure out why WriteProcessMemory worked with one EXE but not with another one. so i just used : ----------------------- BOOL res = VirtualProtect(ppfn, pfnLen, PAGE_READWRITE, &oldprotect); if(res && oldprotect != NULL) { res = WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, pfnLen, NULL); res = VirtualProtect(ppfn, pfnLen, oldprotect, 0); } ----------------------- It's probably not the good way to do it, but it works like a charm ;) Submitted via EggHeadCafe - Software Developer Portal of Choice IE username:password @domain.com behavior http://www.eggheadcafe.com/tutorials/aspnet/dac20244-3179-45f1-9ae5-9d4aa87d6b14/ie-usernamepassword-dom.aspx
From: Bruce. on 14 Jan 2010 15:20 Your welcome Jerome. I never was able to handle the case of the exe getting killed in the task manager, but at least this handles the case of an intentional exit. Bruce. <Jerome> wrote in message news:2010114123534jayjayj67(a)hotmail.com... > Thanx Bruce, it helped me to fix the exact same problem :) > After many hours i could not figure out why WriteProcessMemory worked with > one EXE but not with another one. > > so i just used : > > ----------------------- > BOOL res = VirtualProtect(ppfn, pfnLen, PAGE_READWRITE, &oldprotect); > if(res && oldprotect != NULL) > { > res = WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, pfnLen, > NULL); > res = VirtualProtect(ppfn, pfnLen, oldprotect, 0); > } > ----------------------- > > It's probably not the good way to do it, but it works like a charm ;) > > > > Bruce. wrote: > > Re: Hooking exit process > 20-Mar-08 > > "Volodymyr M. Shcherbyna" <v_scherbina(a)online.mvps.org> wrote in message > news:%232yLtRqiIHA.5968(a)TK2MSFTNGP04.phx.gbl... > > That helped!! I'm now able to set my replacement ExitProcess from the > "bad" > exe. > > So that leaves me with the question, why did I have a "bad" exe and a > "good" > exe? > > By playing with that API I could tell that the memory for the bad exe was > set to PAGE_READONLY, while the good exe was set to PAGE_READWRITE. > > VirtualProtect allowed me to alter the bad one to PAGE_READWRITE and then > I > could write it. > > Anyone have any idea why there would be a difference from one exe to the > next exe? > > Thanks Roger and Volodymyr, and everyone else! > > Bruce. > > Previous Posts In This Thread: > > On Wednesday, March 19, 2008 6:04 PM > Bruce. wrote: > > Hooking exit process > As a continuation of my other thread here, I am now trying to hook > ExitProcess() so a routine up in my dll will be called at the time the exe > is unloading BEFORE the DllMain is called with DLL_PROCESS_DETACH is > called. > > I used the example code from > > http://www.jamajm.com/e-books/cpprichter/HTML/ch22j.htm > > which shows how to hook ExitProcess. I pasted that code in a test exe and > it works very nicely. MyExitProcess() code is always called when the exe > exits. Perfect so far. > > So I pasted the code in to my dll and MyExitProcess() is never called. > The > registering of the hook seems to work perfectly, but it never gets called. > > I have tried scanning for both the exe name and the dll name, and neither > works. In both cases it finds the right entry, installs the hook, but > MyExitProcess in the dll is never called when the exe exits. > > Any idea what I'm doing wrong? Why would hooking ExitProcess in this code > work in an exe but not in a dll loaded by that exe? > > Bruce. > > On Wednesday, March 19, 2008 10:07 PM > Bruce. wrote: > > Re: Hooking exit process > "Bruce." <noone(a)example.net> wrote in message > news:eVZx50giIHA.5088(a)TK2MSFTNGP02.phx.gbl... > > The mystery deepens. I have 2 exe's. exeOld and exeNew. exeOld has been > around for probably 15 years. exeNew I just made. Both call my dll that > registers a ExitProcess hook in DllMain. > > When I run exeNew, the hook is called when the exe unloads. When I run > exeOld, the hook is never called when the exe exits. Same exact dll in > both > cases. > > I now have about 99.99% of the code in both exes commented out yet the > problem remains. Something is different between the 2 exe's but so far it > has me stumped. > > Bruce. > > On Wednesday, March 19, 2008 11:27 PM > Alexander Grigoriev wrote: > > See my post in the previous thread. > See my post in the previous thread. You better avoid hooking; these hacks > will one day bite you in the rear. > > In DLL_DETACH_PROCESS on ExitProcess you cannot do any meaningful > teardown. > You don't actually need any. You only need to tell that your DllMain is > called in response to ExitProcess, and in this case just return. Your > thread > will die in peace then. Only in case of explicit FreeLibrary you'll need > to > stop your thread, which will unload the DLL. > > "Bruce." <noone(a)example.net> wrote in message > news:eVZx50giIHA.5088(a)TK2MSFTNGP02.phx.gbl... > > On Thursday, March 20, 2008 5:13 AM > Bruce. wrote: > > Re: Hooking exit process > it is not dying in peace. The thread stops running as soon as > DLL_DETACH_PROCESS is called and never again runs to completion. My > thread > never completes. > > Bruce. > > On Thursday, March 20, 2008 5:26 AM > Bruce. wrote: > > Re: Hooking exit process > On your actual question, my first try would be: > - logging all the addresses patched by your hook > - running under a debugger > - place a breakpt at Kernel32!ExitProcess > - work back up the stack to find out how you got there > > Thanks Riger. I am running in the debugger. How to I place a break at > Kernel32!ExitProcess? I don't know what module that's in? > > Bruce. > > On Thursday, March 20, 2008 6:08 AM > Volodymyr M. Shcherbyna wrote: > > Why in the first place you're trying to get this information using hackery > Why in the first place you're trying to get this information using hackery > approach? In kernel mode driver you can use documented API: > PsSetCreateProcessNotifyRoutine && PsSetLoadImageNotifyRoutine to setup > callback for processes creation / termination. Depends on task, but you > can > do a small driver to process processes creation / termination (you also is > able to get notifications for threads) and pass it to user mode if > neccessary. > > -- > V. > This posting is provided "AS IS" with no warranties, and confers no > rights. > "Bruce." <noone(a)example.net> wrote in message > news:%23SUh5xmiIHA.1212(a)TK2MSFTNGP05.phx.gbl... > > On Thursday, March 20, 2008 9:15 AM > Bruce. wrote: > > Re: Hooking exit process > <roger.orr(a)gmail.com> wrote in message > news:6f61f3f1-5f44-4568-a193-7f67a21cd66d(a)c65g2000hsa.googlegroups.com... > > Thanks so much Roger. There's so much of this I never would have been > able > to figure out on myself. > > That experiment yields these call stacks. Here is my program callled > HookExitProcess that calls (my dll) dba32dll.dll and it installs the > ExitProcess hook. When run I get this: > > kernal32.dll!ExitProcess > dba32dll.dll!MyExitProcess > HookExitProcess.exe!__crtExitProcess > HookExitProcess.exe!doexit > HookExitProcess.exe!exit > HookExitProcess.exe!main > > So, you can see that dll32dll did in fact installi the hook and my routine > MyExitProcess is part of the call stack. > > However, here is my other older program, called dba.exe. It does exactly > the same thing, calling dba32dll, and I've watched it successfully install > the hook. Yet my exit routine is not part of the call stack. > > kernal32.dll!ExitProcess > dba.exe!__crtExitProcess > dba.exe!doexit > dba.exe!exit > dba.exe!main > > Could someone be resetting the hook after I set it? > > Bruce. > > On Thursday, March 20, 2008 9:19 AM > Bruce. wrote: > > Re: Hooking exit process > I do appreciate your reply and suggestion, but writing a driver is WAY > beyond my level of expertise. > > Bruce. > > On Thursday, March 20, 2008 9:28 AM > Alexander Grigoriev wrote: > > You should not wait for the thread to complete. > You should not wait for the thread to complete. When handling > DLL_DETACH_PROCESS on ExitProcess (lpReserved!=NULL), do nothing, just > return. > > On Thursday, March 20, 2008 9:30 AM > Volodymyr M. Shcherbyna wrote: > > Time to fix all bugs and possible drawbacks of your current solution > (imagine > Time to fix all bugs and possible drawbacks of your current solution > (imagine your software deployed for thousands of machines) will be less > and > less smaller then writing + testing a small nt driver using a documented > and > fully supported approach. > > -- > V. > This posting is provided "AS IS" with no warranties, and confers no > rights. > "Bruce." <noone(a)example.net> wrote in message > news:udG88zoiIHA.5504(a)TK2MSFTNGP05.phx.gbl... > > On Thursday, March 20, 2008 10:26 AM > Bruce. wrote: > > Re: Hooking exit process > Whether I wait or not, the thread does not complete. I need it to > complete > to maintain the integrity of the objects it is accessing. > > Bruce. > > On Thursday, March 20, 2008 10:32 AM > Bruce. wrote: > > Re: Hooking exit process > <roger.orr(a)gmail.com> wrote in message > news:3bdc4adb-5cac-4b67-b0ab-1a8b63d24eb6(a)i29g2000prf.googlegroups.com... > On Mar 20, 1:15 pm, "Bruce." <no...(a)example.net> wrote: > > > > Roger, you're a genious. The code I "borrowed" from that web site wasn't > checking the return of WriteProcessMemory(). Well, guess what, it's > failing > but only in 1 of my 2 exes. > > BOOL fStatus = WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, > sizeof( pfnNew ), NULL ); > if( !fStatus ) > { > rc = GetLastError(); > } > > In the case of the bad exe (99.9% of which has been commented out), > fStatus > is false and rc is 998. 998 is: > > error 998, Invalid access to memory location, ERROR_NOACCESS > > In the good exe, fStatus is true. > > So why does the write succeed in one of my test programs but fail in the > other? Do programs have rights? > > Bruce. > > On Thursday, March 20, 2008 11:54 AM > Bruce. wrote: > > Re: Hooking exit process > <roger.orr(a)gmail.com> wrote in message > news:a8316775-e5ad-4afb-8b8f-01b78e5a8a14(a)e10g2000prf.googlegroups.com... > On Mar 20, 2:32 pm, "Bruce." <no...(a)example.net> wrote: > > > Here are the comparison between the exe that works and the one that > doesn't > as displayed by the debugger. > > doesn't work: ppfn 0x0041902c __imp__ExitProcess@4 int (void)* * > does work: ppfn 0x0043a364 __imp__ExitProcess@4 int (void)* * > > It's looking like for some darn reason I don't have rights to write my own > memory. I can't think of any other reason to get an error 998. The API > says I must have PROCESS_VM_WRITE and PROCESS_VM_OPERATION access to the > process. > > My call is simply: > > WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, sizeof( pfnNew ), > NULL ); > > How can I check if I have those rights, comparing the working program with > the failing program? If I don't have those rights, how do I get them? > > Bruce. > > On Thursday, March 20, 2008 12:06 PM > Volodymyr M. Shcherbyna wrote: > > Use VirtualProtect (...)-- V. > Use VirtualProtect (...) > > -- > V. > This posting is provided "AS IS" with no warranties, and confers no > rights. > > On Thursday, March 20, 2008 1:06 PM > Volodymyr M. Shcherbyna wrote: > > Most likely, your code did not log the errors which were returned by > Most likely, your code did not log the errors which were returned by > WriteMemory, so you never noticed that it fails ;) > > -- > V. > This posting is provided "AS IS" with no warranties, and confers no > rights. > <roger.orr(a)gmail.com> wrote in message > news:53be1cb1-f2a3-4ea2-9769-506baffb3c5e(a)e10g2000prf.googlegroups.com... > On Mar 20, 4:06 pm, "Volodymyr M. Shcherbyna" > <v_scherb...(a)online.mvps.org> wrote: > > You live and learn. > > I've used WriteProcessMemory before and never had any problems. > It worked for all the code and data I've tried it on. > > I've just tried - and it fails if the target is a readonly page, > although it is OK for execute_read. > > I'd always assumed before that WriteProcessMemory() sorted > the page protection out behind the scenes. > > Regards, > Roger. > > On Thursday, March 20, 2008 1:36 PM > Bruce. wrote: > > Re: Hooking exit process > "Volodymyr M. Shcherbyna" <v_scherbina(a)online.mvps.org> wrote in message > news:%232yLtRqiIHA.5968(a)TK2MSFTNGP04.phx.gbl... > > That helped!! I'm now able to set my replacement ExitProcess from the > "bad" > exe. > > So that leaves me with the question, why did I have a "bad" exe and a > "good" > exe? > > By playing with that API I could tell that the memory for the bad exe was > set to PAGE_READONLY, while the good exe was set to PAGE_READWRITE. > > VirtualProtect allowed me to alter the bad one to PAGE_READWRITE and then > I > could write it. > > Anyone have any idea why there would be a difference from one exe to the > next exe? > > Thanks Roger and Volodymyr, and everyone else! > > Bruce. > > On Thursday, March 20, 2008 4:17 PM > Bruce. wrote: > > Re: Hooking exit process > "Volodymyr M. Shcherbyna" <v_scherbina(a)online.mvps.org> wrote in message > news:eEwngJniIHA.3400(a)TK2MSFTNGP03.phx.gbl... > > Would this work in my environment? We distribute an API in the form of a > DLL (it's much more but let's keep it simple). Whatever solution you > envision here can not entail requiring our customers to modify their > programs. And we have no way of knowing what the program names of what > they > write are. They could be console, GUI, COM, C, VB, exe, dll, whatever. > > Bruce. > > On Thursday, March 20, 2008 9:59 PM > Alexander Grigoriev wrote: > > After ExitProcess is called, there is no concept of "objects integrity". > After ExitProcess is called, there is no concept of "objects integrity". > Your process is under last rites and is about to stop breathing. Forget > about the thread, it's a goner. It's as if your process was killed by > TerminateProcess. > > "Bruce." <noone(a)example.net> wrote in message > news:ObL6aZpiIHA.5088(a)TK2MSFTNGP02.phx.gbl... > > On Friday, March 21, 2008 6:14 AM > Bruce. wrote: > > Re: Hooking exit process > "Alexander Grigoriev" <alegr(a)earthlink.net> wrote in message > news:eeLQ1hviIHA.3740(a)TK2MSFTNGP03.phx.gbl... > > Hooking ExitProcess did 99% of what I wanted. The counts and objects are > now being cleaned up properly when normally exiting a program. > > If a user decides to use the task manager to kill the process, then yes, > things can go wrong, but at least the normal case is handled now. > > Bruce. > > On Friday, March 21, 2008 5:40 PM > Ben Voigt [C++ MVP] wrote: > > Bruce. > Bruce. wrote: > > Your library would, at startup, open a device created by the driver and > issue an IOCTL. The driver would then set a callback for the termination > of > that process. > > Or just forget about the process exit notify routine, leak the open handle > to the driver's device. At process termination it will get closed > automatically, your driver will get notified. > > Note that you can do the same thing in user mode using pipes or any other > IPC mechanism which notifies one end when the other closes... and you > don't > even need admin rights for this. > > On Saturday, March 22, 2008 12:05 AM > Pavel Lebedinsky [MSFT] wrote: > > In the read/execute case, WriteProcessMemory automatically > changesprotection > In the read/execute case, WriteProcessMemory automatically changes > protection to writeable. My guess is that this was done to make life > easier for debuggers (e.g. setting breakpoints). > > This behavior however is not documented so you should not depend > on it. Just use VirtualProtect in all cases. > > -- > This posting is provided "AS IS" with no warranties, and confers no > rights. > > On Saturday, March 22, 2008 10:06 AM > roger.or wrote: > > Re: Hooking exit process > On Mar 20, 3:27=A0am, "Alexander Grigoriev" <al...(a)earthlink.net> wrote: > > I agree. > > What tidy up is actually needed (other than the thread itself?) > > There may be better ways than trying to get the thread to do it. > > On your actual question, my first try would be: > - logging all the addresses patched by your hook > - running under a debugger > - place a breakpt at Kernel32!ExitProcess > - work back up the stack to find out how you got there > > Regards, > Roger. > > On Saturday, March 22, 2008 10:06 AM > roger.or wrote: > > Re: Hooking exit process > On Mar 20, 9:26=A0am, "Bruce." <no...(a)example.net> wrote: > t > > I guess you're not using windbg then :-) > It is bp kernel32!ExitProcess in that debugger. > > Format is module ! entry > > In VS 2005 ensure you've selected DLL exports: > Tools -> Options -> Debugging -> Native > Click Load DLL exports > > Then type: > ExitProcess,,kernel32 > into the breakpoint location. > > Regards, > Roger. > > On Saturday, March 22, 2008 10:06 AM > roger.or wrote: > > Re: Hooking exit process > On Mar 20, 1:15=A0pm, "Bruce." <no...(a)example.net> wrote: > > > Possibly - but unlikely. > More likely is > a) You're not actually successfully writing the hook > b) The old program is getting the entry point another way > > If you disassemble the code in __crtExitProcess > you should be able to see where it goes. > > You'll probably see something like: > > __crtExitProcess: > push dword ptr[esp+4] > call __crtCorExitProcess > pop ecx > push dword ptr [esp+4] > call dword ptr [_imp__ExitProcess (41D1C4h)] > > And the contents of the word at 0x41D1C4 will be the address > of ExitProcess -- this is the word you should have modified earlier. > Does the instrumented patching code give you the same address? > Set a data breakpoint on this address to catch writers. > > Regards, > Roger. > > PS You've still not said what you need to do in the closedown. > Might be better to investigate that, rather than going > further along this route.. > > On Saturday, March 22, 2008 10:06 AM > roger.or wrote: > > Re: Hooking exit process > Yes they do, but you usually have rights on yourself... > > I'd carefully check the address you are trying to write to. > > Regards > Roger. > > On Saturday, March 22, 2008 10:06 AM > roger.or wrote: > > Re: Hooking exit process > On Mar 20, 4:06=A0pm, "Volodymyr M. Shcherbyna" > <v_scherb...(a)online.mvps.org> wrote: > > You live and learn. > > I've used WriteProcessMemory before and never had any problems. > It worked for all the code and data I've tried it on. > > I've just tried - and it fails if the target is a readonly page, > although it is OK for execute_read. > > I'd always assumed before that WriteProcessMemory() sorted > the page protection out behind the scenes. > > Regards, > Roger. > > On Saturday, March 22, 2008 10:06 AM > roger.or wrote: > > Re: Hooking exit process > On 20 Mar, 17:06, "Volodymyr M. Shcherbyna" > <v_scherb...(a)online.mvps.org> wrote: > > I've just been lucky :-) > > I use it to write to:- > + Read/Write memory I've allocated in the target process > + Read/Execute code in target process > > and these both work. > Still puzzled that read only doesn't work when read/execute does > - may be a wierd Intel protection mask issue. > > Roger. > > On Thursday, January 14, 2010 12:33 PM > Jerome wrote: > > VirtualProtect solution > Thanx Bruce, it helped me to fix the exact same problem :) > After many hours i could not figure out why WriteProcessMemory worked with > one EXE but not with another one. > > so i just used : > > ----------------------- > BOOL res = VirtualProtect(ppfn, pfnLen, PAGE_READWRITE, &oldprotect); > if(res && oldprotect != NULL) > { > res = WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, pfnLen, > NULL); > res = VirtualProtect(ppfn, pfnLen, oldprotect, 0); > } > ----------------------- > > It's probably not the good way to do it, but it works like a charm ;) > > On Thursday, January 14, 2010 12:34 PM > Jerome wrote: > > VirtualProtect solution > Thanx Bruce, it helped me to fix the exact same problem :) > After many hours i could not figure out why WriteProcessMemory worked with > one EXE but not with another one. > > so i just used : > > ----------------------- > BOOL res = VirtualProtect(ppfn, pfnLen, PAGE_READWRITE, &oldprotect); > if(res && oldprotect != NULL) > { > res = WriteProcessMemory( GetCurrentProcess(), ppfn, &pfnNew, pfnLen, > NULL); > res = VirtualProtect(ppfn, pfnLen, oldprotect, 0); > } > ----------------------- > > It's probably not the good way to do it, but it works like a charm ;) > > > Submitted via EggHeadCafe - Software Developer Portal of Choice > IE username:password @domain.com behavior > http://www.eggheadcafe.com/tutorials/aspnet/dac20244-3179-45f1-9ae5-9d4aa87d6b14/ie-usernamepassword-dom.aspx
|
Pages: 1 Prev: VirtualProtect solution Next: Stange trecing of nt!NtOpenFile (winxp) |