riconvertire l'eseguibile in codice sorgente C.


14

Sfortunatamente ho perso il mio codice sorgente e ho solo il file di output creato con gcc in Linux e non ho alcun accesso al mio PC adesso. Esiste un modo per convertire il file di output in file sorgente (in c sotto Linux)?


Quello che vuoi è chiamato un decompilatore. Potresti trovare aiuto con questa risposta: stackoverflow.com/questions/193896/whats-a-good-c-decompiler
Eric Renouf

IDA Pro con il modulo decompilatore è l'unica soluzione pratica che funziona effettivamente con grandi eseguibili.
fpmurphy,

@ fpmurphy1 Hai Hopper, che è paragonabile in termini di qualità a IDA Pro e quale licenza è una frazione del prezzo.
Rui F Ribeiro,

@ fpmurphy1 Non sono ancora riuscito a vedere la qualità del codice generato da Avast ... chi utilizza più le piattaforme Intel a 32 bit? Inoltre non uso Wintel da decenni ormai. vedi unix.stackexchange.com/questions/418354/… Tuttavia, la differenza di prezzo è piuttosto significativa, Hex-rays / IDA pro parte da 1500 USD per una licenza personale ad alcuni valori esorbitanti per licenze commerciali come 5000 USD o fino AFAIK, Hopper è 100 USD per un singolo utente e 130 per un singolo computer.
Rui F Ribeiro,

@RuiFRibeiro. Un sacco di malware che esaminerò è ancora a 32 bit.
fpmurphy

Risposte:


25

Quindi avevi una mucca, ma l'hai inavvertitamente convertita in hamburger, e ora vuoi riprenderla.

Mi dispiace, non funziona così.

Ripristina semplicemente il file di origine dai tuoi backup.

Ah, non avevi i backup. Sfortunatamente, l'universo non ti dà una pausa per quello.

Puoi decompilare il file binario. Che non vi darà il codice sorgente, ma ti do un po 'di codice sorgente con lo stesso comportamento. Non otterrai i nomi delle variabili a meno che non fosse un binario di debug. Non otterrai la stessa identica logica se non hai compilato senza ottimizzazioni. Ovviamente, non riceverai commenti.

Ho usato Boomerang per decompilare alcuni programmi e il risultato è stato più leggibile del codice macchina. Non so se sia lo strumento migliore là fuori. Comunque, non aspettarti miracoli.


1
Boomerang sembra piuttosto pulito; peccato che la documentazione faccia riferimento a gcc -O4 poiché non fa assolutamente nulla (oltre a -O3) se la memoria mi serve bene. La tua ultima frase ovviamente è estremamente valida così come le tue prime cinque frasi. Questo non vuol dire che il resto non sia valido tanto quanto stai sottolineando l'importanza del backup regolarmente. +1
Pryftan,

6

Diversi strumenti sono comuni nel reverse engineering di un eseguibile.

  1. Il comando "file" che prende il percorso del file come primo parametro in modo da poter determinare (nella maggior parte dei casi) il tipo di eseguibile che si possiede.
  2. Disassemblatori che mostrano ESATTAMENTE cosa fa l'eseguibile, ma è difficile da leggere per coloro che non scrivono codice assembly su quella specifica architettura o hanno esperienza con il disassemblaggio.
  3. I decompilatori come Boomerang, Hex-rays e Snowman possono fornire una maggiore leggibilità, ma non recuperano i nomi delle variabili o la sintassi del programma originale e non sono affidabili al 100%, specialmente nei casi in cui gli ingegneri che hanno creato l'eseguibile testato con questi pacchetti e ha cercato di offuscare ulteriormente la sicurezza.
  4. Diagrammi o tabelle del flusso di dati. Non conosco nessuno strumento gratuito per farlo automaticamente, ma uno script Python o Bash sopra un parser di testo dell'output dell'assembly (che può essere scritto in sed o Perl) può essere utile.
  5. Matita e carta, che ci crediate o no, per annotare flussi e idee.

Nella maggior parte dei casi che ho visto, il codice doveva essere riscritto da zero, mantenuto come programma di linguaggio assembly o ricostituito applicando nuovamente le richieste di modifica a una versione precedente.


1
# 1: vero anche se ha anche i suoi difetti. # 3: Immagino che quelli siano commerciali? Sono solo curioso dal punto di vista accademico (ho backup ridondanti, quindi non è necessario per quel tipo di cose). # 4: cflow (sebbene utilizzi il sorgente ce ne sono alcuni che funzionano sul binario - con alcuni avvertimenti ovviamente). Ce ne sono altri là fuori, a seconda di cosa stai cercando. Per quanto riguarda l'output grafico, non posso aiutarti in quanto non mi piace o non ho bisogno di output grafico per quel tipo di cose (lo troverei più distratto in realtà). # 5: molto vero. Puoi anche usare un file di testo qui, ovviamente.
Pryftan,

3

Quello che vuoi fare si chiama "decompilazione". Ci sono molti decompilatori là fuori e non è pratico coprirli tutti qui.

Tuttavia, come osservazione generale: la conversione dal codice sorgente C al codice macchina eseguibile è in perdita. Per esempio:

  • I commenti sono irreversibilmente persi
  • I nomi delle variabili sono spariti
  • A volte i loop vengono srotolati per le prestazioni
  • Le funzioni possono essere riorganizzate

È raro che il codice sia compilato come scritto. La maggior parte dei compilatori in questi giorni cambierà drasticamente il codice per ottimizzarlo. Quindi quando si decompila, il compilatore può solo indovinare come deve essere stato il codice sorgente, non ha modo di sapere quale fosse il tuo codice, perché non c'è più. Se il decompilatore è valido, il codice che otterrai sarà almeno compilabile in un eseguibile equivalente, quindi puoi iniziare lentamente a riformattarlo in modo che sia leggibile. Ma molto probabilmente il decompilatore produrrà un codice spaghetti assolutamente illeggibile e sarà un grosso mal di testa decifrarlo. A volte, potrebbe essere meno lavoro per riscrivere il programma da zero.


Riguardo ai commenti qualcosa che ho notato di recente è - e non ho idea se ciò consentirebbe ai commenti di essere decompilati da un decompilatore né mi aspetto che i decompilatori cerchino nemmeno questo tipo di cose - questo: -C Non scartare i commenti. Tutti i commenti vengono passati al file di output, ad eccezione dei commenti nelle direttive elaborate, che vengono eliminati insieme alla direttiva. Evidenzia gli effetti collaterali e quello dell'opzione -CC (questo è per gcc anche se probabilmente è invece il cpp). Non che mi aspetto che si applichi all'OP, ma che potrebbe interessare ad alcuni.
Pryftan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.