flat assembler
Message board for the users of flat assembler.

Index > Windows > win64 64 bit source samples, executables

Goto page 1, 2, 3, 4, 5, 6, 7  Next
Author
Thread Post new topic Reply to topic
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
Few amd64 asm64 sources, executables, stupid m$ assembler, include *.lib files: kernel32.lib, user32.lib
Maybe useful for FASM developers by developing win64 PE format for FASM, you can compile exe.
This is not FASM, but stupid m$ assembler.

download here:
http://feryno.host.sk
asm_amd64_win64.zip 860574 bytes because include everything for compile
Post 06 May 2005, 06:12
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
I see sources again, and
there is one error in a01.asm
but a01.exe run correct, maybe upper dword of rdi=0 before.

bad -
lea edi, string

correct -
lea rdi, string
Post 06 May 2005, 06:30
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
Method for debugging win64 asm exe:

download debugger:
http://msdl.microsoft.com/download/symbols/debuggers/dbg_amd64_6.4.7.2.exe
http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx

Place db 0CCh (int 03) at begin of code
under WinDbg.exe go to File -> Open Executable (CTRL+E)
Debug -> Go (F5)
now you are at int 03 and you can use F10 F11 for step
use View -> Command, Registers, Memory to see everything

Don't run exe with int 03 outside debugger - cause application error. You must remove int 03 after developing and releasing exe to use.


Description:
Download
Filename: asm_amd64_win64_debug.zip
Filesize: 2.71 KB
Downloaded: 180 Time(s)

Post 11 May 2005, 04:43
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17667
Location: In your JS exploiting you and your system
revolution
Quote:

bad -
lea edi, string

correct -
lea rdi, string


From my reading of the docs I thought that all 32 bit writes to the registers will also clear the top 32 bits. (one exception being xchg eax,eax)
Post 11 May 2005, 05:21
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Oh my God - what code should be introduced to make it retain the previous values. Why would anyone do such a horrible thing.

mov al,5
mov ah,50
mov ax,500
never touched other parts of the registers!
Razz I think I don't like 64bit anymore.
Post 11 May 2005, 09:17
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
MCD



Joined: 21 Aug 2004
Posts: 604
Location: Germany
MCD
Madis731 wrote:
Razz I think I don't like 64bit anymore.

The same is true for me since a long time. sad but true.
Post 11 May 2005, 09:31
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
Anyway "lea edi" is still wrong, since you should not assume that your data is placed in the low 4 GB of memory.
Post 11 May 2005, 10:18
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
fasm 1.61.3 now supports the COFF format for x86-64. Here's the sample source:

Code:
format MS64 COFF

extrn MessageBoxA
extrn ExitProcess

section '.text' code readable executable

 public main

 main:
        mov     r9d,0
        lea     r8,[_caption]
        lea     rdx,[_message]
        mov     rcx,0
        call    MessageBoxA
        mov     ecx,eax
        call    ExitProcess


section '.data' data readable writeable

 _caption db 'Win64 assembly',0
 _message db 'Coffee time!',0    


Can someone test it for me?
Post 13 May 2005, 15:14
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Not that I would program 64 just yet, but I think that r09d, r08 would look nicer i.e.:
Code:
mov  r13,rcx
add  rdi,r09
sub r01d,r04d ;<=- I can't find solution to this Razz 
    


Did I see rWx somewhere like you can use up to 16th letter instead of the W? Then the name would remain the same length even with d, w, b postfixes:
eax,ebx,ecx,edx,eex,efx,egx,...,epx
al,ch,gx,pl,ph,...
of course now there are lot of fun names reserved and this leaves less room for meaningless names like these above...

...oh well I think the AMD/Intel guys where smart enough to think them over already Razz
Post 13 May 2005, 16:59
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
Thanx, Privalov, this is GREAT. I can forget to stupid m$ assmebler, yeah !

There is another bug in my a01.asm example.
Passing 5th arg to syscall, but a01.exe still work...

See new sources, contain correct method for pass more than 4 args to syscall.
Contain skeleton for make window exe, not only console apps.
There is difference in WNDProc between win64 and old win 32 - parameters retrieve not on stack, but on registers...

See a03.asm

Debugging... see included stuff in asm_amd64_win64_debug_2.zip


Description:
Download
Filename: asm_amd64_win64_debug_2.zip
Filesize: 14.88 KB
Downloaded: 161 Time(s)

Post 18 May 2005, 06:28
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17667
Location: In your JS exploiting you and your system
revolution
Madis731:

Make your own register names if you want to.

Code:
r08 equ r8
r09 equ r9
r01d equ eax
r08d equ r8d
r09d equ r9d

eex equ esi

etc..
    


EDIT: fix changed to equ


Last edited by revolution on 19 May 2005, 08:58; edited 1 time in total
Post 18 May 2005, 07:10
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
Feryno: read this (and also this) for more details about Win64 calling convention.
The idea is that you allocate the stack space once and then reuse it for many calls (and when the argument is, for example, of byte size, you need to store only one byte in appropriate place). Here's my version of your a02 example, with detailed comments:
Code:
format MS64 COFF

extrn CreateFileA
extrn WriteFile
extrn CloseHandle
extrn ExitProcess

section '.data' data readable writeable

 phy1ename   db 'Rambo.txt', 0
 stryng      db 'Rambo - First Blood, Part II :', 0Dh,0Ah
             db 'For our country love us, as much as we love it!'
 stryng_syze = $ - stryng

 BytezWrytten dq ?

section '.text' code readable executable

 public main

 main:

        sub     rsp,7*8 ; reserve stack space for up to 7 arguments
                        ;  (you may expand this allocation if you need
                        ;  to call procedures that take more than 7 arguments)
                        ;  and restore the stack frame only at the end of your routine.

        mov     qword [rsp+6*8],0   ; store 7th argument
        mov     dword [rsp+5*8],80h ; store 6th argument
        mov     dword [rsp+4*8],2   ; store 5th argument

        xor     r9,r9           ; the first four argument are passed in registers,
        xor     r8d,r8d         ;  but stack space is still reserved for them,
        mov     edx,40000000h   ;  the called routine may want to spill them there
        lea     rcx,[phy1ename]
        call    CreateFileA

        xchg    rbx,rax         ; store result in the register that is preserved by calls

        mov     qword [rsp+4*8],0   ; store 5th argument

        lea     r9,[BytezWrytten]
        mov     r8d,stryng_syze
        lea     rdx,[stryng]
        mov     rcx,rbx
        call    WriteFile

        mov     rcx,rbx         ; not that this call does not need any arguments on stack,
        call    CloseHandle     ;  but the stack space should be reserved for the arguments passed
                                ;  in registers to be fully compliant with calling convention

        xor     rcx,rcx         ; restoring stack frame is not needed at all in this case, if
        call    ExitProcess     ;  this was the end of procedure, you would have to do it before returning.    

BTW: are you able to test the fasm-generated files on x86-64 machine for me? I don't have access to any Win64 machine, nor the AMD64 processor.

revolution: even EQU would be enough for such purpose.
Post 18 May 2005, 09:23
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
Thanx, Privalov, right, better way allocate stack once and use'm.
Today i go home to my beloved AMD64 comp - after finishing my work here in job - and try to test FASM64, your sample source above.
You finded very good AMD64 stuff. I have about 1 hour dissasembling and debugging why find method how to pass 5th arg to syscall, and about a half of day to find how to make windows skeleton and WNDProc (a03.asm)... playing with 64 bit notepad.exe using WinDbg and IDA...
Faster way is find good stuff on inet. But i like disassemblers and debuggers so much!
Good luck in FASM64 !
Feryno, Slovak Republic (you know now why so bad english i use)
Post 18 May 2005, 11:00
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
FASM generate perfect *.obj ms64 coff object file. You need linker to generate exe.
Here some working samples as well on my homepage http://feryno.host.sk
(big 0,75 MB file, include new linker and *.lib files from april 2005 DDK release)
Great work, Privalov, thanx !
edit from 2007-01-31: deleted attachment, lack of space to put newer things (5 MB quota)


Last edited by Feryno on 31 Jan 2007, 09:19; edited 2 times in total
Post 19 May 2005, 04:53
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
Small note about your problem with PUSH 80000000h - fasm being very strict in terms of realizing the instruction you specify, doesn't allow it, since in long mode PUSH instruction opcode contains the signed 32-bit immediate operand, which is sign-extended to 64 bits that are then stored on stack. So 80000000h immediate gets extended to 0FFFFFFFF80000000h and this is the true value that gets pushed. So fasm will accept if you write PUSH 0FFFFFFFF80000000h or PUSH -80000000h (they're both the same 64-bit value, and fasm's expression calculator works on 64 bits internally), but it forbids PUSH 80000000h, because there is no way to push 64-bit immediate 80000000h on the stack. The REX prefix you tried has no effect in this case - the immediate in PUSH opcode is always signed 32 bits (and that's why fasm won't also accept PUSH QWORD 80000000h instruction - it's just impossible to encode it).
This is another reason why it's better to allocate stack first, and then fill it with appropriate values with MOV instructions - when you need to store only double word somewhere in stack, you use just 32-bit MOV, etc.

And some more things specific to fasm, which I thought would be good to note after reading your RIP.ASM sample (not yet converted to fasm): first, fasm allows RIP-relative addressing written like INC BYTE [RIP+1],
second, the direct addressing in long mode is automatically converted to RIP-based (since only this can work with full 64-bit addresses), but that doesn't mean the absolute direct addressing isn't possible at all. DEC BYTE [0] won't work, but DEC BYTE [DWORD 0] will, and will use direct absolute 32-bit addressing.

The x86-64 support in fasm was very carefully designed after a months of "meditating" over the AMD64 manuals - I did my best to make fasm always generate the correct opcodes for you, while allowing as much freedom as possible.

PS. Direct PE+ executable output for Win64 coming soon. Wink
Post 19 May 2005, 09:34
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
I'm too fascinated by small asm code and that's why i use push. E.g. push 0 use 2 bytes, mov qword [rip+...],0 use to much bytes of opcodes for me style of coding.
But i see, my method of producing smallest code is too problematic, so i must convert to method that produce bigger code. Bigger and safer.
I think, i't too hard to develope without possibility of testing if it work. Is a developer here that need help with this "Sysiphos work"? I'm not able to send hardware, but i'm with other... to "lend" that i self have "cost free".
Post 19 May 2005, 10:59
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
Quote:
I think, i't too hard to develope without possibility of testing if it work.

I think that with my latest fasm releases I have proven that this is not really such a big problem. Wink Someone (like you) that tests it remotely for me is just enough.
Post 19 May 2005, 11:04
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
Privalov wrote:
Quote:
Someone (like you) that tests it remotely for me is just enough.

Every time i'm able to testing asm code on Win64 as well Linux 64 bit.

You develop only from documentation, without testing... I see, you are realy good coder. I'm poor self-educater and i must test everything too much times before make code working. But 8 years of hobby asm coding make my code better and better.
Post 20 May 2005, 05:07
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
I tried to add resource section - with success, required some filez from m$ $DK.
I got a trubble why API destroy 4 quadwords on stack. I know that win64 api can use first 4 quadwords of stack to save regs, but i have see this first time. E.g. DefWindowProcA don't destroy'em, FindResourceA destroy, hence i must preserve this.
How crazy can be region window - see *.jpg file if you haven't win64 to run exe. For people with slow connection - sorry for it size 150kB.
Sample include everything for compile, because > 800 kB must be split to 2 parts. 1st contrain relevant part, 2nd m$ DLL's required for compile.
Sample is skeleton only, contain nothing for run. To close you need press ALT+F4 because ws_popup window style.
See ya in win64 asm!

edit from 2007-01-31: deleted attachment, lack of space to put newer things (5 MB quota)


Last edited by Feryno on 31 Jan 2007, 09:20; edited 2 times in total
Post 03 Jun 2005, 05:13
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
jorgon



Joined: 29 Jun 2005
Posts: 4
Location: London, UK
jorgon
Congratulations TG for taking the lead with FASM for 64-bit assembly using the x86-64 processors, and thank you Feryno for the excellent samples. I started my move in this direction with GoLink.
Since for the time being FASM 64 is limited to producing object files, GoLink may be a useful tool in the interim. It takes one or more 64-bit object
files and a res file (if used) and makes a 64-bit executable which can be run on x86-64 processors. No lib files are needed since GoLink looks inside the DLLs themselves to see which APIs they export. Even when FASM is able to produce 64-bit executables GoLink may remain useful to combine more than one object file, permitting source code to be divided into modules.
Whilst working with FASM produced object files, I came across an incompatibility between these files and GoLink even under Win32, of which I was not aware. I have now fixed this so that GoLink can be used as a linker for FASM Win32 object files. This works if "format MS COFF" is specified in the source text.
GoLink is at Version 0.26.0 beta and can be downloaded from here. This link will also work for updates until the version is officially published. Its early days yet so all bug reports would be appreciated.

_________________
Author of "Go" tools
Post 30 Jun 2005, 21:50
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 1, 2, 3, 4, 5, 6, 7  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-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.