[Frontend] CFG creation: 21445 (KeyError)

[NeoQuix]

What happened?

Traceback (most recent call last):
  File "/home/neoquix/Git-Repos/DeWolf/decompile.py", line 80, in <module>
    main(Decompiler)
  File "/home/neoquix/Git-Repos/DeWolf/decompiler/util/commandline.py", line 87, in main
    task = decompiler.decompile(function_name, options)
  File "/home/neoquix/Git-Repos/DeWolf/decompile.py", line 54, in decompile
    task = self._frontend.create_task(function, task_options)
  File "/home/neoquix/Git-Repos/DeWolf/decompiler/frontend/binaryninja/frontend.py", line 137, in create_task
    raise e
  File "/home/neoquix/Git-Repos/DeWolf/decompiler/frontend/binaryninja/frontend.py", line 126, in create_task
    cfg = self._extract_cfg(function.function, options)
  File "/home/neoquix/Git-Repos/DeWolf/decompiler/frontend/binaryninja/frontend.py", line 156, in _extract_cfg
    return parser.parse(function)
  File "/home/neoquix/Git-Repos/DeWolf/decompiler/frontend/binaryninja/parser.py", line 37, in parse
    self._add_basic_block_edges(cfg, index_to_BasicBlock, basic_block)
  File "/home/neoquix/Git-Repos/DeWolf/decompiler/frontend/binaryninja/parser.py", line 50, in _add_basic_block_edges
    lookup_table[edge.target.source_block.start],
KeyError: 21445

How to reproduce?

Decompile decode_format_string.part.0 from od.zip

Affected Binary Ninja Version(s)

Version 3.3.3996

[ebehner]

The problem is that the address of the jump-table is not in this function, instead it is an address of another function.
Consider the switch statement of the function:

To obtain the case-constants, we have a look at the lookup_table

dewolf/decompiler/frontend/binaryninja/parser.py

Line 50 in e99a805

lookup_table[edge.target.source_block.start],

The lookup table has the following entries:

Now, the entry for case 0 belongs to the address 0x2800 and not the address 0x53c5 which is the first address of the leftmost block.
Instead, 0x2800 is the address of the block of function decode_format_string.part.0.cold:

Not sure what we can do here. If we can not match a block to a case, we can have a look whether a very similar function is called there, and then look at this instruction and try to figure out whether this address matches, but this is neither clean nor nice:

[ebehner]

try some kind of recursive search.

[rihi]

Potentially fixed by #297. No longer able to reproduce.