Pensando a questo, ci sono diversi tipi di offuscamento. Iniziamo con l'offuscamento del codice sorgente, che è una completa perdita di tempo; è abbastanza difficile capire senza quello! Quindi concentriamoci invece sulla confusione del pacchetto di consegna, su come il codice viene consegnato all'utente.
Offuscamento minore
Esiste una piccola offuscazione per impedire all'utente casuale di infilare le dita dentro e di rompere le cose facilmente. Non tiene fuori l'hacker determinato, ma ha un valore nel contribuire a garantire che le cose che ti viene chiesto di supportare siano ciò che hai effettivamente consegnato. Il livello di protezione richiesto per questo genere di cose è davvero piuttosto basso; il pacchetto di consegna deve semplicemente non guardare leggibile e modificabile (senza strumenti specializzati) e questo è abbastanza buono.
La minifrazione di Javascript è un esempio di ciò, sebbene non sia commercializzato come tale. Nessuno sano di mente vorrebbe leggere e modificare un file JS minificato, anche se è tecnicamente possibile farlo se sei determinato / abbastanza persistente.
Allo stesso modo con la consegna di applicazioni Java. Il semplice confezionamento del codice in un JAR eseguibile interromperà la maggior parte delle sciocchezze, anche se ha tutta la forza di un segno di cortesia "Please Keep Off The Grass" in un parco cittadino.
Anche quando si consegna il codice C ++, rimuovere i simboli non necessari dall'eseguibile sarà sufficiente per qualificarsi come parziale offuscamento. La chiave è che è awkward leggere il risultato come utente, ma non è un problema eseguirlo come un computer.
Offuscamento principale
L'offuscamento principale sta mantenendo l'utente determinato e esperto . È anche un gioco in perdita totale; se un computer può eseguirlo, una persona può distinguerlo e capire cosa fa. La cosa più vicina che si potrebbe ottenere sarebbe quella di fare in modo che il programma si decodificasse continuamente, trasformando ciò che fa in una volta in una cosa completamente diversa che fa in un altro momento. Creare una cosa del genere sarebbe piuttosto difficile e ancora non riuscirebbe a tenere fuori un buon hacker (anche se alla fine sarebbe davvero abbastanza scontento di te con la quantità di sforzo necessaria per decrittografare tutto quel codice auto-modificante). / p>
È molto meglio pensare in termini di altre soluzioni. Ad esempio, è possibile mantenere i "gioielli della corona" del codice sui server che si controllano e consentire solo chiamate di servizio su di esso, rendendo il client un omaggio essenzialmente gratuito che rappresenta un front-end per i bit di valore. Oppure puoi seguire il percorso più contratto / legale e consegnare solo gli eseguibili alle organizzazioni che accettano formalmente di non aggirare il tuo codice o di indennizzarti se lo fanno (quindi sarebbe una sorta di NDA). L'obiettivo sarebbe quello di creare un strong incentivo per l'hacker a non violare e agli utenti di mantenere il codice lontano da qualsiasi hacker non vincolato dall'accordo.
Ma non devi presumere che il tuo codice non possa mai essere incrinato. Con la virtualizzazione, qualsiasi stato del programma di un'esecuzione può essere esaminato e tracciato e qualsiasi cosa tenti di sconfiggerlo (ad esempio, il tracciamento dell'orologio su un'origine temporale esterna) sarà molto più probabile che causi problemi agli utenti legittimi rispetto agli hacker. (Vedi la storia del DRM per come persino gli molto editori determinati di informazioni non possono mantenere i loro sistemi sicuri una volta che il codice è nelle mani dei loro avversari.) È molto meglio focalizzarsi su rendere felici gli utenti legittimi. Le perdite causate dal crack occasionale saranno nulle rispetto ai soldi extra introdotti correttamente dai clienti soddisfacenti.