Il caso dell'offuscamento del codice?

46

Quali sono le ragioni principali per scrivere codice offuscato, in termini di un beneficio reale per le persone che sviluppano il codice e per l'attività che esegue quel codice (se il codice in questione è in realtà codice commerciale)? Esistono casi documentati (disponibili online in qualche luogo) che descrivono quando l'offuscamento ha fatto più bene che male? Esistono esempi noti in cui, ad esempio, è stato dimostrato che l'oscuramento ha ritardato in modo significativo la ricezione da parte di terzi di un codice dannoso? Sembra che, proprio come far rotolare le finestre dell'auto, non si fermino le persone a romperle e rubare il tuo stereo, offuscando il tuo codice, mantiene onesti le persone oneste.

=========

Sfondo:

Questo è un tentativo di sfidare intenzionalmente le mie ipotesi su questo argomento.

Sono molto grato contro l'offuscamento del codice in generale, ma sono curioso di sapere se mi manca qualcosa. Capisco perché, in casi come JavaScript, il minification aiuta le cose a caricarsi più velocemente e tutto (c'è un vantaggio reale, funzionale lì), ma non riesco a trovare una sola ragione per cui il codice offusca, allo scopo di essere un ostacolo alla scoperta di ciò che una sezione di codice / algoritmo fa , è effettivamente efficace per qualsiasi scopo.

Visto che l'open source è pazzo popolare, la domanda sembra essere "condividere il codice o mantenerlo proprietario?" Quando si tratta di codice commerciale, posso capire perché non puoi condividere tutto, e hai la legge dalla tua parte per combattere il furto.

BTW, se la ragione per cui qualcuno sta scrivendo codice offuscato è "sicurezza del posto di lavoro", allora licenzierei qualsiasi programmatore trovato coerente e userei volutamente l'offuscamento con l'unico scopo di aiutare a mantenere il proprio lavoro, a meno che non possano ragionevolmente dimostrare di avere alcuni vantaggi economici. È così completamente anti-team che è ridicolo e punta a qualcuno che è più interessato a mantenere il proprio lavoro attraverso pratiche sbagliate, quindi a tenerlo perché scrivono un software fantastico.

Ho solo menzionato questo caso specifico perché, mentre mi rendo conto che le persone di solito scherzano, mi piacerebbe scoraggiare qualsiasi risposta la cui spinta fondamentale è che l'offuscamento per la sicurezza del lavoro da solo sia una buona idea.

    
posta jefflunt 10.01.2012 - 04:35
fonte

4 risposte

48

Un caso d'uso molto interessante per l'offuscamento è tracciare l'origine delle copie illecite. Supponendo che l'offuscamento sia un'operazione relativamente economica, l'autore originale può fornire a ciascun cliente versioni della domanda in modo completamente offuscato, se viene trovata una copia illecita l'autore può confrontarsi con le versioni fornite e risalire all'origine della pirateria.

Questa è una forma di steganografia , ispirata e in variazione del "tracciamento degli schemi di crittografia" . Non ho idea se sia comune 1 , o anche se è una buona idea, ma l'ho visto applicato in pratica con i seguenti parametri:

  • Mercato nazionale altamente competitivo con due soli fornitori,
  • Circa 50 distribuzioni coprivano il mercato,
  • Il tempo di sviluppo medio per entrambe le applicazioni era di un paio d'anni (più o meno),
  • Il tempo medio di offuscamento per la nostra applicazione era di un paio d'ore,
  • La durata di vita di entrambe le applicazioni era prevista in circa dieci anni.

La logica era ovviamente sicurezza attraverso l'oscurità inizialmente, e si è evoluta allo schema sopra menzionato ad un certo punto 2 . Entrambi i venditori hanno avuto accesso al codice binario degli altri, legalmente, e penso che sia ovvio che ci si aspettava che i tentativi di decompilazione da entrambi fossero previsti. L'offuscamento non ha fatto nulla in termini di sicurezza, a lungo termine. Entrambi i venditori disponevano di team altamente motivati e di talento, lavorando in un mercato estremamente redditizio e di nicchia, alla fine i nostri prodotti erano più simili e qualsiasi vantaggio competitivo era ottenuto attraverso altri mezzi meno oscuri.

Non posso davvero espandermi, perché (a) è stato molto presto nella mia carriera e non ho avuto una chiara panoramica delle decisioni di progettazione o dei risultati dello schema di tracciamento (se presente) e (b) alcuni del mio coinvolgimento con il progetto era sotto la NDA.

Un altro caso d'uso valido per l'offuscamento potrebbe essere quando sei in qualche modo legalmente obbligato a inviare il tuo codice a una terza parte :

If your firm does IP work for technology companies, or is involved in cases involving software source code, you may be obliged to submit your client’s source code to the USPTO, a court or third party.

Since source code is considered a trade secret, most regulatory agencies use a "50%" rule. Source code submitted is obscured so that it cannot be used as-is.

IANAL, e il collegamento è più pertinente alle copie cartacee di codice piuttosto che al codice di lavoro effettivo, quindi questo potrebbe essere completamente irrilevante.

Ora, come Javascript è l'esempio canonico per l'offuscamento, c'è un effetto collaterale che non è comunemente considerato, e che sta nascondendo il codice dannoso in Javascript offuscato. Anche se ci sono determinati vantaggi nel minificare 3 Javascript, non vedo alcun punto di effettiva offuscazione e sono felice Douglas Crockford è d'accordo con me :

Then finally, there is that question of code privacy. This is a lost cause. There is no transformation that will keep a determined hacker from understanding your program. This turns out to be true for all programs in all languages, it is just more obviously true with JavaScript because it is delivered in source form. The privacy benefit provided by obfuscation is an illusion. If you don’t want people to see your programs, unplug your server.

Per quanto riguarda l'offuscamento per la "sicurezza del lavoro", questo è un comportamento che non dovrebbe mai superare la revisione del codice e, se identificato, non dovrebbe essere tollerato. All'inizio non mi spingerei a colpire il colpevole, ma almeno i trasgressori meritano sicuramente una buona sculacciata.

In conclusione, l'offuscamento è un tipico esempio di sicurezza attraverso l'oscurità, è solo ovvio che il merito è un deterrente e nient'altro. Potrebbero esserci casi d'uso creativi 4 che non conosco, ma in generale i benefici sono minimi, nella migliore delle ipotesi.

1 Dopo aver scritto questo ho scoperto questa risposta che fondamentalmente descrive lo stesso schema, quindi potrebbe essere più comune di quanto pensassi.
2 Sebbene la steganografia sia ancora sicurezza attraverso l'oscurità.
3 Minification ~ rimuove gli spazi bianchi e accorcia i token, non intenzionalmente oscurando.
4 Il Concorso Internazionale del codice C offuscato conta?

    
risposta data 10.01.2012 - 05:45
fonte
40

Il caso dell'offuscamento del codice è che alza la barra di una terza parte per determinare cosa / come funziona il codice.

Tuttavia, ciò NON significa che uno sviluppatore dovrebbe mai scrivere codice offuscato.

Vedi, questo è il bit che ritengo manchi dalla tua domanda: l'offuscamento del codice (proprio come JavaScript minification) non ha bisogno - e non dovrebbe - essere fatto manualmente dallo sviluppatore. Allo stesso modo, questo non dovrebbe essere memorizzato come i tuoi file sorgenti di base nel controllo della versione.

L'offuscamento del codice dovrebbe avvenire come una fase di post-elaborazione durante la compilazione nella build di produzione. Ci sono un sacco di prodotti di terze parti per fare questo, quindi non c'è quasi nessun motivo per farlo in casa.

Ad esempio: Dotfuscator

L'IEEE ha un documento sulla efficacia dell'offuscamento del codice

Results show that identifier renaming significantly decreases the efficiency of attacks, at least doubling the time needed to complete a successful attack (even in the worstcase scenario, i.e., against the best attacker). In addition, obfuscation reduces the gap between novice and skilled attackers, making the latter less efficient, and makes systems that are easier to attack in clear more similar to those that are intrinsically harder to break.

Enfasi sulla mia.

    
risposta data 10.01.2012 - 05:23
fonte
35

Ho partecipato allo sviluppo di un MMORPG. Ciò ha coinvolto la logica del server e la logica del client. Durante tutto lo sviluppo pluriennale del progetto, ogni volta che abbiamo preso in considerazione l'interfaccia tra il client e il server, la regola era che il client doveva essere sempre trattato dal server sotto la presunzione che fosse stato violato. In altre parole, il server doveva essere scritto in modo tale che non ci fosse una risposta che potesse venire dal client che avrebbe potuto causare il fallimento del server, o consentire al client di imbrogliare. Tuttavia, era noto sin dall'inizio che gli hacker avrebbero inevitabilmente trovato buchi nel sistema e li avrebbero sfruttati per imbrogliare. E dopo un po 'hanno fatto.

Ovviamente, prima di spedire il cliente al grande mondo là fuori, abbiamo fatto in modo di offuscarlo. Riteniamo che l'offuscamento abbia i seguenti effetti:

  1. Ha scoraggiato gli hacker non esperti persino nel provare.
  2. Ritardava gli hacker esperti nel raggiungere qualsiasi hack.
  3. Ha ridotto il numero di hack realizzati da esperti hacker.
  4. Limita l'efficacia degli hack.
  5. Ancora più importante: ha causato agli hacker di eseguire più esecuzioni di test con i loro client hackerati contro i nostri server prima di ottenere un hack funzionante, aumentando le possibilità di scoprirli cercando attività irregolari nei log del server.

Gli account di gioco degli hacker scoperti sono stati chiusi senza rimborso, quindi questo ha reso il business degli hacker più costoso e meno attraente.

Quindi, a causa di tutto quanto sopra, credo che l'offuscamento abbia avuto un effetto complessivamente positivo nel nostro gioco e, per estensione, l'offuscamento può avere un effetto complessivamente positivo in qualsiasi pezzo di software che potrebbe essere hackerato. (Ad esempio, software contenente misure di protezione contro la copia.)

Gli effetti dell'offuscamento sulla manutenzione non erano vicini a nessuno. C'erano alcuni posti in cui alcuni programmatori inesperti stavano facendo delle ipotesi sui nomi degli identificatori, (stavano usando la riflessione), ma una volta sistemati, tutto andava bene. La fase di offuscamento è appena entrata a far parte della fase di costruzione generale della versione di produzione del gioco, quindi la maggior parte di noi sviluppatori non ha mai dovuto preoccuparsi o avere nulla a che fare con esso. Avevamo già uno strumento per visualizzare i log del gioco, quindi abbiamo modificato lo strumento per utilizzare la tabella di associazione (mappatura degli identificatori indentati agli identificatori appropriati) prodotta dall'offfuscator per tradurre i log per noi al volo, quindi non abbiamo mai ha persino dovuto vedere eventuali identificatori offuscati durante gli esami post-mortem basati sui log raccolti dal campo.

    
risposta data 10.01.2012 - 09:53
fonte
3

Leggere e comprendere (e ovviamente scrivere) codice offuscato può essere una sfida mentale interessante. Probabilmente non rientra nello scopo di ciò che stavi chiedendo, ma esempi come IOCCC possono essere una fonte di divertimento e di orrore.

    
risposta data 10.01.2012 - 17:11
fonte

Leggi altre domande sui tag