[Bug] Preserve external-call signatures in generated recovery code

Aperta
  • Qualcosa non va?
#3 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c, cpp
Ambito
reverse-engineering

Direzione di ricerca

Start with the call-emission code at src/decompiler/decompiler.cpp:558-590, which always assigns the result to rax, and the known-API table and header emission in src/decompiler/project.cpp:79-86 and 262-265. Compile the reproducer with gcc -std=c11 -Wall -Wextra -Werror to see the current errors. Done means the reproducer compiles cleanly, void calls like free are emitted as statements, and the needed libc headers are included.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

Summary

The native recovery renderer does not preserve external-call signatures: every recovered call is assigned to rax, while the generated file only includes a small set of C headers. This makes common libc calls fail to compile and can change call semantics.

Evidence

src/decompiler/decompiler.cpp:558-590 always emits:

body << "    rax = " << call << ";\n";

src/decompiler/project.cpp:79-86 treats APIs such as malloc, free, memcpy, and strlen as known declarations, but src/decompiler/project.cpp:262-265 only includes <stdint.h>, <stddef.h>, and <stdio.h> (plus a manual scanf declaration).

Reproducer:

#include <stdlib.h>
int main(void) {
    void *p = malloc(8);
    free(p);
    return 0;
}

The recovered source contains rax = malloc(8); and rax = free(...);. Compiling it with gcc -std=c11 -Wall -Wextra -Werror reports missing declarations for malloc/free, pointer conversion errors, and:

error: void value not ignored as it ought to be

Impact

The advertised GCC round-trip is limited to a narrow subset of stdio calls. Programs using allocation, cleanup, string, memory, termination, or other common libc APIs produce non-compilable output even when the imported symbol is recognized.

Expected behavior

External calls need a signature model that records at least return type, parameter categories, variadic status, and required headers. Void calls such as free, abort, and exit should be emitted as statements; value-returning calls should be assigned only when their result is used. Required standard headers or compatible declarations must be emitted.

Acceptance criteria

  • The reproducer compiles under -Wall -Wextra -Werror.
  • Void-returning calls are not assigned to rax.
  • Known libc imports have matching declarations/includes, including <stdlib.h> and <string.h> where needed.
  • Unknown imports still use a collision-safe fallback without suppressing valid standard-library declarations.
Lingua principale
C++
Stelle
0
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di TiElixir/caraxes

Tutte le issue di TiElixir/caraxes

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.