Reverse engineering: a cosa serve davvero? [chiuso]

What is reverse engineering is good for?

Reverse Engineering è principalmente utile per cracking e hacking (rimuovere la protezione del numero di serie o prompt 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 per correggerli.

As a programmer, should I learn the art of reverse engineering?

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

What will be the benefits of a programmer who is well-experienced with reverse engineering?

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

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

I won't limit it to "bad" cracking. Disassembling can be useful to figure out whether the compiler went mad (usually it's your code, though), from a more sysadmin point of view it can be interesting to see where an application fails

Mi piace la risposta di Falcon , ma vorrei aggiungere che su qualche vecchio mondo di applicazioni aziendali noiosi al contrario l'ingegneria può farti uscire da alcuni brutti 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 rompere.

Usiamo anche il reverse engineer per verificare la qualità del codice (con determinati vincoli, ovviamente) su 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 si impara l'interno di una "scatola nera" . Se si dispone di un codice da cui si dipende, ma non ci si può o non si può fidarsi, è necessario dare una sbirciatina e vedere cosa sta facendo quel codice.

C'è anche il lato noioso del reverse engineering. Questo è quando la società in cui ti trovi ha un po 'di codice o programma che è ancora in uso, ma nessuno pretende di sapere nulla a riguardo. Così lo attraversi, lo documenta, scrivi test e tutto quel materiale tecnico che dovrebbe essere fatto prima che un progetto venga avviato. Lo fai per un software che è già stato scritto, quindi "reverse engineering".

È molto più semplice avere il codice, ma è ancora tecnicamente un reverse engineering. È uno di quei termini che appaiono molto nelle riunioni di lavoro quando parlano di progetti legacy.

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

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

E in un paio di casi in cui i precedenti vendor sono diventati malvagi, hanno oscurato i binari, hanno timbrato il codice ecc. per irretire il cliente indefinitamente.

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 "business critical" per estrarre conoscenza dimenticata 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 debugger fantastico, sei anche un fantastico tecnico del reverse e viceversa.

A volte è usato per far interagire alcune parti / software per quanto ho capito. Alcune strane interfacce, bug nell'implementazione, ecc.

Ma da quello che capisco, è un argomento molto sfuggente, e così, 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 riducendo al minimo il tuo lavoro.Ad esempio, in Symfony2, puoi convertire un database creato dal normale MySQL e convertirlo nel formato doctrine e questo è un processo di reverse engineering possibile in Symfony .... e con il reverse engineering, sei in grado di vedere il codice diciamo 'in 2D'

Sto dando un esempio di mondo reale dalla mia esperienza.

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

Ho dovuto reverse engineer il sottoprogetto.

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

Poi ho cercato di capire dove cambiare quel codice. Per fare questo ho semplificato il codice per comportarmi allo stesso modo, ma in modo più conciso. Ho anche indovinato i nomi delle variabili dal suo comportamento. Ho passato il codice molte volte fino a quando ho capito cosa sta facendo.

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