Como crackear una cartera bitcoin. (Teoria y practica).

Bueno esta investigación comenzó a manera de broma y solo por hobby. En las platicas que tenemos en la comunidad de elhacker.net en Telegram ( https://t.me/elhackerdotnet )

Se menciono hace tiempo la existencia de una  cartera de bitcoin con 69 Mil BTC, al tipo de cambio actual hoy 4 de Noviembre de 2020 serian unos 995 millones de dólares, entre bromas se menciono que teníamos que crackearla con algún computador cuántico.

En fin, el proceso "normal" para abrir una cartera cifrada utilizando las aplicaciones oficiales de Bitcoin-Core es el siguiente.

Primero cargamos la cartera


"wallet.dat" es un archivo que debe de existir en el directorio ~/.bitcoin/wallets/

Se puede llamar de otro modo, el punto es que debe de exisitir en ese path

Segundo desbloqueamos la cartera con nuestra passphrase o mas comúnmente contraseña


Entre comillas tenemos nuestro password y el 60 a continuación indica que desbloqueamos la cartera por 60segundos

Si el password es correcto no marcara error, de lo contrario lo indicará.


Ahora la forma lenta e ineficiente de intentar crackearla por fuerza fruta probando directamente distintos passphrase desde la misma terminal.
Sigue siendo lento incluso aunque se utilice algún script bash por que pasar del bash al programa y de regreso es ineficiente.

Necesitamos saber que hace internamente la aplicación, para tratar de reproducirlo en un programa en C y ejecutarlo por aparte posiblemente con multihilo para mejorar la eficiencia

¿Que hace el bitcoin core con nuestro passphrase?

Nuestro passphrase es combinado con un salt que se encuentra almacenado en el archivo, mediante un algoritmo estilo PBKDF y con mas de 25000 iteraciones generan un hash sha512.

De estos 64 bytes generados mediante PBKDF, se utilizan los primeros 32 bytes como KEY para inicializar el contexto de AES y los siguientes 16 bytes como IV para el algoritmo CBC

A este algoritmo AES256CBC se le pasa como parámetro para descifrar el mKey (master KEY) cifrado y se obtiene un mKey Descifrado

El master key ya descifrado se le hacen varias pruebas, se utiliza este valor como KEY para otros descifrados y en este caso como IV en todas las pruebas se utilizan 16 bytes del public Key de la cartera bitcoin obtenidos por una función interna llamada GetHash que desconozco que valores devuelva exactamente, solamente me limite a llamarla.

Y si el master key ya descifrado pasa todas las pruebas se almacena en memoria para sea utilizado en el futuro.

Fin de la triste Historia.  

Resumen en pseudo codigo

El siguiente codigo en Pseudo C esta solo para representare que hace la aplicación internamente.

prekey = PBKDF(passphrase,IV, N Iteraciones,"sha512");
memcpy(KEY,prekey,32);
memcpy(IV,prekey+32,16);
aesctx = AES256_init(KEY);
if( AES256CBC_decrypt(aesctx,IV,ENC_mKey,DEC_mKEY) > 0)	{
	foreach(OthersENC as oENC)	{
		oCtx = AES256_init(DEC_mKEY);
		if(!AES256CBC_decrypt(oCtx,IV_fromPublickey,oENC,dummy) > 0)	{
			return false;
		}
	}
	return true;
}

Entonces si nuestro plan es un ataque por fuerza bruta podemos saltarnos el PBKDF que se ejecuta N Iteraciones (Mínimo 25000) y saltar directamente al Decrypt de AES.

Tenemos 2 opciones:

1.- Generar un par (KEY,IV) 48 bytes random o secuencial y empezar con el primer AES256CBC_decrypt y utilizar el valor generado para continuar con los AES256CBC_decrypt dentro del for.

2.- O generar solamente un KEY de 32 bytes random o secuencial y pasar directamente a los AES256CBC_decrypt dentro del For.

Asi con 32 bytes solo tenemos 1 de 115792089237316195423570985008687907853269984665640564039457584007913129639936 posibilidades de dar con la KEY correcto.
xD xD xD

Resultados vistos en la práctica.

Con la opción 1 solamente el 0.4% de los valores aleatorios generados pasaban el primer AES256CBC_decrypt posteriormente solo el 0.4% de esos valores pasaban el primer AES256CBC_decrypt dentro del FOR

Para la cartera que cree con el propósito de realizar las pruebas los challenge dentro del FOR eran sobre 500.

Sin embargo para la cartera lackeada con 69K BTC solo está disponible un solo challenge dentro del FOR, al ser solo dos AES256CBC_decrypt me dio bastantes KEY "Falsos positivos" aproximadamente uno de cada millón de valores random generados (KEY,IV) pasaban ambas pruebas

En conclusión

La aproximación por Fuerza Bruta a AES256CBC es improbable que funcione ojo, improbable no imposible, Tal vez en el futuro con mejor poder de computo disponible, o tal vez con Múltiples equipos trabajando de forma sincronizada con alguna RED tipo BOINC o algún tipo de BOTNET

Tengo el código utilizado para realizar este proceso, un poco de manera hardcodeada Ya que los Valores cifrados los saque directamente mediante Hexedit, si alguien esta interesado en la estructura del archivo no dude en comentarlo.

Saludos

Posdata
La cartera de 69K BTC fue vaciada por alguien el dia de ayer. 3 de Noviembre a las 3PM
https://twitter.com/albertobsd/status/1323752623510446080
https://decrypt.co/es/47133/wallet-de-bitcoin-con-955-millones-famosa-entre-hackers-se-acaba-de-vaciar?amp=1

Gracias Kub0x, tema clarificado. Me quedo con la reflexion y me pongo a leer los links que agregaste.

Saludos!

Anteriormente no me había fijado la salida del descifrado por AES 256 CBC con Pad habilitado.

Normalmente uno solo espera la data original descifrada, vamos que si ciframos la palabra "hola" esperamos de vuelta la misma palabra "hola" ya descifrada.

Cuando encriptas sin padding cada bloque del tamaño  "AES_BLOCKSIZE" devuelve la misma cantidad de bloques. Pero el cifrar con Padding agrega cierta cantidad mas de datos.

Por ejemplo si ciframos 32 bytes con AES256CBC con Padding nos devuelve un buffer con 48 bytes de data

Y cuando desciframos esos 48 bytes, nos devuelve la data original de 32 bytes + un buffer "sucio" es decir que hay mas datos en el buffer, en mi caso he comprobado que para este ejemplo siempre devuelve un buffer sucio de 16 bytes y cada uno de esos bytes tiene valor de uno.

Mi pregunta es ¿Es normal esto, o solo es la forma en la que trabaja la librería ctaes?

hice un programa que muestra que independientemente del key y del IV utilizados  siempre pasa lo mismo




De ser normal esto se podría tomar ese buffer sucio como una comprobación de que la key y el iv utilizados son los correctos?


Saludos

Ya vi la pagina y si muchas de esas cosas son posibles, si y sólo si configuras el router de esa manera.

Sencillamente no lo hagas y listo, he visto la configuracion de mi modem y todo eso esta deshabilitado.

Saludos

Acabo de buscar, pense que se podia definir utilizando el segundo parámetro de json_encode pero no, no esta la opcion de forzar el uso de comillas sencillas.

Y a todo esto, ¿hay alguna diferencia para javascript?


Podrias tratar de realizar la sustitución manualmente, sin embargo dependiendo del contenido puede darte problemas al momento de escapar las " que realmente estén en las variables.

$array = array('A', 'B', 'C', 'D');
echo  str_replace('"',"'",json_encode($array));
 

Saludos!

La primera opciones tienes que pasar por el proceso completo es decir generar un passphrase random de N cantidad de bytes que buen puede ser 1 byte o bien puede ser 1GB, posteriormente pasarlos por el PBKDF sha512 con un mínimo de 25000 iteraciones.

Yo se que la gente no mete passphrase de 1GB de longitud y también están limitadas por los caracteres fácilmente  localizables por el teclado sin embargo las mínimo 25K iteraciones del sha512 hacen el proceso un poco mas ineficientes para el crackeo desde el momento que cada passphrase random tiene que pasar por ese proceso.

La segunda opciones que mencionas es la que voy implementar ya que solo tienes que generar el KEY y el IV de forma aleatoria y pasalos a la función  AES256CBCDecrypt saltándose el costoso proceso de PBKDF.

Además esta opción esta claramente limitada por el tamaño de la dupla Key,IV y en la primera opción no voy a estar seguro si probe todas las combinaciones posibles en el passphrase además que un passphrase de mas 46 dígitos ya es mas costoso por que incluyen más posibilidades y el proceso del PBKDF.


Si claro que se que es improbable, pero al final mi objetivo será encontrar el camino más eficiente para hacerlo, independientemente de su probabilidad.

Saludos!

Si y no,  Si se puede hacer multihilo (multi thread) pero estás limitado por la cantidad de Cores/threads que tenga el CPU, ahorita muchos no pasan de 4 Cores / 8 Threads o 8 Cores / 16 Threads.

Esto sin considerar el restarle el proceso del sistema operativo que no es poco generalmente te va a quitar como mínimo 1 Core y 2 threads.

Puedo hacerlo Multihilo SI, de hecho es lo que tengo pensado hacer. Pero no he podido empezar ya que de la información que tengo no se cual es Key, cual es Salt y cual es numero de Derivaciones, esto solo para hacer algunas pruebas con una cartera que si tengo la contraseña, si funciona para esta cartera debería de funcionar para la cartera que realmente quiero crackear.

Por cierto si quieres potencia olvida te python Lo que esta escrito en C o C++ si funcionara bien, pero todo lo que entre en algun script de python se verá afectado y/o consumirá más memoria de la necesaria

Saludos!

---

Solucionado el master key cifrado son 48 bytes que se encuentran a un offset de -72 bytes de la primera coincidencia de mkey.

Saludos

Interesante esa parte de la historia no me la sabia, puedes desarrollar un poco mas tu punto?

Muchas veces los drivers para linux están implementados de manera genérica y las opciones son limitadas, probablemente no se pueda hacer.

Realmente nunca he tenido la oportunidad de revisar ese sistema sin embargo en otros linux me pasa lo mismo, di por hecho que era cosa de Linux.

Se que es casi improbable y muy costoso en tiempo y poder de computo pero para nada es imposible

Lo hago por hobby y simplemente por saber un poco más del tema, no lo voy a olvidar, es una lotería de mil millones de dolares asi que si existe la posibilidad de hacerlo no pierdo nada con intentarlo.

Saludos!