Is there a more centralized location other than searching through all the posts on all 6 pages to find both the current linux and windows versions?

Linux version with updated disasm engine (nothing more changed since the previous version)

according the idea posted by kdownload - the first post of this thread will now point to latest versions

thank you =)

...isn't it better you point to
a) http://feryno.host.sk/ or
b) http://fdbg.x86asm.net/

this windows version has fixed disassembling problems with R8-R15 byte/word/dword/qword registers for group of instructions like TEST, DIV/IDIV, MUL/IMUL, NOT
implemented also various formats of displayed data (qwords/dwords/words/bytes) - to rotate among them, click on any column header in Data 1st, Data 2nd, Data 3rd
improved speed performance if you minimize unnecessary MDI windows: the less windows displaying info, the better performance (filling more than 200-300 items in 14 SysListView32 may sometimes last longer than keystroke repeat delay on huger OS running on slower CPU, especially under vista/win2008server updating all items lasts terrible long)

please let me know about stability, functionality and feelings about performance

I'll upload newer version into locations posted by Madis731 only after some positive reports, before that only FASM forumers have this version.

edit from 2009 October 02
deleted the attachment, new version available

Great work Feryno!!!

I'm going to check it soon!!!

I discovered one bug, fdbg001F for windows may crash if you try to use the Search function, the reason is one missing input parameter, to solve the problem, you need to update the file from attachment and recompile fdbg

edit from 2009 October 02
deleted the attachment, new version available

new version for windows x64
fixed few bugs
DebugCtlMSR feature backdoor is supported for Intel in windows 2008 server x64 R2 (the same kernel as windows 7 x64) - not thanks to me but thanks to windows kernel programmers (somebody implemented branching feature backdoor support for Intel CPUs into kernel)

people having older x64 versions of windows (like XP, windows 2003 server) can compare the slowness of filling SysListView32 under newer versions of windows, to improve performance (not to wait upto 1 second to finish displaying every step) I really suggest you to minimize unnecessary MDI children windows and let displayed only Code/Data/Stack windows + GPR + Flags + what you need (e.g. XMM), then the performance is acceptable on newer windows versions running at slowlier CPUs

edit from 2009-Dec-14
deleted the attachment, newer version available

Hi Feryno!

Your debugger is really impressive, great work!
I have a couple of suggestions:
- Add a support to the mouse wheel.
- Enable drag'n'drop.
- Don't scroll the code window on step over/into, unless the command is not visible.
- An assembler would be really nice

That's all for now, keep it up!

Shouldn't this be done automatically by your OS?



I do know that the linux version is a terminal program, so i assume the windows version is, so i don't think there's much that can be done about that. The whole point of using a terminal window to do this is that it does most of the design work for you.



Look at your address bar.

No.
And the version for windows is GUI based.


Yeah, FASM rules as heck, but I was talking about some simple one-command built in assembler, so that I could insert some command in a second.
I won't fire up FASM for that.

And I have another one:
- When double clicking on a value to copy or change, make it selected right away.

Pardon me, i use linux so i didn't know which version you were testing and i sort of assumed they were both similar. And because of that, i should probably not talk too much about your requests then.



Ah, that'd be nifty. Just remember that it'd be a pain to resume right where you left off before adding code (thus why even MS doesn't allow it with their debuggers).

Here's how FDBG for windows looks like:
http://fdbg.x86asm.net/fdbg000C_screenshot.png


OllyDbg does
A great debugger, but it does not support x64.

And some more!

- Would be great if FDBG could highlight jumps and calls.
- An option to set a breakpoint while process is running would be also useful.

And a couple of bugs I encountered:
- If you put a breakpoint, break on it, and remove it right away, before resuming the program or stepping away, an INT3 command appears on that spot.
- FDBG does not accept paths with spaces in the command line, like:
FDBG.exe "C:\new folder\1.exe" -switch
- If a new thread is created, the code window updates itself and jumps to a new location, really bothering in a multi-threaded program.

Sorry for spamming your topic

Hello,

A few more improvements (if Feryno is in the mood)

1) When a conditional jump is going to be executed (jcc instruction highlighted), put a string on the right or something that says if jump is taken or not

2) The current instruction (highlight cursor) is always the top one (on the disassembly window). It would be great if the highligh cursor moves down when instruction is executed, instead of refreshing the window and put again the current instruction the top one. This is a good feature as it's "good" to see previous executed instructions when we are tracing (this is the common behavior in OllyDbg, WindDbg, etc)

Keep up the good work

Thanks!

to alorent - the 2)
you may still look into code 2nd which is not updated to RIP, if you need to update it, put the string:
rip
at any address location after clicking on it


more difficult things to solve - reply to a rabbit:

there is a lot of colors in code windows and their possible combinations, I don't plane to add more colors
then another thing - what to highlight in such code sequences like:
EB01C2EBFFE1
or what to highlight in this second sample:
E9FFFFFFFFC0



problem with breakpoints
bp may be temporary (one-shot), or permanent (much harder to implement to work)

there is no problem with temporary bp
the scenario of its handling is very easy:
software bp is set at some address by user (e.g. pressing F2, or from one submenu of the menu Breakpoint -> ...) or is set by fdbg itself (e.g. at the entrypoint of exe when loading it as debuggee)
fdbg records the address of the bp and its flags (temporary bp) and PID (process ID), saves the original byte from the address of the process, writes byte 0CCh there
thats all about preparing soft bp
when such temporary soft bp hits, the handling is also very easy:
fdbg looks into its internal records for matching process and address and it finds in fdbg internal records that such bp was set by user or fdbg itself with temporary flag into that address of that process (if fdbg doesn't find anything matching, then the instruction of the breakpoint should be incompiled into the debuggee, e.g. the forgotten instruction int3 should be present in the source file of the project, or user manually edited some part of the code into byte 0CCh or into word 0CDh, 03h)
fdbg restores the original byte of debuggee (the original byte was overwritten with the byte 0CCh = instruction of soft breakpoint) and erases its internal records about the breakpoint
then fdbg decreases the RIP (calculating the subtraction RIP-1) of the thread hitting the temporary breakpoint (because RIP points after the instruction of the already removed int3, soft breakpoint is trap type of exception, it is completed so RIP is updated to point after the instruction, so we must restore the RIP 1 byte back)
thats all

there is a plenty of simulations to implement permanent breapoint, I was quite happy when I successfully finished that made to work (look for try_rest_from_previous in fdbg_DebugLoop.inc file)
there is the same ammount of work to set permanent software bp (the only one difference is that fdbg stores different flag about that bp in its internal buffer telling that this bp is permanent = until user deletes it by its own intervention)
when the permanent soft BP hits, fdbg must temporary pretend that this bp disappeared to allow debuggee to continue and after the debuggee continues its execution, fdbg must set this breakpoint as soon as possible
the disappearing must be done really, there isn't any choice to simulate that, it means fdbg really erases the bp as in case of temporary breakpoint (restores the orignal byte at the address of the process, calculates the subtraction RIP-1 of the thread), then it must wait for the first debug event of the thread and set it again (fdbg calls the procedure try_rest_from_previous)
as soon as possible means that fdbg must execute one single step if you execute run (F9) or step over (F and then immediatelly set the soft bp again (there is still a choice of incorrect behaviour when e.g. DebugCtl.BTF=1 when single step takes more instructions to complete and theoretically the soft bp may be missing during all instruction executed during this single step (rflags.TF=1) with DebugCtl.BTF=1
for hardware breakpoint (writing debug registers of thread) there is an easier way than for software breakpoint (writing byte 0CCh into process memory), for hw bp, there is enough to set RFLAGS.RF bit (resume flag) to pass through permanent hw bp, but in real life, the above simulation method worked better than this way implemented by CPU designers (setting rflags.rf=1), the way by rflags.rf was implemented in one older version but the next version I reverted back to the simulation method

so my suggestion to you is to use temporary breakpoint type if you plane to erase it immediatelly after hitting it (in fact, you don't need to erase it, it is erased automatically by fdbg without your intervention because temporary bp = one shot bp)
currently I don't see any way how to cheet life and implement another simulation method to implement permanent soft bp (but perhaps I will have some ideas in feature and I'll implement it in better way)
I think your problem with bp was caused by something staying in fdbg internal buffers to do after calling try_rest_from_previous, perhaps it may be erased when user tries to delete permanent soft bp, I just don't wan't to damage the currently almost perfectly working vulnerable way)

I will see what can I do, I will schedule this problem with the highest priority if I have a time



problem with 'messing' code 1st window when creating new threads
code 1st window is updated every debug event (somebody may prefer to see every debug event, not only debug events in only one thread), but you may still look into code 2nd window which is not updated at debug events so the code 2nd window is not 'messed' with debug events (but its disadvantage is that it may be off the current thread instruction pointer, most of time it is off RIP)
you may update code 2nd window to current thread RIP in this quickiest way:
click on the title bar of code 2nd window (or activate it using CTRL+TAB / SHIFT+CTRL+TAB rotating among all MDI childred windows of fdbg)
press ALT+G (or Explore -> Goto)
press SHIFT+END (or double click on the hexadecimal address, or press 16 times DELETE, or hold the DELETE once and keep pressed long enough, etc)
type these 3 characters: rip (so then the original 16 bytes long hexadecimal address e.g. '00000001000019C0' is completely replaced with the string 'rip'
press ENTER




problem with command line
fdbg parses command line with very simple algorythm which is not too much powerfull
it tries to read the first char of every string, if it is "-" then it takes it as switch for fdbg
the first string which doesn't start with "-" is taken as debuggee till the complete rest of command line (program + params of the program)
spaces aren't allowed, your path to debuggee must be without spaces




sorry for long story and exhausting reading, but these problems couldn't be explained in shorter way (especially breakpoints)
perhaps there is nobody who would like to share its own ideas how to implement handling of permanent software breakpoints and perhaps there is no one article about that over the whole internet freely available to downloading and reading, I don't know, I developped my own way, it is still a choice that somebody have a patent for the same way, I don't know, I didn't investigate it, I just wanted that people will have this choice freely available to use to simplify their work, but now I can see, that such way may fail in some exotic situations and give unpredicable results, that's life... I will see what can I do with that. Currently I' m very busy, I don't expect perfectly working solutions in few weeks or few months.

Thanks for the replay, Feryno.


I don't think using two code windows is a good solution.
I also suggested not to scroll the list in my first post of this topic.


Look, for example, how OlldDbg handles highlighting:


You see right away what the code is about. Very useful.


And why is that useful? I see the info in the log window, that's enough.
It's correct to update it on an event like an exception, but a thread creation? I don't think so.

Also, this would be really handy:

Then you could go to an address on double click, instead of 4(!) clicks.

Keep up the good work!

When double clicking on a value to copy or change, make it selected right away.
- very easy to implement, so you need only 2 clicks instead of 4 clicks - I'll add it as a choice into the face menu something like a checkbox with 'double cliking on address selects the whole address also'
don't forget that you may also put something like:
rip
as the address instead of hexadecimal values (or even another 64 bit register, e.g. rsi, rdi, rsp - usefull in data windows)

perhaps I may also add similar checkbox with "don't update code 1st on thread creation"

highlighting jumps and calls (perhaps every branching instruction) - now I understand your idea, but I don't plane to add more colors than currently

I'll see how much time I'll have to implement that. Currently I'm very busy. When I started to work on debugger, I had only girls, it was perhaps 5 years ago, I don't know it exactly. Now I have wife + we have 2 small children (3 years, 1 year). Currently I have 3 jobs (40+12+10 hours of paid work per week). 4-5 years ago had only 1 job (40 hours of paid work weekly) - in old years I was able to work on debugger even 8 hours in some days (not every day). I need 1 extra life to satisfy all requests (1 extra paralel life would be the right solution, or 2-3 paralel extra lifes would be even better) - although that impossible dream, currenly I'm more happy and lucky man than 5 years ago and my life is now more meaningful than years ago.

Wow, you are busy
I've just finished school, going to the army in a month...


Yeah, I use it quite frequently in fact.
OllyDbg has a hotkey to go to RIP (EIP for Olly, 32-bit) right away.

I would probably tweak it a bit if it was written in C, which I'm more experienced with than asm. For me, asm is a pain in the ass for large projects

Thanks for your reply Feryno!

I'm glad for your new life. Family is always more important than computers....though, some times, we are so inmersed on computers that we forget that

Just take your time to implement it

Thanks!!!