ok, ive been trying to code an small debugger code in FASM for some time now, this code is to break at a certain EIP and "steal" the value of eax.

im trying to do so because you can steal DMA offsets out of the file without
the need of calculating it.


anyways, heres the prob...

when trying to define the DEBUG_EVENT it ALWAYS fails, i dont know if the
MASM syntax is incorrect NOR how to define a TYPE in FASM.

if anyone could post a small snippet which would break at a EIP i would be
very thankful.

im still learning ASM and im sure i will for many years to come but such an source code would be most helpful in my teachings.

if anyone know of a good FASM community beside's this one i would really appriciate such a link that aswell.

thank you.

Regards, Forsaken.

i find this coding topic very interesting, sadly... ive not been able to find any such debugger code in any other language then C++ and MASM/NASM...


and as im not coding c++ i would really like to see some FASM tutorials on this.

i know there's a lot of ppl here which has the knowledge, im just hoping someone will write an example for me

ive looked at Iczelion's debugging tutorials but i cant seem to get em working under FASM as i dont know the syntax differences.

it would be just wonderful if someone could port this to FASM as his tutorials contain great knowledge.

Regards, Forsaken.

what is this for? trainers?

yes, trainers would be the main use yes.

still, it might also be fun to code some sort of a mini debugger to learn from.
got any sources? fasm links?

in masm

thank you

forsaken: Debuggers work this way. They inject 0CCh (int3 opcode) in the place where you want to stop the program from executing. When there is an exception (which the debugger shall catch of course) it changes back the byte to normal. The code then is executed only till that moment and then you can use GetThreadContext to get all registers values, etc.

using DRs would be nicer... doesn't win allow that?

I work on debugger for win64. I implemented SW (int03) as well HW ("hardware" = debug registers) breakpoints successfuly. But the code is for win64, you must downgrade it to 32 bit...
Sources and executables here:
1. try my homepage and download link (fasm_amd64_win64_p002.zip file)
part 002 - Flat Assembler FASM win64 sources, executables, system drivers (FASM), debugger for win64 written in FASM
2. try http://board.flatassembler.net/topic.php?t=3437&start=25 but later, after I update new version dbg10... here

HW_BP is very big feature, It can break most of antidebug tricks...
SW_BP change opcode, so it's easy to detect them and antidebug routine can make a mess...
But detecting HW_BP isn't so easy (not easy but it's possible...)
To set HW_BP just set address to one of DR0-DR3 and set some bits in DR7
After HW_BP occur, it report EXCEPTION_SINGLE_STEP and code halt on next instruction.
refer to
http://www.logix.cz/michal/doc/i386/chp12-02.htm
how to set DR7 and what return in DR6 after EXCEPTION_SINGLE_STEP

i also found a really nice example at Sulaiman Chang's site, http://sulaiman.netadvant.com/


sadly, it contains errors and wont compile ;/

it seems that it doesnt wanna work with the DEBUG_EVENT type even thou its been defined in the source...


if anyone could post a working source here i would be really greatful
the source is in fasm and i dont think theres anything else besides the DEBUG_EVENT which wont compile...

he also used return instead or ret but i dont know if this would be considered a bug as i dont know if the 'return' instruction can be used in fasm, i couldnt anyway...

EDIT:
if anyone succeeds in compiling this, could they please specify their compiler version, IDE and so on?

it wont get past those MOV instructions which tries to work with dbgEvent.dwDebugEvent or whatever the variable is called


regards, forsaken.

My code in win64 works perfectly, but win64 structures differs from win32 not only by size (dword-qword), e.g. ThreadContext has too different structure. API's are the same.
You can try masm win32 specific tuts
http://spiff.tripnet.se/~iczelion/tut28.html
http://spiff.tripnet.se/~iczelion/tut29.html
http://spiff.tripnet.se/~iczelion/tut30.html
and compiled examples
http://spiff.tripnet.se/~iczelion/files/icz-tuts.zip
Of course, you can debug and step debugger (load debugger as debuggee) to learn how it works.


this is typical win32 debug loop:
debug_loop:
push -1 ; timeout
lea ebx,[DebugEv]
push ebx
call [WaitForDebugEvent]

EXCEPTION_DEBUG_EVENT = 1
CREATE_THREAD_DEBUG_EVENT = 2
CREATE_PROCESS_DEBUG_EVENT = 3
EXIT_THREAD_DEBUG_EVENT = 4
EXIT_PROCESS_DEBUG_EVENT = 5
LOAD_DLL_DEBUG_EVENT = 6
UNLOAD_DLL_DEBUG_EVENT = 7
OUTPUT_DEBUG_STRING_EVENT = 8
RIP_EVENT = 9
EXCEPTION_MAXIMUM_PARAMETERS = 15

DBG_CONTINUE = 00010002h
DBG_TERMINATE_THREAD = 40010003h
DBG_TERMINATE_PROCESS = 40010004h
DBG_CONTROL_C = 40010005h
DBG_CONTROL_BREAK = 40010008h
DBG_EXCEPTION_NOT_HANDLED = 80010001h

mov eax,[ebx] ; DebugEventCode
cmp eax,EXCEPTION_DEBUG_EVENT
jz handle_EXCEPTION_DEBUG_EVENT
cmp eax,CREATE_PROCESS_DEBUG_EVENT
jz handle_CREATE_PROCESS_DEBUG_EVENT
cmp eax,EXIT_PROCESS_DEBUG_EVENT
jz exit
; cmp....

ContinueDebug:
push DBG_CONTINUE
lea ebx,[ProcessInfo]
push dword [ebx + 4*3] ; ThreadId
push dword [ebx + 4*2] ; ProcessId
call [ContinueDebugEvent]

jmp debug_loop

handle_EXCEPTION_DEBUG_EVENT:
mov eax,[ebx + 4*3] ; u.Exception
; ebx point now to the EXCEPTION_DEBUG_INFO

STATUS_BREAKPOINT = 80000003h
STATUS_SINGLE_STEP = 80000004h
EXCEPTION_BREAKPOINT = STATUS_BREAKPOINT
EXCEPTION_SINGLE_STEP = STATUS_SINGLE_STEP
cmp eax,EXCEPTION_BREAKPOINT
jz ...
cmp eax,EXCEPTION_SINGLE_STEP
jz ...


note1, that in source there is raw put breakpoint at prog.exe startup entry point 401000. Entry point can differs in another exe. You can grab entry point:
CREATE_PROCESS_DEBUG_INFO.lpStartAddress
under win64:
lea rsi,qword [DebugEv + 40h] ; lpStartAddress
mov rax,[rsi]

under win32 maybe
mov eax,[DebugEv + 20h]

Note2: first exception occurs CREATE_PROCESS_DEBUG_EVENT
after first EXCEPTION_BREAKPOINT occur (it's somewhere in the kernel), this is the right time to put breakpoint on debuggee startup entry (or another place if you like)
next a few LOAD_DLL_DEBUG_EVENT occur
next your EXCEPTION_DEBUG_EVENT occurs at address at which you put breakpoint
after you process breakpoint (remove db 0CCh from memory), decrease EIP by 1 (decrease EIP isn't implemented in win32 source - it's handled as debuggee = prog.exe has at startup code inc eax - 1 byte opcode that is overwrited by db 0CCh - you can see different eax if you run prog.exe and if you run it by debug00.exe - but it's simple - GetThreadContext, decrease EIP by 1, SetThreadContext) (or if you didn't put breakpoint), debugge run until EXIT_PROCESS_DEBUG_EVENT occur, at whis is the right time to escape debug_loop