I am not sure it is proper to ask this question here.
I have read one article from Anton Bassov called “Process-wide API spying - an ultimate hack” on www.codeproject.com.
He introduced a method of injecting dll to process:
(1) Create the process in suspended state
(2) Allocate memory in the remote process
(3) Write some code into the memory to load the extra DLL
(4) Use SetThreadContext() change the main thread’s context to execute our handcrafted code first
(5) Resume the remote process’s main thread.
My question is how to debug the little piece of handcrafted code?
Usually I will replace a byte of code with the instruction of “int 3” which is 0xCC in hex to control the thread stop running and trigger the just-in-time debugger.
But in this case, the new created process will just quit when I give an “int 3” at the beginning of the handcrafted codes.
Could anyone give me some advice?
Thanks in advance!
Well, I was stupid enough to describe even more powerful techniques in a codeproject - it just would con get into my head that newbies would try to make use of them in their commercial products, without even understanding how things work…
There is a field in PEB that tells the system whether a given process has a debug port. If it does not and UM exception occurs, it is forwarded to the thread that caused it, and, if exception remains unhandled, the system terminates the process. If the process does have a debug port and exception remains unhandled, then the system sends debug msg to the debugger. If debugger does not recognize an exception, exception will get sent to the failing process’s exception port, i.e. the failing process will be given the last chance. If exception remains unhandled, the process wil get terminated
If debugger receives a message describing exception at the address that debugger did not inset a breakpoint at, how on Earth should it react??? Of course it is not going to recognize it, and, once the process does not handle it itself on either first or last chance, it gets terminated…
On 12/18/08, xxxxx@hotmail.com wrote: > > > If debugger receives a message describing exception at the address that > debugger did not inset a breakpoint at, how on Earth should it react??? Of > course it is not going to recognize it, and, once the process does not > handle it itself on either first or last chance, it gets terminated… > > > Anton Bassov
can you please explain with some examples the op is talking about a JIT debugger not responding to his embedded int3 in the source he compiles is what i understand from the original post i have never seen a JIT Debugger Not responding to Int3 and breaking in
:>“c:\Program Files\latestDebugging Tools for Windows (x86)\cdb.exe” -iae
:>type tryint3.c #include <stdio.h>
int main (void) { printf(“hey im gonna embed an int3 now to see if jitty baby starts danci ng\n”); _asm { int 3 } return 0; } :>bcc32 /v /M tryint3.c Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland tryint3.c: Warning W8002 tryint3.c 6: Restarting compile using assembly in function main Turbo Assembler Version 5.0 Copyright (c) 1988, 1996 Borland International
Debug the parent process in WinDbg and enable child process debugging (.childdbg 1). You should be able to debug the child process when it is created.
Use the | command to switch active processes (see the WinDbg documentation for more details).
? S
-----Original Message-----
From: xxxxx@msn.com Sent: Thursday, December 18, 2008 00:35 To: Windows System Software Devs Interest List Subject: [ntdev] How to debug handcrafted code?
Hi everyone:
I am not sure it is proper to ask this question here.
I have read one article from Anton Bassov called “Process-wide API spying - an ultimate hack” on www.codeproject.com.
He introduced a method of injecting dll to process:
(1) Create the process in suspended state (2) Allocate memory in the remote process (3) Write some code into the memory to load the extra DLL (4) Use SetThreadContext() change the main thread’s context to execute our handcrafted code first (5) Resume the remote process’s main thread.
My question is how to debug the little piece of handcrafted code? Usually I will replace a byte of code with the instruction of “int 3” which is 0xCC in hex to control the thread stop running and trigger the just-in-time debugger. But in this case, the new created process will just quit when I give an “int 3” at the beginning of the handcrafted codes.
Could anyone give me some advice? Thanks in advance!
I do not think the debugger is seeing it at all. Virtually all debuggers handle “unexpected” exceptions, e.g. access violations or hardcoded DbgBreakPoint() style breakpoints.
If the OP actually attaches a debugger to the child process then I believe it will work. I suspect that the OP is waiting for the JIT debugger to activate; however, it is possible that the state in the child process has been sufficiently damaged that this does not successfully happen. Again, pre-attaching a debugger to the child process would solve that possible issue.
? S
-----Original Message-----
From: xxxxx@hotmail.com Sent: Thursday, December 18, 2008 04:09 To: Windows System Software Devs Interest List Subject: RE:[ntdev] How to debug handcrafted code?
> I have read one article from Anton Bassov called “Process-wide API spying - an ultimate hack” > on www.codeproject.com.
Well, I was stupid enough to describe even more powerful techniques in a codeproject - it just would con get into my head that newbies would try to make use of them in their commercial products, without even understanding how things work…
There is a field in PEB that tells the system whether a given process has a debug port. If it does not and UM exception occurs, it is forwarded to the thread that caused it, and, if exception remains unhandled, the system terminates the process. If the process does have a debug port and exception remains unhandled, then the system sends debug msg to the debugger. If debugger does not recognize an exception, exception will get sent to the failing process’s exception port, i.e. the failing process will be given the last chance. If exception remains unhandled, the process wil get terminated
If debugger receives a message describing exception at the address that debugger did not inset a breakpoint at, how on Earth should it react??? Of course it is not going to recognize it, and, once the process does not handle it itself on either first or last chance, it gets terminated…
You have to configure the debugger to be invoked. This is done
automatically when VS is installed on a machine; it is not clear that WinDbg
does the same thing. I don’t recall the key and a quick search didn’t pop
it up to me, maybe someone else remembers it.
joe
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Thursday, December 18, 2008 10:32 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to debug handcrafted code?
If debugger receives a message describing exception at the address that debugger did not inset a breakpoint at, how on Earth should it react??? Of course it is not going to recognize it, and, once the process does not handle it itself on either first or last chance, it gets terminated…
Anton Bassov
can you please explain with some examples the op is talking about a JIT debugger not responding to his embedded int3 in the source he compiles is what i understand from the original post i have never seen a JIT Debugger Not responding to Int3 and breaking in
:>“c:\Program Files\latestDebugging Tools for Windows (x86)\cdb.exe” -iae
:>type tryint3.c #include <stdio.h>
int main (void) { printf(“hey im gonna embed an int3 now to see if jitty baby starts danci ng\n”); _asm { int 3 } return 0; } :>bcc32 /v /M tryint3.c Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland tryint3.c: Warning W8002 tryint3.c 6: Restarting compile using assembly in function main Turbo Assembler Version 5.0 Copyright (c) 1988, 1996 Borland International
0:000> da tryint3!d2_1 0040a128 “hey im gonna embed an int3 now t” 0040a148 “o see if jitty baby starts danci” 0040a168 “ng.”
0:000>
regards
raj_r
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer – This message has been scanned for viruses and dangerous content by http:</http:> MailScanner, and is believed to be clean.</stdio.h>
‘windbg -I’ or ‘windbg -IS’ will do this. The former will display a
message indicating either success or failure; the later only displays a
message in the case of failure.
For the record (assuming I’m correct), I believe that the key and values
in question are:
In order to do this, you have to have local admin rights (maybe ‘power
user;’ I don’t know), and executing this command will overwrite whatever
values, if any, already exist. Also, I haven’t yet read the rest of
this thread, so I’m not commenting on whether doing this is a good idea
or will be of help in solving your problem, whatever it may be.
Good luck,
mm
Joseph M. Newcomer wrote:
You have to configure the debugger to be invoked. This is done
automatically when VS is installed on a machine; it is not clear that
WinDbg does the same thing. I don’t recall the key and a quick search
didn’t pop it up to me, maybe someone else remembers it.
joe
*From:* xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] *On Behalf Of *raj_r
*Sent:* Thursday, December 18, 2008 10:32 AM
*To:* Windows System Software Devs Interest List
*Subject:* Re: [ntdev] How to debug handcrafted code?
On 12/18/08, *xxxxx@hotmail.com mailto:xxxxx* > mailto:xxxxx> wrote: > > > If debugger receives a message describing exception at the address > that debugger did not inset a breakpoint at, how on Earth should it > react??? Of course it is not going to recognize it, and, once the > process does not handle it itself on either first or last chance, it > gets terminated… > > > Anton Bassov > > > can you please explain with some examples > the op is talking about a JIT debugger not responding to his embedded > int3 in the source he compiles is what i understand from the original post > i have never seen a JIT Debugger Not responding to Int3 and breaking in > > > > > :>“c:\Program Files\latestDebugging Tools for Windows (x86)\cdb.exe” -iae > > :>type tryint3.c > #include <stdio.h> > > int main (void) > { > printf(“hey im gonna embed an int3 now to see if jitty baby > starts danci > ng\n”); > _asm > { > int 3 > } > return 0; > } > :>bcc32 /v /M tryint3.c > Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland > tryint3.c: > Warning W8002 tryint3.c 6: Restarting compile using assembly in function > main > Turbo Assembler Version 5.0 Copyright (c) 1988, 1996 Borland International > > Assembling file: tryint3.ASM > Error messages: None > Warning messages: None > Passes: 1 > > Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland > > :>map2dbg tryint3.exe > Converted 573 symbols. > > :>tryint3.exe > hey im gonna embed an int3 now to see if jitty baby starts dancing > > Microsoft (R) Windows Debugger Version 6.10.0003.233 X86 > Copyright (c) Microsoft Corporation. All rights reserved. > > *** wait with pending attach > Symbol search path is: > SRVF:\SYMBOLSHTTP://MSDL.MICROSOFT.COM/DOWNLOAD/SYMBOLS > > tryint3!c2_0+0xe: > 0040115e cc int 3 > > 0:000> ub @eip l3 > tryint3!c2_0+0x3: > 00401153 6828a14000 push offset tryint3!d2_1 (0040a128) > 00401158 e80b270000 call tryint3!printf (00403868) > 0040115d 59 pop ecx > > 0:000> da tryint3!d2_1 > 0040a128 “hey im gonna embed an int3 now t” > 0040a148 “o see if jitty baby starts danci” > 0040a168 “ng.” > > 0:000> > > regards > > raj_r > > > > > > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging > and other seminars visit: http://www.osr.com/seminars To unsubscribe, > visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > – > This message has been scanned for viruses and > dangerous content by MailScannerhttp:</http:>, and is > believed to be clean.</stdio.h></mailto:xxxxx></mailto:xxxxx>
The problem here is likely that the JIT debugger support is inherently (by design) unreliable when certain forms of process breakage (early init or stack is bogus) are present.
? S
From: Joseph M. Newcomer Sent: Thursday, December 18, 2008 15:35 To: Windows System Software Devs Interest List Subject: RE: [ntdev] How to debug handcrafted code?
You have to configure the debugger to be invoked. This is done automatically when VS is installed on a machine; it is not clear that WinDbg does the same thing. I don’t recall the key and a quick search didn’t pop it up to me, maybe someone else remembers it. joe
________________________________ From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r Sent: Thursday, December 18, 2008 10:32 AM To: Windows System Software Devs Interest List Subject: Re: [ntdev] How to debug handcrafted code?
If debugger receives a message describing exception at the address that debugger did not inset a breakpoint at, how on Earth should it react??? Of course it is not going to recognize it, and, once the process does not handle it itself on either first or last chance, it gets terminated…
Anton Bassov
can you please explain with some examples the op is talking about a JIT debugger not responding to his embedded int3 in the source he compiles is what i understand from the original post i have never seen a JIT Debugger Not responding to Int3 and breaking in
:>“c:\Program Files\latestDebugging Tools for Windows (x86)\cdb.exe” -iae
:>type tryint3.c #include <stdio.h>
int main (void) { printf(“hey im gonna embed an int3 now to see if jitty baby starts danci ng\n”); _asm { int 3 } return 0; } :>bcc32 /v /M tryint3.c Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland tryint3.c: Warning W8002 tryint3.c 6: Restarting compile using assembly in function main Turbo Assembler Version 5.0 Copyright (c) 1988, 1996 Borland International
0:000> da tryint3!d2_1 0040a128 “hey im gonna embed an int3 now t” 0040a148 “o see if jitty baby starts danci” 0040a168 “ng.”
0:000>
regards
raj_r
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer – This message has been scanned for viruses and dangerous content by MailScannerhttp:</http:>, and is believed to be clean. — NTDEV is sponsored by OSR
Using a debugger pre-attached is still much more reliable. All of those *still* require running code in a crashed process, which can easily fail. WER in Windows Vista and beyond makes this a bit better by reducing the amount of work that must be done from a CreateProcess call (which requires a perfectly working process heap among many other unlikely things), but it’s a far cry from the simpler and *far* more bulletproof solution of debugging child processes and pre-attaching the debugger.
? S
-----Original Message-----
From: Maxim S. Shatskih Sent: Thursday, December 18, 2008 18:13 To: Windows System Software Devs Interest List Subject: Re:[ntdev] How to debug handcrafted code?
> My question is how to debug the little piece of handcrafted code?
Postmortem dumps by DrWatson are good, especially together with “windbg -z”
On 12/19/08, Joseph M. Newcomer wrote: > > You have to configure the debugger to be invoked. This is done > automatically when VS is installed on a machine; it is not clear that WinDbg > does the same thing. I don’t recall the key and a quick search didn’t pop > it up to me, maybe someone else remembers it. > joe >
i had already done this while i posted my sample session :>“c:\Program Files\latestDebugging Tools for Windows (x86)\cdb.exe” -iae
you can also do
or windbg -I
or
ntsd -iae
or
set this reg key
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug] “Auto”=“1” “Debugger”=“"c:\Program Files\latestDebugging Tools for Windows (x86)\cdb.exe" -p %ld -e %ld -g” “UserDebuggerHotKey”=dword:00000000
to make the JIT Debugger Popup
in AeDebug key you can also configure other debuggers like vs,ollydbg and like
thanks and regards
raj_r
------------------------------ > From:xxxxx@lists.osr.com [mailto: > xxxxx@lists.osr.com] On Behalf Of raj_r > Sent: Thursday, December 18, 2008 10:32 AM > To: Windows System Software Devs Interest List > Subject: Re: [ntdev] How to debug handcrafted code? > > > > On 12/18/08, xxxxx@hotmail.com wrote: >> >> >> If debugger receives a message describing exception at the address that >> debugger did not inset a breakpoint at, how on Earth should it react??? Of >> course it is not going to recognize it, and, once the process does not >> handle it itself on either first or last chance, it gets terminated… >> >> >> Anton Bassov > > > can you please explain with some examples > the op is talking about a JIT debugger not responding to his embedded int3 > in the source he compiles is what i understand from the original post > i have never seen a JIT Debugger Not responding to Int3 and breaking in > > > > > :>“c:\Program Files\latestDebugging Tools for Windows (x86)\cdb.exe” -iae > > :>type tryint3.c > #include <stdio.h> > > int main (void) > { > printf(“hey im gonna embed an int3 now to see if jitty baby starts > danci > ng\n”); > _asm > { > int 3 > } > return 0; > } > :>bcc32 /v /M tryint3.c > Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland > tryint3.c: > Warning W8002 tryint3.c 6: Restarting compile using assembly in function > main > Turbo Assembler Version 5.0 Copyright (c) 1988, 1996 Borland > International > > Assembling file: tryint3.ASM > Error messages: None > Warning messages: None > Passes: 1 > > Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland > > :>map2dbg tryint3.exe > Converted 573 symbols. > > :>tryint3.exe > hey im gonna embed an int3 now to see if jitty baby starts dancing > > Microsoft (R) Windows Debugger Version 6.10.0003.233 X86 > Copyright (c) Microsoft Corporation. All rights reserved. > > *** wait with pending attach > Symbol search path is: SRVF:\SYMBOLS > HTTP://MSDL.MICROSOFT.COM/DOWNLOAD/SYMBOLShttp: > > tryint3!c2_0+0xe: > 0040115e cc int 3 > > 0:000> ub @eip l3 > tryint3!c2_0+0x3: > 00401153 6828a14000 push offset tryint3!d2_1 (0040a128) > 00401158 e80b270000 call tryint3!printf (00403868) > 0040115d 59 pop ecx > > 0:000> da tryint3!d2_1 > 0040a128 “hey im gonna embed an int3 now t” > 0040a148 “o see if jitty baby starts danci” > 0040a168 “ng.” > > 0:000> > > regards > > raj_r > > > > > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and > other seminars visit: http://www.osr.com/seminars To unsubscribe, visit > the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > – > This message has been scanned for viruses and > dangerous content by MailScannerhttp:</http:>, and is > believed to be clean. > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer ></http:></stdio.h>
On 12/18/08, Skywing wrote: > > > I suspect that the OP is waiting for the JIT debugger to activate; > however, it is possible that the state in the child process has been > sufficiently damaged that this does not successfully happen. Again, > pre-attaching a debugger to the child process would solve that possible > issue. > > ? S
Thanks ken you mean to say that the child process foobars even before it executes the embedded int3 and thats why the JIT isnt working ?? or is it possible that even after the child executes the int3 there are circumstances where JIT might not get Activated
Given what the OP is saying, it seems to me that something else has been ?broken? with the new process that causes JIT debugger launching to fail. Normally just writing an int3 as the first instruction post ntdll initialization ought to work, but as this doesn?t appear to be working for the OP, something else must be going on, which means there is probably an earlier failure.
Just debugging it by .childdbg 1?ing the parent processs across the child process creation is going to be the simplest and most reliable way to figure out what is really going on here. There?s plenty of things that can be done to screw up process initialization, but we don?t really have enough information to do anything other than wildly speculate right now.
S
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Friday, December 19, 2008 11:05 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] How to debug handcrafted code?
On 12/18/08, Skywing > wrote:
I suspect that the OP is waiting for the JIT debugger to activate; however, it is possible that the state in the child process has been sufficiently damaged that this does not successfully happen. Again, pre-attaching a debugger to the child process would solve that possible issue.
? S
Thanks ken you mean to say that the child process foobars even before it executes the embedded int3 and thats why the JIT isnt working ?? or is it possible that even after the child executes the int3 there are circumstances where JIT might not get Activated
There is probably a way to do that with other debuggers, as it is a standard feature of the Win32 debugging API.
However, the only time I would use one of those two debuggers would be debugging managed code or WinCE code - both of which would tend towards VS. I would not use OllyDbg nor VS in general for debugging as they are quite inferior to WinDbg, IMO.
? S
-----Original Message-----
From: xxxxx@msn.com Sent: Tuesday, December 23, 2008 00:01 To: Windows System Software Devs Interest List Subject: RE:[ntdev] How to debug handcrafted code?
Thank you Ken!
I tried the way your adviced and it works. I can debug the code with WinDbg now.
I still wonder if this technology can be performed by other debuggers, such as Visual Studio debugger or Ollydbg?
On 12/23/08, xxxxx@msn.com wrote: > > Thank you Ken! > > I tried the way your adviced and it works. I can debug the code with WinDbg > now. > > I still wonder if this technology can be performed by other debuggers, such > as Visual Studio debugger or Ollydbg?
ollydbg Creates Debuggeee process DEBUG_ONLY_THIS_ **flag so it does not handle debugevents from child processes
you can find a buggy kludge hack for ollydbg if you google with this search query childdbg ollydbg