fixed the problem reported by a rabbit:
- Put a permanent bp on some address which is going to be executed.
- Run the program and wait until it breaks on that bp.
- Press F2 to remove that permanent bp.
- Press F7 to step into, a CC byte is written even though the bp is no more.


added info whether conditional jump occure or not (if such instruction is at current RIP, then string YES / No is appended after it)


added a choice to automatically select item after double clicking on it (so you don't need to do left 4-click = double click for starting editing it + double click to select the text in item)
Face -> Various settings: double click selects the item



Somebody may dislike the behaviour of code 1st when it always starts from current RIP and is updated every debug event. This design is because such way always shows the first instruction correctly no matter some antidebugs (e.g. code sequence like EB FF C3). If you want to see few instructions before current RIP, you may set the count of back instructions in Face -> Various settings -> Code 1st disassemble back instructions). More than 10 years ago when I played with DOS 16-bit viruses and various antidebugs, I used Borland Turbo Debugger (td.exe which lacked such style so I had manually adjuct code window almost every single step to see correctly the first instruction to execute)
for comparison, this was the style of td.exe when single stepping code EB FF C3 90, the char > means instruction pointer at current instruction pointer:


As you can see, there is no visible instruction after first single step. It wasted a lot of my time to adjust code every such obfuscating step to see the instruction to execute.

this is default behaviour of fdbg:


As you can see, the instruction to execute is always visible in default fdbg style.
This was a reason for implementing such fdbg design.
Again, if you mind it (you may e.g. prefer to see 1 preceeding instruction or even more instructions), you may e.g. set Face -> Various settings -> Code 1st disassemble back instructions
You may set it e.g. to 1 or even more (don't set it to more than count of "rows" in code 1st).

edit 2011-01-11 deleted attachment, newer version available

Feryno, thank you for your continued 64bit efforts!

Thanks Feryno for your work!!! Hope this project goes ahead with new updates

Recently I met my brother. He is going to work in reversing viruses. Most of them are 32 bit windows executables, he showed me a sample to analyze from his future employer. It was necessary to unpack the executable at first, then break some antidebugs, etc... It was a challenge posted on the page of his future employer months ago. The timeout for reporting analyzis expired already and some best solutions were already posted or available to download thanks to skilled guys (btw the best of them refused to work and earn money as employees of an antivirus company, it is perhaps against their honest).
But it inspired me in implementing 2 new commands in fdbg (most of 32 bit debuggeers contain them)
- putting breakpoint at export from executable (typing the bare name without worrying about executable/DLL name)
- run until return from procedure

These 2 commands are usefull in e.g. very fast unpacking/decrypting of protected executable - you just place breakpoint at some executable/DLL export expected called early from executable (like GetModuleHandleA, CreateWindowExA,...) and after hitting breakpoint then using Run until return from procedure.

I looked into Borland Turbo debugger (td32.exe) - my favorite debugger which I abandoned years ago with abandoning 16 and 32 bit world - and the command Run until return from procedure is implemented there (I have never used that command in my whole life, I usually looked into stack and manually determined the return address from procedure, I needed that only very rarely).
The procedure for putting breakpoint at executable export (from the menu Breakpoint -> Breakpoint at symbol) pretends to be a bit clever and guess what do you want to type (it tries to automatically finish the name of export as you started to type it, something like automatically finishing http address in browser). You may turn the auto finishing off if you dislike it. But the automation may sometimes save your time (e.g. for typing IsDebuggerPresent, it is usually necessary to type only first 5 letters, time saving depends on the amount of loaded DLLs and how much unique name you want to type).

edit 2012-10-01 deleted attachment, reached quota limit and newer version available

Hallo Feryno,
a temporary solution for that boring flickering
at the line ~ 3519

Regards,
hopcode

entrypoint old/new kernels:
in old kernels, it was necessary to execute one single step to reach entrypoint (RIP was 0 when intercepting the first debug event), in new kernels RIP is at entrypoint so no necessity to do any extra single step to reach entrypoint

better handling of single step / hardware breakpoint debug events (in case when more events occure at once)

temporary (one-shot) / permanent hardware breakpoints (debug register BP)
syntax of the command x changed also
previously, all hw bp were only temporary
(software breakpoints = memory breakpoints = int3 instructions still remain only temporary)
permanent hw bp doesn't work on older kernels, read the file help.txt how to fix that

new command u (run until return from procedure)

the command l (leave, detach) now waits until debuggee starts to run - previosly fdbg sometimes exited earlier which killed debuggee

Peter Ferrie reported problems with REP prefix instructions overwriting software breakpoint fixed

when doing single step on the PUSHF instruction, single step is avoided which prevents pushing rflags.TF=1 and then detecting debugger and possible mess at following POPF instruction

Why doesn't FDBG stop to debug?
Windows seems confused?

The same idea as in fdbg0022.zip\fdbg0022_samples\entrypoint\a00.asm

Yes, OS is confused, read the above asm file. When debugger captures CREATE_PROCESS in debug loop, debug_event.CreateProcess.lpStartAddress is not set properly so debugger sets the initial breakpoint out of expected entrypoint. But FDBG is able to compare CreateProcess.lpBaseOfImage with IMAGE_NT_HEADERS64.OptionalHeader.ImageBase and in case of mismatch it calculates the address by
CreateProcess.lpBaseOfImage + IMAGE_NT_HEADERS64.OptionalHeader.AddressOfEntryPoint
the procedure is Rambo_FirstBlood_find_entrypoint in fdbg0022\fdbg_debuggee_actions.inc

try to set this feature on:
Rambo -> First Blood

then fdbg should stop at OEP

let me know if the solution doesn't help you

New version for windows.
Tested under windows 2003 server (the same kernel as XP) and windows 2008 server R2 (the same kernel as win7) both OS-es (oldest and newest) at AMD64 and Intel CPU.
A lot of new antidebugs in the archive to train skills / developp and protect your apps. Please test them if you have another OS (especially windows 2008 server = vista). Read corresponding *.asm files how to pass through executables with debugger. Same executables can not be completely stepped/traced (as self debugging), some of them escape from debugger (HideFromDebugger).
Current version may help to both sides of barricade:
- Same samples/features may inspire you to make analysis of your apps harder.
- When analysing executables - comments and saving int3 breakpoints between sessions may help.
Testing and proving stability is very welcome. I let previous version available as its stability is proven by 1 year.

Preliminary AVX version

Excellent and very clean work!
Installed windows 2008 server R2 x64 SP1 under AMD SimNow 4.6.2 public release and must confirm that it runs very well on emulated AMD Bulldozer

Looking at the disassembly, I noticed that the address in movaps is not aligned. It turned out I absentmindedly caused all RIP-relative address to end in 0x58 (char '^'). Trivial to fix.
Also....
How about an 'assemble' command?
Basically, the user would enter an instruction in (limited) fasm syntax into the 'disassembled instruction' column, and the debugger would overwrite the neccessary bytes in memory.
Would this break any other features?

It won't break anything. I didn't have time to add assembler.
Yeah, writing disasm engine requires a lot of work and much more tests than the work itself. It took me about 1 month to write an early version of engine and then a lot of mistakes appeared during following months and years, most of them was discovered in the first 1 year, but now there is more users and testers and everything will be tested earlier and more thoroughly.

Couldn't we just use fasm to get a assembler in fdbg? It would be as simple as:
1. Have fasm assemble somthing like

2. Copy the output file to the process memory.

That is very elegant solution. If Tomasz would allow to use FASM for that, it would eliminate a lot of paralel work and both fasm and fdbg would stay synchronized and compatible as much as possible.

I finaly found the way how to read/write YMM in Linux. Currently you can do not more than display and change YMM registers, the disasm of AVX instructions is not yet possible (disasm wasn't updated thoroughly for few years). Disasm shows you AVX code as illegal instructions but CPU interprets instructions correctly, so you may do single steps through the code (you must look into a_ymm.asm file and ignore disasm output).
Could somebody test that on real hardware (everything was developed using AMD emulator SimNow 4.6.2, vp_bd_phase1.bsd, Fedora 14 x64) - report from one AMD CPU and one Intel CPU would be enough + version of linux kernel used for the test.

I've just made fdbg for uefi x64
UEFI is for me definitely the best platform to create debugger, no need to study OS internals as under Linux, win...
created exception handling + procedures for memory access from my head
target CPU is AMD64, but created also a method for finding branching debug MSRs on Intel (but not tested, please report results if you can test it and have UEFI + Intel CPU)
ymm regs supported but disasm engine doesn't know new instructions and disassembles them in wrong way, anyway, you may step these instructions and inspect/change ymm registers (see the video in the link)

read the file !!readme.1st from the archive as the first step

here some video what is this debugger doing
http://www.metacafe.com/w/8296876

When i place fdbg.efi in /efi/boot/bootx64.efi and choose to boot devices as UEFI, it boots ok. But when i just boot in UEFI Shell and try to run "load fdbg.efi" it show error:


EFI version:

Thats on ASRock A55 Pro3 board, AMD Llano

Also it works ok (loading, printing registers, 'v' and 'w' commands show valid data) on Intel-based system Foxconn + Intel i5

Try FDBG.EFI, I'm pretty sure the load command loads drivers.

I implemented loading executable so no need to ingloriously compile your source code with fdbg anymore

Emulators starts to be UEFI capable so everybody may become UEFI-ready, here all in one pack:
http://fdbg.x86asm.net/fdbg.uefi.0001.qemu.zip
look at PNG images and run the bat file as first steps

Suggestion: support for debugging over serial console or usb debug port