Format of data in the .code/.text section

Question

I'm attempting to dissect/disassemble a windows PE file under Linux using objdump. On surface analysis, the .code section was disassembled to :

tmp.exe:     file format pei-i386


Disassembly of section CODE:

00401000 <CODE>:
  401000:       04 10                   add    $0x10,%al
  401002:       40                      inc    %eax
  401003:       00 03                   add    %al,(%ebx)
  401005:       07                      pop    %es
  401006:       42                      inc    %edx
  401007:       6f                      outsl  %ds:(%esi),(%dx)
  401008:       6f                      outsl  %ds:(%esi),(%dx)
  401009:       6c                      insb   (%dx),%es:(%edi)
  40100a:       65                      gs
  40100b:       61                      popa
  40100c:       6e                      outsb  %ds:(%esi),(%dx)
  40100d:       01 00                   add    %eax,(%eax)
  40100f:       00 00                   add    %al,(%eax)
  401011:       00 01                   add    %al,(%ecx)
  401013:       00 00                   add    %al,(%eax)
  401015:       00 00                   add    %al,(%eax)
  ...

Then I looked at the entry point which was 0x45e534, which ended up within an opcode:

  45e52f:       00 dc                   add    %bl,%ah
  45e531:       e2 45                   loop   0x45e578
  45e533:       00 55 8b                add    %dl,-0x75(%ebp)
  45e536:       ec                      in     (%dx),%al
  45e537:       83 c4 f0                add    $0xfffffff0,%esp
  45e53a:       b8 04 e3 45 00          mov    $0x45e304,%eax
  45e53f:       e8 e0 84 fa ff          call   0x406a24

Which, I feel is very wrong; but since my understanding of assembly is lacking, I could be wrong.

So having read [1] and the chapter on Disassembly in "Practical Malware Analysis", I realized that there could be data in the .text (or in this case, CODE) section. So I took a gander at the hex dump on the file and came across at the beginning of the code section:

0000400: 0410 4000 0307 426f 6f6c 6561 6e01 0000  [email protected]...
0000410: 0000 0100 0000 0010 4000 0546 616c 7365  [email protected]
0000420: 0454 7275 658d 4000 2c10 4000 0204 4368  .True.@.,[email protected]
0000430: 6172 0100 0000 00ff 0000 0090 4010 4000  ar..........@.@.
0000440: 0107 496e 7465 6765 7204 0000 0080 ffff  ..Integer.......
0000450: ff7f 8bc0 5810 4000 0104 4279 7465 0100  [email protected]..
0000460: 0000 00ff 0000 0090 6c10 4000 0104 576f  [email protected]
0000470: 7264 0300 0000 00ff ff00 0090 8010 4000  rd............@.
0000480: 0108 4361 7264 696e 616c 0500 0000 00ff  ..Cardinal......
0000490: ffff ff90 9810 4000 0a06 5374 7269 6e67  [email protected]
...

This lead me to believe that there is definitely DATA in the code section [but, again, I could be wrong].

My question is (even given [1]), is it possible to figure out what the format of the DATA is in that part of the binary?

With my limited understanding, I'm guessing it's a structure of some sort or possibly a long list of DB/DW but (again, I could be wrong).

For instance, the very first set:

0410 4000 0307 426f 6f6c 6561 6e01 00 00..

Could the above be translated to something like (in assembly)

   DB 0x00401004
   DB 0x0703
   DB "Boolean"
   ...

I tried to look for the opcode DB in [2] but couldn't find it, so I'm wondering if I'm barking up the wrong tree.

Any help/pointers appreciated

:ewong

[1] - How do reverse engineers commonly detect the format of binary data?

[2] - http://mathemainzel.info/files/x86asmref.html

Answer 1

objdump disassembles linearly, it does not do control flow, so you may get gibberish in return. Use

objdump -f 

to get the entry point, and use that address as --start-address argument.

Be aware — since it is linear, it will disassemble from this address till the end of the binary or end of the code section, so you may need to provide a --stop-address, too, if you don't want a seemingly endless spew.

:\>f:\mingw\bin\objdump.exe -f .\getinst.exe

.\getinst.exe:     file format pei-i386
architecture: i386, flags 0x0000012f:
HAS_RELOC, EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_LOCALS, D_PAGED
start address 0x00404ee3 <<<<<<<<<

Disassembling some bytes from a specific address:

:\>f:\mingw\bin\objdump.exe -d --start-address 0x00404ee3 --stop-address 0x00404f00 .\getinst.exe

.\getinst.exe:     file format pei-i386


Disassembly of section .text:

00404ee3 <.text+0x3ee3>:
  404ee3:       e8 0a 07 00 00          call   0x4055f2
  404ee8:       e9 74 fe ff ff          jmp    0x404d61
  404eed:       8b 4d f4                mov    -0xc(%ebp),%ecx
  404ef0:       64 89 0d 00 00 00 00    mov    %ecx,%fs:0x0
  404ef7:       59                      pop    %ecx
  404ef8:       5f                      pop    %edi
  404ef9:       5f                      pop    %edi
  404efa:       5e                      pop    %esi
  404efb:       5b                      pop    %ebx
  404efc:       8b e5                   mov    %ebp,%esp
  404efe:       5d                      pop    %ebp
  404eff:       51                      push   %ecx

If you notice, the instruction at 0x404eed may never be executed as there is a hard-coded jmp which will divert the control flow, so all disassembly after the jmp might be gibberish and useless.

You may need to provide 0x404d61 as --start-address for following the flow as below:

:\>f:\mingw\bin\objdump.exe -d --start-address 0x404d61 --stop-address 0x404d80 .\getinst.exe

.\getinst.exe:     file format pei-i386


Disassembly of section .text:

00404d61 <.text+0x3d61>:
  404d61:       6a 14                   push   $0x14
  404d63:       68 b0 9c 42 00          push   $0x429cb0
  404d68:       e8 53 0b 00 00          call   0x4058c0
  404d6d:       6a 01                   push   $0x1
  404d6f:       e8 d9 02 00 00          call   0x40504d
  404d74:       59                      pop    %ecx
  404d75:       84 c0                   test   %al,%al
  404d77:       0f 84 50 01 00 00       je     0x404ecd
  404d7d:       32 db                   xor    %bl,%bl
  404d7f:       88                      .byte 0x88

If you notice, you may still see gibberish at 0x404d7d. That is because the provided stop-address is insufficient to decode the bytes into a sensible instruction.

:\>f:\mingw\bin\objdump.exe -M intel -d --start-address 0x404d7d --stop-address 0x404d8b .\getinst.exe

.\getinst.exe:     file format pei-i386


Disassembly of section .text:

00404d7d <.text+0x3d7d>:
  404d7d:       32 db                   xor    bl,bl
  404d7f:       88 5d e7                mov    BYTE PTR [ebp-0x19],bl
  404d82:       83 65 fc 00             and    DWORD PTR [ebp-0x4],0x0
  404d86:       e8 90 02 00 00          call   0x40501b

Edit

db = define byte like  size(1)  "\xff"   
dw = define word like  size(2)  "\xff\xff"  
dd = define dword like size(4)  "\xff\xff\xff\xff"     
dq = define qword like size(8)  "\xff\xff\xff\xff\xff\xff\xff\xff"  

Answer 2

Delphi executables store read only data such as RTTI (Run time type information) at the start of CODE section. objdump can’t know that it’s not really code so it tries to disassemble it as instructions and you get nonsense.