Non puoi implementarlo in modo efficace.
Ti stai imbattendo in quello che viene generalmente definito il "problema DRM": il codice in esecuzione su una piattaforma di elaborazione generica può sempre essere sovvertito o modificato dal proprietario di quel sistema. Il tuo codice non è più il tuo codice quando viene eseguito su un sistema utente.
La progettazione di questi tipi di sistemi anti-dumping, anti-iniezione, anti-modificazione, anti-debug, anti-cracking, anti-retromarcia, anti-emulazione, anti-quant'altro-che-senti-come è un continuo campo di ricerca e sforzo commerciale. Finora nessuno è stato in grado di produrre una protezione non incrinata. Ci sono stati casi in cui la protezione dalla frantumazione era particolarmente difficile, ma tutti i sistemi sono stati in qualche modo risolti, anche nel caso in cui fosse utilizzato hardware specializzato (vedi: HDCP , PS3 LV0 keys )
La discussione su cosa può essere fatto per rendere le cose difficili per qualcuno che tenta di sovvertire il tuo programma potrebbe facilmente estendersi su un intero libro, ma ecco una descrizione approssimativa dei trucchi su una piattaforma Windows:
- Trucchi anti-analisi come:
- Compressione o crittografia del codice (imballaggio)
- Macchine virtuali (implementare un emulatore di processore personalizzato, scrivere codice per quello)
- Offuscamento del flusso di controllo
- Offuscamento di stringhe e dati
- Codice falso
- Modifica del codice di runtime
- Trucchi anti-debug come:
- Esecuzione anticipata del codice (pre-EntryPoint) utilizzando i callback TLS.
- Confronto dei tempi di esecuzione utilizzando
rdtsc o GetTickCount .
- Controlli debugger diretti (flag PEB,
IsDebuggerPresent , ecc.)
- Sfruttare le vulnerabilità nei debugger comuni (ad esempio OllyDbg
OutputDebugString bug)
- Rilevamento di debugger e strumenti comuni tramite nomi di processi, nomi di finestre, classi di finestre, mutex e altri oggetti, driver, presenza di file
- Iniezione dei controlli del debugger in altri processi (ad es. explorer) per evitare che vengano identificati.
- Infiniti altri ...
- Trucchi anti-modifica come:
- checksum runtime di codice e dati critici
- Copie shadow di dati critici per una verifica successiva
- Codifica della memoria utilizzando
CryptProtectMemory API.
- Spostamento delle operazioni critiche nel kernel (utilizzando un driver) per rendere più difficile per un utente manomettere il codice.
- Rilevamento VM (ancora una volta possono essere scritti interi libri su questo)
- Agganciare le API comuni in tutti i processi (sia in usermode usando DLL injection o nel kernel) per negare o altrimenti manomettere le chiamate che tentano di accedere al tuo processo.
- Trucchi anti-tracciamento utilizzando i breakpoint del software e i gestori delle eccezioni.
- Sicurezza di sicurezza generale come l'abilitazione di NX + ASLR + ForceIntegrity, più politiche di mitigazione che potrebbe rendere più difficile per il software accedere al processo o iniettare DLL.
Anche se hai implementato tutte le funzionalità di questo elenco, tutto può essere bypassato con un po 'di lavoro.
È importante notare che .NET stesso non ha necessariamente alcuna debolezza per essere modificato dalla memoria che gli eseguibili nativi (ad esempio C, C ++) non lo fanno. Ciò che rende .NET più facile da attaccare in generale è che le istruzioni di linguaggio intermedio (IL) ei metadati contenuti all'interno possono essere più facilmente decodificati in qualcosa di comprensibile all'uomo, mentre gli eseguibili nativi hanno più opzioni per offuscamenti e trucchi anti-rovesciamento e don ' t contenere tali metadati. L'articolo che hai collegato mostra semplicemente un modo di utilizzare la riflessione per ottenere l'accesso alla variabile piuttosto che un approccio più nativo che potrebbe funzionare altrettanto bene.