I have firmware for a system and I'm trying to decrypt some of it just for the sake of seeing what it all does; nothing illegal or anything like that, such as reproducing copies of it decrypted and such.

But it can seem tough for several reasons:

1.May have no specific format or way to distinguish it from other binary files;

2.May not know how it is encrypted;

3.May not be "normally" encrypted and may be specially so.

The thing is, the file has some unencrypted code, but I'm not 100% sure what kind of opcode bytes it could represent since it

This is firmware for an all-ARM-powered device, but I'm not publicly saying it's name. Should that mean that the firmware for it will be some variant of ARM ISA/opcodes (because it's machine code for the ARM processor)? If so, where should I begin decrypting and should I continue to determine, if possible for me, what version of ARM, ISA (instruction-set=architecture), etc.?

The firmware has a magic number right at the beginning of the file (which just says the company's name), but afterwards it has unencrypted bytes, then more magic numbers, then encrypted bytes, then more magic numbers, then more unencrypted bytes, etc., etc. You can tell the encrypted parts apart because each byte has a completely inane ASCII character that no other part of the file has, and they're in followed segments. This says clearly that these are irregular, encrypted ranges of bytes.

  • In general, people post the hardware they're working with, here, this might attract good answers from people who have done a similar thing. Look around, you'll see that many questions even provide links to the downloadable firmware. As it is right now, the only answer you can get is probably "run binwalk and signsrch on it and see what happens". If it's ARM, it's likely it runs some kind of linux, which in turn makes it likely that you're dealing with some kind of squashfs. Dec 9, 2014 at 18:46
  • 1
    "If it's ARM, it's likely it runs some kind of linux" What runs some kind of Linux? The firmware here is firmware to start the rest of the computer up. SquashFS is a filesystem, and how is that supposed to help decrypt the firmware? If anything, decrypting the firmware is what'll allow the rest of the hardware to be reverse-engineered, so it's kind of like a gateway-hack in some ways. Dec 9, 2014 at 19:06

1 Answer 1


Wow to identify firmware format

  1. In old days the Intel HEX and bin Flash memory dump was used

    the firmware was usually copied to device by HW programer for specific IC or by ISP. HEX is very specific Intel_HEX (*.hex) text file easy to identify. Ont he other hand BIN dumps are hard to identify. If you can see any tokens inside or can disassemble it and the code makes sense then it is probably a binary memory dump. If it is encrypted you are out of luck.

  2. elf or obj format

    these are newer object formats similar to PE. ELF in hex view looks like this:

    7f 45 4c 46 01 02 01 00 | 00 00 00 00 00 00 00 00 | .ELF...

    OBJ is very dependent on target platform and if it is from Intel,MS or for Linux,...

  3. file system dump

    some devices have own programing interface implemented and use firmware as disc image so the file is dump of some FileSystem in which is the firmware written as some file(s). You have to identify the FileFormat type (usually by boot sector first 512 Bytes). Then extract the files inside and start over again from scratch. Sometimes helps if you take an USB key and write the file system dump to it 1:1 and then try to access it from OS that supports various fileformats. You can also use some HDD utility like PQ-magic or whatever capable of identify FS types.

  4. decryption

    you need disassembler for used IC or even better simulator/emulator some device SDK's contains also the simulation so try to load the firmware to its memory and try to run it to test if it does something meaningful. For disassembly you need to analyze the code to see that too ...


you should post at least file extension and hex view of the start of the file

[edit 1] response to commend + some additional info

starts the text exactly from start or not?

So it still can be: - bin memory dump - anything packed/encoded (even specific file system)

  1. Identify packed/encoded structures

    try to find chunks inside like the RIFF (*.avi) format. Beware there could be no ID string present. You are basically looking for hex encoded length or offset in file that would add up to file size or next chunk structure that have the length at specific chunk offset or in separated table. Do not forget it can be booth LSB or MSB first do not assume anything. Length/offsets are usually encoded 16/32/64 bit (2/4/8 BYTE) Also try to find repeating patterns (if some kind of header of chunk is present)

  2. Identify file system

    some FS have specific ID at some offset so look for that (like FAT32,...). Most FS use FAT+DIR tables so look for something like this:

    MDOS DIR example

    this is how DIR table looks like in MDOS file system. It is a structure holding all files/directories of the disc. Each file should have encoded name,type(extension),start sector,length.

    • E5 hex = 229 dec usually marks free directory space (in many FS systems)

    so if you know any filename that should be present in the target system you could look for it to locate DIR table ...

    MDOS FAT example

    this is how FAT table looks like in MDOS. The FAT holds information about each sector/cluster of the disc. In this case it is 12 bit so each value is 1.5 Byte long !!! Some values mark sectors as system/reserved (non usable),bad,free or if any other value present then it is an index of next sector that is connected to this like in linked list. While decoding take in mind that endianess could be both little or big

  3. To identify bin memory dump

    In this case the file is memory dump of your arm OS. That mean you should look for specific parts of program like:

    • interrupt table
    • specific program tokens (what it prints out... )
    • graphics

    The last two are pretty straightforward so I will add info only for the interrupts. Interrupts on most processors have fixed location in memory so for each interrupt there is few bytes reserved. In this place is usually some jump instruction present that jump should lead to interrupt handler routine which should end with specific end of interrupt instructions like: reti,retn or by setting/reseting specific register to mark interrupt was handled ...

    So look for tightly packed jump instructions inside bin and if found check if their count and distance match the CPU datasheet. Also you can check if somewhere near the jump address is return from interrupt present. If yes then you have all you need. Offset of the interrupt table is usually fixed ... so you should easily find out where from the bin dump starts in the target device memory map.

    Beware your bin can have offset encoding like the Intel hex files

  • The extension is just .bin. Hex view at the start is the company's name, which occupies 50+ bytes and is identifiable by ASCII, Unicode text. Dec 12, 2014 at 17:33
  • @stackfullofheaps added [edit1] to answer as response would be too much for comment
    – Spektre
    Dec 13, 2014 at 9:48
  • I never really bothered to think that firmware could be used as a filesystem/disk for that purpose. Dec 13, 2014 at 17:27
  • @stackfullofheaps some devices have no connections capabilities so an upgrade SD card is the only usable option. also some fileformats include FATs directly like Garmins map files ... so you should always consider that option too
    – Spektre
    Dec 13, 2014 at 20:52
  • The device I am trying to reverse engineer has a hard disk and full operating system, so I am going to rule-out a filesystem flash bridge, but maybe not entirely yet. Dec 13, 2014 at 21:43

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.