Il caso dell'offuscamento del codice?

Quali sono i motivi principali per scrivere codice offuscato, in termini di un reale vantaggio per le persone che sviluppano il codice e per l'azienda che lo gestisce (se il codice in questione è in realtà codice commerciale)? Ci sono casi documentati (disponibili online in alcune località) che descrivono quando l'offuscamento ha fatto più bene che male? Esistono esempi ben noti in cui, ad esempio, è stato dimostrato che l'offuscamento ritarda significativamente una terza parte malintenzionata dall'ottenere il codice? Sembra che, proprio come arrotolare i finestrini della tua auto non impedirà alle persone di romperli e rubare il tuo stereo, offuscare il tuo codice mantiene oneste le persone oneste.

=========

Sfondo:

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

Sono molto contento di non usare l'offuscamento del codice in generale, ma sono curioso di sapere se mi manca qualcosa. Capisco perché, in casi come JavaScript, la minificazione aiuta le cose a caricarsi più velocemente e tutte (c'è un reale vantaggio funzionale lì), ma non riesco a trovare un solo motivo per cui l'offuscamento del codice, allo scopo di essere un ostacolo scoprire cosa fa una sezione di codice / algoritmo , è effettivamente efficace per qualsiasi scopo.

Con l'open source molto 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.

A proposito, se il motivo per cui qualcuno sta scrivendo un codice offuscato è "sicurezza del lavoro", licenzierei qualsiasi programmatore ritenuto coerente e intenzionalmente usando l'offuscamento con l'unico scopo di aiutare a mantenere il proprio lavoro, a meno che non possano ragionevolmente dimostrare che aveva beneficio aziendale. È così completamente anti-team che è ridicolo e indica qualcuno che è più interessato a mantenere il proprio lavoro attraverso pratiche sbagliate, quindi a mantenerlo perché scrivono software fantastico.

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

Un caso d'uso molto interessante per l'offuscamento è rintracciare l'origine delle copie illecite. Supponendo che l'offuscamento sia un'operazione relativamente economica, l'autore originale può fornire a ciascun client versioni dell'applicazione offuscate in modo diverso, se viene trovata una copia illecita l'autore può confrontarsi con le versioni fornite e rintracciare la fonte della pirateria.

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

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

Naturalmente la logica era inizialmente la sicurezza attraverso l'oscurità , e ad un certo punto ² si è evoluta nel suddetto schema . Entrambi i fornitori avevano accesso al codice binario reciproco, legalmente, e penso che sia ovvio che ci si aspettassero tentativi di decompilazione da entrambi. L'offuscamento non ha fatto nulla in termini di sicurezza, a lungo termine. Entrambi i distributori avevano team altamente motivati ​​e di talento, che lavoravano in un mercato estremamente redditizio e di nicchia, alla fine i nostri prodotti erano più simili che no e ogni vantaggio competitivo veniva 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) parte del mio coinvolgimento con il progetto era sotto un accordo di non divulgazione.

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

Se la tua azienda opera in ambito IP per aziende tecnologiche o è coinvolta in casi riguardanti il ​​codice sorgente del software, potresti essere obbligato a inviare il codice sorgente del tuo cliente a USPTO, a un tribunale oa terzi.

Poiché il codice sorgente è considerato un segreto commerciale, la maggior parte delle agenzie di regolamentazione utilizza una regola del "50%". Il codice sorgente inviato è oscurato in modo che non possa essere utilizzato così com'è.

IANAL e il collegamento è più rilevante per le copie cartacee del codice piuttosto che per il vero codice di lavoro, quindi questo potrebbe essere completamente irrilevante.

Ora, poiché Javascript è l'esempio canonico per l'offuscamento, c'è un effetto collaterale che non è comunemente considerato e che nasconde codice dannoso in Javascript offuscato. Sebbene ci siano chiari vantaggi nella minimizzazione di ³ Javascript, non vedo alcun punto nell'offuscamento reale e sono felice che Douglas Crockford sia d'accordo con me :

Infine, c'è la questione della privacy del codice. Questa è una causa persa. Non ci sono trasformazioni che impediranno a un determinato hacker di comprendere il tuo programma. Questo risulta essere vero per tutti i programmi in tutte le lingue, è ovviamente più vero con JavaScript perché viene fornito in formato sorgente. Il vantaggio sulla privacy fornito dall'offuscamento è un'illusione. Se non vuoi che le persone vedano i tuoi programmi, scollega il server.

Per quanto riguarda l'offuscamento della "sicurezza del lavoro", si tratta di un comportamento che non dovrebbe mai superare la revisione del codice e, se identificato, non dovrebbe essere tollerato. All'inizio non avrei sparato al colpevole, ma ripetere i trasgressori merita sicuramente una buona sculacciata, almeno.

In conclusione, l'offuscamento è un tipico esempio di sicurezza attraverso l'oscurità, è solo ovvio che il merito è come deterrente e niente di più. Potrebbero esserci casi di utilizzo creativo ⁴ che non conosco, ma in generale i vantaggi sono minimi, nella migliore delle ipotesi.

_{¹ Dopo aver scritto questo ho scoperto questa risposta che sostanzialmente descrive lo stesso schema, quindi potrebbe essere più comune di quanto pensassi.
² Sebbene la steganografia sia ancora sicurezza attraverso l'oscurità.
³ Minificazione ~ rimuovendo gli spazi bianchi e accorciando i token, non oscurando intenzionalmente.
⁴ Il Concorso internazionale per codice C offuscato conta?}

Il caso dell'offuscamento del codice è che alza l'asticella 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 pezzo che penso manchi dalla tua domanda: l'offuscamento del codice (proprio come la minificazione JavaScript) non deve - e non dovrebbe - essere fatto manualmente dallo sviluppatore. Allo stesso modo, anche questo non deve essere archiviato come file sorgente principale nel controllo versione.

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

Ad esempio: Dotfuscator

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

I risultati mostrano che la ridenominazione più idonea riduce significativamente l'efficacia degli attacchi, almeno raddoppiando il tempo necessario per completare un attacco di successo (anche nello scenario peggiore, cioè contro il miglior attaccante). Inoltre, l'offuscamento riduce il divario tra attaccanti principianti e abili, rendendo questi ultimi meno efficienti , e rende i sistemi che sono più facili da attaccare in modo più simile a quelli che sono intrinsecamente più difficili da rompere.

Enfasi mia.

Ho partecipato allo sviluppo di un MMORPG. Ciò ha comportato la logica del server e la logica del client. Durante lo sviluppo pluriennale del progetto, ogni volta che abbiamo considerato l'interfaccia tra il client e il server, la regola era che il client doveva essere trattato dal server in ogni momento con la presunzione che fosse stato violato. In altre parole, il server doveva essere scritto in modo tale che dal client non vi fosse alcuna risposta che potesse causare un errore del server o consentire al client di barare. Tuttavia, si sapeva fin dall'inizio che gli hacker avrebbero inevitabilmente trovato buchi nel sistema e li avrebbero sfruttati per imbrogliare. E dopo un po 'lo fecero.

Naturalmente, prima di spedire il cliente nel grande mondo là fuori, ci siamo assicurati di offuscarlo. Riteniamo che l'offuscamento abbia avuto i seguenti effetti:

1. Ha dissuaso gli hacker non esperti dal provarci.
2. Ha ritardato gli hacker esperti nel realizzare eventuali hack.
3. Ha ridotto il numero di hack raggiunti da hacker esperti.
4. Limita l'efficacia degli hack.
5. Ancora più importante: ha fatto sì che gli hacker eseguissero più test con i loro client hackerati contro i nostri server prima di realizzare un hack funzionante, il che ha aumentato le probabilità che noi li scopriamo cercando attività irregolari nei registri del server.

Gli account di gioco degli hacker scoperti sono stati chiusi senza rimborso, quindi questo ha reso l'attività di hacking più costosa 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 software che rischia di essere violato. (Ad esempio, software contenente misure di protezione dalla copia.)

Gli effetti dell'offuscamento sulla manutenzione non erano praticamente inesistenti. Ci sono stati alcuni posti in cui alcuni programmatori inesperti stavano facendo ipotesi sui nomi degli identificatori (stavano usando la riflessione), ma una volta che questi erano stati risolti tutto andava bene. Il passaggio di offuscamento è appena diventato parte del passaggio di costruzione generale per la versione di produzione del gioco, quindi la maggior parte di noi sviluppatori non ha mai dovuto preoccuparsene o non 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 delle associazioni (mappatura degli identificatori offuscati su identificatori appropriati) prodotta dall'obfuscator al fine di tradurre i log per noi al volo, quindi non abbiamo mai perfino dovuto vedere qualsiasi identificatore offuscato mentre faceva gli esami post mortem basati sui ceppi raccolti dal campo.

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