Ho sentito parlare di strumenti che potrebbero essere usati per rappresentare graficamente l'entropia di un file. C'è un programma grafico Linux che potrei usare per questo lavoro che mi consenta di esplorare con facilità quali blocchi di un file hanno determinati pattern di entropia che potrebbero suggerire dati compressi o crittografati?
Non esiste una cosa come "entropia" di un file. entropy è una caratteristica di un processo - ad esempio, di un processo che genera un file. L'entropia non descrive quali sono i contenuti del file; descrive ciò che il contenuto del file avrebbe potuto essere . In quanto tale, qualsiasi strumento che pretenda di identificare "schemi di entropia" è, nel migliore dei casi, in grado di perdere una terminologia estremamente scadente.
Detto questo, si può ancora fare qualche euristica. Accade così che la maggior parte dei "dati di vita reale" mostrino molta ridondanza nella sua struttura; questa è la compressione dei dati . Quindi puoi lavorare sulla seguente ipotesi: i dati che possono essere compressi da un importo non banale sono i dati non che sono già stati compressi o crittografati. Infatti:
Gli algoritmi di compressione si sforzano di identificare e rimuovere le ridondanze. Il risultato non dovrebbe essere suscettibile di ulteriore compressione; altrimenti, questo significa che l'algoritmo di compressione fa un lavoro scarso.
I dati crittografati dovrebbero essere indistinguibili dalla casualità (se l'algoritmo di crittografia è valido); quindi, ha una probabilità estremamente bassa di essere comprimibile.
Quindi puoi estrarre i blocchi dal tuo file e comprimerli (ad es. con gzip ), per vedere se possono essere sostanzialmente ridotti. Ad esempio, questo comando estrae un chunk di 2000 byte dal file data.bin (all'offset 15000), lo comprime e riporta la lunghezza risultante:
dd if=data.bin bs=1 skip=15000 count=2000 2>/dev/null | gzip | wc -c
Se il valore risultante è sostanzialmente inferiore a 2000, il chunk, molto probabilmente, contiene dati che non sono crittografati o già compressi. Ad esempio, se utilizzo come file di dati il file /usr/bin/gcc-4.8 (un eseguibile pieno di codice, ma non compresso) dal mio laptop Linux, ottengo una lunghezza di output di 1491 byte per quel chunk, che è effettivamente molto più piccolo del 2000. Se provo su /dev/urandom , ottengo 2023 byte.
(Queste figure vengono stampate sul mio schermo come sequenze di personaggi, che elaborano con i miei occhi e il mio cervello. Questo, a mio avviso, si qualifica come "grafico".)
L'esecuzione del comando in un ciclo che estrae vari blocchi di file e li comprime viene lasciato come esercizio al lettore (non è difficile, e se non puoi farlo, è probabile che non sarai in grado di fare molto con i file comunque, l'elaborazione dei dati richiede alcune abilità di programmazione.
Caveat: gzip , come la maggior parte dei compressori per uso generico, funziona su base byte, e cerca di trovare ripetizioni di pattern e bias nell'uso dei valori di byte. Questo è noto per funzionare male su dati analogici che sono stati digitalizzati, ad es. campioni audio. Il rapporto di compressione offerto da gzip su file WAV è quindi spesso scarso, mentre il file WAV è ancora "non compresso" ( questa pagina dichiara di aver misurato una lunghezza compressa di circa il 92% dell'originale, sebbene dipenda dalle caratteristiche del file WAV).
Quindi non immaginatevi che il test "compresso da gzip" sia il metodo di rilevamento definitivo per dati compressi / crittografati. Tuttavia, questo può dare buoni risultati, a patto che i blocchi compressi / criptati che stai cercando di localizzare siano abbastanza lunghi (in questo modo non troverai pezzi di 50 byte).
Leggi altre domande sui tag linux encryption