In breve, sì, puoi modificare l'eseguibile, utilizzare un debugger, ecc. per alterare la logica del codice in esecuzione.

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 sbagliata, non decodificherà con successo 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 nel tuo account utente e apportare modifiche, ma tutto ciò che otterrai sarà eseguirlo con i permessi dell'utente, annullando così le possibilità di sfruttamento.

La tua percezione delle password .zip non è accurata. L'approccio, utilizzato anche da molti altri programmi, è quello di eseguire sempre un algoritmo di decrittazione e ottenere un risultato, prima ancora che il programma raggiunga la decisione "password buona o cattiva". Il trucco è che la decrittazione 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 vantaggioso ignorarlo.

Sì e No”.

Poiché nessuno ha ancora escogitato un esempio di vita reale (non relativo al computer), io " proverò qui:

Immagina di provare a salire a bordo di un volo. Hai bisogno di una carta d'imbarco, altrimenti i ragazzi della sicurezza non ti lasceranno passare. Se hai accesso al sistema e sei in grado di modificarlo (diciamo che sei il CEO), puoi aggirare la sicurezza? Sì! Puoi:

• Rimuovere i ragazzi della sicurezza (rimuovere l'intero componente di autenticazione)
• Chiedere ai ragazzi di far entrare tutti (rimuovere il segno di spunta "se il passeggero ha una carta d'imbarco valida" )
• Chiedi ai ragazzi di concedere l'accesso se qualcuno presenta una carta d'imbarco speciale (aggiungi una nuova regola di convalida per consentire credenziali false)

Ora, un altro scenario : un mucchio di casseforti sono immagazzinate in una banca. Per aprire una cassaforte, hai bisogno di una chiave fisica per girare la serratura.

Riesci a tirare il trucco precedente? Sì, puoi, ma non aiuterà. Non è che l'addetto alla sicurezza che sta lì abbia accesso a tutte le casseforti: non ha la chiave di nessuna delle casseforti. Puoi batterlo a morte, ma non possiede solo ciò che è necessario (la chiave fisica) per aprire le serrature.

Puoi provare a scassinare la serratura (forzatura bruta), ma lo farebbe richiede molto tempo (la matematica delle moderne chiavi di crittografia dice che hai bisogno di miliardi di anni per sbloccarlo, anche se tutti i computer del mondo lo fanno per te). Quindi eccoti qui: in questo design (crittografia dei dati), l'unico modo per ottenere i dati memorizzati è utilizzare una chiave, che rende impossibile aggirare.

Certo, il software può fare qualsiasi cosa tu programmi per farlo.

Come esempio banale, se mi fosse stato fornito un programma Python che controllava una password:

  password = raw_input ('Enter your password:') if password! = 'oh-so-secret': sys.exit (1) do_secure_thing ()  

Potrei semplicemente cambiarlo in non importa quale sia la password:

  password = raw_input ('Enter your password:') do_secure_thing ()  

(In questo caso, potresti anche basta vedere qual è la password di testo in chiaro hardcoded e inserirla.)

Con le applicazioni binarie, devi decompilarle prima di poter modificare il sorgente, ma ci sono molti decompilatori per le lingue comuni.

Questo è il motivo per cui esiste la firma del codice.

Ora, se questo non è il tuo sistema, le tue opzioni potrebbero essere un po 'più limitate. Sulla maggior parte dei sistemi Unix-like, gli eseguibili sono generalmente memorizzati con permessi di sola lettura ed esecuzione per utenti non root; quindi, se non sei root, non puoi modificare l'eseguibile di destinazione. Ci sono altri metodi meno diretti da provare, ma se falliscono stai cercando di spostarti su un vettore diverso.

Ad esempio, un keylogger registrerà le password che l'utente inserisce, permettendoti di riutilizzarle da solo in seguito.

Un altro metodo di attacco che non richiede la modifica del sorgente di un programma è modificare il percorso di caricamento della libreria dinamica in modo che il programma utilizzi una chiamata di libreria che hai scritto, piuttosto che quella 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 la tua verify_password () che restituisce sempre true e carica invece quello.

La vera distinzione che cambia la risposta da "sì" a "no" è se la password non è effettivamente una password, ma una chiave di crittografia. Se i dati sono crittografati, non importa cosa fanno i programmi esterni: i dati vengono comunque crittografati finché l'algoritmo di decrittografia non riceve la chiave corretta.

Supponi di avere un'app che memorizza i dati in un file di testo (o un piccolo database), ma per accedere al file dall'app devi inserire una password o utilizzare una procedura speciale. Si potrebbe semplicemente aprire il file di testo (o db) dalla directory del file utilizzando il sistema operativo (non è richiesto il reverse engineering). Questo accadeva spesso nei vecchi programmi (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 renderli difficili da usare.

Dipende da come il software XYZ utilizza la password per produrre un'azione desiderabile e dal tipo di dati con cui lavora.

Se guardiamo l'algoritmo astratto di il programma XYZ sarebbe:

1. Chiedere all'utente di inserire la password.
2. Fare qualcosa con la password inserita dall'utente.
3. Produci un output desiderabile (o esegui un'azione desiderabile).

Quindi, la tua domanda può essere ridotta al passaggio # 3 :

È possibile produrre un output desiderabile (o eseguire un'azione) senza utilizzare il programma XYZ?

Ci sono molte varianti possibili qui, ma il punto principale è che il software XYZ esegue passaggi particolari per produrre il risultato.

Se si può creare un programma ABC che può produrre lo stesso risultato in una quantità ragionevole di volta senza richiedere una password, l ' XYZ può essere ignorato.

Ciò indicherebbe che l'intero " protezione "è implementata nel programma XYZ stesso.

Se la creazione di tale programma ABC non è possibile, la protezione si basa su un algoritmo che richiede il password indipendentemente dal programma che sta tentando di utilizzarla .

Esempio 1 : un account del sistema operativo senza privilegi non può impostare la password per un altro utente, perché è applicato dal sistema operativo. Quindi il sistema operativo in questo caso è XYZ . Ma è possibile avviare il computer da un'unità di avvio e sovrascrivere il file contenente le password, perché il sistema operativo originale non funziona in questo momento, quindi non può applicare 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 è correttamente crittografata con un potente algoritmo di crittografia. Se avviamo il computer con un disco avviabile nel tentativo di bypassare il sistema operativo originale scopriremo che non possiamo raggiungere il nostro obiettivo, perché non possiamo accedere al file contenente le password. Risiede su una partizione che deve essere prima decrittografata, ma non conosciamo la password. Un tentativo di forzare il processo di decrittazione non porterebbe il risultato desiderato in tempi brevi, quindi in questo caso non è stato possibile bypassare il programma XYZ o qualsiasi altro programma con funzionalità simili, perché il 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" che sono limitate nel tempo o nel set di funzionalità.

Ricordo un paio di articoli in una rivista di programmazione (potrebbero essere stati Computer Language ) che spiega come farlo e come contrastare i tentativi di farlo al tuo codice, rispettivamente.

So di casi in cui era letteralmente semplice come trovare l'istruzione di confronto e cambiare la condizione di salto, cioè cambiare un byte, per bypassare il controllo reale.

Questo è a volte il caso ora se l'autore semplicemente ha scritto la riga di codice come parte del programma. Ma per le chiavi di attivazione e simili è nato 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 impedirlo utilizzando tecniche comuni familiari a un codice di debug del programmatore .

Tutto dipende da come funziona il sistema durante la decodifica della 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 che modificano il sistema per costringerlo a rivelare la password.

Un modo è l'uso di MD5 insieme a "salt" per aumentare la sicurezza: questo funziona sul fatto che la password viene trasformata in un codice irriconoscibile che non può essere restituito - un esempio di base di ciò che accade è il seguente

Il sistema richiede la password - ad es. PASSWORD Il sistema aggiunge "salt" alla password, ad es. 1234 (la password ora è PASSWORD1234) Il sistema utilizza MD5 sulla password con salt - la maggior parte delle persone saprà che PASSWORD da sola genererà il codice MD5 319f4d26e3c536b5dd871bb2c52e3178 tuttavia con il sale "1234" aggiunto alla password l'MD5 ora diventa 579f276ad2a77fd1698c2038e3 - un codice completamente diverso.

A questo punto il sistema non ha ancora verificato se quella password fosse valida o meno, quindi passa questo nuovo codice ad un'altra sezione del programma che decide se il codice MD5 corrisponde a ciò che ci si aspetta se lo fa mostra il file (la password iniziale è stata a lungo scartata dalla memoria).

Affinché qualcuno possa infiltrarsi in questo tipo di password, dovrebbe ottenere la password iniziale che è stata digitata prima, e poi in seguito scopri se il programma ha consentito l'apertura del file. Su un software su un computer potrebbe essere possibile ottenere la password e quindi 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 + salt a un altro server ( per esempio attraverso 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 qualche modo, che è il modo in cui funzionano i file zip, ad esempio ho un file con il seguente testo ....

la rapida volpe marrone salta sopra il cane pigro

Gli do una password di una lettera di! ok lo 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 sopra viene archiviata come

SGD PTHBJ AQNVM ENW ITLOR NUDQ SGD K @ YX CNF

ora se qualcuno sta cercando di decriptare questo messaggio non sai se ha o meno la password corretta - se ha inserito la password # invece di! riceverebbero loro il seguente messaggio

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 inizialmente alterano la password in modo che non possa essere hackerata da qualcuno semplicemente deviando il risultato - l'unica volta che questo a volte cade è quando qualcuno crea il proprio sito Web o programma falso e induce l'utente a inserire inizialmente la propria password nel programma o nel sito Web fasullo e, naturalmente, molti siti Web ora lo stanno persino aggirando utilizzando token di autenticazione che generano password speciali valide solo per circa 5 minuti alla volta (ad esempio la chiave intelligente HSBC).

La domanda necessita di chiarimenti. La tua comprensione di come viene letto un file zip protetto da password non è corretta. Come altri hanno sottolineato, un file zip è crittografato (i dati vengono codificati) e la password è la chiave per decrittografare.

Ciò che stai descrivendo (un reindirizzamento dell'esecuzione del codice tramite il reverse engineering del flusso del codice) lo farebbe lavorare per sconfiggere il "controllo di accesso" imposto dal programma.

Quindi, alla tua domanda originale:

È possibile alterare la logica del software per eseguire il comando invece di un altro comando? Se è così, allora niente può essere protetto dal cracking?

È certamente possibile alterare la logica del software per eseguire i comandi, bypassando il controllo degli accessi per fare qualcosa che il programma potrebbe altrimenti fare, tramite reverse engineering. Tuttavia, ciò non supporta la tua seconda affermazione che "nulla può essere protetto dal cracking". Il file zip crittografato è un ottimo esempio di dove il tuo controllo sul codice non ti fornisce il contenuto del file.

In tal caso, la chiave non è un gatekeeper che ti impedisce di eseguire un percorso di codice, ma piuttosto un componente necessario 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 ecc. Che possono essere eliminati per ottenere questo risultato. I tutorial al contrario di Lena su tuts4you dovrebbero essere un buon inizio.

Il processo che potrebbe essere meglio descritto come "reverse engineering" sarebbe un Timing Attack, che implica l'analisi del tempo impiegato per verificare una password. È infatti possibile rallentare l'elaborazione di un algoritmo e contare quanti tick del processore servono per rifiutare una password. Man mano che indovini più lettere correttamente, ci vorrà più tempo per rifiutarle, così potrai essere guidato nelle tue ipotesi.

Questa non è solo una situazione ipotetica; questo attacco è stato utilizzato contro SSL e alcune versioni di Unix.