Interesante si ya vi varias noticias confirmando lo mismo, no sabía que esa cartera estaba relacionada con el silk road.

En fin, yo como lo mencione en el primer post me interese en el tema por lo "famoso" de esa cartera, lamentablemente me interese muy tarde en ese tema, ya que solo una semana después de de empezar a entender lo que hacia el bitcoin core para cifrar las llaves privadas, la cartera mencionada fue vaciada.

Prueba de concepto.

Veremos a continuación una prueba de concepto de cómo funcionaria el crackeo por fuerza bruta de forma secuencial o aleatorio, el
ejemplo esta "Arreglado" solo se  utiliza para  mostrar que el método funciona cuando el valor correcto llegue.

El código está publicó en github:

https://github.com/albertobsd/crackBTCwallet



Recalco, es muy pero muy IMPROBABLE que se encuentre por medio de algún ataque tipo Aleatorio. No es imposible, pero a no ser que cuente con un exceso de poder de computo, no se alcanzara a obtener el key utilizado en una vida completa..

Exacto me pasa un poco eso cuando veo series españolas.

Tambien me pasa y no se por que cuando busco un trailer de alguna película No se en español. tengo que especificar que sea Latino por que si no, por lo general me aparecen películas en español de españa.

Bravo por la respuesta de Machacado y tincopasan, son las mas adecuadas explicando la proporción de hispanoablantes latino americanos contra hispanohablantes españoles.

Saludos!

Tiene que ser en C++? Que api están utilizando para graficar?

Ya para este caso utilizaría un canvas HTML5, pero bueno no se cual sea tu caso.

Saludos!

La ventaja es que puedes agregar cualquiertipo de valor. Independientemente mente di es un valor ascii printable o no printable

Por recomendación de seguridad no te recomendaria descargar nada de lo cual no estes enterado como funciona.

El diagnostico lo puedes hacer directamente desde tu computadora.



Funciona? Que error exacto devuelve?


Busca tu puerta de enlace y realiza ping a esa dirección


Funciona? que error devuelve


Funciona que error devuelve?

Hay muchas pruebas mas que se pueden hacer pero si no empiezas a entender estas pruebas básicas, no podras seguir con otras

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!