You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It might be possible to use binja like in #3 to check this. Basically for branch destinations with 32-bit instructions, we'd try to parse them with binja in both ARM and THUMB mode and see if one case fails. u32s that are valid in both may require a more involved solution (e.g. looking at cpu registers), but using binja would be a good first step.
The text was updated successfully, but these errors were encountered:
It should be straightforward to determine if an insn is ARM/THUMB at translation-time using BinaryNinja. Since the only callback arg is a single u64 which is already used for the branch/target address I could encode the processor state as the LSB of this u64 (similar to how it works in hardware). This avoids the need for dynamic memory allocation and would simplify the plugin design.
I updated the simple built-in backend to check for both the ARM and THUMB encodings of the blx with register instruction. The plugin should track whether the CPU is in ARM or THUMB mode because the current solution may print spurious warnings as explained in this commit. I should track the CPU state before adding THUMB support for the binja backend.
It might be possible to use binja like in #3 to check this. Basically for branch destinations with 32-bit instructions, we'd try to parse them with binja in both ARM and THUMB mode and see if one case fails. u32s that are valid in both may require a more involved solution (e.g. looking at cpu registers), but using binja would be a good first step.
The text was updated successfully, but these errors were encountered: