Well, in fact, I wanted to polish the usability of the interface on Windows, rather than doing fancy stuff like supporting new platforms or booting under BIOS.

Here are some of the stuff I'd like to have done:
http://board.flatassembler.net/topic.php?p=103282#103282
http://board.flatassembler.net/topic.php?p=103332#103332

I'm not sure how far I'd go with FASM sources, though. I know ASM, but I'm not used to actually program with it, only temper with binaries
If only it was written in C, that would be perfect.

I'm totally unable to produce anything in C.
I even usually have problems to understand sources written in C (especially operations with bits etc) - I prefer to disassemble binary and then I understand everything.
FDBG started as a FASM sample for newly born win x64 platform (in early stages, I still have images of beta versions of win server 2003 x64, ms didn't remove the links till today).
The performance of FDBG win x64 GUI is catastrophic (hundreds of ListView Items, coloring them in own procedures etc). But I think it is easy and intuitive to use it for beginners.

Yeah - I think we on the board here should try to improve windows fdbg in the following ways:

1. dissable more instructions
2. better gui (I agree with all of the rabbit's suggestions here)

As for #1, I did sucesufully rewrite the dissasmbler engine for avx (it's a few pages back), but I would need to hints from Feryno on on how to link it with the gui to make everything work correctly.

Hopefully the rabbit can work on #2?

I don't understand...


you compiled everything correctly
later I found a bug to fix in my code (described in my latest release - I was coding the buggy part at nights about 6 or 8 years ago) - you shoud fix the same in your release

I was in too much of a hurry at that time - I meant to say "disassemble"
I was able to get the jcc instructions to display YES/NO correctly but as, you can see, fdbg is trying to dislpay the content of certain memory addresses after the ";".
Im not sure what to do about this.
Hopefully if I get the bigger disassembler working correctly you can add it to the official version?

hi, if you want to show more disassembled instructions then increase the size of code window (more lines), but it is limited to max. 64 instructions (for performance reasons, fdbg tries to get fresh content every step it does - e.g. self modifying code may change its content) - you can tweak that in fdbg_constants.inc - navigate there to MaxInstructionsToDisplay
fdbg always tries to get the content of memory when an instructions is attempting to access it
it also tries to resolve any label before disasm (call address2symbol)
after disasm, call post_disasm_pro is responsible to show the content of memory - you want to disable this, so go to syslistview32.asm and search there for disassemble_one_instruction
then look about 10 lines above and below this line for address2symbol, post_disasm_pro and disable that
currently there are some disasm engines for x64 available as free projects - but only a few of them are capable to resolve memory address and memory size when an instruction tries to access memory

post here your versions (don't forget to add you as the developer) and I update the link at the first post in this thread to point to your version

So the first thing I'll try is understanding how your code works.
Then, I'll try to to improve the speed(it is currently really bad)/user-friendliness of the interface. I hope the result will be something that looks like ollydbg but uses the core functions that you built.
Fortunately, the code is well-commented so it shouldn't be too bad.

I remember contacting the author of ollydbg to see when he would release a 64bit version, and he said he was working on it. That was 5 years ago!

Here is a new version.
see the news file for comments
If I did break something, please let me know what I broke and how it should work correctly...

Giulia Scrammed notified me few weeks ago about problems using DR7.GE as shadow for DebugCtlMSR.BTF under windows 7.
So I did a small binary which worked at me fine.
But soon a reply from Giulia come that it doesn't work.
I ran the sample at another PC and found that single stepping on branches really doesn't work there. The first PC where it worked was Core 2 Duo (single stepping on branches and also recording Last branch from / last branch to), the second one where it didn't work was Xeon (cpuid with input eax=1 reported eax=000306A9h which means family 06h, model 3Ah).
AMD cpus are not affected (I hope), this extended debug feature works well there (because the same debug ctl MSRs in all AMD64 and no variations as at Intel). For AMD the feature was present since windows server 2003 = XP x64 (Intel x64 CPUs were not yet available), for Intel it was added in windows server 2008 R2 x64 (windows 7 x64) but only for Intel CPUs present at the time of releasing that OS.
So debug control feature is not supported by win server 2008 R2 (win 7) at new Intel CPUs.
I found where is the problem and realised to create a patch to add the support.
Because patching ntoskrnl.exe triggers Patchguard (=BSOD), it required disabling Patchguard. Such method was already developed by fyyre (member of fasm forum) and released to public. Fyyre also described how to bypass driver signing necessity.
In my patch, I modify 2 bytes in ntoskrnl.exe to add support for debug control feature. Disabling patchguard and driver signing is research done of fyyre.
I would like to ask you to test the patch. You should be familiar with bcdedit command to delete the patch in case you start to unlike / hate it.
Original kernel won't be modified, new 2 kernel binaries will created and a boot menu entry will be added to boot menu.

requirements:
- Intel Core i3, Core i5, Core i7, Xeon based on Core i architecture
- windows server 2008 R2 x64 / windows 7
- be not afraid of encountering BSOD (but very probable it shouldn't happen)
- use fdbg for ms windows and toggle any of (or both) menu Control -> DebugCtl...

to apply the patch, run the patch.cmd file, it requires to launch if from 64 bit parent (e.g. from desktop), if you launch it from 32 bit parent (as e.g. 32 bit total commander) then bcdedit won't work

after applying the patch and rebooting, fdbg should be able to do single stepping on branching instructions (instead of only at every instruction) and it should corectly record LastBranchFrom / LastBranchTo so these addresses won't be 0 (reported in Log window).

the patch modifies 2 bytes in procedure KiSetFeatureBits in ntoskrnl.exe to add support for DebugCtl and another modifications to disable patchguard and driver signing (method developed by fyyre) and it corrects some mistakes in validation of canonical address form - I reported it to Landy Wang so it is calculated correctly in windows server 2012 / windows 8


if you want to contribute, please report these 3 things:
- result (patch works / patch doesn't work)
- the Intel CPU you used - most valuable is reporting result of CPUID with input eax = 1 so family / model may be extracted
- OS including installed updates / hotfixes only concerning ntoskrnl.exe (or size + some CRC of ntoskrnl.exe as e.g. MD5) and also method of booting (BIOS / UEFI) - currently supported only for BIOS, not yet UEFI (probably I'll implement the support for UEFI soon)

here my test:
result = working
cpuid with input eax=1 reported eax=000306A9h which means family 06h model 3Ah, it is Intel Xeon E3-1230V2
windows server 2008 R2 x64 SP1 clean installation (no hotfixes / no updates) installed and booted via BIOS

edit from 2013-jun-03
deleted the patch, newer one available with not only BIOS but as well UEFI boot support

What are your thoughts on using a borderless container window for all the views. We could really regain a lot of screen space, or work better in lower resolutions. I've coded up a quick example of how the user can size the windows and then lock them down. If you are interested I'll also code routines for auto organizing, cascade, etc. -- as needed.

As you can see I've made the whole client area usable to move the window. Child controls put on top are not effected by this. So, it affords a great flexibility. Would probably need to sub-class the listviews to make them pseudo-transparent.

Eh, looks like I got the toggle backwards.

in the first patch, there was missing 1 space in the cmd file
the correct line should be:


but here newer patch which supports UEFI also, so I'm deleting the older patch and leaving only this new one

When I got FDBG - it tripped my AV program.
Is it false positive or is it really infected?

The problem is your AV. Just remove it. If you still want some (weak) assurance you can use virustotal.com and see what other AVs have to say about it.

The self_dbg samples are coded in a way, that AV does not like.
Rest of the package is good.
No need for freaking virustotal.

I included some samples to learn how to debug them. I like antidebugs very much. The self_dbg is very efficient technique, I learned it from 16 bit ms dos viruses about 20 years ago. Few years ago I ported it into 64 bit mode. Only the one instruction which is going to execute is decrypted, its execution causes single step exception at which the already executed instruction is encrypted back and the following instruction is decrypted and going to be executed. The parent process becomes debugger and handles debug events (like single step exception) and the child process is debuggee (where always only the one instruction to execute is decrypted). Unfortunately this is the only one sample which cannot be easily debugged (because the parent process is debugger and then using another debugger don't help too much).

Hmm, as for this debugger, looks like I will have to add AVX 512 support soon...

Hi Feryno,

I get the following error when I try to compile the Fdbg for uefi:

Flat assembler version 1.71.17
src\a00.asm [66]:
lea rdx,[fdbg_frame.executable_info]
error: invalid use of symbol.

A disassembly of your executable shows:
0x1065 lea rdx,[rip-0x104C]
Is this a structure in the PE_header? Please explain.

Thank you for your indispensible Fdbg.efi.

Hi Seppe, I used some older version of FASM, I can't remember which one, very probably it was some 1.68.xx

You are right, it is mistake, RSP is missing everywhere before fdbg_frame so structure is incorrectly placed in header at runtime. It should be:

Very probably after fixing that you'll be able to compile using newest version of FASM

Yes, it compiles at lightspeed without errors, and the resulting executable seems to work fine.
In case you wonder what I'am up to:
I intent to integrate Fdbg in my UEFI source level debugger.
Theoretically I only need to take over the commandline input and the text output.
Thanks a lot.

Hi Feryno,

I mix your Fdbg sources with my sources to obtain a two-level debugger in UEFI.
Your code is meant to take care of the low level disassembly and breakpoint handling.
I've got your disassembly routine to work fine.
However, when I include 'exceptions.asm', Fasm reports:
cannot hook interrupts by calling hook_exceptions . . .

I do not understand why the int00 code takes 32 bytes or less when assembled with your sources, and more then 32 bytes when mixed with my sources.

Could you please hint me what my mistake could be?


Here is an excerpt of the concerned code:



Thank you for your indispensible Fdbg

With this code: I get these results: So depending upon the size of debug_ctl_available and the distance of the jump you will get different output sizes.

BTW: because the constant is '1' in the test you can always use the override size of 'byte' as long as you are not concerned about causing a page load if the variable is unaligned.