analyze object files

[m4b]

Because panop is quickly becoming my goto when i need to disassemble cross platform, I was hoping I could use it to dump the unrelocated functions in an object file (e.g., I wanted to disassemble some mach o object files to see the code, but gdb won't work obviously and not much else)

This should be as simple as sucking up the symbol table and printing the addresses; I have a working example for macho object file.

ELF should be straightforward; PE obj file should be as well, but I have yet to make a serious foray into PE object files yet.

Anyway, first thing I noticed was that because the callq's are unrelocated, panopticon cleverly begins disassembly from the location of the callq (e.g., the next line in the function), which generates functions that are really artifacts of unrelocated callqs.

Example:

00000010 <_main>:
      10: push rbp
      11: mov rbp, rsp
      14: sub rsp, 10
      18: mov dword ptr [rbp-0x4], 0
      1f: call 24 <func_0x24>
      24: lea rdi, 41
      2b: mov esi, eax
      2d: mov al, 0
      2f: call 34 <func_0x34>
      34: xor esi, esi
      36: mov dword ptr [rbp-0x8], eax
      39: mov eax, esi
      3b: add rsp, 10
      3f: pop rbp
      40: ret 
Aliases: []
00000024 <func_0x24>:
      24: lea rdi, 41
      2b: mov esi, eax
      2d: mov al, 0
      2f: call 34 <func_0x34>
      34: xor esi, esi
      36: mov dword ptr [rbp-0x8], eax
      39: mov eax, esi
      3b: add rsp, 10
      3f: pop rbp
      40: ret 
Aliases: []
00000034 <func_0x34>:
      34: xor esi, esi
      36: mov dword ptr [rbp-0x8], eax
      39: mov eax, esi
      3b: add rsp, 10

func_0x24 and func_0x34 are resuts of this.

For now i don't care; but for larger binaries its extra unnecessary noise (and will likely be a whole lot, one fake function for every unrelocated call!).

One solution is to ignore callq's with 0 operand (I don't think this is a good idea, because iirc, i386 uses this technique to implement thunks for simulated RIP relative addressing), OR, cough relocate the binary.

The latter is probably the way to go and for starters could just be as simple as looking up 0 callq functions (or any callq really) for a matching relocation request, in which case, ignore it.

This will be extra machinery (good machinery), so for starters I think it's sane to just start with getting the object file to be disassembled at all