3

Would be great to know where the entry point is after decompress bootloader from a bin firm, mips based or os21..

I mean, is always in same offset or it depends on compilation made? I think is a very useful information for good starting...

update: ok, but at this point I have another doubt, normally when you make a dump from a device (nor-nand), you get a binary which is compressed/encrypted, we know the flash map, which is divided into bootstrap / bootloader and later app, logs etc...

Main doubt comes when I get app in plain, maybe a root file system, maybe other binary files like .rodata.bin...so after this, how to deduce entry point? because with .elf is very easy (auto load) but with extracted files, normally binaries, I can't deduce if apply entry point to these extracted files, or try to find out entry point into main binary dump..(I guess that main bin could be disassembled just in it's bootloader part)

  • First, your are lucky for instructions recovery. Mips use aligned instructions, so you will be able to see the whole assembler code with a basic linear sweep. Second, isn't the entrypoint located at the top of the file for firmware usually ? Or, are you speaking about a memory dump ? – perror Nov 28 '13 at 18:08
  • ok thanks a lot for this info, I know you are a master in disassembling Igor... Many thanks in advance I will keep trying. – numind Dec 5 '13 at 14:18
  • ok, but at this point I have another doubt, normally when you make a dump from a device (nor-nand), you get a binary which is compressed/encrypted, we know the flash map, which is divided into bootstrap / bootloader and later app, logs etc... Main doubt comes when I get app in plain, maybe a root file system, maybe other binary files like .rodata.bin...so after this, how to deduce entry point? because with .elf is very easy (auto load) but with extracted files, normally binaries, I can't deduce if apply entry point to these extracted files, or try to find out entry point into main binary dump. – numind Dec 5 '13 at 14:57
9

Embedded systems are commonly run on bare metal, without any BIOS. Thus the entry point is usually the reset vector which is architecture- and system-specific. You need to consult datasheets for your chip or at least the architecture to see what it says about reset vectors.

For example, on ARM the default reset vector is at address 0 (except for Cortex-M series), so you can usually just start disassembling from the start of the firmware. i8051 is another notable example which starts at 0.

For MIPS, the canonical reset vector is 0xBFC00000. However, this is a processor address, and you'll need to figure what it maps to in the flash. This depends on how the flash is connected to the CPU, how the chip selects are set up etc. Quite possibly it may actually correspond to the start of the flash.

Another approach, used mostly by older 8-bit and 16-bit chips is placing the reset vectors near the end of the address space. So addresses like FFFE are good candidates for those. 8086 started at FFFF0 and the current x86 chips start at FFFFFFF0. But once again, if you have any datasheets, you should check them instead of guessing.

  • 1
    Alternatively the ARM vector table can be located at 0xFFFF0000. – ixje Nov 29 '13 at 18:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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