Debugger Breakpoint Problem.

Index > Windows > Debugger Breakpoint Problem.

Author

Thread

Overflowz

Joined: 03 Sep 2010
Posts: 1046

Overflowz 04 Sep 2011, 03:53

Hello everyone, I've got problem when trying to set breakpoint on entry point (or somewhere else, doesn't matter.) it never reaches BP, just continues code execution.. My question is, I'm doing this wrong way ? Thanks.
Here's full working code.

Code:

format PE GUI 4.0
include 'WIN32AX.INC'
entry main
section '.data' data readable writeable
fname db "helloworld.exe",0
szMsg db "Breakpoint!",0
exitmsg db "Debugger Quited.",0
szCap db "Debug",0
dbgstring db  "Entry Point: 0x%x",0x0d,0x0a,"Continuing Debugging...",0
buffer db 512 dup (?)
align 4
pinfo            PROCESS_INFORMATION
sinfo            STARTUPINFO
DBEvent          DEBUG_EVENT
context          CONTEXT
section '.text' code readable executable
main:
      invoke CreateProcess,fname,0,0,0,0,DEBUG_PROCESS+DEBUG_ONLY_THIS_PROCESS,0,0,sinfo,pinfo
      mov [context.ContextFlags],CONTEXT86_CONTROL ;I need EIP only.
.debug:
      invoke WaitForDebugEvent,DBEvent,0FFFFFFFFh
      cmp [DBEvent.dwDebugEventCode],EXIT_PROCESS_DEBUG_EVENT
      je .exit
      cmp [DBEvent.dwDebugEventCode],CREATE_PROCESS_DEBUG_EVENT
      je @f
      invoke GetThreadContext,[pinfo.hThread],context    ;Get context from pinfo.hThread (I think I have problem here!)
      mov eax,[context.Eip]  ;moving it to eax
      cmp eax,0x00402000  ;comparing with 0x402000 to trigger bp message but it never reaches, I see program runs normally but BP message wont appear!
      je .bp
      invoke ContinueDebugEvent,[DBEvent.dwProcessId],[DBEvent.dwThreadId],DBG_CONTINUE
      jmp .debug
      ret
@@:
      cinvoke wsprintf,buffer,dbgstring,[DBEvent.u.CreateProcessInfo.lpStartAddress]
      invoke MessageBox,0,buffer,szCap,MB_OK+MB_ICONINFORMATION
      invoke ContinueDebugEvent,[DBEvent.dwProcessId],[DBEvent.dwThreadId],DBG_CONTINUE
      jmp .debug
.bp:
      invoke MessageBox,0,szMsg,szCap,MB_OK+MB_ICONERROR
      ret
.exit:
      invoke MessageBox,0,exitmsg,szCap,MB_OK+MB_ICONINFORMATION
      ret
section '.idata' import data readable
library user32,'user32.dll',\
        kernel32,'kernel32.dll'
include 'API\USER32.INC'
include 'API\KERNEL32.INC'

04 Sep 2011, 03:53

typedef

Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000

typedef 04 Sep 2011, 04:06

you need to tell the OS you want to debug the process by calling DebugActiveProcess()

How is the breakpoint being triggered? It's best to make another EXE that way you can try an exception like

Code:

MOV EAX,DR0

04 Sep 2011, 04:06

typedef

Joined: 25 Jul 2010
Posts: 2909
Location: 0x77760000

typedef 04 Sep 2011, 04:15

I don't know about setting a BP on a system created memory area like that. Maybe you can read the EIP first then clone the image into another memory space so that you can write break points at any location you choose. Sounds like overkill?

04 Sep 2011, 04:15

Overflowz

Joined: 03 Sep 2010
Posts: 1046

Overflowz 04 Sep 2011, 04:29

I'm doing exactly that. getting EIP, comparing to base address but failed. read carefully.
as I guess, DebugActiveProcess is not needed anymore when I'm doing CreateProcess with DEBUG_PROCESS+DEBUG_ONLY_THIS_PROCESS flags.

04 Sep 2011, 04:29

ctl3d32

Joined: 30 Dec 2009
Posts: 206
Location: Brazil

ctl3d32 04 Sep 2011, 12:44

Once you get it working, please share. I want to learn exactly the same thing.

04 Sep 2011, 12:44

Overflowz

Joined: 03 Sep 2010
Posts: 1046

Overflowz 04 Sep 2011, 14:33

I did it! I have to just modify byte with int3 breakpoint with WriteProcessMemory and check if DEBUG_EVENT.u.Exception.ExceptionRecord.ExceptionCode == EXCEPTION_BREAKPOINT and it pauses there! Here's sources.
Problem is that, WaitForDebugEvent only pauses when debug event is occured, not step by step. I understand now Wink

Description:	helloworld + debugger	Download
Filename:	ASM Stuff.rar
Filesize:	912 Bytes
Downloaded:	375 Time(s)

04 Sep 2011, 14:33

ctl3d32

Joined: 30 Dec 2009
Posts: 206
Location: Brazil

ctl3d32 04 Sep 2011, 20:44

Thanks

04 Sep 2011, 20:44

Feryno

Joined: 23 Mar 2005
Posts: 509
Location: Czech republic, Slovak republic

Feryno 05 Sep 2011, 07:04

how to do step by step -

when the debuggee is not running, e.g. when it generated int3 breakpoit exception and parent debugger is executing something between WaitForDebugEvent / ContinueDebug it is the right time to modify thread registers (you may modify them only when the thread is not executing, else you may cause a mess)

DebugLoop:

call [WaitForDebugEvent]

; ----- here you are currently

mov [Context.ContextFlags],CONTEXT_CONTROL ; put another flags if you want to access more registers, some versions of win are also buggy and to access maybe EFlags or maybe debug registers - cant remember from my head - you must also set more than CONTEXT_CONTROL, then try to set CONTEXT_ALL that will always work
call [GetThreadContext]
or [Context.EFlags],trap_flag_mask
call [SetThreadContext]

call Continue DebugEvent

jxx DebugLoop

then the next exception generated by the debuggee will be usually single step exception

in such way it is possible to trace debuggee by executing 1 instruction in 1 step

there is also a feature by setting DebugCtlMSR.BTF to 1 so single step is generated only on branching instructions (like call, ret, jxx, ...) instead of every instruction (a way to big speedup)

small note:
the first one int3 breakpoint occures usually in ntdll.dll (or some corresponding DLL, DLL and function may be different among a lot of versions of win)
int3 breakpoint at executable entry point (which you already successfully prepared) occures only as the second int3 exception generated by debuggee - you solved that manually by the cmp eax,0x00402000 instruction which is specific for you executable

05 Sep 2011, 07:04

Overflowz

Joined: 03 Sep 2010
Posts: 1046

Overflowz 05 Sep 2011, 11:19

Feryno
Thanks, but when I tried to call GetThreadContext, I failed. error was - [DBEvent.u.CreateProcessInfo.hProcess] was 0 instead of handle. Try me example below.

05 Sep 2011, 11:19

Feryno

Joined: 23 Mar 2005
Posts: 509
Location: Czech republic, Slovak republic

Feryno 05 Sep 2011, 13:59

OK, same FASM samples for you
they are something different, but similar, they are self debuggers, you must do these changes:

remove the:
call [IsDebuggerPresent]
or eax,eax
jnz child

change input params for CreateProcess so debugger launches another executable, not itself

you have working samples for all core system calls
the skeleton is prepared to debug more processes/threads simultaneously (when e.g. debuggee creates more threads/processes)

I'll delete the attachment soon as I reached the quota limit of the FASM forum, notice me that you downloaded the stuff please

when you start to write and implement things like your own debugger you are on the best way to find a good job in IT (my brother could confirm that)

Last edited by Feryno on 06 Sep 2011, 07:00; edited 1 time in total

05 Sep 2011, 13:59

Overflowz

Joined: 03 Sep 2010
Posts: 1046

Overflowz 05 Sep 2011, 15:54

Feryno
I have downloaded that before Razz

I'll study what is problem in my code.
P.S what can I do when I'll write my own debugger ? What it have to deal with IT ? Very Happy

05 Sep 2011, 15:54

Overflowz

Joined: 03 Sep 2010
Posts: 1046

Overflowz 05 Sep 2011, 16:00

When I was doing something like this:

Code:

invoke WaitForDebugEvent,[DBEvent],0FFFFFFFFh
cmp [DBEvent.dwDebugEventCode],CREATE_PROCESS_DEBUG_EVENT
je .start
.........
.start:
mov [ctx.ContextFlags],CONTEXT_CONTROL
invoke GetThreadContext,[DBEvent.u.CreateProcessInfo.hThread],ctx ;<-- This fails, invalid handle it says.

What's wrong ? Sad

05 Sep 2011, 16:00

Feryno

Joined: 23 Mar 2005
Posts: 509
Location: Czech republic, Slovak republic

Feryno 06 Sep 2011, 06:59

I guess you are trying to access thread context too early
just save thread handle and use it later
OS must do a lot of things before executable really starts to execute and for performance reasons OS is doing it in steps, when some step is already fully finished, the following step may be done only partially

typically this happens in this order:

[0]
Create Process Debug Event

[1]
Create Thread Debug Event

[2]
few of Load DLL Debug Events (about 2-3 depending on version of win - NTDLL.DLL, KERNEL32.DLL upto w2k8 R2, 1 newer DLL under w2k8 R2 SP1 can't remember its name from my head just now)

[3]
Exception generated by int3 in NTDLL.DLL DbgBreakPoint (the function name is different in w2k8 server R2 SP1)

[4]
a lot of Load DLL Debug Events (depending on the count of DLL required in debuggee, in its import directory, minus DLLs already loaded)

[5]
Exception generated by int3 you put at executable entry point

you are trying to access thread registers too early
windbg even refuses to modify thread debug registers at step [3] - e.g. if you try to put debug registers breakpoint at that stage they are not modified (windbg notifies you about that), you must do then at least 1 single step and then you can prepare debug registers breakpoint, it is command like:
ba e 402000

try to access thread registers at the step [5]

1 note, context should be aligned, I guess it is enough to align 4 for win32 bit, for 64 bit win it is necessary to align 10h and for AVX it is even necessary to align 40h (or append some padding bytes so OS aligns the context itself and returns aligned begin of context)

just continue, you are on the right way, I'll help you, you will certainly do it, it is only question of time and effort
people able to write own debugger are very welcome to most of antivir labs (because there is bbbbbiiiiiiigggg lack of them)

06 Sep 2011, 06:59

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum