Diciamo che ho i privilegi di amministratore nel mio sistema operativo (Windows o qualsiasi altra cosa). Quando il software XYZ è installato ed eseguito, significa che c'è comunicazione tra il sistema operativo e XYZ e il sistema operativo esegue e vede tutto ciò che XYZ fa.
Ecco la mia percezione delle password (come le password .zip):
È possibile modificare la logica del software per eseguire il comando anziché un altro comando? Se è così, niente può essere protetto dal cracking?
In breve, sì, puoi modificare l'eseguibile, usare un debugger, ecc. per modificare la logica del codice che viene eseguito.
Ma potrebbe non essere sufficiente.
Per utilizzare il tuo esempio di "password .zip", gli archivi protetti da password utilizzano la password per derivare una chiave di crittografia. A meno che tu non fornisca una password corretta, la chiave generata sarà sbagliata, e anche se la modifichi per usare una chiave errata, non decodificherà il file ZIP.
Un altro scenario potrebbe coinvolgere un eseguibile setuid che viene eseguito con privilegi più elevati. Potresti eseguirlo con un debugger, o copiarlo sul tuo account utente e apportare modifiche, ma tutto ciò lo raggiungerà eseguendolo con le autorizzazioni dell'utente, annullando così le possibilità di sfruttamento.
Bene, la tua percezione delle password .zip non è accurata. L'approccio, utilizzato anche da molti altri programmi, è quello di sempre eseguire un algoritmo di decrittografia e ottenere un risultato, prima che il programma raggiunga anche la decisione "password buona o cattiva". Il trucco è che la decrittografia produce spazzatura su qualsiasi password tranne una buona che "magicamente" (o meglio - matematicamente) calcola i dati corretti. Quindi il programma non sa quale sia la buona password.
Il momento "buono o cattivo" che vuoi hackerare controlla solo se il risultato è spazzatura. Non è molto utile sovrascriverlo.
Sì e No .
Poiché nessuno ha ancora trovato un esempio di vita reale (non relativo al computer), proverò qui:
Immagina di provare a salire a bordo di un volo. Hai bisogno di una carta d'imbarco, o i ragazzi della sicurezza non ti lasceranno passare. Se hai accesso al sistema e sei in grado di modificarlo (ad esempio sei il CEO), puoi ignorare la sicurezza? Sì! Puoi:
Ora, un altro scenario: un mucchio di casseforti sono conservati in una banca. Per aprire una cassastrong, è necessario un tasto fisico per attivare il blocco.
Puoi tirare il trucco precedente? Sì, puoi, ma non sarà di aiuto. Non è come il tizio della sicurezza che sta lì ha accesso a tutte le casseforti - non ha la chiave per nessuna delle casseforti. Puoi batterlo a morte, ma non possiede solo ciò che è necessario (la chiave fisica) per aprire le serrature.
Puoi provare a selezionare il blocco (forzatura bruta), ma sarebbe molto dispendioso in termini di tempo (la matematica delle chiavi di crittografia moderne dice che hai bisogno di alcuni miliardi di anni per sbloccarla, anche se hai tutti i computer del mondo farlo per te). Così ci sei - in questo design (crittografia dei dati), l'unico modo per ottenere i dati memorizzati è l'utilizzo di una chiave, che rende impossibile l'esclusione.
Certo, il software può fare tutto ciò che si programma da fare.
Come esempio banale, se mi è stato fornito un programma Python che ha controllato la password:
password = raw_input('Enter your password: ')
if password != 'oh-so-secret':
sys.exit(1)
do_secure_thing()
Potrei semplicemente cambiarlo per non preoccuparmi di quale sia la password:
password = raw_input('Enter your password: ')
do_secure_thing()
(In questo caso, potresti anche solo vedere qual è la password in chiaro in codice e inserirla.)
Con le applicazioni binarie, devi decompilarle prima di poter modificare l'origine, ma ci sono molti decompilatori per le lingue comuni.
Questo è il motivo per cui esiste firma del codice .
Ora, se questo non è il tuo sistema, le tue opzioni potrebbero essere un po 'più limitate. Nella maggior parte dei sistemi di tipo Unix, gli eseguibili sono generalmente archiviati con autorizzazioni di sola lettura ed esecuzione solo per utenti non root; quindi, se non sei root, non puoi modificare il file eseguibile di destinazione. Ci sono altri metodi meno diretti da provare, ma se falliscono stai cercando di passare a un vettore diverso.
Ad esempio, un keylogger registrerà le password immesse dall'utente, consentendoti di riutilizzarle in un secondo momento.
Un altro metodo di attacco che non richiede la modifica dell'origine di un programma consiste nel modificare il percorso di caricamento della libreria dinamica in modo che il programma utilizzi una chiamata alla libreria che è stata scritta, anziché quella che si aspetta. Se usano una libreria esterna, caricata dinamicamente per la gestione delle password, e quella libreria ha una funzione verify_password() che restituisce un valore booleano, puoi scrivere il tuo verify_password() che restituisce sempre true e caricarlo invece.
La vera distinzione che cambia la risposta da "sì" a "no" è se la password non è in realtà una password, ma una chiave di crittografia. Se i dati sono crittografati, non importa ciò che fanno i programmi esterni: i dati vengono ancora crittografati finché l'algoritmo di decrittografia non viene alimentato con la chiave corretta.
Supponiamo di avere un'app che memorizza i dati in un file di testo (o in un piccolo database), ma per accedere al file dall'app devi inserire una password o utilizzare un processo speciale. Potresti semplicemente aprire il file di testo (o db) dalla directory dei file usando il sistema operativo (non è richiesto alcun reverse engineering). Questo accadeva spesso nei programmi più vecchi (i giochi, in particolare).
Ecco perché le app che sperano di essere sicure adottano misure per proteggere i dati dal sistema operativo stesso. Come crittografare i dati o offuscare i dati per renderne difficile l'uso.
Dipende da come il software XYZ utilizza la password per produrre un'azione desiderabile e che tipo di dati con cui lavora.
Se guardiamo all'algoritmo astratto del programma XYZ sarebbe:
Quindi la tua domanda può essere ridotta al passaggio # 3 :
È possibile produrre output desiderabili (o eseguire un'azione) senza utilizzare il programma XYZ?
Qui ci sono molte varianti possibili, ma il punto principale è che il software XYZ esegue particolari passaggi per produrre il risultato.
Se puoi creare un programma ABC che può produrre lo stesso risultato in un tempo ragionevole senza richiedere una password, è possibile ignorare XYZ .
Ciò indicherebbe che l'intera "protezione" è implementata nel programma XYZ stesso.
Se la creazione di tale programma ABC non è possibile, la protezione si basa su un algoritmo che richiede la password indipendentemente dal programma che sta tentando di usarlo .
Esempio 1 : un account OS non privilegiato non può impostare la password per un altro utente, perché viene applicato dal sistema operativo. Quindi il sistema operativo in questo caso è XYZ . Ma si può avviare il computer da un'unità avviabile e sovrascrivere il file contenente password, perché il sistema operativo originale non funziona in questo momento, quindi non può imporre la protezione. Quindi, siamo stati in grado di produrre risultati desiderabili senza utilizzare il programma XYZ .
Esempio 2 : nel secondo esempio, l'unità di sistema del sistema operativo è crittografata correttamente con un algoritmo crittografico avanzato. Se avviamo il computer con un'unità avviabile nel tentativo di aggirare il sistema operativo originale, scopriremo che non possiamo raggiungere il nostro obiettivo, perché non possiamo accedere al file contenente password. Si trova su una partizione che deve essere decifrata per prima, ma non conosciamo la password. Un tentativo di forzare il processo di decifrazione non porterebbe il risultato desiderabile in tempi brevi, quindi in questo caso non è stato possibile aggirare il programma XYZ o qualsiasi altro programma con funzionalità simili, perché i dati sottostanti richiedevano la password .
La password zip non è un esempio di ciò che stai pensando. Ma molte cose sono , in particolare versioni di "prova" limitate nel tempo o nel set di funzionalità.
Ricordo un paio di articoli in un editor di programmazione (potrebbe essere stato Computer Language ) che spiega come farlo e come contrastare i tentativi di farlo al tuo codice, rispettivamente.
Conosco casi in cui è stato letteralmente semplice trovare l'istruzione di confronto e modificare la condizione di salto, ovvero cambiare un byte per ignorare il controllo reale.
Questo è a volte il caso ora se l'autore ha semplicemente scritto la riga di codice come parte del programma. Ma per le chiavi di attivazione e simili è sorto un intero settore e l'autore può includere un kit che offusca il test effettivo e rende difficile il funzionamento del programma se si tenta di curcumvent usando tecniche comuni a un codice di debug del programmatore .
Dipende tutto da come funziona il sistema quando decodifica la password.
Stai immaginando un sistema di password di tipo "log in" molto semplice che potrebbe essere infiltrato. Tuttavia, qualcosa come i file ZIP e i siti Web utilizzano vari metodi per combattere le persone semplicemente modificando il sistema per costringerlo a rivelare la password.
Un modo è l'uso di MD5 insieme a "sale" da aggiungere alla sicurezza - questo funziona sul fatto che la password viene trasformata in un codice irriconoscibile che non può essere ripristinato - un esempio di base di ciò che accade è come segue
Sistema richiede password - ad es. PAROLA D'ORDINE Il sistema aggiunge 'sale' alla password - ad es. 1234 (la password è ora PASSWORD1234) Il sistema usa MD5 sulla password con sale - la maggior parte delle persone saprà che PASSWORD di propria volontà genererà il codice MD5 319f4d26e3c536b5dd871bb2c52e3178 tuttavia con il sale "1234" aggiunto alla password, l'MD5 diventa 579f276ad2a77fd1698c38e3ad4d20a7 - che è un codice completamente diverso.
A questo punto il sistema non ha ancora verificato se la password fosse valida o meno, quindi passa questo nuovo codice su un'altra sezione del programma che decide se il codice MD5 corrisponde a ciò che è previsto se lo fa. il file (la password iniziale è stata scartata a lungo dalla memoria).
Affinché qualcuno possa infiltrarsi in questo tipo di password, è necessario ottenere la password iniziale che è stata digitata per prima, e successivamente scoprire se il programma ha consentito o meno l'apertura del file. Su un pezzo di software su un computer potrebbe essere possibile ottenere la password e poi controllare in seguito per vedere se il file è stato aperto e ottenere la password in questo modo, tuttavia se la password viene inviata come MD5 + sale a un altro server ( ad esempio tramite javascript e PHP) diventa molto più complicato perché un computer ha la password nella sua memoria che converte e il server php ha solo la password md5 + salt che non può essere riconvertita.
Inoltre, un altro metodo utilizzato è quello di prendere la password e codificarla all'interno dei dati in un modo che è come funzionano i file zip, ad esempio, ho un file con il seguente testo ....
la volpe marrone veloce salta sul cane pigro
Gli do una password di una lettera di! ok, so che è un po 'semplice ma questo è un semplice esempio: il computer potrebbe convertirlo! nel suo equivalente ASCII e sottrarre il codice ASCII di ogni lettera da esso per codificarlo - il codice ASCII per! è 33 e il codice ASCII per t è 116 e 116 - 33 = 83, che è il codice ASCII per una lettera maiuscola S, quindi quando i dati vengono crittografati, la riga precedente viene memorizzata come
SGD PTHBJ AQNVM ENW ITLOR NUDQ SGD K @ YX CNF
ora se qualcuno sta tentando di decrittografare questo messaggio non sai se hanno o meno la giusta password - se inseriscono la password di # invece di! avrebbero ricevuto il seguente messaggio a loro
vjg swkem dtqyp hqz lworu qxgt vjg nc | {fqi
che non ha alcun senso - quindi la maggior parte dei sistemi controlla effettivamente la validità di una password, ma alterano inizialmente la password in modo che non possa essere violato da qualcuno che devia solo il risultato - l'unica volta che a volte questo cade è quando qualcuno crea il proprio sito o programma falso e fa in modo che l'utente inserisca inizialmente la propria password nel falso programma o sito Web e naturalmente molti siti Web ora lo ottengono anche utilizzando token di autenticazione che generano password speciali valide solo per circa 5 minuti alla volta (ad esempio la chiave smart HSBC).
La domanda ha bisogno di chiarimenti. La tua comprensione di come viene letto un file zip protetto da password non è corretto. Come altri hanno sottolineato, un file zip è crittografato (i dati sono criptati) e la password è la chiave per decrittografare.
Quello che stai descrivendo (un reindirizzamento dell'esecuzione del codice tramite reverse engineering del flusso di codice) funzionerebbe per sconfiggere il "controllo di accesso" che viene applicato dal programma.
Quindi, alla tua domanda iniziale:
Is it possible to alter software logic to execute the command instead of another command? If so, then nothing can be protected from cracking?
È certamente possibile alterare la logica del software per eseguire comandi, ignorando il controllo dell'accesso per fare qualcosa che il programma potrebbe altrimenti fare, tramite il reverse engineering. Tuttavia, ciò non supporta la tua seconda affermazione secondo cui "nulla può essere protetto dal cracking". Il file zip crittografato è un ottimo esempio di dove il tuo controllo sul codice non ti dà il contenuto del file.
In questo caso, la chiave non è un gatekeeper che ti impedisce di eseguire un percorso di codice, ma piuttosto un componente richiesto per ottenere i dati di testo normale. Niente a che vedere con il controllo del flusso del programma.
Questo è fondamentalmente chiamato cracking e può essere fatto usando un debugger. Ci sono salti condizionali come je, jne, jnz etc che possono essere eliminati per raggiungere questo obiettivo. Le esercitazioni per l'inversione di Lena su tuts4 dovrebbero essere un buon inizio.
Il processo che potrebbe essere meglio descritto come "reverse engineering" sarebbe un Timing Attack , che prevede l'analisi del tempo preso per verificare una password. È infatti possibile rallentare l'elaborazione di un algoritmo e contare quanti tick di processore ci vogliono per rifiutare una password. Mentre indovini più lettere correttamente, ci vorrà più tempo per rifiutarle, quindi puoi essere guidato nelle tue ipotesi.
Questa non è solo una situazione ipotetica; questo attacco è stato utilizzato contro SSL e alcune versioni di Unix.
Leggi altre domande sui tag reverse-engineering