Writing a disassembler is a tedious task. You have to decode the opcode, interpret the meaning of the operands and, finally, print the instruction correctly. Fortunately, you can count on IDA to provide modules with mapping executable, a colorful GUI, control flow graphs and so on. In this article, I'll share my feedbacks on developing an IDP module for IDA.

Even if IDA supports plenty of processors, sometimes you can stumble upon an unsupported architecture and you have to do the dirty job yourself. The aim of this article is to give an overview regarding the development of a processor module for IDA (IDP). However I'm not an expert and there's no documentation at all (only samples in the SDK). So, if you have specific questions, feel free to contact the IDA support. Igor and Ilfak answer really quickly (more quickly than my own mum), and if you find errata, feel free to leave a comment. :)

Disassembly process

IDA uses 3 steps to disassemble an instruction:

Analyze (ana) In this step, the IDP module has to fill a global structure insn_t named cmd. Basically, this structure contains the instruction id, the size of the instruction, and operands information. Since IDA can only remember 2 operands type per instruction, if your targeted processor can handle multiple operand, you have to use them wisely.

Emulation (emu) The term emulation doesn't mean you must define the whole semantic for all instructions. But you have to provide the instructions behavior expected by IDA: ua_add_cref (Code cross-reference) fl_F (flow), fl_JN / fl_JF (jump near or far) or/and fl_CN / fl_CF (call near or far),

(Code cross-reference) (flow), / (jump near or far) or/and / (call near or far), ua_add_dref (Data cross-reference) dr_O (offset), dr_R (read), dr_W (write), and so on.

(Data cross-reference) (offset), (read), (write), and so on. segment register see .

stack analysis see . These data are required in order to explore the executable as much as possible (the more the navigation bar is blue, the better).

Output (out) Output process makes your IDP fill a string using tag color_t which enables IDA to display colorful disassembly. Usually, you start to reserve a local buffer and define it using the function init_output_buffer, then you can use out_tagon and out_tagoff to specify color or helper functions like out_keyword, out_symbol... Once the buffer is filled, you tell IDA it's done by calling term_output_buffer, setting gl_comm = 1 and calling MakeLine. To tell the truth, I had to check on sample for this one...