Issue with jump table detection

[Leseratte10]

I'm analyzing a proprietary binary (no symbol names) for the PowerPC architecture.

Whenever there's code in the binary that used to be a large switch-case in the original C program (which is implemented in Assembly with a jump table), I see the ASM instructions to load the index, multiply it by 4, load the address from the jump table, then jump to it - but the code immediately afterwards isn't recognized as belonging to that function, the jump table isn't recognized.

This looks like this in the code:

Code:

Jump table:

Sadly, while BN seems to know that this is a jump table (it named the data block "jump_table_808bc810"), it seems to refuse to actually display this as a jump table and read the code that follows immediately after the jump. That's rather annoying, I found no easy way to tell Binary Ninja that a "bctr" isn't necessarily the function end.

It does know it's a jump table, so why doesn't it continue disassembling? Am I doing something wrong? How can I fix this?
I didn't want to open a bug report for this, as I've seen jump tables work correctly in other binaries - it's probably something I'm doing wrong, or some setting I fucked up - but I can't figure out which one.

[bpotchik]

Which version of Binary Ninja are you using?

[Leseratte10]

I believe I have the most recent one. 2.2.2643-dev-e5ac6185.

[bpotchik]

Are you able to share the MLIL of the dispatch related code? You can DM in slack as well if you like.

[Leseratte10]

This?

Looks like that already shows the issue - it doesn't handle the offset correctly. Looks like the ppc-capstone plugin I compiled myself ( https://github.com/Vector35/ppc-capstone/issues/2 ) still has some issues. When I remove my compiled module and switch back to the included one, the jump is detected correctly. Though I swear it was also broken not too long ago with the stock version of the plugin ...

Thanks for the hint with the MLIL code. I'll make some more tests with the ppc plugin and open an issue in that repository depending on the results.

[v1X3Q0]

For what its worth, I am seeing a similar problem. For myself, its because at the moment of the bctr, the value for the control register cannot be determined. I'm working on the best way I can to broaden the possible values for the submitted control register. In your case, it seems like the r4 register's value may not be able to be determined, while in mine its r0. Without it being able to get a solid for possible reg values, I'm guessing its just gonna assume that the jump table has infinite scope and eat it.