Ho questo blob di dati esadecimali che possono essere trovati su link
e sto cercando di trasformarlo link
Ho lavorato molto e ho ricevuto molti consigli dalla comunità online, e lo apprezzo davvero.
Mi piacerebbe avere più feedback su come potrei gestirlo.
Questo campo è nel db come questo ... dropbox.com/s/vhlbgmwn37ro7h0/example.csv?dl=0
Sto anche cercando di apprendere il processo di ciò che consigli per poterlo gestire da solo.
I dati sono ovviamente codificati in esadecimale, eccetto per il prefisso "0x" che è comunemente usato per la codifica esadecimale.
Quindi il primo passo è convertirlo in forma binaria.
Una volta fatto questo, troviamo un blocco di dati binari, non ASCII.
00000000 ed d5 7b 4c 53 57 1c 07 f0 8b 22 c8 43 79 2b 08 |..{LSW....".Cy+.|
00000010 c2 a5 88 9a 8d 76 b4 34 08 22 70 a0 80 22 14 44 |.....v.4."p..".D|
00000020 d4 e0 a6 40 1f b7 52 ad 85 15 6a 04 dd 82 4b 44 |[email protected]|
00000030 40 33 67 04 04 c7 d0 e9 62 8c 6c 1a 81 3d 54 dc |@3g.....b.l..=T.|
00000040 2a be 48 74 1a a7 a0 6e f1 3d 42 b6 11 dd 7c 64 |*.Ht...n.=B...|d|
Quindi il prossimo passo è capire di cosa si tratta.
Poiché file data sotto Linux non lo riconosce come qualsiasi formato noto, il primo test facile è provare a comprimerlo.
I dati sono 1407 byte non compressi e 1434 byte compressi gzip. Questo divertente risultato è il segno rivelatore della crittografia, della compressione o di entrambi.
Il prossimo test è cercare di indovinare da dove provengono i dati.
È da un database, l'esagono maiuscolo mi ricorda MySQL, quindi mi chiedo "chi potrebbe averlo messo lì?" e penso che probabilmente fosse un'applicazione web che utilizza probabilmente PHP. Quindi è probabile che sia il risultato di
'0x' . bin2hex(gzcompress(...something...));
e quindi il prossimo tentativo è di usare gzuncompress() da PHP. Un'altra possibilità è che qualcuno abbia usato la funzione COMPRESS di MySQL, quindi UNCOMPRESS è un'altra strada possibile.
Sfortunatamente, entrambi i tentativi sembrano fallire:
mysql> SELECT UNCOMPRESS(UNHEX('ED...'));
e
<?php var_dump(gzuncompress(hex2bin('ED...'))); ?>
restituisce i dati obsoleti o NULL.
Ma c'è un altro server SQL che è ancora più simile - Microsoft SQL Server. Che ha, ecco una funzione "blob compresso". I blob esadecimali iniziano effettivamente con 0x proprio come fanno i nostri dati misteriosi.
Quindi questo potrebbe essere un po 'il sapore della compressione deflate eseguita da SQL Server.
Tutto ciò che resta è mettere le mani su un server SQL per testare l'ipotesi.
... ma anche questa ipotesi non riesce, poiché UNCOMPRESS(0xED...) restituisce esattamente la stessa stringa di CONVERT(varchar, 0xED...) ; vale a dire, UNCOMPRESS non può decomprimerlo e restituirlo invariato.
UPDATE : l'elaborazione sottostante si basa sul presupposto che il testo possa essere crittografato da MS SQL Server e ho fatto affidamento sul presupposto che la crittografia sia completamente opaca (ad esempio, asserzioni come "testo è indistinguibile da casuale "si applica". Questo non è il caso . Dati crittografati con MS SQL Server ha un formato riconoscibile, tre zero consecutivi agli offset 17-18-19 . I dati misteriosi non mostrano tale rivelazione.
A questo punto devo considerare l'ipotesi che la stringa non sia semplicemente compressa , in realtà è crittografata . Sfortunatamente, una buona crittografia risulterà testo non distinguibile da casuale , "casuale" significa "con massima entropia" e "compressione" ha l'effetto di aumentare la densità di entropia di un testo. In altre parole,
... appariranno tutti esattamente uguali e non c'è un modo semplice per "riconoscere" la compressione o la crittografia nel modo in cui potresti dire che {"key":"value"} è JSON o II*.... è probabilmente un flusso TIFF.
Se il testo è crittografato, è probabile che sia stato crittografato utilizzando una delle funzioni standard di MS SQL , il che significa che non esiste un modo semplice per recuperare i dati originali, a meno che tu non conosca o acquisisca la chiave.
Il programma che hai fornito nel commento non può funzionare così com'è, perché stai usando due stringhe esadecimali e PyCrypto richiede stringhe binarie. Se si importa il modulo binascii, dovrebbe funzionare:
from Crypto.Cipher import AES
import binascii
import gzip, zlib
iv = binascii.unhexlify('631a5c0147c15d2e3053264131a211dd')
pp = binascii.unhexlify('6dd247cb95d269b7d7393e67d6fee570')
msg = binascii.unhexlify('00EDD57B4C(...omitted...)FE06')
obj = AES.new(pp, AES.MODE_CBC, iv)
txt = obj.decrypt(msg)
print txt
Qui, pp è la passphrase e iv è il vettore iniziale. Non funziona perché, prima di tutto, la stringa esadecimale deve essere un multiplo di 16 byte, ovvero 32 caratteri esadecimali. Non è; mancano due caratteri esadecimali. Ho provato ad aggiungere 00 alla fine e all'inizio.
Quindi, l'esempio che hai fornito ha gli stessi valori di pp e iv, il che è strano. Prima hai citato due diverse stringhe esadecimali, quindi ho provato entrambe, in entrambi i casi; ancora nessuna gioia.
I dati risultanti non erano né in chiaro, né potevano essere decompressi con zlib o gzip.
Credo che dovrai raccogliere ulteriori informazioni sul problema. Per esempio: da dove viene questo script Python? Tenta una decrittazione AES, che sembra una buona strada di indagine.
Leggi altre domande sui tag encryption encoding