The following issue was identified, triaged and written by Claude Fable 5.1, I have read through it to make sure the information is coherent and useful.
Version and Platform (required):
- Binary Ninja Version: 6.1.10594-dev
- Edition: Ultimate
- OS: macOS
- OS Version: 26.5.1
- CPU Architecture: arm64
Bug Description:
Calling create_auto_var on a variable that already has a user-defined type replaces the type that reads back from Variable.type / Function.get_variable_type with the auto one, while is_var_user_defined still reports True for the variable. The same happens in the other order: a user type set after an auto type wins, and a further auto type set after that wins again. It is not clear to me whether an auto type is meant to override a user one, but the combination of a variable reporting itself as user-defined and returning the auto type looks wrong either way. In practice an analysis activity that types variables with CreateAutoVariable undoes a user's manual retype of the same variable on every re-analysis.
Steps To Reproduce:
Observed on dyld shared cache and a Mach-O with a plugin workflow, and reproduced from a script with the analysis settled. f is a function, v one of its MLIL variables with no user type, T1/T2/T3 distinct pointer types.
f.create_user_var(v, T1, v.name); bv.update_analysis_and_wait()
v.type # T1, f.is_var_user_defined(v) is True
f.create_auto_var(v, T2, v.name); bv.update_analysis_and_wait()
v.type # T2, f.is_var_user_defined(v) is still True
Reverse order on a second variable:
f.create_auto_var(w, T1, w.name) # T1, user-defined False
f.create_user_var(w, T2, w.name) # T2, user-defined True
f.create_auto_var(w, T3, w.name) # T3, user-defined still True
Expected Behavior:
Either the user type keeps precedence and create_auto_var on a user-defined variable is a no-op for the reported type, or the variable stops reporting itself as user-defined once an auto type has replaced its type. Which of the two is intended is the question.
Additional Information:
Setting the auto type with confidence 255 or 250 makes no difference. Workaround in use: check is_var_user_defined before every auto retype.
The following issue was identified, triaged and written by Claude Fable 5.1, I have read through it to make sure the information is coherent and useful.
Version and Platform (required):
Bug Description:
Calling
create_auto_varon a variable that already has a user-defined type replaces the type that reads back fromVariable.type/Function.get_variable_typewith the auto one, whileis_var_user_definedstill reportsTruefor the variable. The same happens in the other order: a user type set after an auto type wins, and a further auto type set after that wins again. It is not clear to me whether an auto type is meant to override a user one, but the combination of a variable reporting itself as user-defined and returning the auto type looks wrong either way. In practice an analysis activity that types variables withCreateAutoVariableundoes a user's manual retype of the same variable on every re-analysis.Steps To Reproduce:
Observed on dyld shared cache and a Mach-O with a plugin workflow, and reproduced from a script with the analysis settled.
fis a function,vone of its MLIL variables with no user type,T1/T2/T3distinct pointer types.Reverse order on a second variable:
Expected Behavior:
Either the user type keeps precedence and
create_auto_varon a user-defined variable is a no-op for the reported type, or the variable stops reporting itself as user-defined once an auto type has replaced its type. Which of the two is intended is the question.Additional Information:
Setting the auto type with confidence 255 or 250 makes no difference. Workaround in use: check
is_var_user_definedbefore every auto retype.