Is there any way to differentiate different microcontroller's hex files? I have a hex file and now I have forgotten of which micro-controller it belongs. Is there any available tool to tell this? or any tip or trick to know?

Edit: There is a similar question here, But this question specifically belongs to PIC family while I what if we have to differentiate from different families like AVR, 8051, PIC etc.

  • Related: reverseengineering.stackexchange.com/q/233/187
    – user187
    Mar 24, 2013 at 16:26
  • Perhaps you could specify the microcontroller brand already? ARM, PIC, ..?
    – user187
    Mar 24, 2013 at 16:27
  • I have edited my question, making it more clarifying Mar 24, 2013 at 16:30
  • Maybe someone could contribute common byte patterns you're likely to see for different architectures? Is that the question you're asking? Mar 24, 2013 at 18:03

3 Answers 3


My first idea would be to perform a frequency analysis on aligned bytes. For most of the assembly languages, the most relevant bytes are aligned on the most significant bits.

So it might be quite easy to create a distinguer that can recognize the type of asm. But, suprisingly, after a few googling, I didn't find any tool or paper about this...

Maybe there is something to do here.


I don't know of tools designed for this. In practise, loading it into IDA (or any other disassembler) with different architectures until it looks right is probably the easiest way to do it. You might be able to write a script to automate this.

If you want to build your own tool, I suggest you look at Christopher Domas's talk "The future of RE Dynamic Binary Visualization". It discusses a number of techniques that can be used to analyse unknown data. The general idea graph the frequency of every group of two or three bytes in each file. The graphs are distinctly different between different architectures, and could be used to automatically identify data types. The actual tool, and the dataset you would need, is not publicly available, but this is the way I would go if I wanted to do automatic architecture detection.

A simpler approach would be to search for function prologue patterns in different architectures. Although the implementation is simpler, it would take more human-time to prepare the dataset (because identifying function prologues cannot be automated). Some processors may not be powerful enough to run C code, and if the code is not compiled it's possible to not have predictable function prologues. You may be able to find other common operations that you could search for.

  • My first thought was Domas's Cantor Dust tool as well, but I can't seem to find the demo version online anywhere. Absent that, a simple histogram of 2 or 3 bytes sequences in the file can give a quick picture of what kind of data is in it and lead to some common instructions. Some hex editors have histogram functionality built in if you don't want to write up your own tool. Mar 25, 2013 at 3:26
  • @nopnopgoose a 'demo/alpha' version of Cantor Dust can be downloaded from the black hat media archives. If you rename your binary to "visual_re.example" under /resources/ you can play around with it a bit.
    – ixje
    Mar 25, 2013 at 7:46

Try to get an idea of what kinds of CPUs it could target. You can probably also guess the bit length of the CPU by looking at this file (file_size % 32 == 0? Probably 32 bit). Once you have a simple list, run the binary through some disassemblers and see if the code makes sense. Try running it in some emulated CPUs and see if it does anything.

Also, keep in mind that invalid instructions might not mean you've got the wrong CPU, it could just be data or something. It's actually probably worth checking out the file to see if you can't find any strings or anything, just to get a better sense of where things are.

  • 1
    We're talking about microcontrollers here, there are 8-bit and 16-bit MCUs as well. This is not about a computer.
    – user187
    Mar 24, 2013 at 19:57
  • Oh, whoops, misread the question. Apologies. Mar 25, 2013 at 20:11

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.