8

When using objdump I see the following disassembled code:

8049436:    89 04 24                mov    DWORD PTR [esp],eax
8049439:    e8 52 f7 ff ff          call   8048b90 <gtk_entry_get_text@plt>
804943e:    89 44 24 24             mov    DWORD PTR [esp+0x24],eax
8049442:    eb 01                   jmp    8049445 <gtk_grid_new@plt+0x6c5>
8049444:    1d c7 04 24 0b          sbb    eax,0xb2404c7
8049449:    00 00                   add    BYTE PTR [eax],al
804944b:    00 e8                   add    al,ch
804944d:    0f f7 ff                maskmovq mm7,mm7
8049450:    ff eb                   jmp    <internal disassembler error>

This is using an obfuscation technique to make the disassembling harder. When I check in gdb I see the real code at 0x8049445:

(gdb) > x/10i 0x8049445
0x8049445:  mov    DWORD PTR [esp],0xb
0x804944c:  call   0x8048b60 <raise@plt>
0x8049451:  jmp    0x8049454
0x8049453:  sbb    eax,0xfff8a7e8

Now, my question is: is it possible to tell objdump that the byte at 0x8049444 can be ignored for the purpose of disassembly? One obvious way is to actually patch the file, but is there another way?

And if not with objdump, are there other tools that can do that? Though I'd rather stay with the basic tools included with Linux so as to familiarize myself with those better.

Improve this question
1

4 Answers 4

Reset to default
9

Most tools don't support a 'ignore that byte for disassembly' feature, only IDA, Hopper and a few others do.

The only alternative is to patch the byte at 8049444 with a 90 NOP, or change your mind and not rely on basic tools.

Improve this answer
1
  • Both good suggestions. For option (1), search for jmp +1, set the next byte to nop and happily continue working with objdump. I'd go for option (2) -- to the extent I wrote my own.
    – Jongware
    Commented Oct 16, 2013 at 10:15
8

That's not obfuscation, that's just the output of a lousy disassembler engine.

Use IDA Pro instead. You can download an evaluation version for Linux from here.

Improve this answer
4
  • 6
    This has nothing to do with being "lousy". It simply uses a linear sweep disassembling strategy (as opposed to recursive traversal). Both strategies fail in certain situations / against different anti-disassembling techniques.
    – newgre
    Commented Oct 15, 2013 at 20:55
  • "Lousy" in regard to meeting the original poster's needs. He should be using a recursive descent disassembler such as IDA Pro.
    – Jason Geffner
    Commented Oct 15, 2013 at 20:58
  • IDA Pro actually uses both, IIRC. First off, it tries to evaluate from the program entry point (which would already produce a correct listing for the OP's code). Then it scans remaining data for what looks like function prologue, and only after that it rounds up stray bytes (of which there should not be much left).
    – Jongware
    Commented Oct 15, 2013 at 21:26
  • 1
    I tried IDA Pro. Its disassembly was, for this particular case, less corrent than the one made by objdump. But once debugging it fixed itself. Or I could fix it manually too.
    – Mew
    Commented Oct 16, 2013 at 18:42
6

This problem comes from the way objdump disassemble a binary. The technique used here is called linear sweep, it is done by starting at the beginning of each symbol in all the sections that are flagged as CODE and disassemble instruction after instruction, supposing that what follow an instruction is also an instruction. The problem with this disassembly technique is that if you mix code and data, data will be interpreted as code as well. For example:

...
0x0    mov DWORD PTR [esp+0x24],eax
0x4    jmp *0x10
0x6    DATA 0xfffa2345
0x10   mov DWORD PTR [esp+0x20],eax
...

Here, applying a linear sweep technique on the hexadecimal code will result in a wrong interpretation of the data which will be considered as code. And, if your are really unlucky, a few instructions after the data will also be scrambled.

As already suggested in other answers, the only way to discover the real code is to use a different disassembling technique. Unfortunately, objdump provide only one (linear sweep), so you need to use another tool.

Note also that the other technique suggested in other answers (recursive traversal) will perform well for this specific case but can also issue a wrong disassembly of the original code on some other examples. So, you cannot trust it either.

Improve this answer
4

As everybody else is saying, in this case it is due to linear sweep. However, I would like to add that even IDA can be fooled with Junk Bytes and you can only trust the disassembly while debugging a sample. As encoders can change the code on the run, only trust the value on the EIP and nothing else to be correct code.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.