I created a small project under Win64 without any _printf from standard C library (on pure WinAPI). Code of the program below:
; ------------------------------------------------------------------------------ EXTERNS
extern GetStdHandle
extern WriteConsoleW
; ------------------------------------------------------------------------------ MACROSES
%define NULL 0
%define STD_OUTPUT_HANDLE -11
; ------------------------------------------------------------------------------ PROGRAM DATA
section .bss noexecute
hStdOut resq 1
chWritten resd 1
section .data noexecute
; wchar string!
msg dw __utf16__('Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї=Ї'), 10, 0
msg.sizeof equ ($-msg)
section .rodata noexecute
; ------------------------------------------------------------------------------ PROGRAM CODE
section .text
global __main
; prologue
__main: push rbp
mov rbp, rsp
; Get hStdOut to print in console
mov rcx, STD_OUTPUT_HANDLE
call GetStdHandle
mov qword [hStdOut], rax
mov rcx, rax
mov rdx, msg
mov r8, msg.sizeof
mov r9, chWritten
push NULL
call WriteConsoleW
; epilogue
pop rbp
exit0: xor rax, rax
ret
command:
nasm -fwin64 D:\Desktop\Roberto\asm_docs\files\myprog.asm -o myprog.exe
The error is a blue window that says:
Unable to run executable on your PC. To find a version for your computer, contact to developer of the application
No warnings during the preprocessing, compilation and linking.
Tried to run with -fwin32 replacing all r- registers on e- but still no effect...
What should i do? Thanks in advance!
Related
I am new to x86 assembly and have been doing some experiments lately using nasm and running the program on a windows 10 machine.
I Have this code:
global _start
extern _GetStdHandle#4
extern _WriteFile#20
extern _ExitProcess#4
section .data
message db "1234"
section .text
_start:
call print
call _ExitProcess#4
print:
; DWORD bytes;
mov ebp, esp
sub esp, 4
; hStdOut = GetstdHandle( STD_OUTPUT_HANDLE)
push -11
call _GetStdHandle#4
mov ebx, eax
; WriteFile( hstdOut, message, length(message), &bytes, 0);
push 0
lea eax, [ebp-4]
push eax
push 4
push message
push ebx
call _WriteFile#20
mov esp, ebp
ret
; ExitProcess(0)
That I assemble it using the following commands:
nasm -f win32 out.asm
link out.obj /entry:start /subsystem:console "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x86\kernel32.lib"
and when running it on cmd it outputs "1234" as expected
Now when assembling and running the following code, where instead of pushing message the program pushes "1234" directly
global _start
extern _GetStdHandle#4
extern _WriteFile#20
extern _ExitProcess#4
section .data
message db "1234"
section .text
_start:
call print
call _ExitProcess#4
print:
; DWORD bytes;
mov ebp, esp
sub esp, 4
; hStdOut = GetstdHandle( STD_OUTPUT_HANDLE)
push -11
call _GetStdHandle#4
mov ebx, eax
; WriteFile( hstdOut, message, length(message), &bytes, 0);
push 0
lea eax, [ebp-4]
push eax
push 4
push "1234"
push ebx
call _WriteFile#20
mov esp, ebp
ret
It outputs nothing
Why? What information does message have that "1234" doesn't? When pushing message, does the program just push the address of the memory that is storing "1234"? If so, can I store "1234" somewhere else, and than push its address without creating a variable?
A variable is a logical construct — variables have lifetimes, some short, some long. They can come into being and disappear.
By contrast, registers and memory are physical constructs — in some sense, they are always there.
In assembly programming, by a human or generated by compiler, we make mappings from logical variables needed by our C code, algorithms, and pseudo code, to physical storage available in the processor. When a variable's lifetime ends, we can reuse the physical storage that it was using for another purpose (another variable).
Assembly language supports global variables (full process lifetime), and local variables — which can be either in memory on the stack, or CPU registers. CPU registers, of course, do not have addresses, so cannot be passed by (memory) reference. CPU registers also cannot be indexed, so to index an array requires memory.
I would make a local variable on the stack, like this:
print:
; DWORD bytes;
mov ebp, esp
sub esp, 12
; hStdOut = GetstdHandle( STD_OUTPUT_HANDLE)
push -11
call _GetStdHandle#4
mov ebx, eax
lea ecx, [ebp-12]
mov dword ptr [ecx], “1234”
; WriteFile( hstdOut, message, length(message), &bytes, 0);
push 0
lea eax, [ebp-4]
push eax
push 4
push ecx
push ebx
call _WriteFile#20
mov esp, ebp
ret
Note: the syntax mov ..., “1234” may or may not do what you want, depending on the assembler. I don’t remember how the Microsoft assembler handles it. If it doesn’t translate to 0x34333231, then use that constant instead.
I intend to create a file using Mac system calls (OS X and not the bios for now). Everything compiles well, but the result that should be the creating the file "fileName db "Teste.txt", 0xA, 0x0" is not realized and I do not understand. can you help me, I also post you the source code compiled with nasm
Thank you in advance for your answers.
;------------------------------------------------------------------------------
; TITLE: SOURCE.ASM
;------------------------------------------------------------------------------
bits 64
;------------------------------------------------------------------------------
; Definition des syscall
;------------------------------------------------------------------------------
%define _stdout 0x1
%define _stderr 0x2
%define O_RDONLY 0x0000 ; open for reading only
%define O_WRONLY 0x0001 ; open for writing only
%define O_RDWR 0x0002 ; open for reading and writing
%define O_ACCMODE 0x0003 ; mask for above modes
%define O_CREAT 0x0200 ; create if nonexistant
%define O_TRUNC 0x0400 ; truncate to zero length
%define O_EXCL 0x0800 ; error if already exists
%define syscall_write 0x2000004
%define syscall_exit 0x2000001
%define syscall_open 0x2000005
%define syscall_close 0x2000006
;------------------------------------------------------------------------------
; Section code
;------------------------------------------------------------------------------
section .text
global start
start:
xor rax, rax
xor rbx, rbx
mov rbx, fileName
push mode_f
push FLAGS
push rbx
syscall
pop rax
xor rbx, rbx
mov rbx, rax
mov rax, syscall_exit
mov rdi, rbx
syscall
f_open_file:
mov rbp, rsp
push rbp
xor rax, rax
mov rax, syscall_open
mov rdi, [rbp+8]
mov rsi, [rbp+16]
mov rdx, [rbp+24]
syscall
pop rax
if: cmp rax, -1
jge else
mov rbx, rax
mov rax, syscall_close
mov rdi, rbx
syscall
pop rax
ret
else:
xor rbx, rbx
mov rbx, MsgErrr
push size_err
push rbx
call f_print_data
xor rax, rax
mov rax, -1
ret
f_print_data:
mov rbp, rsp
push rbp
mov rax, syscall_write
mov rdi, _stdout
mov rsi, [rbp+8]
mov rdx, [rbp+16]
syscall
xor rax, rax
ret
;------------------------------------------------------------------------------
; Section Data
;------------------------------------------------------------------------------
section .data
fileName db "Teste.txt", 0xA, 0x0
MsgErrr db "Erreur open File", 0xA, 0x0
size_file equ ($-fileName)
size_err equ ($-MsgErrr)
mode_f equ 0777
FLAGS equ 0xA02 ;( O_RDWR| O_CREAT| O_EXCL )
fileName db "Teste.txt", 0xA, 0x0
The inclusion of the newline code 0xA is fine for displaying purposes, but for opening it is no good! Drop it:
fileName db "Teste.txt", 0x0
mov rbx, fileName
push mode_f
push FLAGS
push rbx
syscall
Your code is missing the open command in order to create the file!
mov rbx, fileName
push mode_f
push FLAGS
push rbx
mov rax, syscall_open
syscall
f_open_file:
mov rbp, rsp
push rbp
To actually preserve rbp you need to swap these two instruction:
f_open_file:
push rbp
mov rbp, rsp
In doing so, you'll also need to adjust the offsets used on [rbp + ...].
All of your subroutines forget to pop rbp, and so you end up with an unbalanced stack. This leads to "segmentation faults".
If you want to write assembly code that makes direct system calls, use a Linux virtual machine.
The macOS system call interface is not a public API. There is no official documentation for this interface, and it differs in a number of important ways from the Linux system call interface. This makes it a terrible place for a beginner to be learning assembly!
There are much better debugging tools available on Linux as well, such as strace, which will allow you to see the exact system calls being made by your application.
How to include debug symbols in NASM code for debugging using GDB on Windows?
Having coded some NASM assembly, I want to debug it using GDB.
I assemble and link using the following commands:
nasm -f win32 insertion_sort.asm
ld insertion_sort.obj
However, starting GDB (gdb a) yields:
Reading symbols from C:\Users\nze\Desktop\asm\sorting\insertion_sort\a.exe...(no debugging symbols found)...done.
In the code below I cannot reference _array like:
(gdb) x/4xw _array
No symbol table is loaded. Use the "file" command.
(gdb) x/4xw array
0x1: Cannot access memory at address 0x1
Also, setting breakpoint at _exit:
(gdb) break exit
Breakpoint 1 at 0x401464
(gdb) run
Starting program: C:\Users\nze\Desktop\asm\sorting\insertion_sort/insertion_sort.exe
[New Thread 5488.0x1c7c]
[New Thread 5488.0xc54]
[Inferior 1 (process 5488) exited with code 01]
causes GDB to just run the program to completion when run...
What is wrong?
The assembly code is:
BITS 32
section .data
_array: dd 4, 2, 8, 6, 1
_len: equ ($ - _array) / 4
section .text
global _start
_start:
push ebp
mov ebp, esp
xor ecx, ecx
_outer:
inc ecx
cmp ecx, _len
jge _exit
mov ebx, ecx
dec ebx
lea esi, [_array + ecx * 4]
lea edi, [_array + ebx * 4]
_inner:
cmp ebx, 0
jl _outer
mov eax, [edi]
cmp eax, [esi]
jle _outer
xchg eax, dword [esi] ; swap [esi] and [edi]
mov dword [edi], eax
sub esi, 4
sub edi, 4
dec ebx
jmp _inner
_exit:
mov esp, ebp
pop ebp
ret
have you tried include the debug information available for Windows (Codeview 8)?
$ nasm -gcv8 -f win32 -o insertion_sort.o insertion_sort.asm
$ gcc -m32 -o insertion_sort.exe insertion_sort.o
I assumed I had push'ed something without popping it, or vice versa, but I can't find anything wrong! I write to the console with a call to a dll that links properly, and I inexplicably am in no mans land... (address 0x0000000000000000)
I've put some sleeps in, and I'm sure that the api call WriteConsoleA is returning. It's on my last ret under the print function.
Any ideas?
.exe:
extern FreeConsole
extern Sleep
extern ExitProcess
extern print
extern newconsole
extern strlen
section .data BITS 64
title: db 'Consolas!',0
message: db 'Hello, world',0,0
section .text bits 64
global Start
Start:
mov rcx, title
call newconsole
mov rcx, 1000
call Sleep
mov rcx, message
call print
mov rcx, 10000
call Sleep
call FreeConsole
xor rcx, rcx
call ExitProcess
.dll:
extern AllocConsole
extern SetConsoleTitleA
extern GetStdHandle
extern WriteConsoleA
extern Sleep
export newconsole
export strlen
export print
section .data BITS 64
console.writehandle: dq 0
console.readhandle: dq 0
console.write.result: dq 0
section .text BITS 64
global strlen
strlen:
push rax
push rdx
push rdi
mov rdi, rcx
xor rax, rax
mov rcx, dword -1
cld
repnz scasb
neg rcx
sub rcx, 2
pop rdi
pop rdx
pop rax
ret
global print
print:
mov rbp, rsp
push rcx
call strlen
mov r8, rcx
pop rdx
mov rcx, [console.writehandle]
mov r9, console.write.result
push qword 0
call WriteConsoleA
ret
global newconsole
newconsole:
push rax
push rcx
call AllocConsole
pop rcx
call SetConsoleTitleA
mov rcx, -11
call GetStdHandle
mov [console.writehandle], rax
pop rax
ret
I assume you're talking about this function:
global print
print:
mov rbp, rsp
push rcx
call strlen
mov r8, rcx
pop rdx
mov rcx, [console.writehandle]
mov r9, console.write.result
push qword 0
call WriteConsoleA
ret
The x64 ABI requires that stack space is reserved even for parameters passed in registers. WriteConsoleA is free to use those stack locations for whatever it wants - so you need to make sure that you've adjusted the stack appropriately. As it stands, you're pushing only the last reserved pointer parameter. I think something like the following will do the trick for you:
push qword 0
sub rsp, 4 * 8 // reserve stack for register parameters
call WriteConsoleA
mov rsp, rbp // restore rsp
ret
See http://msdn.microsoft.com/en-us/library/ms235286.aspx (emphasis added):
The x64 Application Binary Interface (ABI) is a 4 register fast-call calling convention, with stack-backing for those registers.
...
The caller is responsible for allocating space for parameters to the callee, and must always allocate sufficient space for the 4 register parameters, even if the callee doesn’t have that many parameters.
According to calling convention, you have to clean up arguments you put on the stack. In this case that applies to the 5th argument to WriteConsoleA. Since you have a copy of original rsp in rbp, you can reload rsp from rbp, or just add 8 after the call.
With online help, I was able to write nasm code in Mac OS X resulting in an executable that prints its own filename, argv[0] in equivalent C code. When I use the same code in Windows, I want it to print the programs name:
C:\> nasm -f win32 -o scriptname.obj scriptname.asm
C:\> golink /fo scriptname.exe scriptname.obj /console kernel32.dll Msvcrt.dll
GoLink.Exe Version 0.27.0.0 - Copyright Jeremy Gordon 2002/12 - JG#JGnet.co.uk
Output file: scriptname.exe
Format: win32 size: 2,048 bytes
C:\> scriptname.exe
Program: scriptname.exe
But what it actually prints is emptiness:
C:\> scriptname.exe
Program:
Specs:
golink 0.27.0.0
nasm 2.10.05
Windows 7 Professional x64
MacBook Pro 2009
You call GetStdHandle and save the returned value to ecx, ecx is a volatile register, the value will not be saved across calls unless you push/pop it. Your first call to WriteConsoleA uses it and clobbers it so the next call, ecx is not what you expect.
* EDIT *
I was bored so here is working code:
[bits 32]
section .data
program db "Program: ", 0
programlen equ $-program
nl db "", 13, 10, 0
nllen equ $-nl
section .bss
buf resd 1
argc resd 1
argv resb 255
section .text
global Start
extern GetStdHandle
extern __getmainargs
extern WriteConsoleA
extern ExitProcess
strlen: ; eax: a string ending in 0
push eax ; cache eax
.strloop:
mov bl, byte [eax]
cmp bl, 0
je .strret ; return len if bl == 0
inc eax ; else eax++
jmp .strloop
.strret:
pop ebx ; ebx = cached eax
sub eax, ebx ; eax -= ebx
ret ; eax = len
Start:
push 0
push buf
push argv
push argc
call __getmainargs
add esp, 16 ; clear stack (4 * 4 arguments)
push -11 ; get stdout
call GetStdHandle
mov esi, eax
add esp, 4 ; clear stack (4 * 1 argument)
push 0 ; null
push buf ; [chars written]
push programlen
push program
push esi ; stdout
call WriteConsoleA
add esp, 20 ; clear stack (4 * 5 arguments)
mov edx, [argv]
mov eax, [edx] ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
call strlen
push 0 ; null
push buf ; [chars written]
push eax ; len argv[0]
push dword [edx] ;<<<<<<<<<<<<<<<<<<<<<<<<<<<< ; argv[0]
push esi ; stdout
call WriteConsoleA
add esp, 20 ; clear stack (4 * 5 arguments)
push 0 ; null
push buf ; [chars written]
push nllen
push nl
push esi ; stdout
call WriteConsoleA
add esp, 20 ; clear stack (4 * 5 arguments)
push 0
call ExitProcess
D:\NASM Projects\ReadArgs>ReadArgs.exe
Program: ReadArgs.exe
D:\NASM Projects\ReadArgs>
The argc and argv arguments are for C based programs only. Assembly based programs are must use __getmainargs or __wgetmainargs functions from the C library to generate those variables like they are internally used by C based programs. See below MSDN article for details:
http://msdn.microsoft.com/en-us/library/ff770599.aspx
Well, yes and no. In Linux, at the _start: label, argc is at [esp] and argv[0] is at [esp + 4]. If your code works, this must also be true of Mac OSX. By doing -e main on the ld command line, essentially main is lying about its name. It isn't really a "C style main". This label is jumped to, not called. If main (or _main, for 'doze and Mac OSX) is called by "C startup code" (crt2.o), then there's a return address on the stack, so argc is at [esp + 4] and argv[0] is at [esp + 8]. Also, as Tim tells you at news:comp.lang.asm.x86 argv is a ** - a "pointer to pointer" - so you also need the mov ebx, [ebx] (a "de-reference"). I'm pretty sure in Windows, our code is called regardless of what we name the entrypoint. Can you get it to work that way?
EDIT: Well this has pretty much been beaten to death, and "solved"(?), but I got bored, too. This works in Linux, and "might" be portable.
; prints its own name (possibly portable?)
; nasm -f elf32 myprog.asm
; nasm -f macho myprog.asm --prefix _
; nasm -f win32 myprog.asm --prefix _
; gcc -o myprog myprog.o(bj) (-m32 for 64-bit systems)
global main
extern printf
section .data
prog db `Program: %s \n`, 0
section .text
main:
mov eax, [esp + 8]
mov eax, [eax]
push eax
push prog
call printf
add esp, 4 * 2
ret
;----------------------