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!

Extraer la llave cifrada para posteriormente intentar descifrarlo. Vamos básicamente crackear el password por fuerza bruta.

Publico este tema aquí, ya que no se en qué sección queda mejor publicarlo.

Estoy intentando extraer la información Cifrada de una cartera bitcoin, en específico la información del Key para posteriormente intentar descifrarlo por algún ataque de fuerza bruta.

Quiero extraerla por que no quiero depender del bitcoin core ya que si se realiza el ataque por fuerza bruta mediante algún script bash o algun otro metodo NO compilado, el ataque puede ser realmente ineficiente.

También quiero brincarme algunos pasos innecesarios de funciones tipo rehash o PBKDF2 (key derivation) ya que aunque no consumen mucho CPU si quitan algunos miles de ciclos de procesamiento que a la larga pueden hacer aun mas eterno el proceso de crackeo.

Segun he leido la informacion del Key cifrado el salt y el numero de iteraciones esta contenida en un campo de 64 bytes del wallet.dat llamado mkey.

Segun vi en el siguiente Link:


La data contiene los siguientes campos:

mkey, nID, encrypted_key, salt, derivation_method, derivation_rounds, other_derivation_parameters

mkey es solo el ascii "mkey", se que el encrypted_key debe de ser de 32 bytes y el salt de 16, restando solo 12 bytes para los otros datos, sin embargo no estoy seguro del orden de los mismos.

Si vemos la siguiente imagen:





Vemos que ahí esta la data, escribí un pequeño programa que la encuentra y la extrae, pero no se en que orden este, con ver los datos de esta cartera y otras me doy cuenta de algunos datos que pueden ser números como los primeros 8 bytes después del mkey, pueden ser números, al igual que los últimos 4 antes de ckey.

---

Edit

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

Para esta cartera en cuestión el Master Key Cifrado es:

CEC646179A7F947349A0AA99EC7122B01F72BF18FFA4FDC760635D8C13109DA196D3DC802D5AABB23FA6C6AABA9A1DBB

Saludos

Recientemente publique el tema:Como determina la función AES256CBCDecrypt una correcta desencriptación El cual esta relacionado con este de forma algo indirecta.

Todo esto viene del análisis que estoy realizando al código fuente del Bitcoin Core.

Hoy hablaré sobre la función BytesToKeySHA512AES la cual es una de las primeras que se utilizan cuando intentas desbloquear una cartera bitcoin protegida con un passphrase.

BytesToKeySHA512AES básicamente toma las passphrase ingresada + un salt proporcionado por el mismo archivo wallet.dat y los transforma en un (key, iv) para posteriormente utilizarlos como material para descifrar la llave cifrada.

El código fuente de BytesToKeySHA512AES, lo pueden encontrar en

 

Tiene 3 parámetros de entrada y 2 de salida
Entrada:
Salt
Passphrase
Count

Salida:
Key
IV

La parte interesante del código es la siguiente:

    for(int i = 0; i != count - 1; i++)
        di.Reset().Write(buf, sizeof(buf)).Finalize(buf);

Básicamente obtiene el hash sha512 de si mismo (count -1) veces ya la que primera vez fue el hash sha512 de (passphrase + IV) como muestra el siguiente código:

    di.Write((const unsigned char*)strKeyData.data(), strKeyData.size());
    di.Write(chSalt.data(), chSalt.size());
    di.Finalize(buf);

Posteriormente copia los primeros 32 bytes al Key y los siguientes 16 bytes al Vector IV

Si no están familiarizados con la sintaxis  del codigo anterior dejare un código en PHP ejemplificando lo que hace la función:

<?php
$salt = "BBBBBBBBBBBBBBBB";
$passphrase = "AAAAA";
$key_ ="";
$iv_ = "";
BytesToKeySHA512AES($salt ,$passphrase,2,$key_, $iv_ );
 
echo "Key:\n";
var_dump($key_);
echo "IV:\n";
var_dump($iv_);
 
function BytesToKeySHA512AES($chSalt,$strKeyData,$count,&$key,&$iv)	{
	$ctx = hash_init('sha512');
	hash_update($ctx,$strKeyData);
	hash_update($ctx,$chSalt);
	$buf = hash_final($ctx,true);
	$i = 0;
	while($i != $count -1)	{
 
		/* //Estas tres líneas básicamente se transforman en una simple llamada a hash
		$ctx = hash_init('sha512');
		hash_update($ctx,$buf);
		$buf = hash_final($ctx,true);
		*/
		$buf = hash('sha512',$buf,true);
		$i++;
	}
	echo "hash:\n";
	var_dump($buf);
	$key = mb_substr($buf,0,32);
	$iv = mb_substr($buf,32,16);
}
?>

Lo escribí en PHP ya que es mas fácil darle seguimiento a las funciones hash, solo que no estoy 100% seguro de como manejar las copia de los bytes del hash resultante al key y al IV respectivamente.

Saludos

Un vector es como un arreglo fijo, pero tienen muchas diferencias si lees un poco sobre los mismos encontraras que


Sigue probando mas index a ver hasta donde llega, tiene que marcar segment fault en algun punto.

Saludos!

Muy buena dia, estoy con una pequeña duda ya que estoy tratando de automatizar un proceso de crackeo por fuerza bruta de una key de 256 bits (Se que es improbable, sin embargo la clave esta ahi del 0 al 2^256)  

La función original recibe 2 parametros un un KeyCifrada, y el candidato a Key como segundo parametro:

Decrypt(KeyCifrada,KeyCandidato);

Dicha función realiza un llamado internamente a AES256CBCDecrypt



y si nLen es igual a 0 entonces retorna false indicando que Key Candidato no es un Key valido.

Mi duda es la siguiente como determina internamente AES256CBCDecrypt  que la KeyCandidato es valida.

Saludos

---

Edit
Platicando con Kub0x me corrigio el KeyCandidato no es parámetro de entrada si no de salida

Si vemos el link

en la linea 112 hay se muestra que las comprobaciones las hace directamente sobre el texto descifrado y si alguna de ellas no pasa simplemente regresa 0.

Me comenta kub0x que  existen varios valores Key y IV de entrada que podrian dar una salida valida, siendo esto un falso positivo, sin embargo me gustaría investigar cuantas veces pasa eso en realidad.

Saludos

---

Edit 2
Tal como menciono Kub0x, el proceso arroja muchos falsos positivos.

Programe un programa multihilo para crackear un key


Con solo 4 Hilos y solo probando 1554 hashes random me dio 4 resultados que la función AES256CBCDecrypt considera válidos, pense que serian mucho menos el ratio de falsos positivos, pero asi no me da tiempo de probarlos manualmente, tendrás que optimizar ese proceso también.