L'offuscamento a livello di codice sorgente è più efficace degli offuscatori?

Question

Imparando dalla mia ultima domanda , la maggior parte nomi dei membri sembrano essere inclusi nell'output del progetto.

Guardando alcuni decompilatori come 9rays , Salamander , Jungle , molte tecniche offuscanti sembrano essere già state sconfitte, c'è questa affermazione particolarmente spaventosa:

  

Rimuove automaticamente le crittografie di stringa iniettate dagli offuscatori ~ Salamander

Quindi il livello del codice sorgente manuale, offuscando, è più efficace rispetto all'offuscamento post-compilazione / metà compilazione, "superficiale", offuscato da noti programmi di offuscamento (facilmente sconfitti ??)?

Answer 1

L'offuscamento del codice sorgente si autodistruggerà in termini di manutenzione.

Se il tuo progetto è così 'segreto', immagino tu abbia due scelte:

• Posiziona il codice proprietario "segreto" dietro un servizio su un server che controlli

• Codificalo in una lingua, quindi non è facile da decompilare come C / C ++

Answer 2

Forse, discutibilmente, ma distruggerai la manutenibilità per farlo.

Ne vale davvero la pena?

In realtà questo si riduce alla sicurezza attraverso l'oscurità , cioè non è affatto sicurezza, è solo un inconveniente. dovresti lavorare dal presupposto che qualsiasi parte interessata decompilerà il tuo codice se può accedervi. Non vale la pena che ti infliggerai per renderlo un po 'più lungo e dispendioso in termini di malvagità. Gestire i veri problemi di sicurezza dell'accesso.

Answer 3

Come dicevano le persone, l'offuscamento riguarda alzare l'asticella. Se offuschi il tuo assemblaggio, fermerai uno sviluppatore occasionale il cui solo curioso ma non impedirai a una persona leggermente motivata dal reverse engineering.

Se si desidera alzare ulteriormente la barra di molti strumenti di offuscamento, è possibile utilizzare caratteri non stampabili come nomi dei membri. usa il riflettore su se stesso per dare un'occhiata. Questo fermerà molte più persone, potrei guardare il codice offuscato per capirlo, ma se non riesco a leggerlo, non passerò il dolore di scaricarlo su IL e rinominare manualmente tutti i membri, nessuna motivazione per me per perdere così tanto tempo.

Tuttavia, per alcune persone esiste una motivazione, quindi è necessario fare un altro passo se i requisiti aziendali lo richiedono. Ma qualunque cosa tu faccia se il computer è in grado di leggerlo, ci sarà qualcuno là fuori in grado di leggerlo. L'obiettivo è ridurre il numero di persone che possono leggerlo o che sarebbero motivate a leggerlo.

Ci sono anche alcuni trucchi che puoi usare per far rompere il riflettore (Obfuscator di PreEmptive rompe il riflettore in alcuni casi, ma ovviamente puoi ancora leggere l'IL). Una volta ho avuto una conversazione interessante con uno sviluppatore di uno strumento di offuscamento e non sarò in grado di renderlo giustizia, ma ha avuto un modo per far rompere completamente il riflettore facendo saltare il codice in modo dinamico. Ad esempio, un momento nella tua funzione a, salteresti al centro della funzione b. Doign questo causa PEVerify per generare errori in modo che non lo abbiano mai effettivamente implementato, ma in qualche modo un'idea chiara

Answer 4

annakata è corretto. Davvero tutto ciò che puoi fare è rendere più difficile (e costoso) per la persona decodificare il software.

La mia azienda ha identificato diverse aree in cui volevamo renderlo il più difficile possibile per il reverse engineering. Ad esempio, i nostri file sono un formato binario che ogni oggetto nella nostra gerarchia è responsabile del salvataggio di se stesso e della lettura della versione corretta. Ciò significa che per una persona che legge i nostri file avrebbe replicato l'intera nostra gerarchia nel codice creato per leggere i nostri file. Inoltre, molte delle informazioni contenute nel file di lavoro sono utili senza il bit corrispondente nei file degli standard del negozio. Quindi devono fare il lavoro due volte per capire cosa dice il file di lavoro.

Diverse aree critiche (protezione del dongle, comunicazione con le nostre macchine per il taglio dei metalli) risiedono in Win32DLL. Ciò significa che dovrebbero conoscere assembly e come creare DLL che replicano le firme di altre DLL per decodificare il nostro software. Inoltre il nostro design con il nostro software CAM è che è altamente interattivo con la macchina da taglio (informazioni scambiate continuamente)

Dalle poche volte che abbiamo sentito parlare di concorrenti che cercavano di gestire le nostre macchine da soli, hanno finito per sostituire l'elettronica con la propria per finire il lavoro. Principali dollari per farlo.

Parte dei passi che abbiamo fatto si basava sulla nostra esperienza con il tentativo di gestire la macchina e il software della concorrenza. Abbiamo fatto questa esperienza e abbiamo imparato a modificare la nostra configurazione. Naturalmente abbiamo dei limiti in quanto non stiamo andando a sacrificare l'affidabilità o la manutenzione solo allo scopo di sconfiggere il reverse engineering.

Per il tuo caso, dovrai chiederti quale parte del tuo software sarebbe interessante per i tuoi concorrenti e procedere da lì. Se sei uno sviluppatore del mercato verticale (controllo macchine, contabilità specializzata, ecc.) Ti suggerisco di utilizzare un dongle USB per il controllo del software.

Altrimenti usa un sistema di numeri di serie e accetta che le persone piratino il tuo software e lo inseriscano nel tuo modello di business. Lo scopo di uno schema di numeri di serie è relativamente non invadente e ostacola la copia causale e ti dà una remota possibilità di rintracciare da dove proviene la copia.

Answer 5

Il problema è che sacrificherai la leggibilità per farlo. Se il tuo progetto è così sacro da proteggere, credo che sia sicuro assumere due cose:

1. Il progetto è abbastanza grande che il colpo in leggibilità tornerà a morderti nel culo.
2. Le persone che vogliono decodificare lo faranno comunque. Ci vorrà solo un'impresa di intelligenza leggermente più grande per determinare cosa fanno le cose (invece di leggere semplicemente i nomi dei membri).

Answer 6

Sono allarmato dal fatto che stiate anche considerando l'offuscamento a livello di codice. Non offuscherai il codice anche per te stesso? Come hai intenzione di lavorarci di nuovo? Per motivi di manutenibilità, ciò non dovrebbe essere fatto.

Ma considera questo: -

Supponi che ci sia uno script / un'app che puoi eseguire per aprire il tuo progetto e offuscare abilmente ogni stringa / nome di variabile nel tuo progetto e lo compili in seguito mentre il tuo codice originale non viene toccato in modo sicuro in una posizione separata.

Questa è un'idea.

Answer 7

In realtà l'offuscamento a livello di codice è meno sicuro di quello che gli offuscatori là fuori possono fare. Ciò è principalmente dovuto al fatto che gli offuscatori possono trarre vantaggio dai rigidi dettagli sull'implementazione della CLI che non sono consentiti dai compilatori di lingue. Ad esempio, è del tutto legale che tutti i campi privati ??abbiano lo stesso nome, ma non esiste un compilatore che ti permetta di farlo.

Answer 8

puoi usare una tecnica come questa: http://g.palem.in/SecureAssembly.html usando questo scrivi in ??.net ma hai incorporato in un eseguibile c ++ il tuo eseguibile .net,