flat assembler
Message board for the users of flat assembler.

flat assembler > Projects and Ideas > FDBG - win64 Linux64 UEFI x64 AMD64 debugger

Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 9, 10, 11  Next
Author
Thread Post new topic Reply to topic
alorent



Joined: 05 Dec 2005
Posts: 201
Hi Feryno,

It looks that your debugger does not handle correctly handled exceptions.

I just create a simple test application which calls SetUnhandledExceptionFilter and I force an exception:

mov rax, 0
mov [rax], rax

My exception handler is called correctly when running under no debugger. If I run it under your debugger, it stays at the exception line and cannot continue execution to my handler.

I have also pressed "Ctrl-F12" but it does not work. Application just exists with CTRL-F12

Is there any problems with FDBG and handled exceptions?

Thanks.
Post 27 Oct 2008, 10:12
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
Hi alorent,

msdn.microsoft.com/en-us/library/ms680634(VS.85).aspx
SetUnhandledExceptionFilter Function
...if an exception occurs in a process that is not being debugged...
...
Parameters
lpTopLevelExceptionFilter [in]
...and the process is not being debugged...

I think the function seems not to be friendly with debugger.
You can pass an exception into app exception handler (if the app has installed it), then the exception isn't captured by the debugger in its debug loop but it is delivered to the app exception handler - see IgnoreExceptions\*.* from included fdbg debuggee samples. This can be set in Rambo -> Ignore Exceptions. These settings are not saved at fdbg exits into ini file and are lost. It is usefull for apps reporting self errors or for antidebugs with self-modifyng code.

I was thinking about the G command. My idea is something like this:
fdbg checks whether code/data/stack window is at the top
if yes, then an edit control is created in address column so you can edit the address without any assistence of mouse clicks
now they are 3 choices:
1. cursor is at the begin
2. cursor is at the end (usefull if you often change only last 1-2 digits of address, avoids the necessity to move to the end of string at first before editing it)
3. the whole address in edit is selected, so if you press any char/digit key the whole string is replaced with that 1 char/digit (most usefull when you e.g. frequently change addresses into something like rip+40, rsi+100 etc., it would save a work to delete the whole sting before replacing it with new one)
Is it the same idea as your, or is it far away of it?
Post 30 Oct 2008, 09:17
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
alorent



Joined: 05 Dec 2005
Posts: 201
Hi Feryno,

Yes! Your scheme seems great for me!!! Very Happy I'm happy to help you with beta testing!

Thanks man!
Post 30 Oct 2008, 10:48
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
Hi alorent,
please try this version. I placed the Goto command into Explore menu and its key shortcut is Alt-G (you can change the shortcut in resource.inc -> accelerator main_keys, the line with IDM_GOTO). If you mind losing windows position settings from version 001A then just copy the original fdbg*.ini file into new file with the name fdbg20081103.ini
Don't forget to try changing the cursor settings in Face -> Various settings -> goto command edit style.
Cursor may be at begin / end / select all.
begin is the default
end is usefull if you often edit only last 1-2 digits of address
select all is usefull if you usually change addresses into something like rip-80, r9+A8 etc

edit from 2008-Nov-03, fixed the ini directory location, updated the attachment
edit from 2009-Jan-02, deleted the attachment, newer version available


Last edited by Feryno on 02 Jan 2009, 12:58; edited 2 times in total
Post 03 Nov 2008, 09:24
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
ini file was not stored in fdbg main directory but was stored incorrectly in the directory with opened debuggee, fixed that, updated the attachment in the previous post
Post 03 Nov 2008, 14:58
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
alorent



Joined: 05 Dec 2005
Posts: 201
Hi Feryno,

Thanks a lot for the update!!! It works like a charm! Smile

All the best for you and your x64 debugger Wink
Post 05 Nov 2008, 11:08
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
implemented the idea from:
http://board.flatassembler.net/topic.php?p=85298#85298

edit from 2009-Jan-15, deleted the attachment, newer version available


Last edited by Feryno on 15 Jan 2009, 06:51; edited 1 time in total
Post 25 Nov 2008, 14:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2795
Location: dank orb
It started by wanting to pass a program to FDBG on the command line, but then I decided to use the wide character strings. Mainly because I didn't want to code another command line parser with it's own set of "features" - kind of used to the problems with CommandLineToArgvW.

Currently, figuring on calling CMD_OPEN and using a flag to conditionally jump over the OFN code.
Code:
{below}    


Last edited by bitRAKE on 27 Nov 2008, 16:53; edited 1 time in total
Post 27 Nov 2008, 06:27
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
Thanks bitRAKE, that's good improvement. I was thinking about passing a debuggee name through command line years ago but because of my laziness, lack of time and a lot of other activities, I have never implemented that. I remember only that I did something to avoid the necessity of clicking on an executable again if it terminates and you want to run it again as a debuggee - the name of program stays in memory so if you open a new debuggee (Ctrl-E) and you press Enter only, the previously terminated program is loaded again as a debuggee (this saves some time if somebody is doing intensively programming and needs to debug a program being developped hundreds of times).
Post 27 Nov 2008, 09:56
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2795
Location: dank orb
The way I learnt assembler there wasn't a separation between the debugger and the editor.

This patch works until I convert more to use wide characters.
Try it cannonically for fun, Laughing

fdbg.exe -e fdbg.exe -a "-d -e fdbg.exe -a \"-d\""
Code:
; process command line options
   call [GetCommandLineW]
      lea rdx,[rsp+8*4]
   xchg rcx,rax
        call [CommandLineToArgvW]
   xchg rcx,rax
        jrcxz .z
    ; save for LocalFree
        mov rdi,rcx
 ; skip program name
 lea rsi,[rcx+8]
  .0:    lodsq
       xchg rcx,rax
        jrcxz .x

        ; only test for options
     cmp word [rcx],"-"
        jne .0
      add rcx,2

       cmp dword [rcx],"a"
       je .a
       cmp dword [rcx],"e"
       je .e
       cmp dword [rcx],"d"
       jne .0 ; skip it
    ; use default options, don't load INI
  .d:     bts [__FLAGS],OPTION_FLAG_d
         jmp .0

  .x: mov rcx,rdi
 call [LocalFree]
  .z:   jmp init_from_file

      ; copy arguments
  .a:   lodsq
       xchg rcx,rax
        jrcxz .x
    mov r8,arguments_max_size
   mov rdx,rcx
 lea rcx,[arguments]
 call lstrcpynW
        mov [arguments_size],eax
  jmp .0
      ; copy executable path & name
  .e:  lodsq
       xchg rcx,rax
        jrcxz .x
    mov r8,OFNMaxFileNameSize
   mov rdx,rcx
 lea rcx,[FileNameBuffer]
    call lstrcpynW
      xchg rcx,rax
        jrcxz .0
    ; indicate executable
       bts [__FLAGS],OPTION_FLAG_e
         jmp .0


; fake lstrcpynW for testing
lstrcpynW:
    push rcx
  .0:   mov ax,[rdx]
        add rdx,2
   mov [rcx],al
        add rcx,1
   test ah,ah
  jne .x
      test al,al
  jne .0
      xchg rax,rcx
        pop rcx
     sub rax,rcx
 retn
  .x:       xor eax,eax
 pop rcx
     retn


init_from_file:
 bt [__FLAGS],OPTION_FLAG_d
          jc init_done
        call    load_ini_file
init_done:

...

__FLAGS rq 1
OPTION_FLAG_d = 0 ; use default options, don't load INI
OPTION_FLAG_e = 1 ; executable loaded at start-up    
Now I can press F9 Ctrl-E {return} from editor and be debugging.
Post 27 Nov 2008, 15:18
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
Hi bitRAKE.
I tried to implement that. Sorry, the implemented command line parser is only very simple and not so good and sophiscticated as your design... Implementing the command line support is done easier than hacking cmd_open proc. It is done at the end of the WM_CREATE proc - the command line is parsed and if there is a choice to launch a debuggee then CreateThread is invoked with DbgThreadStartAddr.
I did few tests and it seems to work well. But the number of paths and managing them (splitting, merging) was quite high, so there may be silent mistakes.
1 known problem for me is caused by the behaviour of OFN dialog.

imagine this - you copy fdbg.exe into c:\windows directory and you open command prompt and point it at path e.g. d:\fasmprog
there is a directory fdbg001D in the d:\fasmprog and fdbg001D directory contains fdisasm.exe and fxa16.exe files so the full paths for both executables are:
d:\fasmprog\fdbg001D\fdisasm.exe
d:\fasmprog\fdbg001D\fxa16.exe

now you invoke the debugger from the command prompt from the path d:\fasmprog using this command:

fdbg fdbg001D\fdisasm.exe fdbg001D\fxa16.exe

(it launches fdbg.exe copied into c:\windows dir and fdbg loads a debuggee d:\fasmprog\fdbg001D\fdisasm.exe, fdisasm.exe takes command line argument fdbg001D\fxa16.exe which points to a file d:\fasmprog\fdbg001D\fxa16.exe)

now everything works and you can debug disassembling (fdisasm.exe) of the file fxa16.exe

restarting it works well (Ctrl-R)
if the program terminates, then you can exit fdbg (Alt-X) and invoke the same command again:
fdbg fdbg001D\fdisasm.exe fdbg001D\fxa16.exe

but !
if you want to reload the debuggee after it terminates (F9 run etc...) using the open debuggee command (Ctrl-E), then open file dialog changes the path from d:\fasmprog\ to d:\fasmprog\fdbg001D\
(open file dialog cannot load executable as fdbg001D\fdisasm.exe but it cuts the directory fdbg001D and puts it at the end of original path d:\fasmprog so now the path is d:\fasmprog\fdbg001D and executable fdisasm.exe is loaded correctly but without the preceeding fdbg001D\. Now the arguments put to fdisasm.exe don't have that updated (in fact messed is better word) so now fdisasm.exe fails to accept input params because it input is wrong so you had to manually delete the fdbg001D\ from the arguments Edit control and leave only fxa16.exe there to have success.

This brokes a bit the automation I wanted to implement.
If in the above sample you invoke fdisasm.exe from its directory, e.g. command prompt is at path
d:\fasmprog\fdbg001D and the shell line is then
fdbg fdisasm.exe fxa16.exe
then there is no problem at all. The problem is only if there is a partial path preceeding the debuggee (fdbg001D\fdisasm.exe).

the cmd line switches are:
-d (stays the same as in previous versions)
2 new params do the same as checking/unchecking 2 checkboxes in OFN:
-n (stop at ntdll.DbgBreakPoint instead of OEP, you can put breakpoint manually at program entry point, it is in the Log window as threadstartaddress=xxxxx)
-t debug only this process (exclude children, debug loop won't intercept exceptions from children processes, it will intercept only exceptions from the process being debugged)
mnemonic is D=default, N=ntdll, T=this (only this process)
switches must follow the fdbg immediatally in any order, then debuggee name and then arguments for debuggee (debuggee will get them using GetCommandLine)

OK, so have a fun, here is the present, that new-year edition. Stress-testing is welcome. Let me know in any case of problems. There is no need to update from ver 001C to 001D if you don't need the command line support.

edit 2009-07-13
deleted attachment, newer version available


Last edited by Feryno on 13 Jul 2009, 07:17; edited 1 time in total
Post 02 Jan 2009, 13:02
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2795
Location: dank orb
Open File Dialog crashes on Windows 7 (beta):
Code:
---------------------------
Exception, please report it.
---------------------------
code=000006BA
addr=000007FEFDAFAB7D
rax=000000007263252B
rbx=00000000000006BA
rcx=0000000005ACE870
rdx=0000000000000001
rsp=0000000005ACED80
rbp=00000000000006BA
rsi=000007FEFE0E0000
rdi=0000000005ACEF80
 r8=0000000000000000
 r9=0000000000000000
r10=00000000056DDAA0
r11=000000000000001B
r12=0000000005ACF110
r13=0000000000000000
r14=000007FEF8201C20
r15=0000000005ACF110    
...error occurs when changing directories with the drop down, or navigating buttons. This is not related to recent commandline changes - errors in both versions.

My current work around is to type a valid path into the file name edit field. For example, "D:" to change to the D drive. Otherwise there is no way to navigate between drives.
Post 12 Jan 2009, 22:11
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
the addr is 000007FEFDAFAB7D which looks like inside of a DLL
fdbg virtual address in somewhere in range 0000000100000000-0000000100xxxxxx
sometimes, crashes occure in DLL if there is a stack misalignment in the app e.g. if RSP is something like 6F018h instead of correct 6F010h, e.g. such procedure:
sub rsp,20h
...
call [MessageBox]
fails inside DLL

the included fxa16.exe checks these "silent bombs" by counting the number of pushed registers with the value subtracted from RSP at procedure prologue

I'll try to download the win7 and test it.

I remembered just now, years ago I produced some executables with damaged resource section and then fdbg crashed when pointing the OFN to the directory containg such damaged executable.
The interesting fact was that simple OFN didn't crash. But fdbg OFN has a hook to extend the default OFN (to have an extra edit control to input command line args and 2 extra checkboxes), perhaps the problem is there.
Post 13 Jan 2009, 12:44
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2795
Location: dank orb
I've re-written both the hook and the proceedure and I can't find anything wrong with either.
Code:
OFNHookProc_Notify:
        cmp [r9+NMHDR64.code],CDN_FILEOK
    jne OFNHookProc_default    
...limits the update of options - instead of on every notify.

It only crashes when the directory is symbolic (My Computer). Maybe this is MS's way of pushing developers to the IFileDialog interface? Laughing I can't find another program that even creates the same OpenFileDialog (minus the added options, of course) that fdbg invokes (strange how MS converts the old usage to use the new interface in most cases).
Post 15 Jan 2009, 06:53
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
OK, here is it.
Now let it run forever.

edit from 2009-11-18: deleted the attachment, newer version available


Last edited by Feryno on 18 Nov 2009, 07:20; edited 2 times in total
Post 15 Jan 2009, 06:55
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2795
Location: dank orb
Thank you very much.
Post 15 Jan 2009, 07:21
View user's profile Send private message Visit poster's website Reply with quote
alorent



Joined: 05 Dec 2005
Posts: 201
Hi Feryno,

I'm using your great debugger!

I was wondering if it's possible for you to add a feature in the Data window to display data as BYTE, WORD, DWORD, QWORD. Currently, you just display it as QWORD but as you might know not all our expected structures in memory are QWORD Wink

Keep up the good work! Wink
Post 31 Mar 2009, 12:51
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2795
Location: dank orb
Sometimes the DIV/MUL instructions do not display the correct register. For example: MUL R8 will show as MUL RAX in the disassembly.
Post 08 Jun 2009, 06:55
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
bitRAKE, thanks for your report, I'll fix that
the same is with e.g. TEST R8B,... instruction
DIV/MUL and TEST problems are because of mistake in analyzing of the REX prefix
I started to implement the idea posted by alorent, but I had only 2-3 free hours to do that since his post (currently not more than 1/3 of the necessary work is done)
Post 08 Jun 2009, 08:07
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
to fix the disasm problem, you can update the file from attachment and recompile fdbg

edit from 2009-11-18: deleted the attachment, newer version available


Last edited by Feryno on 18 Nov 2009, 07:21; edited 2 times in total
Post 09 Jun 2009, 07:58
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 9, 10, 11  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2019, Tomasz Grysztar.

Powered by rwasa.