Do you plan to code your own analyzer?

Don't be so mean on each-other. Why not join forces and have a nice 64-bit debugger.

Thanx, Alorent, I am going to fix it.
I divided project to several parts. Disassembler part will be finished soon. Disassembling not much usefull FPU opcodes is done, SSE part is in middle, I need about 5 hours to finish disassembler completely. Maybe after weekend it will be done... I spend much time with my girl, in my job, by sports... The only thing that I make in my home PC is win64 debugger project. After I finish disassembler part, I will continue developing of debugger (better GUI, finish remove breakpoints, attach process, read/write/edit process memory...).
Everybody who want cooperate and help will be appreciated.
Source code is about 250 kB but is full of shits and my comments...
Disassembler routine has 95 kB and disassembler data 20 kB. Everything need only a lot of time or united forces of assembler coders !
I tried to develop fast disasm, I avoided use conditional jumps, I tried to use conditional moves instead of slow jumps, but there is a lot of things to optimize, especialy routine "universal disasm of memory part of opcode" at begin of disasm. Routine works, I fixed several bugs in it and has not nice jumps that are patches. I don't want to touch it because it works OK after 5 weeks of work. I am tired of fixing bugs in it, it was very frustrated for me when I finded bugs after 5 weeks (5 weeks I thinked that it's OK, but it wasn't OK and maybe now it is).
I use "Flinstones" method of make resource in win64, but it works OK (include binary part of resource.obj and patch offsets of rsrc section in executable). This is because I'm a llama for macros and I'm not able to do it as real coder do.

My x64 computer is comming soon, so I look forward to try your debugger. Keep up your good work!

Thanks Feryno. Very good work with the splitting of the source code

It will take me a long while to understand most of the sources...but I will try

Thanks.
Alorent

Disassembler part of debugger has been finished, so I can continue developing debugger.
To MazeGen - Yeah, every asm coder who kicks money to his (and maybe her) AMD64 machinegun must have free access for software, especialy asm and dbg to be able to code easy.
To Alorent - Thanks, INT bug was fixed. Migrate from 32 bit to 64 bit asm can be easy, because we have forum here, so everybody can ask.
I left win32 asm completely 1/2 year ago. In the time, when I bought AMD64, I choose HW which had 64 bit drivers for Linux64 as well win64 (Asus MB with NVidia nForce4 chip, NVidia GeForce graphics, SB Audigy, SATA HD), so I needn't win32 anymore (except sentimentally case when I want to see my old 16-bit DOS work - win64 don't emulate 16-bit DOS).
What has been changed in coding for me after migrate to win64:

1. I left use mov for addressing, I use LEA

2. I don't use push for put 5th and above parameters to API, I just prepare stack space by sub rsp,... and use mov [stack+...],API_param

3. I must be careful for align 16 stack (but this is transparent, you can view patching movdqa only in debugger) = subtract nonparity power of 8
e.g. sub rsp,8*5
or push rbx, sub rsp,8*4

4. help for win32 API is enough, but you must transform API structures:
e.g. fictive win32 structure:
dd structure_size
dd handle0
dd flag0
dd flag1
dd memory_reference_0
dd flag2
dd memory_reference_1
rules for win64 are: handles and memory references are qwords and must be align 8
so translation of fictive structure to win64 is:
dd structure_size
dd ? ; dummy, for align 8 next 64 bit structure
dq handle0
dd flag0
dd flag1
dq memory_reference_0
dd flag2
dd ? ; dummy, for align 8 next 64 bit structure
dq memory_reference_1

5. instructions with 32 bit register zero extend this to 64 bit.
e.g. xor eax,eax zeroes whole rax register, xchg ecx,eax exchanges this 32 bit registers and zeroes high dword of rax as well rcx...

6. And of course, you can see everythig in debugger, so put here any idea how to improve it.

Enjoy win64 asm guys !

Excellent work Feryno! I have download it and ready to try. I'll let you know if I see some possible bugs.

Your words about x64 assembly cheered me up a lot. I'm a x86 ASM enthusiastic but I was quite sad hearing people say that x64 ASM was dead due to so many upcoming changes in computers architectures (AMD64, IA64....).

It gives me strength again to keep going in assembly, but x64 assembly this time

Thanks.

Well, I continue in developing of debugger.
There are still unfinished parts, but the most necessary parts are done.
I added support for attach to a process (this is a dream of every reveresers to attach to a dialog that prompt for serial code etc., search return address in stack some 100h bytes above, put breakpoint at it, enter serial code and catch serial verification routine... hackers, is it right ?). Attach to a process work well, but there will be a lot of things to improve support for multithreaded processes.
There is a log view for see some output, as process info, loaded dll info...
I have to add support for change xmm registers, add displaying/changing mmx and FPU st registers. Restart debuggee function isn't done.
I added support for display API names when trace kernel. Call API inside of process module is displayed without API name (like call qword [100008314]), but after you enter the DLL, it display something like user32.MessageBoxA: sub rsp...). I have to replace memory pointers of api call with API names.
I added support for search in debuggee, strings as well hexa bytes, hackers - usefull and great, isn't it? And you can catch reading of memory by use HW breakpoints = debug registers, but still problem that I have to fix - set HW BP in every thread, not only in the main thread.
There may be a lot of other things, but I can't remember more. You may try to use it. Sources are included, of course.
Oh, I'm not able to translate resource to FASM macros, I tried for 1 hour, but I did't do anything working, because I'm not able to learn any new syntax.
Sources aren't much clear and there is only a few of comments.

I added this project to my homepage feryno.host.sk, where will be updates.

removed attachment because of quota

If you're developing this solely for illegal uses like cracking, then you're probably on the wrong forum.

Old good Turbo Debugger (td32.exe) has attach process as well hardware breakpoints. I have not many ideas for what to use both features... I'm not able to remember anything else now, especialy any great, unnecessary, capital usage for coders.
I have only informed you that both are now implemented.
If anybody more smart than me have an idea how to use them in developing of applications, his idea will be appreciated, so post it here (because serious Borland implemented both features about 10 years ago, there must be one or more usages by find errors in developped applications).
In case when you have sources, you needn't waste a time by attaching to a running process, searching through the stack to find return address. This needs some minutes of work. Faster way can be done in a few seconds - put int 03 into source after API, recompile exe, launch it under debugger and it stops after trigger breakpoint. And of course it needs to remove breakpoint from the source after done tracing and before recompile final exe.
I has been fascinated how easy is to find return address of API after attach to a process (when you don't have sources, or when you have them, but you don't want to look into them - you just want to try to explore process as one unknown) - I ran very simple exe with MessageBox, I attached to it and some hundreds of bytes above stack pointer, there was a return address. Yes, there is a lot of data in a stack, and you have to look into log to see memory range of process and compare every value from stack if it match process memory or if it is outside.
There is one mistake of assembler beginners, that can be catched by attaching to runnig process:
simple loop with my typical (I did it very much times) error from my early asm begins:
L0:
mov ecx,...
...
loop L0
(correct is:
mov ecx,...
L0:
...
loop L0)

But if there is some string operation (lodsb...) in a loop, todays CPU run so fast, so you are noticed by debugger very quickly with access violation exception.
Only in case you have e.g. only multiplications in a loop (calculate factorials), this loop with mistake run forever and you aren't noticed about anything. This is case for attach to a process, you will be entered into loop and you will find mistake very fast. But you needn't attach, there is another working way: Run debuggee and then pause it. After pause, you will be stopped in a loop.
Hardware breakpoints - I love this CPU feature (debug registers). But again, if you have sources, it's enough to use soft breakpoints (int 03). Only in case you developing special antidebugs, you must preserve code against modify it by int 03 and this is the time for use debug registers (they modify nothing in code) -
32 bit code sample
code setion is readable executable WRITEABLE
lea edi,[crypted_opcodes]
mov ebx,size_of_crypted_opcodes
mov dl,magic_start_value
L0:
lea esi,[L0]
mov ecx,crypted_opcodes - L0
L1:
lodsb
ror dl,3
add dl,al
loop L1
xor [edi+ebx-1],dl
dec ebx
jnz L0
...some code, good and necessary may be jmp crypted_opcodes for CPUs with prefetch queue for flush queue - my beloved AMD CPUs...

crypted_opcodes:
...

you have only 2 choices for pass throug this antidebug:
1. put hardware breakpoint after instruction jnz L0 and run debuggee
2. single step several days (or years if size_of_crypted_opcodes is big enough)
If you put soft breakpoint (int 03) after jnz L0, this modify code so wrong checksum in dl is calculated and crypted_opcodes won't be decrypted correctly.

Please don't take this as a lessons of cracking or hacking or something like this. I know about some problems in coding and this is reason for why I implemented some features in debugger (I debugged and disassembled very much on my asm begins, and I learned very much by tracing antidebugs and viruses - because I hadn't any teacher and internet was only small kid in nappy in that time - so no forums like this you are reading now...).
Of course I like battle between crakers and coders but only until point where it improve both sides. I don't like if someone make some damage by bad usage of debugger features.

Hi!
I have problem understanding your driver example, how to count the raw offsets.

e.g.
; mov rcx,[rbx + DRIVER_OBJECT.DeviceObject]
mov rcx,[rbx + 8]

When i count, i would get DeviceObject at Offset 4

Hi Karl20001,
unfortunately we don't have KMD.inc for win64, we have it only for win32.
I'm big lama for macros, so I had to calculate offsets handly, many errors and system reboots until everything was OK... Offsets are realy correct as they have to be.
This structure is from KMD.inc for win32
struc DEVOBJ_EXTENSION { ; sizeof = 024h
.Type dw ? ; 0000h
.Size dw ? ; 0002h
; Public part of the DeviceObjectExtension structure
.DeviceObject dd ? ; 0004h PTR DEVICE_OBJECT owning device object

I have used DDK for win64 headers for compute offsets. It may be
.Type dw ?
.Size dw ?
.dummy dd ? ; for align 8 next qword - look about 5 post above for to see rules of aligning 8 every qword value (handles, memory pointers, ...)
.DeviceObject dq ?

or it may be
.Type dd ?
.Size dd ?
.DeviceObject dq ?

I don't know now if 1st or 2nd choice is correct, I will have to look into DDK at my home, I don't have it here in job.
If you are interested in drivers, it's a good choice for you to buy DDK CD in ms site online, cost is low, only shippment, DDK kit itself looks like cost free... (I have paid by credit card a few of bucks, maybe 10 US $, I don't know it now exactly, CD have arrived in less that one week).
But I have many communistic ideas and I think that everything must be free for students and people who don't earn money with their computer activities and hobbies. So if you want only a few infos from DDK, I'm able to look into it and send all necessary structures to you. (e.g. ThreadContext differs very much between win32 and win64)

It will be great idea of implementing drivers debugging into fdbg debugger project, but I won't be able to complete that difficult task, I don't have any computer school education (only self-education).

Here is next version of debugger. I have included 2 small samples for you for test your skills in debugging.
adbg\protected.exe is encrypted demo, you can see into howto.txt for what to do
noimports_64\protected.exe shows you virii method of finding API offsets without using imports
Maybe a lot of you are or will become antivir experts, or sometimes you catch some badcode and you would trace it what it do (because coder is more smart than the best antivir) so you can try this samples to increase your skills. I have designed code displaying routines for handle self modifying code since the begin of fdbg project.
There is displaying of floating numbers in debugger (FPU st regs, MM regs, XMM regs), but displaying only not changing yet.
And I have one news for you! Because I downloaded docs and I studied them, I was able to rewrote resource into fasm macros!!! This project is now pure fasm, no other prog is necessary, no patches in resources...

I have one question for you: What do you want to implement into debugger ?

removed attachment because of quota

Hi, thx for your answer.
I have my struct from WinXP DDk headers. There was a time when you could download it for free from msdn site. But it doesnt have win64 headers. So would be nice if i can get them.
I thought i could get away with the 32bit ones, and count every pointer as size 8, but didnt had this evil alignment in mind.

Nice update Feryno!!!

I know that it's very easy for us to ask for new features...the difficult part is implement them Will you plan to add the possibility to control each window (CPU, Memory, registers...) so, we can put the desired windows that we need and maximize/resize/.. them.

Anyway, this project is going ahead very well and it's the first free Win debugger for x64!!! (apart for Debugging tools for Windows )

Keep up the good work!

At first, I must say that Tomasz Grysztar has been (and and will be) the greatest inspiration for me because he has developed PE64 support as well implementation of 64 bit instruction without possibility of testing - only from docs. Wow, I produce about 2-5 errors in 100 asm instructions and I catch them only in debugger when prog don't work as I think it has to work. Tomasz has done his task perfectly, only smaller than small mistakes was there and they have been fixed immediately. So the whole world have excelent flat assembler that is completely free and we are able to coding in win64 very well.
I have downloaded microsoft windbg which works perfect but it is command-based debugger and I don't like commands when pressing keys and mouse clicks can be easier. So I have started to try how difficult is to do some simple debug loop. It has been done quickly and I have continued in this project because I don't have anything else to code in assembler.
Because I have been lazy I have developped main window of debugger with fixed sizes of listviews - not more windows. I have used very small font size for to fill everything in listviews. There is badly differentiable between 0 and D in hexa values by small font size.
As Alorent has written it will be better to compose main window and "satelite" windows that will be moveable, resizeable, minimizeable...
There isn't much space in main dbg window now. But fortunately I plane to add only FPU/MM as well XMM flags that needn't much space.
I dream about Alorents solution for a long time, especialy because people who don't have win64 drivers for graphics cards are able to use only 640x480 VGA resolution and main dbg window has 1020x750 which isn't good for resolutions until 1024*800. And if somebody has higher screen resolution he is able to differentiate between 0 and D even worse than at 1024x800.
They are only 3 advantages of fdbg in compare with ms windbg:
- its size
- its included sources and possibility of easy bug fixing
- not commands but simple clicks or single keystrokes
I have found very much disasm errors in windbg and most of them has been at the end of instruction set (e.g. SSE2 instructions) and I'm sure that they will stay there for a long time.

Well, back to Alorents solution: Yes, I dream about it and I will try to do it in this better way if I have a time for it.

Hello, friends!

I have downloaded the source code of 64-bit system driver available at FASM web site. Well, I would like to note that a05.sys driver is fully 64-bit and doesn’t support I/O requests from 32-bit applications aka WoW64 applications. It is too bad, because it needs to do this. Well, using IoIs32bitProcess function exported from ntoskrnl the driver should detect a version of the requested process. This function must be used in IRP_MJ_DEVICE_CONTROL handler. After the driver must convert 32-bit structures into 64-bit. These notes should help to make a05.sys driver to be universal. Thanks for FASM! I have never see such a nice language!

Hello Vitaliy, have you ever tried any win32 app with win64 a05.sys driver?
Win64 a05.sys driver was developped for executing ring0 privileged instructions in user ring3 mode. Especialy a lot of asm coders need access ports (in al,dx out al,dx). It's funny, but driver works with 32-bit apps very well. 32-bit app is allmost 32 bit but has a part which is 64 bit. Small note, don't forger to zero extend address when you send it to driver

win32 app skeleton
use32
...
mov [...],proc_to_execute_in_driver ; = in ring0
mov [...+4],0 ; zero extending address to 64-bit addressing
...
call driver
...
use 64
routine_to_execute_in_driver:
...
ret

use32
...

It's a pitty that win64 don't emulate 16-bit dos. I made small samples that can be used to port dos graphics demos into win64. Samples only emulate 320*200 or 640*480 "screen", you must convert your demo addressing into 64-bit and do something for transform colors into 32-bit palette.
The only way to close samples is by ALT+F4 (or kill task in taskmanager).

Debugger is allmost finished. Especialy multithread support works well. The only unfinished parts are: change xmm/mm/st registers and Alorents great idea of multiwindow (CPU, memory, registers...).

feryno: move your debugger to projects section... vole

If I got the processor manual right, it is a feature of the processor itself:

no V86 mode on X86-64 ?!?