Using the UI to change a function's type removes the assigned custom calling convention
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- cpp
- Domain
- reverse-engineering
Research direction
Reproduce the issue in the Binary Ninja UI using the _localeconv_l function and the apple-arm64-objc-fast-arc-4 calling convention described in the steps. Compare the function type before and after confirming the Change Type dialog; done means the custom calling convention remains present after confirmation.
Written by the indexing model from the issue text.
Description
Version and Platform (required):
- Binary Ninja Version: 5.3.9393-dev Ultimate (ae6ee6f5)
- Edition: Ultimate
- OS: macOS
- OS Version: 26.3
- CPU Architecture: M1
Bug Description:
If a function has a custom calling convention and I right-click and select "Change Type" (or press Y) and then press enter once the dialog box comes up then the custom calling convention is stripped from the function.
Steps To Reproduce:
Please provide all steps required to reproduce the behavior:
- Open a copy of DYLD Shared Cache
- Wait for initial analysis to finish
- Go to
_localeconv_l - Edit its function properties and set its calling convention to
apple-arm64-objc-fast-arc-4 - The function type should change to
void* __convention("apple-arm64-objc-fast-arc-4") _localeconv_l(void* arg1 @ x0) - Right-click the function and select "Change Type"
- Notice that the function type is correct in the dialog
- Press enter to confirm the type
- Notice how its type goes back to
void* _localeconv_l(void* arg1)
Expected Behavior:
Custom calling conventions should not be stripped when changing the type via the UI.
Binary:
Tested against DYLD Shared Cache for iOS 26.2 for an iPhone 17 Pro Max.
Additional Information:
Didn't test whether this happens when using the Python API to make the changes.
- Dominant language
- C++
- Stars
- 1.3k
- Forks
- 298
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 19
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Vector35/binaryninja-api
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Vector35/binaryninja-api#8540 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Vector35/binaryninja-api#8516 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Vector35/binaryninja-api#8503 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Vector35/binaryninja-api#8446 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Vector35/binaryninja-api#8444 ·
All issues in Vector35/binaryninja-api
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
gazebosim/gz-sensors#662 · 1 comment ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
LadybirdBrowser/ladybird#12123 ·