Decompilatori - Mito o Fatto?

Is there such thing as "Perfect Decompiler"?

La fonte originale è - in alcune lingue - irrecuperabile. Una versione del sorgente può essere costruita, ma mancherà di nomi significativi per le variabili. Mancheranno anche commenti e potrebbero avere espansioni di codice inline che sono ripetutamente confuse.

Si noti che l'ottimizzazione dei compilatori può rendere la fonte recuperata piuttosto oscura.

In altre lingue, vi sono sufficienti informazioni di debug che è possibile recuperare una versione ragionevolmente leggibile della fonte.

[perfect] mean the original source files with all the variable names/macros/functions/classes/if possible comments in the respective headers and source files used to get the binary)

Mai. Le macro del preprocessore non fanno parte dell'origine e vengono sempre perse per sempre.

"se possibili commenti" non ha molto senso. Immagino tu voglia dire che vuoi i commenti. In genere sono spariti per sempre.

Puoi, tuttavia, recuperare il binario da cose che mancano macro e commenti. Quindi la tua definizione di "perfetto" è incoerente.

binaries safe from reverse engineering?

No.

What are some of the best practices used to prevent reverse engineering of software?

Offri nuove versioni così velocemente che non c'è alcun valore nel reverse engineering della versione precedente.

Is it a major concern?

Solo per gli avvocati.

Also is obfuscation/file permissions the only way to prevent unauthorized hacks on scripts?

Che cos'è un "hack non autorizzato"? In effetti, cosa intendi per "hack" su una sceneggiatura?

Se vuoi scherzare con una sceneggiatura, devi solo scherzare con essa. A meno che, naturalmente, non sia su un server web e tu non lo sia. Quindi non hai accesso allo script, solo la pagina web presentata dallo script.

I decompilatori sono sicuramente un fatto - Reflector è un esempio eccellente.

Nulla di ciò che so può effettivamente impedire a una persona di decompilare il codice se è abbastanza intelligente e sufficientemente determinato. Ecco a cosa servono gli avvocati e i brevetti software.

L'offuscamento è comunque un modo decente per fermare la maggior parte delle persone. Ad esempio, personalmente non ho alcun interesse nell'hacking, tuttavia se sto cercando di aggiustare qualcosa e può essere facilmente decompilato usando Reflector, lo farò.

La "Regola generale è" se lo hanno fisicamente .. È buono quanto hackerato.

Anche se è crittografato, se la chiave è memorizzata da qualche parte nell'app .. che i dati possono essere ottenuti.

L'UNICO modo per proteggere qualsiasi cosa è mantenerlo sui tuoi server e avere un gatekeeper (IE un servizio web sicuro.).

Il binario più difficile da decompilare è il file binario che non hai. Con un numero sempre maggiore di software che passa a un modello di abbonamento online, il reverse engineering del client ha un certo valore ma non darà via tutto. Certo, potresti tentare di colpire il servizio server più e più volte con molti input per cercare di determinare il codice dall'output ricevuto, ma questo sarà così incline agli errori da risultare quasi inutile in tutti i casi, tranne i più semplici.

Anche decompilare è una strada a doppio senso. Se qualcuno decompila il tuo software e prova a vendere o regalare una versione modificata, puoi decompilare il codice e confrontarlo. Un'enorme quantità di sovrapposizioni tradirà le loro azioni. Se hai un algoritmo piuttosto intelligente che non vuoi che qualcuno veda o qualcosa nel programma considerato un segreto commerciale, fare in modo che una chiamata di servizio a un server remoto sia la migliore protezione (anche se ovviamente non è fattibile in tutti i casi).

Non sono mai stato molto bravo in questo, ma quando l'ho provato, anche io sono stato capace di fare cose incredibili (con qualcuno che non ha mai provato, cioè) cose complicate con un semplice monitor / debugger / disassemblatore qualche anno fa.

Quindi non trovo difficile immaginare come ogni singolo schema di protezione concepito finora sia stato violato. (Di solito in meno tempo di quello necessario per lo sviluppo.)

Il potere della testardaggine umana e della perseveranza è spesso sottovalutato.

Se vuoi veramente comprendere la possibilità di decompilazione di un binario C / C ++ / Delphi, consulta il white paper tecnico di Symantec su Stuxnet.

Praticamente qualsiasi linguaggio che non si compila direttamente nel codice nativo sembra essere relativamente facile da decompilare.

Se questo è un problema, prova a capire come mettere la salsa speciale su un server web. Uno degli altri meccanismi utilizzati è un dongle fisico che contiene chiavi di crittografia o porzioni di codice. YMMV, a seconda dell'applicazione.

What are some of the best practices used to prevent reverse engineering of software? Is it a major concern?

Se tutto quello che offri è codice allora è una preoccupazione importante, perché non puoi fare molto al di fuori delle cause legali. Quindi non limitarti a offrire il codice. Offri supporto, formazione e altri servizi che completano il codice. Assicurati che il tuo codice sia tale da adattarti al mercato in continua evoluzione. Il codice può e dovrebbe essere il "nucleo" di un'azienda del software, ma non credo che possa esistere da solo.

Dipende molto dalla lingua, puoi impacchettare i tuoi binari per fornire un ulteriore livello di sicurezza, ma nella maggior parte dei casi la decompilazione non fornisce nulla di utile, molti decompilatori possono estrarre i riferimenti alle stringhe che se hai informazioni sensibili nel codice come le stringhe può essere cattivo.

Altri decompilatori possono estrarre informazioni come le definizioni dei moduli ecc.

Non preoccuparti nemmeno di sprecare pensieri o sforzi su questo. La protezione da decompilatore è fondamentalmente equivalente alla protezione da copia e sta cercando di risolvere un problema che è noto essere impossibile.

Affinché la CPU possa eseguirlo, il tuo programma deve essere in formato leggibile dalla macchina e non c'è modo di aggirarlo. Anche se lo si cripta in sette modi da domenica, deve essere decrittografato nuovamente prima di poter essere eseguito, ea quel punto un debugger può esaminare la memoria e leggere il codice. L'unico modo per impedire a qualcuno di decompilare il tuo programma è di tenerlo completamente fuori dal loro sistema, ad esempio usando un servizio web, come hanno menzionato alcune altre persone.

Non penso che il reverse engineering sia un problema se intendi usare un decompilatore e creare magicamente il tuo codice sorgente per apparire con poco sforzo. Qualsiasi applicazione abbastanza semplice da ottenere perfettamente da un compilatore probabilmente potrebbe essere stata scritta da qualcun altro in ogni caso (e probabilmente lo è stato.).

Ci sono molte applicazioni aziendali che vanno per $ 100K + che non ti permettono di scaricare il loro programma dal loro sito web. Hanno un mercato di nicchia e pochi, se nessuno dei loro potenziali clienti commerciali, tenteranno di rubare il codice sorgente se avranno installato una demo.

Devi davvero fare qualcosa che valga la pena acquistare e convincere le persone che sarai a supporto e migliorare.

Un decompilatore non è un anti compilatore, offrirà al meglio il codice C o C ++ (è un esempio, visto che stiamo parlando di lingue compilate).

Prova a vedere come appare il codice assembly per vedere cosa il compilatore traduce in C / C ++.

L'offuscamento non è legato alla decompilazione, puoi solo offuscare un codice interpretato come javascript, quando qualcuno sarà in grado di leggere il codice che hai effettivamente scritto, non il codice che hai compilato.

Tuttavia, immagino ci siano alcuni modi per rendere più difficile la decompilazione del codice, magari ad esempio gli indirizzi di offset interni della cripta? Sarebbe un argomento interessante, se ovviamente il tempo di esecuzione non è importante.

D'altra parte, immagino che la pura C possa essere più facile da decompilare di C ++. Immagina modelli di decompilazione: se è già un incubo codificare, non riesco a immaginare come possa essere decompilato.

Decompilare il codice C # è ridicolmente facile.

Non penso che nessuno dei nostri concorrenti possa decompilare il nostro codice per usarlo da solo, ma questo è il motivo per cui usiamo l'oscuramento. Dovrebbe essere sufficiente a fermare il 99% di tutti gli hacker e mantiene la nostra gestione felice.

Il livello di sicurezza necessario dipende molto dalla tua applicazione. Sarà usato da milioni di utenti high-tech? Per la maggior parte delle persone sarà sufficiente la semplice offuscazione.

Se stai usando Java o C #, il tuo codice è estremamente incline alla decompilazione. Questo è per la stessa ragione per cui ci sono così tanti virus per Windows. Quindi, gli offuscatori funzionano in una certa misura, ma soprattutto, si risparmiano contro i decompilatori gratuiti. Coloro che vogliono decodificare il software, lo faranno comunque.

I registri di commit rivelano anche i dettagli. Quindi, non sprecare il tuo tempo a pensare a questo. Se fosse possibile, la SM avrebbe acquistato prima quella tecnologia. :)