Come si implementa l'offuscamento del codice per il codice nativo? [chiuso]

Naviga le tue risposte
3

Mi interessa fare obfuscation del codice (codice nativo, per chiarire cosa intendo per "codice nativo": il codice macchina effettivo nei file eseguibili x86 / x64 / arm - PE, ELF, Macho e ecc., non i sorgenti) come parte di un processo di compilazione. Posso pensare a diversi modi per farlo:

  1. Scrivere un plug-in del compilatore, che otterrebbe una rappresentazione interna dopo tutte le fasi di ottimizzazione, trasformarlo e quindi inviarlo al back-end del compilatore. In questo caso, potresti consigliarmi alcuni compilatori che supportano plug-in del genere? Il linguaggio di programmazione non ha molta importanza, ma mi piacerebbe provare qualcosa di diverso da C / C ++ (so che sia GCC e Clang supportano i plugin, ma non potrei mai farlo funzionare correttamente su Windows).

  2. Esegui il dump della rappresentazione interna dopo tutte le fasi di ottimizzazione per archiviare, analizzare ed elaborare con il mio strumento di offuscamento e passarlo nuovamente al compilatore. Non sono riuscito a trovare come farlo con GCC (ho scaricato diverse rappresentazioni interne, ma non sono riuscito a trovare il modo in cui il compilatore genera codice da esso). E so che Clang è in grado di generare un codice a barre LLVM, che può essere elaborato e compilato con il compilatore LLVM, ma ancora una volta non riesco a farlo funzionare correttamente su Windows. Conosci qualche compilatore che permetta di fare cose del genere?

  3. Attualmente sto facendo l'offuscamento tramite le fonti di pre-elaborazione, funziona, ma ci vuole troppo tempo per farlo per un grande code-base. Quindi sto cercando modi alternativi per farlo, e voglio leggere le tue opinioni su quale sia il modo migliore di offuscare il codice nativo.

PS Per favore, ricorda che sto facendo una domanda concreta. Non sto chiedendo se ho bisogno di offuscare non su . L'offuscamento è fatto per una ragione e ho una ragione per farlo. Non sto chiedendo come eseguire l'effettiva offuscazione del codice nativo o sugli algoritmi di offuscamento del codice . So come farlo e come romperlo.

Sto chiedendo informazioni sui compilatori di codice nativo che hanno un buon supporto per i plugin o possono eseguire il dump e ricompilare una rappresentazione interna di basso livello come AST (abstract syntax tree), RTL (register transfer language), tre -indirizzo del codice o altro .

    
posta user2102508 21.08.2013 - 09:09
fonte

2 risposte

5

Dai un'occhiata a Stuxnet per un punto di partenza. Mi rendo conto che non hai inteso o chiesto informazioni sulla tecnica del malware, ma è l'unico esempio che riesco a pensare che soddisfi le tue esigenze. Indipendentemente dall'intento politico di Stuxnet, la struttura tecnica è piuttosto interessante.

L'analisi di Symantec offre un'ottima introduzione al struttura di quel malware. Sono disponibili alcune analisi aggiuntive che approfondiscono il codice.

The heart of Stuxnet consists of a large .dll file that contains many different exports and resources. In addition to the large .dll file, Stuxnet also contains two encrypted configuration blocks.
The dropper component of Stuxnet is a wrapper program that contains all of the above components stored inside itself in a section name “stub”. This stub section is integral to the working of Stuxnet. When the threat is executed, the wrapper extracts the .dll file from the stub section, maps it into memory as a module, and calls one of the exports.

E penso che l'approccio generalizzato potrebbe funzionare per te. Avrai uno stub o wrapper che ospita la tua applicazione. Ogni componente separabile è crittografato e imballato all'interno del wrapper. Un utente malintenzionato dovrebbe quindi decodificare i componenti compressi prima che possano leggere il codice macchina che contiene.

Per ulteriore offuscamento, utilizzare le chiavi di crittografia separate per ciascun componente. Tenere presente che un utente malintenzionato avrà comunque accesso alle chiavi poiché è necessario includerle per il wrapper per decrittografare i componenti. Tuttavia, se si sta distribuendo in base a un modello di licenza, non è necessario distribuire tutte le chiavi. Allo stesso modo, puoi impostare le chiavi su una distribuzione per client, quindi se una copia del tuo codice di escape viene portata allo stato selvaggio, potresti potenzialmente rintracciare l'origine della fuga.

In alternativa, dai un'occhiata a ciò che i programmatori mainframe del vecchio usavano fare con il codice che avrebbe sovrascritto se stesso.

Un condizionale salta in un'altra posizione che inserirà istruzioni nell'area appena eseguita. Il codice torna quindi all'inizio dell'area modificata. Era "utile" quando le patch hotfix dovevano essere applicate a un sistema. Era anche spesso pericoloso per la salute dell'applicazione, quindi sii cauto con questa tecnica.

L'offuscamento entra in gioco perché il programma deve eseguire e scrivere sulle istruzioni esistenti prima che il programma "effettivo" possa funzionare. Non penso che questo sarebbe scalabile per un progetto più grande

    
risposta data 21.08.2013 - 13:19
fonte
-1

Sembra che tu sia confuso.

L'offuscamento del codice è un metodo (debole) per proteggere il codice sorgente dall'essere capiti da altri se ci mettono le mani sopra. Può essere una barriera superficiale per il dilettante quando nomi variabili, formattazione, ecc. Sono distorti per essere "illeggibili", ma gli attaccanti che dovresti preoccuparsi - hacker e cracker - non sono confusi da tali cambiamenti estetici . Semplicemente normalizzano il codice automaticamente e lo leggono con poca difficoltà.

L'offuscamento del codice nativo ha ancora meno senso. Ci sono solo tanti modi per aggiungere due numeri e se il tuo programma ha bisogno di aggiunte, dovrà usarne uno. Il codice assembler non viene mai stampato in un formato normalizzato ad una riga per riga e raramente utilizza identificatori lunghi e significativi in primo luogo. In altre parole, il codice nativo offuscato sembra proprio come un normale codice nativo. (E sì, ladri di software professionali possono leggere il codice macchina come leggono il giornale.) Mentre è possibile rendere le operazioni reali eseguite dal programma più oscure e inutilmente complicate, questo comporta un grosso rischio di introdurre errori e inefficienze. Vale veramente la pena percepire una maggiore sicurezza contro i ladri di codice?

In breve, ti suggerisco di riconsiderare che cos'è esattamente il tuo modello di minaccia e quali misure hanno senso difenderti.

    
risposta data 21.08.2013 - 09:25
fonte

Leggi altre domande sui tag

Gestione o prevenzione di conflitti in un sistema multiutente Design Pattern dilemma. La strategia sembra sbagliata?