flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Projects and Ideas > FDBG - win64 Linux64 UEFI x64 AMD64 debugger

Goto page Previous  1, 2, 3 ... , 9, 10, 11  Next
Author
Thread Post new topic Reply to topic
a rabbit



Joined: 12 Oct 2009
Posts: 13
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 Smile
If only it was written in C, that would be perfect.
Post 15 Apr 2013, 17:55
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 439
Location: Czech republic, Slovak republic
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.
Post 16 Apr 2013, 08:22
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 699
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?
Post 22 Apr 2013, 22:22
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 439
Location: Czech republic, Slovak republic

tthsqe wrote:
dissable more instructions


I don't understand...


tthsqe wrote:
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.


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
Post 23 Apr 2013, 05:55
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 699
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?


Last edited by tthsqe on 16 May 2013, 19:29; edited 1 time in total
Post 24 Apr 2013, 06:15
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 439
Location: Czech republic, Slovak republic
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
Post 24 Apr 2013, 11:56
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 699
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...


Description: updated 22-6-2013
Download
Filename: fdbg0025.zip
Filesize: 344.95 KB
Downloaded: 1346 Time(s)



Last edited by tthsqe on 19 Jan 2014, 00:47; edited 2 times in total
Post 25 Apr 2013, 07:10
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 439
Location: Czech republic, Slovak republic
debug control feature at newer Intel CPUs
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


Last edited by Feryno on 03 Jun 2013, 05:17; edited 1 time in total
Post 31 May 2013, 12:31
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2624
Location: dank orb
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. Very Happy


Description: Boardless container window.
Download
Filename: tainer.zip
Filesize: 2.81 KB
Downloaded: 262 Time(s)


_________________
The generation of random numbers is too important to be left to chance - Robert R Coveyou
Post 31 May 2013, 18:25
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 439
Location: Czech republic, Slovak republic
debugctl at ws2008R2 / win7 for new Intel CPUs
in the first patch, there was missing 1 space in the cmd file
the correct line should be:

Code:
sc config peauth startdemand



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


Description: patch to add debug control feature support into windows server 2008 R2 x64 / windows 7 x64 for new Intel CPUs (core i architecture) for UEFI boot as well legacy boot (BIOS)
Download
Filename: add_debugctl_support_ws2008R2_w7.UEFI.BIOS.zip
Filesize: 22.05 KB
Downloaded: 249 Time(s)

Post 03 Jun 2013, 05:16
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1386
Location: Toronto, Canada
When I got FDBG - it tripped my AV program.
Is it false positive or is it really infected?
Post 23 Jun 2014, 02:22
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15158
Location: GW170817

AsmGuru62 wrote:
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.
Post 23 Jun 2014, 02:26
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1386
Location: Toronto, Canada
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.
Post 23 Jun 2014, 03:05
View user's profile Send private message Send e-mail Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 439
Location: Czech republic, Slovak republic
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).
Post 23 Jun 2014, 19:57
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 699
Hmm, as for this debugger, looks like I will have to add AVX 512 support soon...
Post 23 Jun 2014, 20:09
View user's profile Send private message Reply with quote
seppe



Joined: 12 Apr 2015
Posts: 9
Location: Belgian in Tenerife
error when compiling a00 for UEFI
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.


Code:
format PE64 dll efi at 0 on 'nul'       ; possible subsystems are: EFI, EFIBOOT, EFIRUNTIME
entry start

include 'uefi.inc'
include 'keycodes.inc'
include 'padAMD64.inc'
include 'constants.inc'
include 'registers.inc'


section '.text' code readable executable

start:
; rcx = ImageHandle
; rdx = SystemTable

struc   executable_info
{
.ImageBase      dq      ?
.ImageSize      dq      ?
.SystemTable    dq      ?
}

struct  executable_info

struc   fdbg_frame
{
.reserved               rq      4
.executable_info        executable_info
}

struct  fdbg_frame              ; only to determine sizeof.fdbg_frame


a=1                             ; return address from procedure
b=1                             ; pushed qwords
d=(sizeof.fdbg_frame+7)/8       ; stack frame in qwords
c=(a+b+dand 1                 ; align stack at 10h

        push    rbx
        mov     rbx,rax
more . . .
        lea     rdx,[fdbg_frame.executable_info]
more . . .



_________________
Greetings from Seppe
Post 12 Apr 2015, 19:42
View user's profile Send private message Reply with quote
Feryno



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

Code:
        lea     rdx,[RSP+fdbg_frame.executable_info]
        mov     rcx,rax
        call    get_executable_info
; CF=0 -> OK
; CF=1 -> error
        jnc     .L1

.L0:
        mov     rcx,rbx
        call    unload_executable
        jmp     egzyd

.L1:
        mov     rdx,[RSP+fdbg_frame.executable_info.ImageSize]
        mov     rcx,[RSP+fdbg_frame.executable_info.ImageBase]
        call    PE32x64_AddressOfEntryPoint
        jc      .L0

; rax = AddressOfEntryPoint, this is an offset

        add     rax,[RSP+fdbg_frame.executable_info.ImageBase]
; rax = virtual memory of the image entrypoint
        call    set_SW_BP               ; or should we call set_temporary_execute_HW_BP

        mov     rcx,[RSP+fdbg_frame.executable_info.SystemTable]
        call    prepare_uefi_spec_symbols


Very probably after fixing that you'll be able to compile using newest version of FASM
Post 13 Apr 2015, 12:24
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
seppe



Joined: 12 Apr 2015
Posts: 9
Location: Belgian in Tenerife

Quote:
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.
Post 13 Apr 2015, 13:00
View user's profile Send private message Reply with quote
seppe



Joined: 12 Apr 2015
Posts: 9
Location: Belgian in Tenerife
Fasm mistery
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:


Code:
macro disable_branches_recording
{
        push    rax rcx rdx
        test    [debug_ctl_available],1
        jz      @f
        mov     ecx,01D9h               ; DebugCtl
        rdmsr
        and     al,not 1                ; disable LBR
        wrmsr
@@:
;       pop     rdx rcx rax             ; this will be done at int_handler
}

align 20h
int_handlers:

align 20h
int00:  push    0                       ; push fake error code
        push    0                       ; interrupt number
        disable_branches_recording
        jmp     int_handler
sizeof_int_entry = $ - int00
if sizeof_int_entry > 20h
cannot hook interrupts by calling hook_exceptions
hooking must be done manually because int entry exceedes 20h bytes
end if




Thank you for your indispensible Fdbg

_________________
Greetings from Seppe
Post 22 Apr 2015, 18:40
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15158
Location: GW170817
With this code:

Code:
SIZE equ qword
DISTANCE = 1000
use64
macro disable_branches_recording {
                push    rax rcx rdx
                test    SIZE[debug_ctl_available],1
                jz      @f
                mov     ecx,01D9h               ; DebugCtl
                rdmsr
                and     al,not 1                ; disable LBR
                wrmsr
        @@:
}
debug_ctl_available=$+128000 ;just some random value
push 0
push 0
disable_branches_recording
jmp $+DISTANCE  ;int_handler

I get these results:

Code:
;SIZE  DISTANCE result
;byte  100      29
;word  100      31
;dword 100      32
;qword 100      33
;byte  1000     32
;word  1000     34
;dword 1000     35
;qword 1000     36

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.
Post 23 Apr 2015, 01:04
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 ... , 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.