Ingegneria inversa: a cosa serve davvero? [chiuso]

Ho alcune domande innocenti / per principianti:

• A cosa serve il reverse engineering?
• Come programmatore, dovrei imparare l'arte del reverse engineering?
• Quali sono i vantaggi per un programmatore che ha esperienza con esso?

A cosa serve il reverse engineering?

Il reverse engineering è utile soprattutto per cracking e hacking (rimuovere la protezione del numero di serie o le richieste di password), ma anche per comprendere virus o miracoli che altri software possono eseguire. A volte è un'abilità utile avere per trovare bug nei programmi per i quali non hai la fonte e correggerli.

Come programmatore, dovrei imparare l'arte del reverse engineering?

Sì, prova a imparare l'assemblatore e usare un debugger decente. Ti renderà uno sviluppatore migliore comprendendo le cose ai livelli più bassi, che sono più vicini al metallo.

Quali saranno i vantaggi di un programmatore che ha esperienza con il reverse engineering?

Sarai un buon hacker / cracker. Potresti lavorare per altri produttori di antivirus. Come esempio personale: una volta ho progettato un software inverso per rintracciare un errore che si è verificato durante la creazione di una connessione Oracle. Nessun altro poteva risolvere il problema, quindi ho avuto un po 'di fama.

Inoltre, vorrei anche citare il commento di @ johannes , poiché ha assolutamente ragione:

Non lo limiterò a "cattivo" cracking. Il disassemblaggio può essere utile per capire se il compilatore è impazzito (di solito è il tuo codice, però), da un punto di vista più sysadmin può essere interessante vedere dove un'applicazione fallisce

Mi piace la risposta di Falcon , ma vorrei aggiungere che su un vecchio noioso mondo delle applicazioni aziendali il reverse engineering può farti uscire da alcuni fastidiosi problemi.

Al lavoro lo facciamo molto quando facciamo l'integrazione dei dati con un sistema di terze parti che non ha alcuna nuova manutenzione, quindi possiamo sapere dove dovrebbe o non dovrebbe rompersi.

Utilizziamo anche il reverse engineer per verificare la qualità del codice (con alcuni vincoli, ovviamente) sui componenti di terze parti che acquistiamo, se il codice sorgente non è incluso.

Il mio vero punto è: il reverse engineering non è legato a una singola tecnologia o lingua, ma è un processo in cui apprendi gli interni di una "scatola nera" . Se hai un codice su cui contare, ma non ti fidi o non puoi fidarti, dovresti assolutamente dare un'occhiata sotto il cofano e vedere cosa sta facendo quel codice.

C'è anche il lato noioso dell'ingegneria inversa. Questo è quando la società in cui ti trovi ha un po 'di codice o programma che è ancora in uso, ma nessuno afferma di sapere qualcosa al riguardo. Quindi lo attraversi, lo documenti, scrivi i test e tutte le cose ingegneristiche che dovrebbero essere fatte prima dell'inizio di un progetto. Lo fai per un software già scritto, quindi "reverse engineering".

È molto più semplice quando si dispone del codice, ma è ancora tecnicamente reverse engineering. È uno di quei termini che emerge molto negli incontri di lavoro quando parlano di progetti legacy.

Solo per espandere il valore commerciale del reverse engineering: più della metà dei nuovi clienti che incontriamo hanno un sistema / app esistente (non sempre in produzione, intendiamoci), ma in cui la relazione con un precedente fornitore di sviluppo software ha colpito gli skid.

In circa il 30% dei casi il cliente non ha affatto la fonte del proprio sistema e, in molti casi, gran parte del processo aziendale reale, delle regole e delle conoscenze è bloccato nel codice.

E in un paio di casi in cui i precedenti fornitori sono diventati semplicemente maliziosi, offuscato i file binari, timelock del codice ecc. Al fine di irretire il cliente a tempo indeterminato.

Quindi, per rispondere alla tua domanda, il reverse engineering è spesso un punto di partenza per nuovi impegni con clienti piuttosto disperati (e bruciati) e può essere un fattore di successo "critico per l'azienda" per estrarre le conoscenze dimenticate dal codice esistente.

Direi che il set di abilità per il reverse engineering e il set di abilità per il debug sono esattamente gli stessi: se sei un fantastico debugger, sei anche un fantastico reverse engineering e viceversa.

A volte viene utilizzato per far interagire alcune parti / software per quanto ne so. Alcune strane interfacce, bug nell'implementazione, ecc.

Ma da quello che ho capito, è un argomento molto scivoloso, e quindi, le già complesse leggi dello sviluppo del software sono portate all'estremo con il reverse engineering.

Bene, con il reverse engineering puoi essere in grado di riutilizzare il codice minimizzando il tuo lavoro.Ad esempio, in Symfony2, puoi convertire un database creato dal normale MySQL e convertirlo nel formato dottrina e questo è un processo di ingegneria inversa reso possibile in Symfony .... e con il reverse engineering, sei in grado di vedere il codice diciamo "in 2D"

Sto solo dando un esempio del mondo reale dalla mia esperienza.

Una volta la nostra azienda ha rilevato un progetto di un'altra società. Circa un anno e mezzo nel progetto ci siamo resi conto che un sottoprogetto era senza codice. Quando abbiamo chiesto all'ex azienda di consegnare il codice, hanno cortesemente risposto che non potevano trovare il codice per il sottoprogetto. Avevamo bisogno del codice perché volevamo cambiare qualcosa in quel sottoprogetto.

Ho dovuto decodificare il sottoprogetto.

Per prima cosa ho decompilato l'assembly (sì, è un progetto .NET). Il risultato dell'assembly decompilato è un codice insignificante e confuso senza nomi di variabili locali e una struttura di controllo complicata. Questo perché la compilazione elimina informazioni importanti che non possono essere decompilate.

Quindi ho provato a capire dove cambiare quel codice. Per fare ciò ho semplificato il codice per comportarsi allo stesso modo ma in modo più conciso. Ho anche indovinato i nomi delle variabili dal suo comportamento. Ho esaminato il codice molte volte fino a quando non ho capito cosa stava facendo.

Non ho decodificato tutto, solo la parte che abbiamo dovuto cambiare. Non era poi così male, circa 200 righe di codice VB. Ci sono voluti circa cinque giorni di orario di lavoro.