A potential bug (or at least weird behavior) I have noticed is that setting the arch and platform and then using the default option of "Make function at this address" (Hotkey P) fails to identify a function, however, selecting that very same platform and architecture from the dropdown menu does so (Linear sweep fails to find that function and makes another one right after it on a non-sense location).
This bug affects thumb2 architecture. Functions created with the default option have a different architecture (armv7).
Example:
>>> current_function.platform
<platform: windows-thumb2>
>>> bv.remove_function(current_function)
>>> # define the function using the default option
>>> current_function.platform
<platform: windows-armv7>
And the newly defined result is not correct.
Steps To Reproduce:
Open any thumb2 arch binary
Find a function
Undefine it
Using hotkey p to define the function
Observe the difference
Expected Behavior:
Make function at this address should stick to the default platform
Additional Information
Given a function's address, the API get_associated_arch_by_address will always return armv7(the function start address is aligned?). Seems like it is not very useful when defining functions.
river-li
commented
1 month ago
From public slack by @martyx00: https://binaryninja.slack.com/archives/C0CV88A83/p1720515368408829
Bug Description:
This bug affects
thumb2architecture. Functions created with the default option have a different architecture (armv7).Example:
And the newly defined result is not correct.
Steps To Reproduce:
pto define the functionExpected Behavior:
Make function at this addressshould stick to the default platformScreenshots/Video Recording: https://binaryninja.slack.com/files/UQTF3HLN5/F07BLEEKB18/weird.webm
Additional Information Given a function's address, the API
get_associated_arch_by_addresswill always returnarmv7(the function start address is aligned?). Seems like it is not very useful when defining functions.