That’s why we strive to add support for new jump tables to IDA, and since it can not be done for all of them, we focus on compiler generated jump tables for popular processors. Take ARM, for example. The ARM processor module have been improved a lot in v5.2, but yet we received a report with a bunch of new patterns. So expect even better support for ARM in the near future 🙂
If you are interested in improving the jump table handling for a rarely used processor, here are the explanations how to do it.
First, you’ll need to hook to the emulation step of the analysis.This way your plugin will be called by the kernel as soon as the instructions that handles the jump table are analyzed. You can do it in many ways, I present 2 of them here:
- hook to processor events and intercept the custom_emu event.
- you may also replace ph.is_switch() pointer by your function. This callback is used only for indirect jump instructions, so your handler will be called only for them.
After recognizing a jump table, the IDA kernel should be informed about it. The structure that holds the jump table information is called switch_info_ex_t. The following details are stored:
- jumps: The address of the jump table
- Element size for the jump table
- ncases: Number of elements
- defjump: The address where the execution continues if the control variable is out of range (default jump address)
- startea: The address of the beginning of the switch idiom
In the simplest case, a plain 32-bit jump table with elements that contain target addresses, the structure is filled like this:
If we have more information about the jump table, we can add it to the structure. If we know the default jump address:
If we know the input register used by the table jump:
If a delta is subtracted from the input value before using it:
If the table entries are shifted to the left before used:
If there is a separate value table:
If the value table are used as indexes into the jump table:
Finally, if the jump table has a special structure, then you can set:
Naturally, the more information you put into switch_info_ex_t, the better the analysis will be. The prepared structure must be stored into the database:
For regular jump tables, the kernel will handle the rest. For custom tables, the kernel will generate the create_switch_xrefs and calc_switch_cases events. Your module must intercept them and either create cross references or calculate the requested information.
One more trick: you may also intercept the processor_t::is_insn_table_jump event to prevent the kernel from creating jump tables when it should not. The kernel has some heuristic rules to create jump tables. If they create wrong jump tables, you can intercept their creation at this event.
This was a very short introduction to the jump tables in IDA Pro. Feel free to post your questions in the forum, I’ll be glad to answer!
3 feb: minor edits