Well, for beginning it would be some package containing assembler, linker, some set of headers for Win64 programming, examples, tutorials etc.

In the last weekend i tried to make some exe's by linking with GoLink. Everthing is O.K., i can't send no one bug. But it's need more tests...
In a zip file some samples, in second is loader - usefull for hackers - loader load protected or crypted or compressed file, wait until protected file decrypt or decompress, then patch some code and data (e.g. time limitation, other trial shit's).
Platform i'am used is Windows 2003 Server x64 Standard Edition Service Pack 1 Build 3790, CPU AMD64. I hope, there isn't relevant difference between winxp and win2003 when work with assembler.

edit 2011-01-11 reached quota limit, deleted some attachments

oops, there is old version of loader that i was uploaded, you must correct one error for don't leave suspended process:

bug in loader.asm:
exitus: lea rcx,[ProcessInfo + 1*8] ; hThread
; lea is bad, mov must be used !!!
call ResumeThread
xor rcx,rcx ; uExitCode
call ExitProcess

correct:
exitus: mov rcx,[ProcessInfo + 1*8] ; hThread
call ResumeThread
xor rcx,rcx ; uExitCode
call ExitProcess

I make very much errors by changing lea and mov because in old win32 asm i every used mov...

Many thanks a lot Feryno for the pleasing no-bug-as-yet report for GoLink - it's pleasing news so far.
Meanwhile I did some tweaking to GoRC, the resource compiler.
This needed alteration only for the RES>OBJ conversion, which does the same job as CVTRES in your sample batch file. This is because the 64-bit object file format is different. The RC>OBJ function has also changed for the same reason. RES file formats are the same no there is no change to the RC>RES function.

You tell GoRC to produce a 64-bit object file instead of a 32-bit object using the switch: /machine AMD64 or /machine X64, or for compatibility with CVTRES, using /machine:AMD64 or /machine:X64 in the command line.

GoRC 0.90.0 beta can be downloaded from here.
This link will always point to the latest beta version of GoRC, until it becomes officially published.

Eventually I will need to add automatic recognition for the appropriate VERSIONINFO constants for Win64 (VOS__WINDOWS64 etc) but they don't seem to have been published yet ..).

I tried GoRC to produce resource section for win64 exe - with SUCCESS, every look nice O.K. See TrIco2.exe in attached *.zip
After a few days i completed porting trayicon demo to win64, i got very much trouble, must trace kernel dll's... maybe because i'am not real coder, but something other... For other coders documentation and study is enough, but it's look as not enough for me.
GetCursorPos API failed if data structure not aligned, that i found after few days of debugging.
Sizes in structures: handles, addresses, ... of course 64 bits quadwords.
But flags, ... is sometimes (or everytimes ?) doublewords... that i found after few hours of debugging, but i can't tell in what API qwords and what dwords, maybe everytime dwords?
You can see that after comment some lines with by ;
WindowsClassEx structure work because delete one qword and split other qword to 2 doublewords...
e.g.
section '.data' data readable writeable
WindowsClassEx
dq WindowsClassEx_size ; UINT cbSize;
; dq 2003h ;CS_HREDRAW | CS_VREDRAW; style;
dq WNDProc ; WNDPROC lpfnWndProc;
; dq 0 ; int cbClsExtra;
dq 0 ; int cbWndExtra;
this is working structure, but i can't tell where is here what param... i finded this after disassembling and debugging working 64 bit exe's.

attached zip contain more samples as well correct version of loader = patcher usefull for hacking data and code in protected file, e.g. in a demo or trials.

64 bit assembler is still wonderful for me. Se ya in assembler!

edit 2011-01-11 reached quota limit, deleted some attachments

Why not have a look at a 64bit PlatformSDK instead of disassembling and tracing kernel? That should save you quite some time...

I have 64 bit SDK installed, I promise look at it. I learn.
But the pleasure of solving a problem after 4 days is bigger as after few seconds when looking to SDK.
OK, looking at SDK is better, i can devote saved time to girls.

Indeed - while tracing kernel can be fun, it's a bit useless having to do it for a lot of APIs... better to translate from the SDK, and devote your spare time to writing useful examples and chasing girls

Your page is not working:

MS IE said:

THEWizardGenius you forgot to tell which page.
my assembler page
http://feryno.host.sk
is up about 5 years and is up now, but I encountered much unavailable intervals. It's free webhosting, I don't donate it (maybe nobody), so services look like you see. Maybe (sure) it will end sometimes (when moneys for server operation drop to zero) and I'll migrate to another free webhosting.
Well, it work OK now, you can browse and download from it. But my work isn't serious material to learn, it's attempts to code something for a fun.
There is enough links on page that point to excelent materials on other pages.
I am able to send every file on my page, if you encounter problems with download. Files download isn't accessible from other pages when you put direct link to a file. You can download files only from host.sk
This is it what I have costfree. I don't plan pay serious hosting. It's no matter of moneys but principles. Everything that I have is costfree (except few US$ for microsoft DDK and more moneys for a hardware of course) and I'll give stuff to everybody costfree.
At the conclusion, internet is costfree in my job (employer pay it)...

Here you have some samples. No one is new, everything is old samples rewrited to direct produce PE64 by FASM. For compile you need only fasm.exe 1.63.1 with size 73216 byte (included in attached file) or later, nothing more.
Is here somebody coding in FASM under win64?

Last evening and night I finished driver for win64, analogy to r0pc driver for win32 posted somewhere on this forum.
I had a problem with import section so I must comile it with microsoft stuff...
But it's a thing of little of a time until produce drivers by FASM, it's thing of macros, structures, other things that I hate, don't known, don't understand.
Stuff for install, start, stop, remove driver is written in FASM. Driver in microsoft stuff.
Just run file !run_tests.bat from attached sys.zip. If you want to compile drivers, download ml64.zip and link64.zip attached here.
Source for driver - a05.asm is full of bullshits, I had not a time to clean it. I had about 20 "correct" system resets until find correct offsets for driver structures. I have DDK, but I must compute offsets by calculator, compile by DDK, disassemble by IDA, find numbers in a IDA disassembled files, IDA 4.7 produce errors by disassemble win64 code... a lot of errors and system resets until finished this.
Driver is a05.sys. You can use ring0 privileged instructions with this driver, e.g. reading and writing to a ports under win64.
Don't use driver nanoreset.sys except you realy need reset system on the fly, without correct shutdown - don't stop services, don't kill processes, don't unmount, don't flush disk buffers...
Well, producing correct import section by FASM for win64 drivers will be follow...

update from 2005-august-04:
Because MazeGen has right, I delete ml64.zip and link64.zip attached here.
Don't wory, I finished producing drivers by FASM, so microsoft compiler isn't necessary. Follow reading this forum for FASM win64 drivers.

I much doubt MS files can't be redistributed this way.

Mazegen, you right, MS files can't be redistributed this way. But somebody need this files for compile.
Mazegen, what about you country? Czechoslovakia don't exist a lot of years... But don't take this personaly. I come from Slovakia and live (temporary) in Czech rep.

Feryno, check your PM.

Last night I finished drivers for win64 with FASM.
What differs from win32 is calling API qword from section .rdata and exchange rva ImportAddress and rva ImportLookup in INIT section.
But maybe as well on win32 this must be called from .rdata because IDA report IMPORT section seems to be destroyed on r0pc.sys for win32 posted somewhere on this forum that have call api to dword from INIT section.
Thanx to Tomasz Grysztar for help and motivation because his work is very big, great and hard and it's a big motivation for me to finish drivers in FASM for win64.
Thanx for biew.exe which help me to find how to make IMPORT sections correct.
See this history of finding on attached file. First working driver beeper64.asm is compiled with microsoft compiler. Next two FASM produced beeper64_2.asm beeper64_3.asm have bad import section. From the beeper64_4.asm sections are correct.


here sample:


format PE64 native 5.02 at 10000h
entry start


section '.text' code readable executable notpageable

start:
; rcx=pDriverObject rdx=pDriverPath

mov ecx,620h
call [imp_HalMakeBeep]
mov eax,6000000h
delay_loop:
dec rax
or rax,rax
jnz delay_loop
xor ecx,ecx
call [imp_HalMakeBeep]


cli
mov al,0B6h
out 43h,al
mov al,74h
out 42h,al
mov al,4
out 42h,al
in al,61h
or al,3
out 61h,al
sti
mov eax,3000000h
delay_loop2:
dec rax
or rax,rax
jnz delay_loop2
cli
in al,61h
and al,0FCh
out 61h,al
sti

xor eax,eax ; success exit code

ret

section '.rdata' readable notpageable

data 12

ImportLookup:
imp_HalMakeBeep dq rva szHalmakebeep
dq 0

end data


section 'INIT' data import readable notpageable
dd rva ImportAddress; dd rva ImportLookup
dd 0
dd 0
dd rva szHal_dll
dd rva ImportLookup; dd rva ImportAddress
times 5 dd 0

ImportAddress:
dq rva szHalmakebeep
dq 0

szHalmakebeep dw 0
db 'HalMakeBeep',0

szHal_dll db 'HAL.dll',0

The package of Win64 driver examples is now in the official examples section.

Please download drivers from FASM official examples section. Official version include more usefull stuff and included utilities have every absolute addressing (my vice from old win32 style of coding) replaced with correct relative addressing.

Driver examples include:
- Driver without call API, only write to a ports - make a beep
- Driver with call API, make a beep
- Driver for read and write to a ports and execute ring0 protected instructions in ring3 user mode programs - analogy of r0pc.sys posted somewhere on this forum. This driver support stop, because it has implemented routines for this (you needn't restart win for repeated use as by both beepers)

Utilities:
- install_drv.exe
- start_drv.exe
- stop_drv.exe (note, both beeper drivers can't be stopped, beepers don't have stop routine)
- remove_drv.exe
- write_device.exe - Sample how to communicate with a05.sys driver from user mode program

*.bat files for howto use drivers and utilities

I finished skeleton for debugger (dbg01.exe in attach). It hasn't interface nor window nor interaction is possible, it display nothing... only simple process that debug another program. It put one breakpoint to the start offset of debugged exe and after process it, it leave exe to run and to terminate. Nothing great, skeleton only... a few of comments, not realy good method for set startup breakpoint (I have a correct idea - described in the source, but isn't finished yet - must be calculated, not every exe has it 401000h...)
Jeremy Gordon has a great idea for port GoBug to win64.
Microsoft WinDbg 64-bit is very good and enough for every asm programmer.
Is somebody here who interest in win64 debugger or want to cooperate with development?

Prog.exe in above debug.zip has a bug with MOVDQA instruction to unaligned memory.
The interesting thing is:
1.
When you boot windows and you load prog.exe by small debugger included in debug.zip, debugger fail (it hasn't implemented exception handling yet). If you load it by dbg02.exe included in new dbg_2005_08_28.zip, you will be informed about exception code caused by prog.exe at xxxxmemory, where MOVDQA execute with nonaligned memory. Prog.exe can't continue normaly. If you will retry debug, you will be informed with exception everytime.
2. If you simply run prog.exe from debug.zip (or prog_cause_exception.exe from dbg_2005_08_28.zip) outside debugger, windows run it normaly, every is silent, you aren't informed about exception and it looks like windows patch this instruction with MOVDQU (move to unaligned memory) because MessageBox following after MOVDQA show correct content of xmm register which is transferred to messagebox text correctly by MOVDQA/MOVDQU (xmm hold 'ASCII' value, no binary or floating).
After you successfuly run exe in win outside debugger, if you launch this exe inside debugger (=as a debuggee), you will be never informed in the debugger about this exception in this exe until you reboot windows. Program running as the debuggee continue correctly after MOVAPS and messagebox show correct content of xmm register as well.
3.
If you want to replay this, you needn't reboot win, simply copy or rename exe with exception to another filename.

Well, development of debugger in asm continue, here you have new version, first interaction is possible by lazy method, single stepping. You have only 2 possibilities - single step or leave prog to run. Use dbg02_interactive.exe for this. Debugger show registers after every step. It hasn't disasm, so you can't see nothing from instructions, only RIP (instruction pointer) show you where are you in debuggee (or in kernel if you step to an API). This debugger inform you about exceptions, but don't handle them (isn't implemented yet). Very very very few things are implemented here, it's only an experimental debugger, something like a game for small children...