func.get_low_level_il_at() fails for ARMv7 Thumb IT EQ instructions

[MartijnB]

While trying to map a IT EQ instruction to the corresponding LLIL instruction, I found out that BNGetLowLevelILForInstruction() is not able to find the corresponding LLIL index for these instructions.

I also attached the corresponding binary:

test_sha1.zip

[rssor]

This isn't actually a bug, as there is no LLIL instruction that would make sense to have that address. The effect of it eq winds up represented in the control flow in the LLIL function.

There is no strict correspondence between assembly and IL instructions. One native instruction can have 0 or many IL instructions.

[MartijnB]

Well, it seems that the corresponding LLIL_IF instruction has as address 0x20b5a (the MOV). I would expect that the IF maps to the IT EQ, not the MOV...

[nshp]

The lifter holds onto some state internally for IT blocks, it's a weird edge case. If you look at other disassemblers, they actually do the same thing -- e.g. objdump will show it eq; moveq (statefully adding the condition to the enclosed instruction). Either way though, this shows an edge case in your logic. There is no guarantee that a native instruction has to produce an IL op.

[MartijnB]

I agree that there is no guarantee that a native instruction always maps to a LLIL instruction and I know that IT EQ is bit of an odd instruction. But for example in ARM mode an ADD followed by a CMP is also merged into a single LLIL_IF. Asking the corresponding LLIL instruction index results in both cases in the index for the same IF. Therefore, I was expecting the same behavior here, instead of failing to map it at all.

[rssor]

I see why it would be surprising, but there were a few reasons that doing it this way wound up making things cleaner in more situations. By deferring insertion of the IF/GOTOs as far as possible we wind up being able to cut out edges in a few extra cases (it comes into play more often when both a condition and its inverse are used in a single block, or when condition flag modifying instructions are themselves used in the block).

Since the outgoing 'edge' doesn't really belong to either the first instruction in the block or the it instruction itself, I wound up just always putting it in the higher address, and that way the behavior is consistent even when something in the it block modifies flags and requires a re-evaluation and possibly a new IF instruction to be added.

It would be possible to 'rewind' the address when adding the IF/GOTO statements, but since it was more work and wasn't necessarily more 'right' decided not to.

[rssor]

To expand slightly on the above: with the way it works right now, we wind up treating instructions in it blocks basically like ARM instruction conditions, where each instruction determines whether or not it executes, and, if it does not, jumps as far as possible in the future (not quite what happens on hardware, but by doing this rather than re-emitting the check on each conditional instruction we wind up with prettier graphs and better dataflow analysis).

We basically don't use it as anything except a cue to start doing exactly what we do with sequences of related conditional instructions in the ARM lifter, hence why it has no direct mapping.