Decrypting firmware: Is there a true "format" to it, and how does it differ from decryping other files?

Question

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.

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 ...

[Notes]

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:

   

   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 ...

   

   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