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 ... 7, 8, 9, 10, 11  Next
Author
Thread Post new topic Reply to topic
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
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:
Code:
cs:0100  EBFF      > jmp 0101
cs:0102  C3          ret
cs:0103  90          nop

after single step:
cs:0100  EBFF        jmp 0101
cs:0102  C3          ret
cs:0103  90          nop

after another single step:
cs:0100  EBFF        jmp 0101
cs:0102  C3          ret
cs:0103  90        > nop    


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:
Code:
0000000100001000  EBFF      > jmp 0000000100001001
0000000100001002  C3          ret
0000000100001003  90          nop

after single step:
0000000100001001  FFC3      > inc ebx
0000000100001003  90          nop

after another single step:
0000000100001003  90        > nop    


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


Last edited by Feryno on 11 Jan 2011, 09:18; edited 1 time in total
Post 18 Nov 2009, 07:26
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
Feryno, thank you for your continued 64bit efforts!
Post 18 Nov 2009, 13:38
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
alorent



Joined: 05 Dec 2005
Posts: 201
Thanks Feryno for your work!!! Hope this project goes ahead with new updates Wink
Post 09 Dec 2009, 18:57
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
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


Last edited by Feryno on 01 Oct 2012, 09:44; edited 1 time in total
Post 14 Dec 2009, 13:05
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
Hallo Feryno,
a temporary solution for that boring flickering
at the line ~ 3519
Code:
List_NewProc:
;the following lines -----------------------------cut
 cmp edx,WM_ERASEBKGND 
 jnz @f                            
 xor eax,eax
 inc eax
 ret
@@:
;-------------------------------------------------end
;...
;List_NewProc_CallWindowProc:
;...
    

Regards,
hopcode
Post 14 Dec 2009, 22:45
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
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


Description: FASM friendly debugger for Linux x64
Download
Filename: fdbg0011.tar.gz
Filesize: 177.65 KB
Downloaded: 1474 Time(s)

Post 15 Jan 2010, 09:47
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2791
Location: dank orb
Why doesn't FDBG stop to debug? Very Happy
Windows seems confused?


Description:
Download
Filename: nostop.zip
Filesize: 792 Bytes
Downloaded: 469 Time(s)

Post 28 Nov 2010, 05:47
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 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
Post 29 Nov 2010, 09:38
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
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.


Description: fasm friendly debugger for x64 versions of ms Windows - Windows XP / Windows 2003 server , Vista / Windows 2008 server , Windows 7 / Windows 2008 server R2
Download
Filename: fdbg0023.zip
Filesize: 528.1 KB
Downloaded: 612 Time(s)

Post 11 Jan 2011, 09:25
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 721
Preliminary AVX version


Description:
Download
Filename: fdbg0024_avx_tmp01.zip
Filesize: 451.79 KB
Downloaded: 436 Time(s)

Post 31 May 2011, 08:20
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
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
Image
Post 02 Jun 2011, 11:41
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 721
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?
Post 02 Jun 2011, 21:46
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
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.
Post 03 Jun 2011, 07:04
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 721
Couldn't we just use fasm to get a assembler in fdbg? It would be as simple as:
1. Have fasm assemble somthing like
Code:
use 64
org 0x1234567890
add rax,rbx    

2. Copy the output file to the process memory.
Post 16 Jun 2011, 19:45
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
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.

Image

Image

Image

Image

Image


Description: for testing reading/writing AVX under Linux
Download
Filename: fdbg0012_tmp02.tar.gz
Filesize: 156.3 KB
Downloaded: 393 Time(s)

Post 17 Jun 2011, 08:54
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
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


Description: fdbg uefi x64 version 0000
Download
Filename: fdbg.uefi.0000.zip
Filesize: 121.86 KB
Downloaded: 356 Time(s)

Post 30 Mar 2012, 07:50
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
XVilka



Joined: 04 May 2011
Posts: 42
Location: Russia
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:
Code:
fs0:\> load fdbg.efi
load: Image fs0:\FDBG.EFI is not a driver
Exit status code: Invalid Parameter
    


EFI version:
Code:
EFI Specification Revision: 2.10
EFI Vendor: American Megatrends
EFI Revision : 4.641
EFI Shell Version 1.0
EFI Shell Machine Type: X64
EFI Shell Signature: ....
    

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
Post 30 May 2012, 10:52
View user's profile Send private message Visit poster's website Reply with quote
STLVNUB



Joined: 08 Aug 2008
Posts: 13
XVilka wrote:
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:
Code:
fs0:\> load fdbg.efi
load: Image fs0:\FDBG.EFI is not a driver
Exit status code: Invalid Parameter
    




Try FDBG.EFI, I'm pretty sure the load command loads drivers.
Post 18 Jun 2012, 04:55
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 447
Location: Czech republic, Slovak republic
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


Description: fdbg uefi x64 ver. 0001
Download
Filename: fdbg.uefi.0001.zip
Filesize: 125.21 KB
Downloaded: 337 Time(s)

Post 26 Jul 2012, 07:31
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
XVilka



Joined: 04 May 2011
Posts: 42
Location: Russia
Suggestion: support for debugging over serial console or usb debug port
Post 30 Jul 2012, 10:44
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3 ... 7, 8, 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.