Entry point

[Golf]

I've been using nasm for a while but decided to take a look at the file in a hex editor and noticed something strange about the entry point.

A very basic example:

Code: [Select]

global _start
 
section .text
_start:
mov eax, 1
int 0x80

nasm test1.asm -f elf32 -o test.o
ld -melf_i386 test.o -o test

When viewed in a hex editor, the 4 bytes for the entry point are:  0x60, 0x80, 0x04, 0x08 which is way beyond the end of the file.  When looking at byte 0x60 however, I can see 0xB8 which as as expected the mov opcode.  Is there any reason why the other three bytes for the entry point have not just been set to 0?

[Frank Kotler]

Are you keeping in mind that the four bytes for the entrypoint are in little-endian order? 0x8048080 would be a fairly "typical" Linux entrypoint. Looks like ld has done a little bit better for you - probably because your program is so small and simple. ELF header should start at 0x8048000 with 7Fh, 'E', 'L', 'F'. Is that what you see?

That's once it's loaded, of course. On the disk, 0x60 may very well be your entrypoint...

Best,
Frank

P.S. Probably irrelevant to what you're doing, but "test" is a Unix command and may not be the best name for your program...

[Golf]

Are you keeping in mind that the four bytes for the entrypoint are in little-endian order? 0x8048080 would be a fairly "typical" Linux entrypoint. Looks like ld has done a little bit better for you - probably because your program is so small and simple. ELF header should start at 0x8048000 with 7Fh, 'E', 'L', 'F'. Is that what you see?

That's once it's loaded, of course. On the disk, 0x60 may very well be your entrypoint...

I am viewing the file on disk rather than in memory.  At 0x18 I have 0x60800408 rather than 0x60000000 which I was expecting (0x60 in little endian).

[Frank Kotler]

Yeah, that's the simpler answer to your question. 0x8048060 is where the entrypoint will be once it's loaded.

Best,
Frank

[Golf]

Thanks, I was getting confused with some files I had compiled from C where the entry point at 0x18 related to location in the file rather than in memory but it turns out these were position independent executables.