Binari autovalidanti?

Question

La mia domanda è piuttosto semplice:Sei un file eseguibile che restituisce "Accesso concesso" o "Accesso negato" e persone malvagie cercano di comprendere il tuo algoritmo o di rattopparti le viscere per farti dire "Accesso concesso" tutto il tempo.

Dopo questa introduzione forse vi starete chiedendo cosa sto facendo.Riuscirà a crackare Diablo3 una volta uscito?Posso placare le tue preoccupazioni, non sono uno di quei cracker.Il mio obiettivo sono i crackmes.

Crackmes può essere trovato, ad esempio, su www.crackmes.de.Un Crackme è un piccolo eseguibile che (la maggior parte delle volte) contiene un piccolo algoritmo per verificare un seriale e restituire "Accesso concesso" o "Accesso negato" a seconda del seriale.L'obiettivo è rendere questo output eseguibile sempre "Accesso concesso".I metodi che puoi utilizzare potrebbero essere limitati dall'autore - nessuna patch, nessun disassemblaggio - o implicare qualsiasi cosa tu possa fare con un binario, objdump e un editor esadecimale.Craccare i crackme è sicuramente una parte del divertimento, tuttavia, come programmatore, mi chiedo come sia possibile creare crackme difficili.

Fondamentalmente, penso che il crackme sia composto da due parti principali:una certa verifica seriale e il codice circostante.

Rendere difficile il tracciamento della verifica seriale utilizzando solo l'assembly è molto possibile, ad esempio, ho l'idea di prendere il seriale come input per un microprocessore simulato che deve finire in un certo stato per far accettare il seriale.D'altra parte, si potrebbe diventare economici e imparare di più sui modi crittograficamente forti per proteggere questa parte.Pertanto, renderlo abbastanza difficile da far provare l'attaccante a patct l'eseguibile non dovrebbe essere difficile.

Tuttavia, la parte più difficile è proteggere il codice binario.Supponiamo una verifica seriale perfettamente sicura che non può essere annullata in qualche modo (ovviamente so che può essere invertita, nel dubbio, strappi parti dal binario, provi a crackarlo e lanciagli seriali casuali finché non accetta).Come possiamo impedire a un utente malintenzionato di sovrascrivere i salti nel binario per far sì che il nostro binario accetti qualsiasi cosa?

Ho cercato un po' su questo argomento, ma la maggior parte dei risultati sulla sicurezza binaria, sui binari autoverificanti e cose del genere finiscono in articoli che cercano di prevenire attacchi a un sistema operativo utilizzando binari compromessi.firmando determinati file binari e convalidando tali firme con il kernel.

I miei pensieri attualmente consistono in:

• verificando che le posizioni esplicite nel binario siano salti.
• parti del checksum del codice binario e confrontare i checksum calcolati in fase di esecuzione con quelli.
• avere controlli di runtime positivi e negativi per le tue funzioni nel codice.Con effetti collaterali sulla verifica seriale.:)

Riesci a pensare a più modi per infastidire più a lungo un possibile aggressore?(ovviamente, non puoi tenerlo lontano per sempre, prima o poi tutti i controlli verranno infranti, a meno che tu non sia riuscito a rompere un generatore di checksum riuscendo a incorporare il checksum corretto per un programma nel programma stesso, hehe)

Answer 1

Stai entrando nelle "Tecniche anti-reverse".Ed è fondamentalmente un'arte.La cosa peggiore è che, anche se calpesti i principianti, ci sono "plug-in anti-anti-inversione" per olly e IDA Pro che possono scaricare e aggirare gran parte delle tue contromisure.

Le contromisure includono il rilevamento del debugger tramite le API del debugger trap o il rilevamento del "single stepping".È possibile inserire codice che, dopo aver rilevato un'interruzione del debugger, continua a funzionare, ma inizia ad agire in momenti casuali molto più avanti nel programma.È davvero un gioco del gatto e del topo e i cracker hanno un vantaggio significativo.

Guardare...http://www.openrce.org/reference_library/anti_reversing - Parte di quello che c'è là fuori.

http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817/ - Questo libro contiene informazioni anti-inversione davvero valide e illustra le tecniche.Ottimo punto di partenza se stai iniziando a fare retromarcia in generale.

Answer 2

Credo che queste cose generalmente siano più un problema che un valore.

Spendi molto impegno scrivendo codice per proteggere il tuo codice binario.I cattivi spendono meno sforzi per craccarlo (generalmente sono più esperti di te) e poi rilasciano il crack in modo che tutti possano aggirare la tua protezione.Le uniche persone che darai fastidio sono quelle oneste che sono disturbate dalla tua protezione.

Considera la pirateria semplicemente come un costo aziendale: il costo incrementale del software piratato è pari a zero se ti assicuri che tutto il supporto venga fornito solo ai clienti paganti.

Answer 3

C'è la tecnologia TPM: tpm su wikipedia

Ti consente di memorizzare le somme di controllo crittografiche di un binario su un chip speciale, che potrebbe fungere da verifica unidirezionale.

Nota:Il TPM ha una cattiva reputazione perché potrebbe essere utilizzato per il DRM.Ma per gli esperti del settore, questo è in un certo senso ingiusto, e c'è anche un TPM aperto gruppo che consente agli utenti Linux di controllare esattamente come viene utilizzato il loro chip TPM.

Answer 4

Una delle soluzioni più forti a questo problema è Informatica affidabile.Fondamentalmente dovresti crittografare l'applicazione e trasmettere la chiave di decrittazione a un chip speciale (il Modulo piattaforma affidabile), Il chip decodificherà l'applicazione solo dopo aver verificato che il computer è in uno stato "attendibile":nessun visualizzatore/editor di memoria, nessun debugger ecc.Fondamentalmente, avresti bisogno di un hardware speciale solo per poter visualizzare il codice del programma decrittografato.

Answer 5

Quindi, vuoi scrivere un programma che accetti una chiave all'inizio e la memorizzi in memoria, recuperandola successivamente dal disco.Se è la chiave corretta, il software funziona.Se è la chiave sbagliata, il software si blocca.L'obiettivo è che sia difficile per i pirati generare una chiave funzionante ed è difficile patchare il programma affinché funzioni con una chiave senza licenza.

Ciò può effettivamente essere ottenuto senza hardware speciale.Consideriamo il nostro codice genetico.Funziona in base alla fisica di questo universo.Cerchiamo di hackerarlo, creare farmaci, ecc., e falliamo miseramente, di solito creando tonnellate di effetti collaterali indesiderati, perché non abbiamo ancora completamente decodificato il complesso "mondo" in cui il "codice" genetico si è evoluto per operare .Fondamentalmente, se si esegue tutto su un processore comune (un "mondo" comune), a cui tutti hanno accesso, allora è praticamente impossibile scrivere un codice così sicuro, come dimostrato dal fatto che il software attuale viene violato così facilmente.

Per garantire la sicurezza nel software, dovresti essenzialmente scrivere la tua piattaforma sufficientemente complessa, che altri dovrebbero decodificare completamente e accuratamente per modificare il comportamento del tuo codice senza effetti collaterali imprevedibili.Una volta eseguito il reverse engineering della tua piattaforma, tuttavia, tornerai al punto di partenza.

Il problema è che la tua piattaforma probabilmente funzionerà su hardware comune, il che rende più semplice il reverse engineering della tua piattaforma, il che a sua volta rende il tuo codice un po' più semplice da decodificare.Naturalmente, ciò potrebbe semplicemente significare che il livello di complessità richiesto alla tua piattaforma è sufficientemente difficile da decodificare.

Come sarebbe una piattaforma software sufficientemente complessa?Ad esempio, forse dopo ogni 6 operazioni di addizione, la settima addizione restituisce il risultato moltiplicato per PI diviso per la radice quadrata del logaritmo del modulo 5 della differenza del numero totale di operazioni di sottrazione e moltiplicazione eseguite dall'inizializzazione del sistema.La piattaforma dovrebbe tenere traccia di questi numeri in modo indipendente, così come il codice stesso, per decodificare i risultati corretti.Pertanto, il tuo codice verrebbe scritto in base alla conoscenza del complesso comportamento sottostante di una piattaforma che hai progettato.Sì, consumerebbe cicli del processore, ma qualcuno dovrebbe decodificare quel piccolo comportamento a sorpresa e riprogettarlo in qualsiasi nuovo codice per farlo funzionare correttamente.Inoltre, il proprio codice sarebbe difficile da modificare una volta scritto, perché collasserebbe in una complessità irriducibile, con ogni riga dipendente da tutto ciò che è accaduto prima.Naturalmente, ci sarebbe molta più complessità in una piattaforma sufficientemente sicura, ma il punto è che qualcuno effettuerebbe il reverse engineering della tua piattaforma prima di poter effettuare il reverse engineering e modificare il tuo codice, senza effetti collaterali debilitanti.

Answer 6

Ottimo articolo sulla protezione dalla copia e sulla protezione della protezione Tenere a bada i pirati:Implementazione della protezione anticrack per Spyro:Anno del Drago

L'idea più interessante menzionata lì che non è stata ancora menzionata sono gli errori a cascata: hai checksum che modificano un singolo byte che causa il fallimento di un altro checksum.Alla fine uno dei checksum provoca l'arresto anomalo del sistema o fa qualcosa di strano.Ciò fa sì che i tentativi di piratare il tuo programma sembrino instabili e fa sì che la causa sia molto lontana dal crash.