Inaccurate address attribution with `else if` (affects Show Condition As Inverted)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- cpp
- Área
- reverse-engineering
Línea de trabajo
Start with the attached test.zip reproducer and inspect func1, comparing the decompiler's address attribution with the shown disassembly. Trace how the shared 00400000 address is used by Show Condition As Inverted and comments; done means the else-if is attributed to its relevant instructions and those actions target the intended condition.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Version and Platform (required):
- Binary Ninja Version: 5.1.8002-dev (9b330043)
- Edition: Commercial
- OS: macOS
- OS Version: 15.5 (24F74)
- CPU Architecture: ARM
Bug Description:
Possibly related to #7080 and #7175.
Here is the reproducer. For this report we're looking at func1 (func2 is for another report).
The initial decompilation I get is:
00400000 int64_t func1(int64_t arg1)
00400000 if (arg1 != 0)
00400010 extern3()
00400000 else if (extern1() != 0)
0040000c extern2()
00400010 extern3()
00400010
00400018 return extern4()
If I right-click the line containing else if (extern1() != 0) and click Show Condition As Inverted, then instead of inverting that condition, it inverts the previous if statement:
00400000 int64_t func1(int64_t arg1)
00400000 if (arg1 == 0)
00400008 if (extern1() != 0)
0040000c extern2()
00400010 extern3()
00400000 else
00400010 extern3()
00400010
00400018 return extern4()
This appears to be caused by the fact that the if and else if are both assigned the same address, 00400000. This doesn't really make sense. The relevant part of the disassembly is:
00400000 800000b5 cbnz x0, 0x400010 <-- branch if arg1 != 0
00400004 13000094 bl extern1 <-- call extern1()
00400008 600000b4 cbz x0, 0x400014 <-- branch if return value == 0
The else if would be better attributed to 00400004-00400008.
(That said, my ideal behavior would be if the decompiler could distinguish two branches in decompiled output even if they did come from the same code address. Show Condition As Inverted is not critical functionality, but the same issue also affects comments, which never end up quite where I want them even after #2728.)
- Lenguaje dominante
- C++
- Estrellas
- 1.3k
- Forks
- 298
- Merge medio
- 5 d 5 h
- PR fusionados (30 d)
- 19
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de Vector35/binaryninja-api
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
Vector35/binaryninja-api#8540 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Vector35/binaryninja-api#8516 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
Vector35/binaryninja-api#8503 ·
-
normalize time logs from WARP Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Vector35/binaryninja-api#8446 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Vector35/binaryninja-api#8444 ·
Todos los issues de Vector35/binaryninja-api
Issues similares
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 92/100
autowarefoundation/autoware_universe#13413 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
automated-analysis bug memory-safety
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
gazebosim/gz-sensors#662 · 1 comentario ·