1

I have around 300 bytes of binary machine code.

I don't know which instruction set the code is for so I can't open it with IDA.

Is there any tool that can help identify the instruction set?

2

There are several tools to identify the opcodes in a file.

  1. binwalk

    If your blob is an archive and mix several files or has no magic numbers at the beginning, then try to run binwalk on it with the following options (see binwalk's documentation for more details):

    #> binwalk --opcodes myfile.bin
    

    If you are using IDA, you can also use this binwalk IDA plugin.

    Binwalk IDA Plugin Menu

    Result of the Binwalk IDA Plugin

  2. file

    If your file has some magic numbers, then the easiest way would be to run a file on it. This program identify a lot of different file formats and display a lot of information about each format.

    #> file myfile.bin
    
| improve this answer | |
  • I don't have a bin fie, I just have 400 bytes of hex , I can copy it to bin file – FIF9K9J Jun 26 '18 at 17:35
  • Then, binwalk... – perror Jun 26 '18 at 17:38
  • Ah, you can also use this binwalk IDAplugin. – perror Jun 26 '18 at 17:44
  • what if the code is a vm code this method won't work special if it is handmade vm @perror – zixcool Jun 27 '18 at 12:57
  • If you can see the bytes, then you can extract it... there is no magic here. – perror Jun 27 '18 at 13:00
1

You might try to use cpu_rec it claims to be able to identify a wide variety of architectures by analyzing the raw binary data ( 70 architectures).

cpu_rec is a tool that recognizes cpu instructions in an arbitrary binary file. It can be used as a standalone tool, or as a plugin for binwalk.

How to use the tool

As a binwalk module

Add the flag -% when using binwalk.

Be patient. Waiting a few minutes for the result is to be expected. On my laptop the tool takes 25 seconds and 1 Gb of RAM to create the signatures for 70 architectures, and then the analysis of a binary takes one minute per Mb. If you want the tool to be faster, you can remove some architectures, if you know that your binary is not one of them (typically Cray or MMIX are not found in a firmware).

As a standalone tool

Just run the tool, with the binary file(s) to analyze as argument(s) The tool will try to match an architecture for the whole file, and then to detect the largest binary chunk that corresponds to a CPU architecture; usually it is the right answer.

If the result is not satisfying, prepending twice -v to the arguments makes the tool very verbose; this is helpful when adding a new architecture to the corpus.

If https://github.com/LRGH/elfesteem is installed, then the tool also extract the text section from ELF, PE, Mach-O or COFF files, and outputs the architecture corresponding to this section; the possibility of extracting the text section is also used when building a corpus from full binary files.

Option -d followed by a directory dumps the corpus in that directory; using this option one can reconstruct the default corpus.

Examples

Running the tool as a binwalk module typically results in:

shell_prompt> binwalk -% corpus/PE/PPC/NTDLL.DLL corpus/MSP430/goodfet32.hex

Target File:   .../corpus/PE/PPC/NTDLL.DLL
MD5 Checksum:  d006a2a87a3596c744c5573aece81d77

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             None (size=0x5800, entropy=0.620536)
22528         0x5800          PPCel (size=0x4c800, entropy=0.737337)
335872        0x52000         None (size=0x1000, entropy=0.720493)
339968        0x53000         IA-64 (size=0x800, entropy=0.491011)
342016        0x53800         None (size=0x22000, entropy=0.727501)

Target File:   .../corpus/MSP430/goodfet32.hex
MD5 Checksum:  4b295284024e2b6a6257b720a7168b92

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             MSP430 (size=0x5200, entropy=0.472185)
20992         0x5200          None (size=0xe00, entropy=0.467086)

We can notice that during the analysis of PPC/NTDLL.DLL a small chunk has been identified as IA-64. This is an erroneous detection, due to the fact that the IA-64 architecture has statistical properties similar to data sections.

If the entropy value is above 0.9, it is probably encrypted or compressed data, and therefore the result of cpu_rec should be meaningless.

Known architectures in the default corpus
68HC08 68HC11 8051 Alpha ARcompact ARM64 ARMeb ARMel ARMhf AVR AxisCris Blackfin Cell-SPU CLIPPER CompactRISC Cray Epiphany FR-V FR30 FT32 H8-300 HP-Focus HP-PA i860 IA-64 IQ2000 M32C M32R M68k M88k MCore Mico32 MicroBlaze MIPS16 MIPSeb MIPSel MMIX MN10300 Moxie MSP430 NDS32 NIOS-II OCaml PDP-11 PIC10 PIC16 PIC18 PIC24 PPCeb PPCel RISC-V RL78 ROMP RX S-390 SPARC STM8 Stormy16 SuperH TILEPro TLCS-90 TMS320C2x TMS320C6x V850 VAX Visium WE32000 X86-64 X86 Xtensa Z80 #6502#cc65

| improve this answer | |
  • 1
    This tool is unreliable due to its tendency to produce false positives. This is due in large part to a lack of binary file preprocessing required to identify and differentiate between data and code regions ("de-noising"). It is telling that in the only example given a false positive is produced. – julian Jun 27 '18 at 0:52

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