version 0015 for win64
thanx to FRET BeaBA project I was kicked up to think about new antidebugs, so I made one. Years ago, I read about one causing refusing loading exe as a debuggee, but then I didn't discover the reason. Perhaps the idea is the same...
I also made new feature in "Rambo menu" to make the ability to debug such a antidebug - watch_dll\a01.exe in fdbg0015_samples.zip
watch_dll contains nice and child-like simple games with DLLs, read *.txt there
During development of ver. 0015 I also discovered and fixed not much important mistake of displaying stack on unaccessible memory.

edit: deleted attachment because of new version of fdbg

fdbg ver 0016 for win64
added hexa value of eflags part of rflags register - MazeGen's idea
I hope that I definitely fixed stack misalignments

edit: deleted attachment because of new version of fdbg and quota limit

Hi Feryno!

I have found a some non critical bug in FDBG. If you try to open for debug 32-bit application, FDBG is crashes.

Feryno
What you think about to add an opportunity to debug a native 32-bit code?

fdbg ver 0017 for win64
Thank to Garthower, one critical bug was fixed (missing one critical instruction - restoring rbx register before epilogue).
Then I added checking for PE32+ executables, so now 32-bit executables are disallowed. This is because 32-bit instruction set differs very much from 64-bit instruction set.
fdbg itself is capable to handle 32-bit executable but it requires to make new disasm engine for 32-bit opcodes (64-bit one consumed me about 1 month of work 8 hours per day... 170 kB of text... and then a lot of testing)
For debugging 32-bit executables you can use few debuggers, I prefer Borland Turbo Debugger (td32.exe) - I downloaded it free years ago, then GoBug, Olly.
Turbo debugger has the same key shortcuts as fdbg and similar window styles (it is console-mode windowed app).
I also improved disasm of instructions like
4883E0FE and rax,FFFFFFFFFFFFFFFE
(the old style was 4883E0FE and rax,FE)

edit: deleted attachment because of new version of fdbg and quota limit

I understand it, but in fact more conveniently, when this all is able one debugger If at you it will realize desire, I could help with a writing дисассемблера, if you not against certainly.

Hello Garthower,
writing disassembler procedures is task for very long time and requires even much more loooonger testing
fdisasm64_proc.inc has 140 kB
fdisasm64_data.inc has 30 kB
you will be discovering disasm mistakes for several months (maybe years)
I thank very much to everybody who reported any disasm mistake. I don't know how much them still persist there...

ver 0018 for win

- added mutibyte nop instruction for opcodes 0F19-0F1F (demand of antidebug developers, undocumented opcodes, so please let me know if AMD or Intel use something else here)

- something patched for slow vista (vista in my config was so slow that 3 keystrokes repeated in 1 debug loop, so now only 1 keystroke = 1 action is allowed in 1 debug loop cycle

- I discovered (perhaps only rediscovered? please let me know if you has known this trick) 1 win specific antidebug - accidentally when our small daughter disturbed me... I forgot to finish
format PE64 GUI at 000000h
(missing 100 before 000000h) - I was just calculating the muber of zeros there and then I forgot to finish this big number...
Shouldn't we call her the youngest FASM programmer ?
Win loads this exe and places it at offset 10000h instead of 0 (mem 0-FFFF is reserved in ms systems), it produces wrong ThreadStartAddress returned in debug loop and fdbg0017 failed to put initial breakpoint at executable entry point. Now fdbg0018 detects this trick after turning on Rambo -> First Blood.
Please test fdbg0018_samples.zip\entrypoint\a00.exe on other configs (I have tested it on win2003 server x64 SP1), especially testing on SP2 is welcomed, I'm going to test it in vista
Perhaps it works in win32 too, I don't know...
exe header:
IMAGE_OPTIONAL_HEADER64.ImageBase=0
exe is loaded here:
DebugEvent.CreateProcess.lpBaseOfImage=10000h
the shift is the core of the trick
It worked only when IMAGE_OPTIONAL_HEADER64.ImageBase=0
other numbers 0001-FFFF produced files which weren't able to execute...

edit: deleted attachment because of new version of fdbg

new version
heh... I just discovered that few months (maybe years) fdbg supported transformation of DLL exports can be easily used to make symbols in exe
see fdbg0019_samples.zip\a_beginner\*.* and symbols_easy\*.*
you just create exports in exe with desired labels...
now I'm really satisfied with symbols under win64
microsoft's dbghelp.dll (1-2 MB DLL) provides support for "microsoft's way of doing symbols", but is is not very suitable for fasm (and I personally think - for masm either...), it is suitable for other languages

edit from 2008-Nov-03
deleted attachment, new version available

I would like to invite you into testing of new experimental features (I had a presentation about them at 2nd FASM conference)
http://fdbg.x86asm.net/debugging-in-long-mode-in-theory.html
please go to www.amd.com then download 24593.pdf then read chapter 13.2.5 Control-Transfer Breakpoint Features

You must accept the risk of encountering reboots (so save your work etc.)
The safest way is to restart OS and manage everything til 5 minutes (read later why)
Under Vista:
- press F8 at boot
- select Disable Driver Signature Enforcement
- when Vista loads, then righ click on fdbg.exe and select Run as administrator

I need your assistance in especially testing in multi CPU systems. But every report is welcome, please write you opinions about usefulness of new features, successes/failures when testing etc.
I hope the synchronization among all CPUs in multiple CPU system is correct (I'm not able to test it)

If the new features are useful then I'll try to defeat the 5 minutes limit in some way...

under fdbg do these steps:
Sys -> Copy driver into system
Sys -> Install driver
Sys -> Start driver
Sys -> Hook Exceptions (this is the only one dangerous step, you need to unhook exceptions until 5 minutes limit, else Patchguard reboots OS - read later)
Sys -> Enable Branches Recording
Debuggee -> Open executable (Ctrl+E) -> select z.exe from fdbg package
Action -> Run (F9)

then you should see something like:
Exception. ProcessId=00000CB4h ThreadId=00000414h Address=0000000100001047h ExceptionCode=C0000005h=EXCEPTION_ACCESS_VIOLATION first_chance
LastBranchFromIP=0000000100001047h
LastBranchToIP=FFFFFADFE51496E0h
LastExceptionFromIP=0000000100001026h
LastExceptionToIP=0000000100001040h

after you finish, unhook eceptions or stop driver (stopping driver unhooks exceptions before driver unloads)
Sys -> Stop driver
Sys -> Remove driver
Sys -> Delete driver from system

If you want to test Sys -> Step on branches feature, then you also must hook exceptions. Then Action -> Step into (F7) will do "bigger" steps (only on branches) instead of standard single steps on every instruction.

Note - addresses in branches:
FFFFFxxxxxxxxxxxh means address in OS kernel (fdbg.sys driver) - address of exception handler
0000000078xxxxxxh means address in user mode system DLL (e.g. kernel32.dll)

Hooking interrupts is very hot action. Win x64 (XP as well Vi$ta) checks kernel integrity and reboots PC when any of protected parts of kernel and CPU settings is compromitted. The interval of checks is randomly between 5 and 10 minutes.
So, you must reboot your PC, do what do you want and UNHOOK interrupts til 5 minutes since boot.
If you don't manage it or you leave interrupts hooked 10 minutes, then you certainly encounter BSOD (blue screen of death) with something like this:

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d89322659e, Reserved
Arg2: b3b7465ee59ffeab, Reserved
Arg3: fffff80002865070, Failure type dependent information
Arg4: 0000000000000002, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification


I have a theoretical design how to cheat the Patchguard, I need a time to do it in reality... (and reports about usefulness of new features)

The reward for a long reading - the link for new experimental features of fdbg:
http://fdbg.x86asm.net/fdbg001A.zip

I discovered a backdoor in windows which enables safe operations with branches. So you don't risk reboots with driver. The game can be easily played from safe user mode (ring3). If somebody is interested, I can post more details (backdoor is a bit described in fdbg package). This is not the final 001A version, I posted it to you stop the testing of fdbg driver. After completing some things, I'll post here the whole package (debugger + samples) as an attachment.
here only links to unfinished version:
updated unfinished debugger
http://fdbg.x86asm.net/fdbg001A.zip
samples, I recommend them if you want to study plays with branches
http://fdbg.x86asm.net/fdbg001A_samples.zip

P.S. it was a very huge satisfaction for me to discover this undocumented feature of microsoft operating systems and I really admire the guy who developped this clever trick by this way. I really don't understand, why ms didn't make this information publicly available (it is very clever trick, it can't be abused for malware, etc).

and here a link to an article about the easy ring3 method:
http://fdbg.x86asm.net/article_DebugCtlMSR_backdoor_in_win64.txt
a bit long reading, so in shortcut: for enabling branches in win x64, just set some bits in debug 7 register (DR7.LE, DR7.GE). That's all ! Simple, huh? Unbeliable and funny? No, that way really works under current versions of x64 windows.

This article will be released in HTML format at x86asm.net soon. Stay tuned.

Nice article Feryno, thanks for posting. About 32-bit versions, do you think that it could be possible for this backdoor to exist? Because according to the AMD manual, legacy implementations does not ignore DR7.LE nor DR7.GE.

I tried only a quick search for opcode mov ecx,000001D9h (db 0B9h, 0D9h, 1, 0, 0) in 32-bit XP ntoskrnl.exe and there isn't such instruction, so I suppose 32-bit windows doesn't have this backdoor.

Here we go.

Backdoor Support for Control-Transfer Breakpoint Features in Windows x64

and here the finished fdbg version 001A for win64

edit from 2008-11-25 deleted the attachment, newer version available

Hi Feryno,

I love your debugger! I was wondering if there is a way to save the current status of all the Windows (from Face menu) like Workspaces in WinDbg.

So, I can place all my desired Windows (regs, memory, disassemby, ...) across the screen and everytime I restart FDBG, all my Windows are restored to the last positions.

That would be a nice feature for FDBG

Keep up the good work!!!

yeah, saved automatically in an *.ini file (but the file contains binary data, not human readable text...)
sometimes it lasts too long to minimize 10 MDI children windows on debugger startup... (depends on windows animation effect settings set by the OS)
Because they are MDI children they all must fit into parent window unlike windbg windows...

I'm quite unhappy about Intel DebugCtlMSR incompatibility in Core2Duo and CoreQuad CPUs with older CPUs and with AMD64 - Single step on branches and Last branch recording doesn't work on Intel C2D / C2Q...

Hi Feryno,

Thanks a lot for the hint! I cannot believe that feature was present and didn't see it!

I prefer your debugger than Windbg, though I still miss a bit more flexibility in your user interface.

It would be great in the data and code windows to have more options when you press the mouse right button, like "G --> Goto address", where we can introduce the new address to watch.

At the moment, I have to double click on the address and it's quite annoying many times to go into the edit mode in your list box. Hopefully, I'm not too exigent for you

Thanks!!!!