come rendere difficile il reverse engineering del software

Ecco un esempio in assembly x86:

MOV AX, 4Ch
MOV [someaddr], AX
MOV AH, 30h
INT 21
CMP AL, 5

Ciò sfrutterà il pipelineing dell'istruzione del processore e l'errore dei debugger (come un singolo passaggio attraverso il codice) e può anche essere un esempio di una misura anti-debug. Ciò è così perché int 21 (interrupt DOS) insieme a una 30h in AH restituirà la versione dos della piattaforma. Tuttavia, le prime due righe sono state così elaborate che [someaddr] diventerà 4Ch (il someaddr è stato scelto in modo tale che contenga l'indirizzo in cui è stato memorizzato 30 ore). Quindi, 4Ch in AH seguito da int 21 terminerà il programma (interrompi thingy!). Senza l'influenza di un debugger questo non sarà un problema dato che la terza riga sarà precaricata e le prime due righe non avranno alcun effetto. Ma i debugger si romperanno mentre eseguono il single step del codice e AH ora conterrà 4Ch che ovviamente interromperà il programma. Hai chiesto la versione di livello superiore di esso. Per questo vorrete sapere come gcc (o qualsiasi altra toolchain del compilatore) converte C in codice asm e poi decompilate il codice precedente. link

Ma alcuni ragazzi davvero fantastici hanno trovato una soluzione e in realtà hanno scritto una contromisura (eseguendo il debug di un loop che è stato sottoposto a pipeline software): leggi Debug non trasparente per loop con pipeline software di Hugo Venturini, Frederic Riss, Jean-Claude Fernandez e Miguel Santana.

Un'altra soluzione sarebbe quella di rendere il debugger consapevole del pipelining. (invia una mail a Oleh!)

Nel computer moderno, indipendentemente dal linguaggio di alto livello o meno, il risultato è lo stesso perché tutto si compila su un insieme di istruzioni note che il processore può eseguire.

Poiché l'attuale generazione di processori non è in grado di elaborare le istruzioni crittografate, le opzioni sono limitate e, anche se ciò fosse possibile, ci sono diversi livelli tra cui è necessario tener conto come sistemi operativi, driver ecc. che eseguono il processore programmazione e gestione della memoria in una certa misura e necessità di capire quale sia la richiesta.

Reverse engineering, potrebbe essere utilizzato per molti scopi tra cui:

• Iniezione di codice dannoso
• Diritti digitali, protezione dalla copia
• Estrazione del codice sorgente, proprietà intellettuale

Fortunatamente possiamo rendere più difficile il reverse engineering di:

• Obfuscation di stringhe, risorse, punti di ingresso e memoria

La codifica della firma ridurrà anche il rischio che qualcuno esegua codice modificato / malevolo se viene controllato dal sistema che esegue il codice.

Ma quando si arriva al punto di codice che gira su un processore non mente.

Ciò di cui stai parlando è nel campo dell'informatica quantistica che potrebbe offrire una soluzione al tuo problema. Però non posso aiutarti con il codice sorgente su quello.

Fai pratica con tutte le cattive abitudini di codifica possibili e continua a farlo funzionare IE segmenti di codice che non fanno quasi nulla, Valori magici, Codice ridondante, Commenti non utili o addirittura falsi IE 'Non so cosa faccia, ma se rimuovo i convocati cuthulu' o 'quando ho scritto questo solo dio e sapevo cosa facesse, ora solo dio lo sa' (li ho presi da una storia come esempi primari)

In generale, dedica tutto il tuo codice a jibirsh come puoi dopo averlo scritto.