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