Desvelado el bug del trucha

clinisbut escribió:2.- Si realmente se esta usando una función de cadenas para tratar datos binarios, y sabemos que la función no trabaja correctamente en cuanto se encuentra un 0x00... que ocurre con aquellas firmas legales que contengan un 0x00 en alguno de sus bytes? Se aceptan sin llegar a comprobarse del todo tal como pasa con el trucha.

Exacto.

Waninkoko escribió:El TMD es el title metadata que contiene informacion sobre el juego.

http://wiibrew.org/index.php?title=Tmd_file_structure

Aqui te viene los diferentes campos que tiene el TMD.

La firma (u8 sig[256]) contiene un codigo hash SHA1 encriptado (el mismo hash del que voy a hablar un poco mas abajo) con la clave privada de Nintendo.

El hash del que yo hablo es aquel que se obtiene aplicando el algoritmo SHA1 desde el byte donde comienza el campo "issuer" hasta el final del TMD.

Si el hash sacado de la firma y el que calculamos sobre esos datos del TMD empiezan por 0x00, adios al chequeo de la Wii

Por cierto, he podido probar a ejecutar un juego con el IOS37 y me da un error

Waninkoko escribió:El TMD es el title metadata que contiene informacion sobre el juego.

http://wiibrew.org/index.php?title=Tmd_file_structure

Aqui te viene los diferentes campos que tiene el TMD.

La firma (u8 sig[256]) contiene un codigo hash SHA1 encriptado (el mismo hash del que voy a hablar un poco mas abajo) con la clave privada de Nintendo.

El hash del que yo hablo es aquel que se obtiene aplicando el algoritmo SHA1 desde el byte donde comienza el campo "issuer" hasta el final del TMD.

Si el hash sacado de la firma y el que calculamos sobre esos datos del TMD empiezan por 0x00, adios al chequeo de la Wii smile_XD

Por cierto, he podido probar a ejecutar un juego con el IOS37 y me da un error smile_XD

iacaca escribió:El método que utilizan los IOS antes del 37 para comparar las firmas se "detiene" cuando en la firma se encuentra un byte NULL, aunque la firma continue. De esta forma se puede firmar el disco con una firma muy corta rápidamente calculada. Por ejemplo, si en la firma pones un NULL en el quinto carácter, simplemente tienes que calcular 4 bytes válidos de la firma, y eso un PC actual lo calcula en nada (eso se comprueba en la rapidez con la que firma el Trucha Signer smile_:Ð )

Con vuestros mensajes se me ha venido una idea a la cabeza para conseguir un hash firmado original, pero una pregunta sino seria imposible. Si un TMD devuelve un hash que no tiene ningun NULL y el hash firmado (u8 sig[256]) lo pones todo a null lo da por valido o no??? si no lo da por valido mi idea se va al garete, sino a lo mejor sirve de algo.

Salu2

merol escribió:Con vuestros mensajes se me ha venido una idea a la cabeza para conseguir un hash firmado original, pero una pregunta sino seria imposible. Si un TMD devuelve un hash que no tiene ningun NULL y el hash firmado (u8 sig[256]) lo pones todo a null lo da por valido o no??? si no lo da por valido mi idea se va al garete, sino a lo mejor sirve de algo.

Salu2

No lo da por valido. Con el nuevo IOS no servira, y con los IOS actuales tampoco.

Hay una cosa que no me termina de quedar clara en la explicación del bug que hay en wiibrew... No sé si se me escapa algo, creo que no, y que los de wiibrew no han explicado completamente el bug...
El fallo viene en la utilización de strncmp y que una de las cadenas contenga el caracter terminador antes de tiempo. Esto provocará que la función parará la comprobación...con lo que vamos a poner este caracter en el quinto byte, que calcular los cuatro primeros es algo rápido...

Lo que no me termina de quedar claro, es que asumen, por lo que veo en el seudocódigo este que muestran que strncmp devolverá cero...ya que los cuatro primeros bytes son iguales. Pero al ser el quinto el caracter terminador en una y en la otra la cadena no terminar todavía, la función no va a devolver 0 sino que devolverá -1 o 1.

Por lo que el bug no me termina de quedar muy claro, salvo que la implementación que haya sea tan tremendamente mala que cuando encuentra el fin de cadena devuelva 0 directamente, sin comprobar que las cadenas tuviesen la misma longitud...no me puedo creer que sea así, vamos.

keridito escribió:Hay una cosa que no me termina de quedar clara en la explicación del bug que hay en wiibrew... No sé si se me escapa algo, creo que no, y que los de wiibrew no han explicado completamente el bug...
El fallo viene en la utilización de strncmp y que una de las cadenas contenga el caracter terminador antes de tiempo. Esto provocará que la función parará la comprobación...con lo que vamos a poner este caracter en el quinto byte, que calcular los cuatro primeros es algo rápido...

Lo que no me termina de quedar claro, es que asumen, por lo que veo en el seudocódigo este que muestran que strncmp devolverá cero...ya que los cuatro primeros bytes son iguales. Pero al ser el quinto el caracter terminador en una y en la otra la cadena no terminar todavía, la función no va a devolver 0 sino que devolverá -1 o 1.

Por lo que el bug no me termina de quedar muy claro, salvo que la implementación que haya sea tan tremendamente mala que cuando encuentra el fin de cadena devuelva 0 directamente, sin comprobar que las cadenas tuviesen la misma longitud...no me puedo creer que sea así, vamos.

Ambas cadenas deben de tener el caracter 0x00 en la misma posicion y los caracteres anteriores deben de ser iguales.

Si una cadena termina y la otra no, strncmp no devuelve 0.

Waninkoko escribió:
No lo da por valido. Con el nuevo IOS no servira, y con los IOS actuales tampoco.

Entonces mi idea no es viable...

Bueno salu2 espero que ahora que se conoce mucho mas la wii, se pueda sacar algo a prueba de actualizaciones.

Salu2

Waninkoko escribió:Os voy a contar mi metodo

La Wii desencripta un hash SHA1 contenido en la firma y calcula otro hash SHA1 desde el campo "issuer" del TMD hasta el final del TMD.

Si ambos hashes coinciden, el disco esta bien firmado.
El caso es conseguir que ambos hashes comienzen por 0x00

El método mas sencillo es cambiar los 256 bytes de la firma por ceros, y modificar el campo "reserved" del TMD hasta que el hash SHA1 que se hace sobre el TMD comience por 0x00.

Bueno, como programador y "aficionado" a los formatos de archivo (principalmente los del Guitar Hero ) me gustaría probar esto.

He estado mirando un tmd.bin del Guitar Hero "trucheado" y es como dices tu, el SHA1 desde "issuer" hasta el fin comienza por 0x00.

El tema es la firma. Según tu está cifrada y contiene un SHA1. No entiendo muy bien como funciona el tema, alguien podria explicármelo o dar algun link? (También veo que el trucha pone unas cuantas tonterias allí, pero me imagino que es la primera parte lo que importa)

Lo primero es la encriptación. Que algoritmo y key se usa?
Lo segundo que no me cuadra es que un hash SHA1 es más corto que la firma (cosa bastante evidente). Como va el tema? Supongo que la firma debe ser una estructura o algo...

Y por ultimo, esto que dices tu de "ponerlo todo a cero" significa que funciona con los 256 bytes directamente a cero ya está?

No acabo de entender cómo funciona pero segun he entendido, lo que intentamos buscar es un código que sea el mismo que el que tiene la Wii escondido? Y lo tenemos que hacer probándolos todos?

Y si fuese así, cuando tengamos dicha cadena, qué podríamos llegar a conseguir? Todo?

Gracias

Lo importante aqui, es que como ya dijerón, este bug esta también en el boot1 de todas las wii actuales, y no se puede modificar el boot1 por mucho parcheo del firmware que hagan.