I'm disassembling a function that seems to use a switch statement, resulting in an indexed indirect jump, in two different places (same function!):

0005FA58                 mov     al, [eax+112h]
0005FA5E                 cmp     al, 4
0005FA60                 ja      loc_5FBED
0005FA66                 and     eax, 0FFh
0005FA6B                 jmp     cs:off_5F98C[eax*4]

00060011                 mov     al, byte ptr unk_A4E30[eax]
00060017                 cmp     al, 3
00060019                 ja      short loc_60053
0006001B                 and     eax, 0FFh
00060020                 jmp     cs:off_5F9A0[eax*4]

0005F98C off_5F98C       dd offset loc_5FBCC, offset loc_5FA73, offset loc_5FAC5, offset loc_5FB14, offset loc_5FB66
0005F98C                                         ; DATA XREF: FunctionStart+BB
0005F9A0 off_5F9A0       dd offset loc_60049, offset loc_6003E, offset loc_60031, offset loc_60028
0005F9A0                                         ; DATA XREF: FunctionStart+670

The first jump table has 5 entries, the second one 4. Unfortunately, the compiler placed them directly behind each other in memory. This seems to confuse IDA when calculating the graph connections for those nodes:

Graph for 1st jump table

Edit, as the the wording of the question was probably misleading

The graph node shows 9 outgoing connections. 5 of them are true connections, the next 4 are not - they belong to a different jump table that happens to be directly after this one in memory. I'd like to tell IDA "This jump table has 5 valid entries, ignore the other ones when creating the graph node". Is there any way to do this?

The original question was:

The first jump table has 9 connections, 4 of which don't belong to that statement. (The second one, ommited here for brevity, has only one connection). Is there any way to tell IDA to remove the extra connections from the first table, and possibly create new connections from the 2nd table to the corresponding targets?

I already tried defining the jump tables as arrays, then undefine the function and re-define it as code, but that didn't change anything.

(I'm using IDA 5.0, as this is a hobby project, and i don't want to spend several hundred bucks on something i'll use a few times a year).


It's possible, but not in the freeware version:

  1. Put cursor on the jmp
  2. Edit->Other->Specify switch idiom...
  • Not what i wanted to hear, but probably the best answer i'll get. – Guntram Blohm Apr 16 '14 at 12:09

I'm not quite sure if I understand your problem, but how I configure jump tables is:

  1. Convert the whole table to db bytes, non-array, one byte per line.
  2. Set up the top element to be 2 bytes (dw) and then O.
  3. Highlight from the top element down to the last one and configure as array (*) but with the array checkbox unchecked.
  4. If there is a second table immediately after the first then do the same for that.

Edit: I've been a bit too wordy. What I think you need is to separate the jumps into one per line, and you do that with the array command {*} and uncheck all the checkboxes. And my experience with graph view is that it doesn't know how to handle jump tables, no matter how you configure them.

  • Sorry, i guess my question was misleading ("remove the extra connections from the first table"). My problem is that the graph node has nine outgoing connections, where it should have only five of them, so some of the links are just wrong, and the graph is more complex than it should be. I'd like to somehow tell IDA "this jump table has 5 entries, even if it seems to be 9, because the last 4 belong to a different jump table". Unfortunately, your "doesn't know how to handle jump tables, no matter how you configure them" means it's probably impossible. – Guntram Blohm Apr 15 '14 at 17:42
  • Maybe I'm wrong about that, but I thought the graph view was broken by jump tables so I never pursued it. It seems that you have to tell IDA that part of the jump table is within one function (proc) and part within another. – Paddywhacker Apr 15 '14 at 20:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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