Message board for the users of flat assembler.
> Windows > Coding a fasm debugger to break at a certain EIP?
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
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.
|10 Oct 2005, 07:07||
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.
|10 Oct 2005, 08:13||
what is this for? trainers?
|10 Oct 2005, 14:45||
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?
|10 Oct 2005, 15:40||
jumplog ain't a leet coding project...
|10 Oct 2005, 16:11||
|10 Oct 2005, 16:58||
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.
|10 Oct 2005, 20:35||
using DRs would be nicer... doesn't win allow that?
|10 Oct 2005, 22:23||
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.
how to set DR7 and what return in DR6 after EXCEPTION_SINGLE_STEP
|11 Oct 2005, 05:09||
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...
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
|11 Oct 2005, 07:13||
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
and compiled examples
Of course, you can debug and step debugger (load debugger as debuggee) to learn how it works.
this is typical win32 debug loop:
push -1 ; timeout
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
push dword [ebx + 4*3] ; ThreadId
push dword [ebx + 4*2] ; ProcessId
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
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:
lea rsi,qword [DebugEv + 40h] ; lpStartAddress
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
|11 Oct 2005, 07:49||
< Last Thread | Next Thread >
Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.
Website powered by rwasa.