Tengo este blob de datos hexadecimales que se pueden encontrar en enlace
y estoy buscando convertirlo en enlace
He trabajado mucho y he recibido muchos consejos de la comunidad en línea, y realmente lo aprecio.
Me ENCANTARÍA más comentarios sobre cómo podría manejar esto.
Este campo está en la db como esta ... dropbox.com/s/vhlbgmwn37ro7h0/example.csv?dl=0
También estoy tratando de aprender el proceso de lo que me aconsejas para poder manejarlo por mi cuenta.
Los datos obviamente están codificados en hexadecimal, excepto por el prefijo "0x" que se usa comúnmente para codificar hexadecimal.
El primer paso es convertirlo en formato binario.
Una vez hecho esto, encontramos un bloque de datos binarios, no 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|
Por lo tanto, la siguiente etapa es entender qué es.
Dado que file data en Linux no lo reconoce como ningún formato conocido, la primera prueba fácil es intentar comprimirlo.
Los datos son 1407 bytes sin comprimir y 1434 bytes comprimidos con gzip. Este resultado divertido es el signo revelador de cualquiera de los cifrados, la compresión o ambos.
La siguiente prueba es probar y adivinar de dónde provienen los datos.
Es de una base de datos, el hex de mayúsculas me recuerda a MySQL, así que me pregunto "¿quién podría haberlo puesto allí?" y creo que es probable que fuera una aplicación web usando probablemente PHP. Así que lo más probable es que sea el resultado de
'0x' . bin2hex(gzcompress(...something...));
y, por lo tanto, el siguiente intento es usar gzuncompress() de PHP. Otra posibilidad es que alguien haya usado la función COMPRESS de MySQL, por lo que UNCOMPRESS es otra posible vía.
Lamentablemente, ambos intentos parecen fallar:
mysql> SELECT UNCOMPRESS(UNHEX('ED...'));
y
<?php var_dump(gzuncompress(hex2bin('ED...'))); ?>
devuelve basura o NULL.
Pero hay otro servidor SQL que es una coincidencia aún más cercana: Microsoft SQL Server. Que tiene, he aquí, una función de "blob comprimido". Las manchas hexadecimales en realidad comienzan con 0x tal como lo hacen nuestros datos misteriosos.
Por lo tanto, esto podría ser una muestra de la compresión deflate ejecutada por SQL Server.
Todo lo que queda es poner mis manos en un servidor SQL para probar la hipótesis.
... pero esta hipótesis también falla, ya que UNCOMPRESS(0xED...) devuelve exactamente la misma cadena que CONVERT(varchar, 0xED...) ; es decir, UNCOMPRESS no puede descomprimirlo y lo devuelve sin cambios.
ACTUALIZACIÓN : el procesamiento a continuación se basa en la suposición de que MS SQL Server puede cifrar el texto, y me basé en la suposición de que el cifrado es completamente opaco (es decir, afirmaciones tales como "texto es indistinguible de al azar "se aplica). Este no es el caso . Los datos cifrados de MS SQL Server tienen un formato reconocible, tres ceros consecutivos en las compensaciones 17-18-19 . Los datos misteriosos no muestran tal indicador.
En este punto, tengo que considerar la hipótesis de que la cadena no está simplemente comprimida , en realidad está cifrada . Desafortunadamente, un buen cifrado resultará en texto no distinguible de aleatorio , "apariencia aleatoria" significa "con máxima entropía" y "compresión" tiene el efecto de aumentar la densidad de entropía de un texto. En otras palabras,
... todos se verán exactamente igual , y no hay una manera fácil de "reconocer" la compresión o el cifrado de la forma en que podrías decir que {"key":"value"} es JSON, o II*.... es probable que sea un flujo TIFF.
Si el texto está cifrado, es probable que se haya cifrado utilizando una de las funciones estándar de MS SQL , lo que significa que no hay una manera fácil de recuperar los datos originales a menos que conozca o adquiera la clave.
El programa que proporcionaste en el comentario no puede funcionar como está, porque estás usando dos cadenas hexadecimales y PyCrypto requiere cadenas binarias. Si importa el módulo binascii, debería funcionar:
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
Aquí, pp es la frase de contraseña y iv es el vector inicial. No funciona porque, en primer lugar, la cadena hex debe ser un múltiplo de 16 bytes, es decir, 32 caracteres hexadecimales. No lo es; Parece que faltan dos caracteres hexadecimales. Intenté agregar 00 al final y al principio.
Luego, el ejemplo que proporcionaste tiene los mismos valores de pp e iv, lo cual es extraño. Usted mencionó dos cadenas hexadecimales diferentes antes, así que probé las dos, en cualquier orden; Todavía no hay alegría.
Los datos resultantes no eran texto sin formato, ni podían descomprimirse con zlib o gzip.
Creo que tendrás que reunir más información sobre el problema. Por ejemplo: ¿de dónde vino ese script de Python? Intenta un descifrado AES, que parece ser una buena vía de investigación.
Lea otras preguntas en las etiquetas encryption encoding