Open DanielBotnik opened 1 month ago
After researching for a bit, I found the problem is not with the CFG normalizing algorithm, but with ConstantResolver.resolve
For some reason the jump at 0xd6f4
should return the address of memcpy
but instead it returns 0x138
Which results in smaller block created inside usb_release_dev
therefor the CFG messes up.
I would assume the calculation for $v0
is wrong.
Some of the bugs happened because R_MIPS_26
wasn't implemented, that lead to creation of wrong blocks.
Should be fixed by https://github.com/angr/cle/pull/525
Still investingating other failiures.
Description
I've tried to run
CFGFast
withnormalized=True
on my binary but I notice that for one of the functionsusb_release_dev
, the blocks were wrong. usbcore.zip is the said binary.While I expect the function to have 10 blocks like the non-normalized, when running it with
normalized=True
I get one block, and its smaller then the original block.Steps to reproduce the bug
Environment
Linux 5.10.16.3-microsoft-standard-WSL2 https://github.com/angr/angr/issues/1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Python 3.10.6 latest angr dev.
Additional context
No response