4

I disassembled the code resulting from compiling the very simple source file test.c, which looked like this:

void main() {}

I ran these commands to link the main function into a static executable (editor's note: with no CRT start code so it would just crash), then extract to a flat binary with a couple sections removed, so I could feed that to ndisasm (editor's note: which doesn't understand ELF metadata like objdump -drwC -Mintel does)

 gcc -c test.c 
 ld -o test -Ttext 0x0 -e main test.o 
 objcopy -R .note -R .comment -S -O binary test test.bin
 ndisasm -b 32 test.bin

And this is what I got:

00000000  55                push ebp
00000001  89E5              mov ebp,esp
00000003  5D                pop ebp
00000004  C3                ret
00000005  0000              add [eax],al
00000007  001400            add [eax+eax],dl
0000000A  0000              add [eax],al
0000000C  0000              add [eax],al
0000000E  0000              add [eax],al
00000010  017A52            add [edx+0x52],edi
00000013  0001              add [ecx],al
00000015  7C08              jl 0x1f
00000017  011B              add [ebx],ebx
00000019  0C04              or al,0x4
0000001B  0488              add al,0x88
0000001D  0100              add [eax],eax
0000001F  001C00            add [eax+eax],bl
00000022  0000              add [eax],al
00000024  1C00              sbb al,0x0
00000026  0000              add [eax],al
00000028  D8FF              fdivr st7
0000002A  FF                db 0xff
0000002B  FF05    00000000      inc dword [dword 0x0]
00000031  41                inc ecx
00000032  0E                push cs
00000033  088502420D05      or [ebp+0x50d4202],al
00000039  41                inc ecx
0000003A  0C04              or al,0x4
0000003C  04C5              add al,0xc5
0000003E  0000              add [eax],al

What is the purpose of everything past the first four lines? Why is it adding to the memory locations pointed to by eax, 2*eax, edx+0x52, comparing, and so on? Is it all about checking that the program executed correctly or something else?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
mring
  • 1,717
  • 2
  • 13
  • 28
  • `add [eax],al` always immediately makes me suspicious. It would (almost) never occur in actual code, especially not that often. – harold May 30 '12 at 12:38
  • 1
    To elaborate on @harold's comment, `add [eax],al` happens to be represented by the bytes `00 00`. No idea why they chose that instruction to be represented by those bytes. When you see that instruction, it's more than likely that those bytes are zeros for a reason other than wanting to add the contents of the lowest byte in EAX to the address pointed to by EAX. Usually it's not actually code being disassembled. – flarn2006 Jan 16 '14 at 08:17
  • http://stackoverflow.com/questions/4751502/help-with-understanding-a-very-basic-main-disassembly-in-gdb?lq=1 – Ciro Santilli OurBigBook.com Oct 21 '15 at 17:17

2 Answers2

11

I believe you have disassembled bits that are not code, which is why it doesn't make a lot of sense.

To get an idea of what the file might contain, I would recommend running objdump on the full binary (ELF), to see if you can recognize the above byte sequences in any of the sections.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • These are the commands I ran: $gcc -c test.c ; ld -o test -Ttext 0x0 -e main test.o ; objcopy -R .note -R .comment -S -O binary test test.bin ; ndisasm -b 32 test.bin – mring May 30 '12 at 12:36
  • Thanks. If not code, then what are those bytes most likely and why are they part of my test.bin file? – mring May 30 '12 at 12:41
  • Yeap, or it can be just random data. – sharptooth May 30 '12 at 13:14
  • Found it using objdump. It was section .eh_frame, which comes right after .text, and which I didn't remove with -R in the objcopy command I ran. It actually makes sense now! :) – mring May 30 '12 at 14:00
2

This section is .eh_frame which comes right after .text. You can get rid of it by using -fno-asynchronous-unwind-tables when compiling with gcc.

See Why GCC compiled C program needs .eh_frame section? for more details.

Nathan Goings
  • 1,145
  • 1
  • 15
  • 33