ninja thumb IT Conditional instruction Bring error analysis

[imethod]

• Binary Ninja Version: [e.g. 3.3.3996-dev] (if version is stable, please also test the latest development build via the "Update Channel" option)
• OS: [win10]
• CPU Architecture: [x64]

Bug Description: IT Conditional append instruction goto instruction ninja does not recognize subsequent instructions, resulting in errors

Steps To Reproduce: Please provide all steps required to reproduce the behavior: Go to 0x12780 Make a function at 0x12781 (because this is Thumb2 code) Observe that the ite cc at 0x12808 does not apply to the b #0x127b6 that follows at 0x1280a

Screenshots:

Additional Information: demo.zip

Please add any other context about the problem here. fix.zip fix.zip rename fix.so

[fuzyll]

If the version you've reported above is correct, this may have already been fixed by #1720. Are you able to update to a newer version of Binary Ninja and see if this is still an issue for you?

I was also unable to open the file you uploaded. It looks like maybe it's a RAR file? But, I can't get it extracted.

[xusheng6]

@fuzyll Yeah the file is a RAR. I extracted it and then compressed it to a zip archive

fix.so.zip

[imethod]

如果您上面报告的版本是正确的，则#1720可能已修复此问题。您是否可以更新到较新版本的 Binary Ninja，看看这对您来说是否仍然是一个问题？

我也无法打开您上传的文件。看起来可能是一个 RAR 文件？但是，我无法将其提取出来。

sorry My compression tool automatically recognizes the files so I always thought they were generic so I just changed the suffix fix.zip

[fuzyll]

Can confirm this still happens on latest dev build. It looks like the ite cc is lifted as undefined, just as shown in the images above. I'm wondering if we just don't handle the carry clear condition in this situation.

I had to actually create the function at 0xbf5e8780 myself, auto-analysis didn't seem to pick it up.

[imethod]

This is my goto patch function for deobfuscator It seems that ninja ignored the following instructions when it recognized goto You can see this in other parts of the function Resulting in subsequent analysis errors

Perhaps the recognition of the goto statement precedes the recognition of the control statement?

[imethod]

Can confirm this still happens on latest dev build. It looks like the ite cc is lifted as undefined, just as shown in the images above. I'm wondering if we just don't handle the carry clear condition in this situation.

I had to actually create the function at 0xbf5e8780 myself, auto-analysis didn't seem to pick it up.

0xbf5e8780 Maybe no function references him He was called indirectly 'carry clear condition' The normal flow of the program cannot be ignored

[fuzyll]

This also repros if you don't rebase the binary above. New repro steps without rebasing:

1. Go to 0x12780
2. Make a function at 0x12781 (because this is Thumb2 code)
3. Observe that the ite cc at 0x12808 does not apply to the b #0x127b6 that follows at 0x1280a

[imethod]

thanks

[lwerdna]

Binja sees the unconditional branch in isolation at 1280a (unaware of IT instruction) and ends the block:

Due to this, when the ite at 0x12808 is lifted, the arch plugin is given only the 6 bytes in green. This blob contains just 1 instruction following the ite, but the lifter knows ite needs 2, so it errors.

This is the context-aware disassembly/lifting issue again. Brainstorming:

• If an itxxxx could "look below" and mark addresses, then would know not to AddBranch(UnconditionalBranch, ...) in that range.
• If unconditional branches could "look up" and see an itxxx, same logic.
• We could consider itxxxx and the instructions that follow as a single instruction, displaying the component instructions on a single line. This approach was demonstrated recently by a customer writing an architecture with packet instructions that contain sub instructions.

[plafosse]

Without support for some sort of context I don't think we're going to be able to solve this. One solution could be: https://github.com/Vector35/binaryninja-api/issues/5197