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

8

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 possa 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 le 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 antipirateria (lo vedo in molti giochi ), Libreria GUI (come Qt), librerie OS, ecc.

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

    
posta user827992 01.07.2012 - 17:33
fonte

3 risposte

26

Non perdere tempo a perdere battaglie

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

Ulteriori letture

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

Risposte StackExchange

Carte

Citazioni famose sull'offuscamento:

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

Mai?

Non sto dicendo che non dovresti mai offuscare e che non ci sono buoni motivi per farlo, ma io ne pongo seriamente in dubbio la necessità nella maggior parte dei casi, e la sua economicità.

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

    
risposta data 01.07.2012 - 17:54
fonte
3

No, non ne 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 gli offuscatori esistono per Java è perché la mappatura tra il codice byte Java e il codice sorgente Java è abbastanza ben definita, ei nomi di tutte le funzioni e le variabili membro sono memorizzati nel codice byte (indipendentemente dal fatto che siano pubblici, privati o protetto) in modo che un interprete di codice di byte Java possa presentare un generico Java che mostra la struttura dell'origine originale abbastanza bene per la fonte non offuscata.

C ++ compila direttamente sul linguaggio macchina. Può essere smontato, ma il linguaggio di assemblaggio è piuttosto noioso da affrontare. La decompilazione è molto più complicata a causa di tutte le modifiche che gli ottimizzatori apportano al codice durante la compilazione.

    
risposta data 01.07.2012 - 17:55
fonte
0

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.

    
risposta data 26.05.2014 - 13:52
fonte

Leggi altre domande sui tag