Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I really need some help here. I've been searching online for about 2 days now and can't seem to find an answer to the problems that I got.
I downloaded nasm and installed it it seems to work but I can't seem to find any example code that works on windows 64bit (it would be awesome if you could make a simple hello world example for me or something).
(And how to compile it)
How would I turn the .o file into a .exe?
How would I accesses the screen or gpu memory (I think) to print stuff on the screen (like some sort of console application)?
There a a few things to consider when programming in assembly using NASM under Windows:
NASM is just an assembler
A linker is needed to create an executable.
Windows API are implemented as a user space library.
The library is not entirely in user space, some functions cross the boundary, but the interface to the application is a set of DLL, most notably: kernel32.dll, user32.dll and so on.
Windows' executables can have different subsystems.
Among the others the IMAGE_SUBSYSTEM_WINDOWS_GUI and IMAGE_SUBSYSTEM_WINDOWS_CUI are the most used, the former being used by applications that create windows and the latter by applications that use a console1.
The linker takes to COFF object (.obj) file generated by the assembler, takes a set of library definitions (.lib) and perform these important steps:
It resolves the call to external functions found in the object file.
A function marked as external is meant to be found in one of the library definition, the linker then fixes the call instruction to point to a location where the address of the function will be found at run-time.
It add the dependency libraries to the final executable.
This is done with the help of the PE file format, basically if F if found on the library L then L is added to the dependencies list along with a location where to write the address of F.
The loader will do the rest.
The linking is actually more complex than that.
It is also responsible for setting the various PE flags and settings, including the subsytem and the entrypoint.
To write an executable using NASM with need:
A linker.
The set of library definitions.
These can be found in the Windows SDK2.
The linker we will use in this example is the Microsoft LINK linker.
As #CodyGray pointed out in its comment (quoting because I'm lazy):
The Windows 7 version of the SDK that you linked does include all of the build tools. The Windows 8 SDK changed and no longer ships with the command-line build tools, forcing you to download a Visual Studio package
Once we have the tools, we can start programming.
We will use WriteFile to write a string to the standard output (like we would in Linux assembly).
The handler to the standard output must be retrieved with GetStdHandle though.
In Windows you can exit a process with a ret even with no CRT (C run-time) linked (i.e. in a bare process).
I won't explain the Window 64 ABI nor the trickery of programming in 64-bit.
BITS 64
DEFAULT REL ;RIP relative addressing by default
GLOBAL main ;Main must be visible to the linker
;Function the linker will look for in other modules (libs or objs)
EXTERN WriteFile
EXTERN GetStdHandle
STD_OUTPUT_HANDLE EQU -11
SECTION .data
strHelloWorld db "Hello world!", 13, 10, 0
lenHelloWorld dd $-strHelloWorld
hOut dd 0 ;Will store STDOUT handler
SECTION .text
main:
sub rsp, 30h ;20h (Home space) + 10h (params)
;Get STDOUT handler (Handler are 32-bit values)
mov ecx, STD_OUTPUT_HANDLE
call GetStdHandle
mov DWORD [hOut], eax ;Useless as now, for future reuse
;Write strHelloWorld to STDOUT
mov ecx, eax
lea rdx, [strHelloWorld]
mov r8d, DWORD [lenHelloWorld]
xor r9, r9
mov QWORD [rsp+20h], r9
call WriteFile
add rsp, 30h
ret
To create an executable from this source, we first assemble it into a 64-bit object file:
nasm -fwin64 hello.asm -o hello.obj
then we link it against the kernel32 library (the only one we need):
link /MACHINE:X64 /SUBSYSTEM:CONSOLE /OUT:hello.exe /NODEFAULTLIB /ENTRY:main kernel32.lib hello.obj
the CLI switches are pretty straightforward, NODEFAULTLIB avoid linking with MSVCVRXX.lib, the Microsoft CRT.
Those are the minimal switches necessary to build an executable in this example.
I assume you are smart enough to fix the path issues when issuing the commands above, particularly you can tell link where to find the lib files.
For this example I just copied them from the SDK installation folder.
As proposed in other answers, you can use other assemblers that may came with a linker.
Another possible developing environment is to use gcc (either inside cygwin or as mingw) to perform the linker step.
1 In this case Windows automatically create a console for the application and set the standard handlers appropriately. GUI application can recreate the console too (or more than one), so IMAGE_SUBSYSTEM_WINDOWS_GUI must be intended as "No console by default".
2 The version linked is the first Google result, invest more time in finding a suitable version. Also, I'm not sure if there is a linker in the Windows SDK or you need to download a Visual Studio instead.
Download Flat Assembler.(Download->flat assembler for windows)
http://flatassembler.net/
Extract zip.
Goto 'examples/win64/pe64demo/'
open 'pe64demo.exe'
(source code is in 'pe64demo.asm')
Related
I'm currently persuing to create a compiler. Because of that I am learning nasm x86 assembly.
I never really coded in c++ or c so I never really used the winapi. When I used ld I could successfully link and create a 32 bit executable but it doesn't use "the real winapi" since it uses a libkernel32.a file internally.
Now, I know this might sound like a silly question but where are files like kernel32.dll located on a default installation of windows 10 64 bit? Maybe the one in the C:\Windows\System32 folder but these somehow won't work with neither ld nor golink.
I am new to assembly language, and I am using macOS. The book I read uses DOS's debug instruction, which could see the values in registers at any time without set breakpoints in some executable programs like lldb, and could execute basic assemble instructions like mov ax, 2000. I know that macOS runs on a x86_64 machine, which is different from DOS. I simply want a way that can inspect and interact with registers/memory in terminal without an formal assembly program.(For example, in DOS, type in debug -r and I can see all the values stored in registers).
In lldb - the stock MacOS debugger
register read
will show you all register values
Also possible with shortened syntax for quicker typing
re r
If you want the floating point registers (xmm* for x86-64) too included
re r --all
If you want particular register value
re r rax
lldb is used in current versions of Xcode the MacOS free programming IDE from Apple which allows you to target MacOS & iOS.
You can also go with the terminal route when you would run your program with:
lldb ./yourProgram
But this approach will require a lot of typing and knowledge about your binary, so I don't recommend it for starters.
Can I manually insert ImageBase value of PE file?
Basically..
ImageBase of DLL = 10000000
ImageBase of EXE = 00400000
If can, I want change ImageBase to random address.
I wonder How to do.
You can easily change the base address AND prevent Windows from relocating your executable module to a random base. I should stress that if you have access to the build environment, you should prefer specifying the base address and preventing the DYNAMICBASE flag from being placed in the module to begin with at build time, allowing the linker to make the proper optimizations. To do this with MSVC, you'd specify linker flags:
/BASE:400000
/DYNAMICBASE:NO
Altering the image base after the fact CAN be done and will work for simple modules, but in some instances could result in crashes depending on how the code was generated. Sometimes there is little choice when one does not have access to the original source code.
The code and data accesses may hardcode values based on the original ImageBase linked with. If you want to modify a module after it has been build, read on.
While Address Space Layout Randomization (ASLR) behavior was introduced in Windows Vista, the modifications suggested here WILL work on ANY version of Windows.
NOTE: The preceding statement assumes Microsoft, in the future, doesn't start randomizing image base addresses without regard to the relevant PE flags in the header or refuse to load these modules altogether. As of the present versions of Windows 10, Windows currently honors images that DO NOT contain IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag, preventing dynamic relocation.
Using a hex editor, a tool like MSVC's editbin, or even your own code, the following modifications should be made to the PE headers of the desired module to set a FIXED base-load address:
-set desired IMAGE_OPTIONAL_HEADER -> ImageBase (e.g. 0x400000)
i.e. editbin.exe /rebase:base=0x400000 <YOUR_MODULE>
-remove the the 0x0040 (DYNAMIC_BASE) bit from the IMAGE_OPTIONAL_HEADER -> DllCharacteristics flags or use editbin:
i.e.: editbin /dynamicbase:no <YOUR_MODULE>
-if not using editbin, you will need to recalculate the header checksum or just leave at zero for any non-driver or start-up Windows service; editbin updates the checksum automatically.
NOTES:
-manually changing the module's base address may require that you walk the .reloc section entries and perform manual fixups for your new base address either statically or at runtime (simulating what the Windows loader does); not doing so could result in crashes. To avoid this hassle, just remove the DYNAMIC_BASE flag and leave the base address the same as when the module was built. Then you still prevent ASLR, even if the original base address doesn't change.
-the editbin version must have come from MSVC 2005 SP1 (8.0.50727.161) to support the /dynamicbase argument; any free modern version of the MSVC C++ toolset's editbin will have this feature; my experience is that the /rebase option might report the cryptic "LNK1175: failed to rebase ; error 487" even for modules without a .reloc section - this ultimately forces you to use a PE editor to change ImgBase.
-The changes above may break embedded digital signature checks or anything that verifies the integrity of the original file since we've modified it.
As far as I remember, windows PE loader decides on base loading address(ImageBase in your question) and you cannot select it manually unless you write PE loader yourself.
Starting Windows Vista, windows uses address randomizer for selecting a random base loading address. So it is not like 0x10000000 or 0x00400000 anymore and it changes in every run unless the process is started in special situations like debug mode.
I am trying to learn assembly language in my spare time to help me in my role as a developer using high level languages.
I have followed the NASM tutorial here: http://leto.net/writing/nasm.php.
I am able to create and run a simple program that prints HelloWorld to the screen. I am confused by the following paragraph in the link above:
mov eax,5 ; the syscall number for open()
So where do find out all of the semantics for all of the various system calls?
Well first, the numbers are listed in asm/unistd.h in Linux, and sys/syscall.h
in the *BSD's
I assume that this means that: if there is a 5 in the eax register, then it is a system call for open. Are the rest of the system calls documented somewhere?
I am using NASM on a Windows 7 PC.
List of Windows API calls
If and when you use NASM on Linux,
http://asm.sourceforge.net/syscall.html#1
http://syscalls.kernelgrok.com/
I need to create an executable from the next assembly code:
.MODEL SMALL
.DATA
TEXT DB 'Hello world!$'
.CODE
.STACK 20
.STARTUP
MOV AX, #DATA
MOV DS, AX
MOV AH, 9
MOV BL, 02H
INT 10H
MOV Dx, OFFSET TEXT
INT 21H
MOV AH, 4CH
INT 21H
END
It works with Turbo Assembler (tasm.exe), but I don't want to continue working with it, because it doesn't run in Windows 7.
Thanks.
If there is an ongoing need to develop MSDOS programs, run a 16-bit environment like DOSBOX. That way tasm.exe—one of the finest assemblers of its day—can also run, along with your program, and the tools that go with tasm—Turbo Debugger, Turbo Linker, and Turbo C.
You could also install Windows XP or Windows 98 over Windows 7, as a multi-boot alongside it, or in a virtual machine hosted by Windows 7. Either way, you'd then have the ability to run MSDOS programs without hassle.
As Greg Hewgill mentioned, major rearchitecting of the program is needed for it to run in a 32-bit (or greater) environment.
use Microsoft macro assembler (MASM)
You could try NASM or MASM, but your source will likely need minor changes to work with those.
Your code as given is suitable for 16-bit DOS systems. To use a modern assembler, you will have to modify your code to work in a 32-bit environment, which may be a nontrivial process. All the code you've given so far will need to be rewritten.
I recommend NASM as it is an active, well supported project.
GNU Assembler