È importante offuscare il codice dell'applicazione C ++?


11

Nel mondo Java, a volte sembra essere un problema, ma per quanto riguarda il C ++? Ci sono soluzioni diverse?

Stavo pensando al fatto che qualcuno può sostituire la libreria C ++ di un sistema operativo specifico con una versione diversa della stessa libreria, ma piena di simboli di debug per capire cosa fa il mio codice. È una buona cosa usare librerie standard o popolari?

Questo può accadere anche con alcune librerie DLL sotto Windows sostituite con la "versione di debug" di quella libreria. È meglio preferire la compilazione statica? Nelle applicazioni commerciali, vedo che per il nucleo della loro app compilano tutto staticamente e per la maggior parte le DLL (librerie dinamiche in generale) vengono utilizzate per offrire alcune tecnologie di terze parti come le soluzioni anti-pirateria (lo vedo in molti giochi ), Libreria GUI (come Qt), librerie del sistema operativo, ecc.

La compilazione statica è l'equivalente dell'offuscamento nel mondo Java? In termini migliori, è la soluzione migliore e più conveniente per proteggere il tuo codice?


4
Ricorda, qualunque cosa tu faccia, qualcuno con troppo tempo sarà in grado di deobfuscolarlo / decompilarlo
Zavior

13
Molti compilatori vengono con un /Ointerruttore di offuscamento. Alcuni hanno anche più livelli di offuscamento, fino a /O3;)
MSalters

@MSalters No, g ++ has -O3;)
BЈовић

@Zavior O semplicemente decodificarlo, chiaro e semplice. Non richiede nemmeno il binario stesso, solo un'analisi approfondita del software.
John Weisz,

Risposte:


27

Non perdere tempo a perdere battaglie

Come notato in molte altre risposte simili per C ++ e altre lingue, questo è per lo più inutile .

Ulteriori letture

Letture selezionate sull'argomento (non tutte sono specifiche per C ++, ma si applicano i principi generali):

StackExchange Answers

documenti

Citazioni famose sull'offuscamento:

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. - Douglas Crockford


Mai?

Non sto dicendo che non dovresti mai offuscare e che non ci sono buoni motivi per farlo, ma metto seriamente in dubbio la necessità nella maggior parte dei casi e la sua efficacia in termini di costi.

Inoltre, ci sono situazioni in cui l'offuscamento è di fatto un requisito. Ad esempio, se scrivi virus, ovviamente l'offuscamento (e uno dinamico, preferibilmente) è una buona cosa per la sopravvivenza del tuo programma quanto la sua capacità di replicarsi. Tuttavia, questo difficilmente costituisce un caso "comune" ...


Una volta abbiamo usato un dongle hardware in cui c'era un requisito di licenza per oscurare tutte le chiamate di funzione dongle - e ci hanno fornito uno strumento per farlo. Mi ha sempre reso un po 'sospettoso della qualità della loro "protezione"!
Martin Beckett,

@MartinBeckett: un po 'strano davvero.
haylem,

3

No, questo non vale la pena, e penso che sia completamente inutile. Le funzioni che chiami possono probabilmente essere indovinate dalla funzionalità che fornisci.

Il motivo per cui esistono gli offuscatori per Java è perché la mappatura tra il codice byte Java e il codice sorgente Java è abbastanza ben definita e i nomi di tutte le funzioni e variabili membro sono memorizzati nel codice byte (indipendentemente dal fatto che siano pubblici, privati ​​o protetti ), quindi un interprete di codice byte Java può presentare un linguaggio Java generico che mostra abbastanza bene la struttura della fonte originale per la fonte non offuscata.

Il C ++ viene compilato direttamente nel linguaggio macchina. Può essere smontato, ma il linguaggio assembly è abbastanza noioso da affrontare. La decompilazione è molto più complicata a causa di tutte le modifiche apportate agli ottimizzatori al codice durante la compilazione.


0

Pensando a questo, ci sono diversi tipi di offuscamento. Cominciamo con l'offuscamento del codice sorgente, che è una completa perdita di tempo; è abbastanza difficile da capire senza quello! Quindi concentriamoci invece sull'offuscamento del pacchetto di consegna, su come il codice viene consegnato all'utente.

Minore offuscamento

Esistono lievi offuscamenti per impedire all'utente casuale di infilare le dita e rompere facilmente le cose. Non tiene fuori l'hacker determinato, ma ha valore nell'aiutare a garantire che le cose che ti viene chiesto di supportare siano quelle che hai effettivamente consegnato. Il livello di protezione richiesto per questo genere di cose è davvero piuttosto basso; il pacco di consegna non deve semplicemente apparire leggibile e modificabile (senza strumenti specialistici) ed è abbastanza buono.

La minimizzazione Javascript è un esempio di questo, sebbene non sia commercializzata come tale. Nessuno nella loro mente corretta vorrebbe leggere e modificare un file JS minimizzato, anche se è tecnicamente possibile farlo se sei determinato / abbastanza persistente.

Allo stesso modo con la consegna di applicazioni Java. Impacchettare semplicemente il codice in un JAR eseguibile bloccherà la maggior parte della follia, anche se ha tutta la forza di un educato cartello "Please Keep Off The Grass" in un parco cittadino.

Anche quando si consegna il codice C ++, sarà sufficiente rimuovere i simboli non necessari dall'eseguibile per qualificarsi come offuscamento minore. La chiave è che è scomodo leggere il risultato come utente, ma non è un problema eseguirlo come un computer.

Grande offuscamento

L'offuscamento maggiore sta tenendo fuori l'utente determinato e competente . È anche un gioco perdente totale; se un computer può eseguirlo, una persona può sceglierlo a parte e capire cosa fa. Il più vicino che potresti ottenere sarebbe far decifrare continuamente il programma, trasformando quello 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 comunque non impedirebbe a un hacker davvero bravo (anche se alla fine sarebbe abbastanza incrociato con te per la quantità di sforzo richiesto per decifrare tutto quel codice che si modifica da solo).

È molto meglio pensare in termini di altre soluzioni. Ad esempio, potresti conservare i "gioielli della corona" del codice sui server che controlli e consentire solo le chiamate di servizio ad esso, rendendo il client un omaggio essenzialmente gratuito che è un front-end per i bit preziosi. Oppure potresti seguire il percorso più contrattuale / legale e consegnare gli eseguibili solo alle organizzazioni che accettano formalmente di non rovistare nel tuo codice o di compensarti se lo fanno (quindi sarebbe una sorta di NDA). Lo scopo sarebbe quello di creare un forte incentivo per l'hacker di non hackerare e per gli utenti di mantenere il codice lontano da eventuali hacker non vincolati dall'accordo.

Ma non devi presumere che il tuo codice non possa mai essere decifrato. Con la virtualizzazione, qualsiasi stato del programma di un'esecuzione può essere esaminato e monitorato e tutto ciò che cerca di sconfiggere tale (ad esempio, il monitoraggio dell'orologio su una fonte di tempo esterna) avrà molte più probabilità di causare problemi agli utenti legittimi rispetto agli hacker. (Vedi la storia di DRM per come anche gli editori di informazioni molto determinati non possono mantenere sicuri i loro sistemi una volta che il codice è nelle mani dei loro avversari.) È molto meglio concentrarsi sul rendere davvero felici gli utenti legittimi. Le perdite dovute al crack occasionale non saranno nulla se paragonate al denaro extra portato a soddisfare adeguatamente i clienti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.