3

I am writing a processor module for the Oki6620* architecture. Like ARM's Thumb mode or m7700's M flag, this architecture has a special flag that affects instruction decoding, named DD (Data Descriptor).

For a POC, I have a global flag to my IDA processor definition, and change the DD flag depending on the instruction analysed. However, due to IDA's multithreading when analysing/decoding instructions (notify_ana/notify_emu/etc), this clearly doesn't work well.

Even worse, when clicking around in IDA on random instructions, said instructions sometimes get changed randomly because the current DD flag's value is different from when the instruction was first analysed.

My two main questions are:

  • m7700 and ARM both have an option to set the flag from the interface (Alt+G, if I'm not mistaken), and I'm looking for a way to implement this in my module too. Does anybody know how to do that ?
  • Also, I'd be interested in input on how one would handle correctly this DD flag depending on the thread actually running (keep DD values in an array, for each block of code between two DD-value-changing instruction ? things like that)

Here is a PDF explaining the ISA and processor info. My current code (draft of course) is available on github.

Thank you very much in advance.

1 Answer 1

1

First of all, IDA kernel can perform an instruction emulation step in any order (usually consecutive, that's why sometimes you are getting the results that you expect) in accordance with their SDK documentation:

The second step, the emulation, is called for each instruction.
This step must make necessary changes to the database, plan analysis of subsequent instructions, track register values, memory contents, etc. Please keep in mind that the kernel may call the emulation step for any address in the program - there is no ordering of addresses. Usually, the emulation is called for consecutive addresses but this is not guaranteed.

Overall, I see a number of issues with your code, that prevent it from operating correctly. I won't be digging deep in each one of them, just provide a quick overview and some hints:

  1. You are trying to store the data about the flags in your own global variables. This is wrong, since IDA is completely unaware of it. Therefore, you should utilize IDAs structures for that.

For example, the DD flag that you are talking about affects just the size of the operands, utilized in the specific instruction. Therefore, this information should be stored in the insn_t object. The closest example would be arc processor module (it is written in C, but it is really easy to understand) from the official IDA SDK, specifically, this part:

// fix operand size for byte or word loads/stores
inline void fix_ldst(insn_t &insn)
{
  if ( insn.itype == ARC_ld || insn.itype == ARC_st )
  {
    switch ( insn.auxpref & aux_zmask )
    {
      case aux_b:
        insn.Op2.dtype = dt_byte;
        break;
      case aux_w:
        insn.Op2.dtype = dt_word;
        break;
    }
  }
}

The information about the flags is stored in insn.auxpref in this case. You can work your way from there, looking further into the implementation of flag set/clear routines in the same module.


  1. You've defined dozens and dozens of the same instructions in INSN_DEFS. Even after processing in init_instructions you would end up with duplicate entries. Take a look, for example, on add instruction. The only difference is actually operands and their sizes. You should've defined just one add instruction with 2 arbitrary operands, for example, like that:

{"add", CF_CHG1|CF_USE2}

All the further processing (number of operands, their values, DD flag, etc.) should be performed in ana and emu modules.

So, you should introduce quite a lot of code changes in order for this processor module to become operational.

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.