Open imethod opened 1 year ago
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.
@fuzyll Yeah the file is a RAR. I extracted it and then compressed it to a zip archive
如果您上面报告的版本是正确的,则#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
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.
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?
Can confirm this still happens on latest
dev
build. It looks like theite cc
is lifted asundefined
, 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
This also repros if you don't rebase the binary above. New repro steps without rebasing:
ite cc
at 0x12808 does not apply to the b #0x127b6
that follows at 0x1280athanks
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:
AddBranch(UnconditionalBranch, ...)
in that range.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
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:
![image](https://github.com/Vector35/binaryninja-api/assets/109936536/66173360-659e-4d27-a04f-246cb6ab5b1e)
Additional Information: demo.zip
Please add any other context about the problem here. fix.zip fix.zip rename fix.so