I have an asm file test.S:
.text
.globl start
start:
movw %cs, %ax
movw %ax, %ds
Then I execute
clang -m32 -fno-builtin -Wall -ggdb -nostdinc -fno-stack-protector -O0 -nostdinc -c test.S -o test.o
ld test.o -o test.bin
gobjdump -S test.bin
I get
test.bin: file format mach-o-i386
Disassembly of section .text:
00001ffa <start>:
1ffa: 66 8c c8 mov %cs,%ax
1ffd: 66 8e d8 mov %ax,%ds
Notice that the address of start is 0x00001ffa, my question is how can I specify this address? I tried to use ld -segaddr, but it doesn't work. My OS is OS X 10.11
Related
When using the gnu toolchain particularly arm-none-eabi is there any reason why when using the command line linker option it resorts to what seems an incorrect address to the start of 'main'. However, when 'main' is anything else the correct starting address and stack is initialized. For example,
.thumb
.syntax unified
.globl _start
_start:
.word 0x20001000
.word reset
reset:
bl main
b .
int main ( void )
{
return(0);
}
arm-none-eabi-gcc -O2 -c -mthumb main.c -o main.o
arm-none-eabi-as start.s -o start.o
arm-none-eabi-gcc -O2 -c -mthumb main.c -o main.o
arm-none-eabi-ld -Ttext=0x08000000 start.o main.o -o main.elf
arm-none-eabi-objdump -d main.elf
main.elf: file format elf32-littlearm
Disassembly of section .text:
08000000 <main>:
8000000: 2000 movs r0, #0
8000002: 4770 bx lr
08000004 <_start>:
8000004: 20001000 .word 0x20001000
8000008: 0800000c .word 0x0800000c
0800000c <reset>:
800000c: f7ff fff8 bl 8000000 <main>
8000010: e7fe b.n 8000010 <reset+0x4>
in the disassembly the output above doesn't initialize the stack 0x20001000 and start of rom 0x08000000 correctly from what I notice, but..
.thumb
.syntax unified
.globl _start
_start:
.word 0x20001000
.word reset
reset:
bl notmain
b .
int notmain ( void )
{
return(0);
}
arm-none-eabi-gcc -O2 -c -mthumb main.c -o main.o
arm-none-eabi-as start.s -o start.o
arm-none-eabi-gcc -O2 -c -mthumb main.c -o main.o
arm-none-eabi-ld -Ttext=0x08000000 start.o main.o -o main.elf
arm-none-eabi-objdump -d main.elf
main.elf: file format elf32-littlearm
Disassembly of section .text:
08000000 <_start>:
8000000: 20001000 .word 0x20001000
8000004: 08000008 .word 0x08000008
08000008 <reset>:
8000008: f000 f802 bl 8000010 <xmain>
800000c: e7fe b.n 800000c <reset+0x4>
...
08000010 <notmain>:
8000010: 2000 movs r0, #0
8000012: 4770 bx lr
I tried looking through the toolchain in my files to find any other reference to main pertaining to linker scripts and got some other help along the way, but there doesnt seem to be a clear solution as to why this is. Of course, if you create your own linker or a generated one you wont run into this problem, but I was just curious as I am trying to learn the tool a bit more.
..but I was just curious as I am trying to learn the tool a bit more
The arm-eabi-none is meant to be used with newlib (as a guess because you have not stated otherwise). This can process elf format files and it is a 'library', but there is no OS. If newlib mechanics want main() to be first, the tool will set things up like this. You don't want an elf file, but a binary. If you want a binary (ihex, srec, etc), then use a linker script! This is what it is meant for.
Use ld --verbose to see the default linker script. You are complaining about the order of emitted .text, but you have done nothing to define the ordering. The linker script may need main to be first so that some other library feature may work. You have a reset vector and a CPU which initializes the stack and 'reset vector' or initial code.
This is still emitted in the 'bad case', but it is not placed correctly. You need to have a custom linker script and position this a the first thing in the binary. Relying on the linker to place it correctly is error prone. An upgrade of tools can definitely change the order.
See: Can _start be a thumb function, were you have options like, -nostartfiles -static -nostdlib and use a custom linker script as an elf binary is unlikely to be understood and you need to flash/burn a binary to whatever boot device (or CPU built-in) is going to read the reset vectors.
I have created a very minimal application in assembly. It sets some registers to 0 and does a multiplication. Nothing fancy.
However, the gcc adds a lot of stuff to the machine code I do not want.
A small list of the stuff I find in the objdump:
deregister_tm_clones
register_tm_clones
__do_global_dtors_aux
frame_dummy
__libc_fini_array
memset
and a few more
I know that I do not need them, but I have no idea how I can tell to compiler to stop including them. I tried to use optimization options, but this did not change anything.
I compile it basically like: GCC -o ./main.elf ./main.S
Thank you very much for any help!
GCC automatically links the C / C++ runtime start-up crt0.o and the standard library. You can provide your own startup code to override the default and provide command line options to force it not to link no the standard library.
Options controlling startup and default libraries include:
-nostartfiles
-nostdlib
-nodefaultlubs
-nolibc
Each affects the link in a different way, but in this case -nostdlib will exclude both crt0.o and standard libraries. Of course if your code makes no reference to the standard library then nothing will be linked in any case, but explicitly excluding it will helpfully generate a link error if something does reference it.
See: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
Be aware that if your code does not establish a valid C runtime environment, providing for example static initialisation and a stack (a minimum), then some C code may not run in the manner intended. You may also need to specify the entry point via --entry=entry if you do not use the same default entry point as crt0 (_start I think).
Alternatively you can invoke gcc with the -c option and separately invoke the linker ld without specifying any library.
so.S:
nop
nop
then build.
as so.S -o so.o
ld -Ttext=0x1000 so.o -o so.elf
objdump -D so.elf
Disassembly of section .text:
0000000000001000 <__bss_start-0x200002>:
1000: 90 nop
1001: 90 nop
objcopy -O binary so.elf so.bin
hexdump -C so.bin
00000000 90 90 |..|
00000002
using gcc
gcc -nostartfiles -nostdlib -nodefaultlibs -ffreestanding so.S -Xlinker "-Ttext=0x1000" -o so.elf
this leaves extra garbage in the file, but
gcc so.S -c -o so.o
ld -Ttext=0x2000 so.o -o so.elf
ld: warning: cannot find entry symbol _start; defaulting to 0000000000002000
objdump -D so.elf
Disassembly of section .text:
0000000000002000 <__bss_start-0x200002>:
2000: 90 nop
2001: 90 nop
But if writing assembly language you might as well use the assembler not the compiler.
_start is not required unless you need an entry point defined in the file then you need to do this:
.globl _start
_start:
plus possibly something in the linker to call that out as the entry point for file formats like elf, exe, etc.
works for cross compiling as well
arm-none-eabi-as so.s -o so.o
arm-none-eabi-ld -Ttext=0x3000 so.o -o so.elf
arm-none-eabi-ld: warning: cannot find entry symbol _start; defaulting to 0000000000003000
arm-none-eabi-objdump -D so.elf
so.elf: file format elf32-littlearm
Disassembly of section .text:
00003000 <__bss_end__-0x10008>:
3000: e1a00000 nop ; (mov r0, r0)
3004: e1a00000 nop ; (mov r0, r0)
pdp11-aout-as so.s -o so.elf
pdp11-aout-as so.s -o so.o
pdp11-aout-ld -Ttext=0x400 so.o -o so.elf
pdp11-aout-objdump -D so.elf
so.elf: file format a.out-pdp11
Disassembly of section .text:
00000400 <so.o>:
400: 00a0 nop
402: 00a0 nop
and so on.
My gcc version : gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
the following is my makefile
all : main.o utility.o
gcc -fno-stack-protector -Wl,-z,execstack -o binary main.o utility.o -lcrypto
main : main.c
gcc -z execstack -fno-stack-protector main.c -c
utility: utility.c
gcc -z execstack -fno-stack-protector utility.c -c
The file utility.o and main.o does not have stack guard
But after linking there are some stack guard
objdump -D binary | grep chk
080488d0 <__stack_chk_fail#plt>:
8048e30: e8 9b fa ff ff call 80488d0 <__stack_chk_fail#plt>
80494dd: e8 ee f3 ff ff call 80488d0 <__stack_chk_fail#plt>
80498e2: e8 e9 ef ff ff call 80488d0 <__stack_chk_fail#plt>
8049b92: e8 39 ed ff ff call 80488d0 <__stack_chk_fail#plt>
8049c9e: e8 2d ec ff ff call 80488d0 <__stack_chk_fail#plt>
8049da2: e8 29 eb ff ff call 80488d0 <__stack_chk_fail#plt>
804a137: e8 94 e7 ff ff call 80488d0 <__stack_chk_fail#plt>
How to disable it?
the following is my makefile
gcc -z execstack -fno-stack-protector main.c -c
That command is bogus; if anything it should have -Wl,-z,execstack. However, since that's a linker option, and you are not linking here, best to remove -z exestack completely.
But after linking there are some stack guard
The calls to __stack_chk_fail must be coming from some code linked into your binary. Perhaps from libcrypto.a, or from libgcc.a. You can see where they are coming from, in two ways:
gcc -fno-stack-protector -Wl,-z,execstack -o binary main.o utility.o \
-lcrypto -Wl,-y,__stack_chk_fail
will produce messages like this:
/some/libfoo.a(bar.o): reference to __stack_chk_fail # you care about this one!
/usr/lib/libc.so.6: definition of __stack_chk_fail
Or you can use the binary you already built:
objdump -d binary | egrep '>:$|__stack_chk_fail' | grep -B1 __stack_chk_fail
That should tell you which functions inside the binary reference __stack_chk_fail, and from that you should be able to guess where these functions are coming from.
P.S. Unless you are studying buffer overflow exploitation techniques, disabling stack protector and linking with -z,execstack is a really bad idea.
I have the following file hello.asm:
section .text
global _start ;must be declared for linker (ld)
_start: ;tells linker entry point
mov edx,len ;message length
mov ecx,msg ;message to write
mov ebx,1 ;file descriptor (stdout)
mov eax,4 ;system call number (sys_write)
int 0x80 ;call kernel
mov eax,1 ;system call number (sys_exit)
int 0x80 ;call kernel
section .data
msg db 'Hello, world!', 0xa ;our dear string
len equ $ - msg ;length of our dear string
On mac, how would i turn it into a .o file. On linux i would do
nasm -f elf64 -o hello.o hello.asm
ld -o hello hello.o
then it could be called with
./hello
I have already installed Xcode and MacPorts, Thanks
Using:
nasm -o hello.o hello.asm
should work, that is, to produce an .o file. typically on OS X you do something such as:
nasm -f macho -o hello.o hello.asm
I'm writing Hello World in NASM, and I can get it to echo Hello World to the console, but the program segfaults if I don't run it with Make.
Trace with Makefile:
$ make
nasm -f macho -o hello.o --prefix _ hello.asm
ld -o hello hello.o -arch i386 -lc -macosx_version_min 10.6 -e _start -no_pie
./hello
Hello World!
Trace with manual commands:
$ nasm -f macho -o hello.o --prefix _ hello.asm
$ ld -o hello hello.o -arch i386 -lc -macosx_version_min 10.6 -e _start -no_pie
$ ./hello
Segmentation fault: 11
hello.asm:
[bits 32]
section .data
msg: db "Hello World!", 0
section .text
global start
extern puts
extern exit
start:
push msg
call puts
add esp, 4
push 0
call exit
Makefile:
# Linux defaults
FORMAT=-f elf
MINV=
ARCH=-arch i386
LIBS=
RUN=./
EXECUTABLE=hello
PREFIX=
ENTRY=
PIE=
# Windows
ifeq (${MSYSTEM},MINGW32)
FORMAT=-f win32
EXECUTABLE=hello.exe
PREFIX=--prefix _
ENTRY=-e _start
ARCH=
LIBS=c:/strawberry/c/i686-w64-mingw32/lib/crt2.o -Lc:/strawberry/c/i686-w64-mingw32/lib -lmingw32 -lmingwex -lmsvcrt -lkernel32
ENTRY=
RUN=
endif
# Mac OS X
ifeq ($(shell uname -s),Darwin)
FORMAT=-f macho
PREFIX=--prefix _
ENTRY=-e _start
LIBS=-lc
MINV=-macosx_version_min 10.6
PIE=-no_pie
endif
all: test
test: $(EXECUTABLE)
$(RUN)$(EXECUTABLE)
$(EXECUTABLE): hello.o
ld -o $(EXECUTABLE) hello.o $(ARCH) $(LIBS) $(MINV) $(ENTRY) $(PIE)
hello.o: hello.asm
nasm $(FORMAT) -o hello.o $(PREFIX) hello.asm
clean:
-rm $(EXECUTABLE)
-rm hello.o
Specs:
ld 64-134.9
LLVM 3.1svn
NASM 0.98.40
Make 3.81
Xcode 4.5
Mac OS X 10.8.1
MacBook Pro 2009
2 things, your hello world string is not NULL terminated and as I mentioned in another post, when you use C functions, you MUST adjust esp after each call
You tore down your stack frame twice:
mov esp, ebp
pop ebp
...
leave
You only need one of those, since leave is equivalent to mov esp, ebp; pop ebp.
See http://michaux.ca/articles/assembly-hello-world-for-os-x for several example hello world programs. Note that all of them exit the program explicitly with
; 2a prepare the argument for the sys call to exit
push dword 0 ; exit status returned to the operating system
; 2b make the call to sys call to exit
mov eax, 0x1 ; system call number for exit
sub esp, 4 ; OS X (and BSD) system calls needs "extra space" on stack
int 0x80 ; make the system call
because you cannot ret from an entry point (there's nothing to return to).
Also note that if you call the function main and don't supply the e option to ld, then libc's entry point will be called. In that case, it is permissible to ret since you will return control to libc (which calls exit on your behalf).