WARP doesn't save varargs status of functions
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- cpp
- Ambito
- reverse-engineering
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Lingua principale
- C++
- Stelle
- 1.3k
- Fork
- 298
- Merge medio
- 5g 5h
- PR unite (30g)
- 19
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Vector35/binaryninja-api
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
Vector35/binaryninja-api#8540 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
Vector35/binaryninja-api#8516 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
Vector35/binaryninja-api#8503 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
Vector35/binaryninja-api#8446 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
Vector35/binaryninja-api#8444 ·
Tutte le issue di Vector35/binaryninja-api
Issue simili
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 92/100
autowarefoundation/autoware_universe#13413 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
automated-analysis bug memory-safety
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
gazebosim/gz-sensors#662 · 1 commento ·