0

The following bytes do the hello world (x86 LE, code part of elf file) :

[0xba, 0x09, 0x00, 0x00, 0x00],// edx len
[0xb9, 0xa4, 0x90, 0x04, 0x08],// ecx msg
[0xbb, 0x01, 0x00, 0x00, 0x00],// mov ebx 1
[0xb8, 0x04, 0x00, 0x00, 0x00],// mov eax 4
[0xcd, 0x80],// int 80h
[0xbb, 0x03, 0x00, 0x00, 0x00],// mov ebx 0
[0xb8, 0x01, 0x00, 0x00, 0x00],// mov eax 1
[0xcd, 0x80],// int 80h
[0x00, 0x00],
[0x48, 0x69, 0x20, 0x57, 0x6f, 0x72, 0x6c, 0x64, 0x0a]// data : "Hi World\n"

It works well. I understand that 0xa4 0x00 0x00 0x00 is the offset of the data and 0x00 0x90 0x04 0x08 is the address of the virtual memory address, which combines give 0xa4 0x90 0x04 0x08.

But why if I change virtual memory address to 0x00 0x80 0x04 0x08 (so 0xa4 0x80 0x04 0x08), it still works ?

[0xba, 0x09, 0x00, 0x00, 0x00],// edx len
[0xb9, 0xa4, 0x80, 0x04, 0x08],// ecx msg   <= change address here and still works, why ??
[0xbb, 0x01, 0x00, 0x00, 0x00],// mov ebx 1
[0xb8, 0x04, 0x00, 0x00, 0x00],// mov eax 4
[0xcd, 0x80],// int 80h
[0xbb, 0x03, 0x00, 0x00, 0x00],// mov ebx 0
[0xb8, 0x01, 0x00, 0x00, 0x00],// mov eax 1
[0xcd, 0x80],// int 80h
[0x00, 0x00],
[0x48, 0x69, 0x20, 0x57, 0x6f, 0x72, 0x6c, 0x64, 0x0a]// data : "Hi World\n"

hd file

00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  80 80 04 08 34 00 00 00  |............4...|
00000020  f8 00 00 00 00 00 00 00  34 00 20 00 02 00 28 00  |........4. ...(.|
00000030  05 00 04 00 01 00 00 00  00 00 00 00 00 80 04 08  |................|
00000040  00 80 04 08 a2 00 00 00  a2 00 00 00 05 00 00 00  |................|
00000050  00 10 00 00 01 00 00 00  a4 00 00 00 a4 90 04 08  |................|
00000060  a4 90 04 08 09 00 00 00  09 00 00 00 06 00 00 00  |................|
00000070  00 10 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  ba 09 00 00 00 b9 a4 90  04 08 bb 01 00 00 00 b8  |................|
00000090  04 00 00 00 cd 80 bb 03  00 00 00 b8 01 00 00 00  |................|
000000a0  cd 80 00 00 48 69 20 57  6f 72 6c 64 0a           |....Hi World.|
000000ad

00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  80 80 04 08 34 00 00 00  |............4...|
00000020  f8 00 00 00 00 00 00 00  34 00 20 00 02 00 28 00  |........4. ...(.|
00000030  05 00 04 00 01 00 00 00  00 00 00 00 00 80 04 08  |................|
00000040  00 80 04 08 a2 00 00 00  a2 00 00 00 05 00 00 00  |................|
00000050  00 10 00 00 01 00 00 00  a4 00 00 00 a4 90 04 08  |................|
00000060  a4 90 04 08 09 00 00 00  09 00 00 00 06 00 00 00  |................|
00000070  00 10 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  ba 09 00 00 00 b9 a4 80  04 08 bb 01 00 00 00 b8  |................|
00000090  04 00 00 00 cd 80 bb 03  00 00 00 b8 01 00 00 00  |................|
000000a0  cd 80 00 00 48 69 20 57  6f 72 6c 64 0a           |....Hi World.|
000000ad

both works.

8HoLoN
  • 1,122
  • 5
  • 14
  • 1
    That should not work. Make sure you are actually running the modified version. – Jester Apr 14 '21 at 14:05
  • well, I verified and I confirm. I added the result of `hd` command – 8HoLoN Apr 14 '21 at 14:15
  • Can you create a minimal example that can be assembled and run? It's not possible to test from your dumps because they are incomplete (no section headers). – Nate Eldredge Apr 14 '21 at 15:56
  • that's because I created the elf by hand, so the only testing method is write a file with the dump bytes and execute and analyse opcode according to their meaning in the docs. Sorry but it's not build with nasm. :/ – 8HoLoN Apr 14 '21 at 16:11
  • 4
    My hypothesis is that you changed the pointer from the data code to the section code. There shouldn't be data there but you packed your sections so tight that the loader will also load the unrelocated data. In the debugger (radare2) those bytes are actively overwittern but when run by the kernel, those data are not overwritten and the pointer works. In fact, if you use another address (e.g. 0x804a0a4, which is one page after the data and not before) it doesn't work. – Margaret Bloom Apr 14 '21 at 18:13
  • @MargaretBloom for all the elf section stuff, I used an minimal example in http://timelessname.com/elfbin/ which has a length of 173 bytes. – 8HoLoN Apr 14 '21 at 18:59
  • 3
    Yes but you have two mappings and you put your things so close together that due to page size limits, your string is visible in two places in memory. – Jester Apr 14 '21 at 21:10
  • @NateEldredge: ELF binaries only need Program Headers for the kernel to execute them. `ld` leaves section headers in the executable for convenience only. FASM assembling straight into an ELF executable omits section headers (making it a pain to work with in GDB, even in disassembly mode.) – Peter Cordes Apr 15 '21 at 01:21
  • thx everyone, https://stackoverflow.com/questions/62885381/why-does-my-data-section-appear-twice-in-the-compiled-binary-ubuntu-x86-nasm answers my question. – 8HoLoN Apr 15 '21 at 07:04

0 Answers0