WARP doesn't save varargs status of functions
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 by reproducing the WARP Include Function, Create, and Load File flow described in the issue, then trace where the exported printf signature is serialized and reapplied. Done means a signature declared as void printf(char* format, ...); is restored with its varargs intact and the reported calling-convention analysis behavior is preserved.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Version and Platform (required):
- Binary Ninja Version: 5.3.9003-dev
- Edition: Ultimate
- OS: macOS
- OS Version: 26.2
- CPU Architecture: aarch64
Bug Description:
When I used WARP to save signatures for printf, and then used those signatures to match printf in a new file, the varargs portion of the arguments to printf was not applied. Notably, it gave printf the signature void printf(char* format); missing the varargs. The varargs are a critical part of the type signature, as they indicate to analysis that the remaining arguments (at least in my architecture's case) are passed via the stack and not registers.
Steps To Reproduce:
- Open a stripped binary containing printf
- Navigate to printf
- Name and type printf as
void printf(char* format, ...); - Use
WARP > Include Functionto mark printf for export WARP > Create > From Current Viewand set included functions to SelectedWARP > Load Fileon the generated signatures you just saved- Re-open stripped binary
- Observe printf is detected but now has the signature
void printf(char* format);with no varargs
Expected Behavior:
I expected the function signature I specified to be saved as-is and for the varargs to be reapplied.
Additional Information:
Signatures were generated for a binary using a custom arch plugin which can be provided if requested
- 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 ·