2

So, as you may know, many android bootloaders are based on the Little Kernel project on codeaurora, and as such one could say you have partial source to most android bootloaders, typically in the firmware packages you can find on the vendor sites, minus the proprietary bits most vendors add instead of the standard open source fastboot protocol.

With this in mind, what would be the best method to approach this disassembly?

I am currently working against the output of objdump -D on the binary and comparing that to the same output on the compiled object files from the little kernel build. There are a number of 1:1 matches, but there are some portions that, while apparently analogous, are not quite correct. One would assume this to be due to changes made by the company, but I can't be sure on this matter.

Improve this question

1 Answer 1

Reset to default
1

The linear sweep provided by objdump should do the job quite nicely with a small amount of work afterward. The reasons are:

  • Bootloaders are quite small and simple code requiring only small amount of external calls (even system calls are few).

  • This is ARM assembly code, which means that this is aligned-instructions. There is no way to confuse the disassembler by shifting one byte ahead the code.

  • There is no real obfuscation in these programs, except for small compiler tricks or a few optimization.

So, even if there will probably be some extra work afterward, most of the code should be recovered nicely with a simple linear sweep.

Improve this answer
7
  • I'm more after techniques that can be used to ease reversing the objdump output into human readable code/psuedocode by avoiding known bits provided by the partial source
    – hanetzer
    Aug 24, 2015 at 13:03
  • What would be the expected output then ? Could you be a bit more precise on what you expect at the end ?
    – perror
    Aug 24, 2015 at 13:52
  • Say I have source for {a..w}.c, and I generate assembly for their object files, and I wish to compare them to the assembly output of the final binary to determine source (approximate) for x.c, y.c, and z.c added by the vendor. What would be the best way of determining which assembly code belongs to known source?
    – hanetzer
    Aug 24, 2015 at 18:15
  • 1
    If it was binary only diffs, I would have advised you to look at BinDiff (or similar tools), but here you want also a link to known source code which makes it a bit more complex (surprisingly because you have more information). I do not know any tool that help to track down a link between a binary and a base of source files... Yet, this is a very interesting problem...
    – perror
    Aug 24, 2015 at 19:15
  • 1
    Perhaps I should cook up a tool myself, then
    – hanetzer
    Aug 24, 2015 at 21:34

Your Answer

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

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