Desvelado el bug del trucha

xt5 escribió:http://debugmo.de/?p=61

edit



no es que pueda estar en cualquiera de las dos, DEBE estar en las dos cadenas y en la misma posicion.

GameZelda se refiere al codigo de la implementacion de strcmp y tu te refieres a la llamada que hicieron en nintendo.

De todas formas si se hubiera comprobado correctamente el valor de entrada en strcmp no hubiera dado un resultado erroneo.

strcmp("gatete",NULL);

Debería devolver un entero mayor que 0 ,"gatete" es mayor que ,por lo que no serian considerados iguales.

Igual se trata de un error en la iniciacion de una variable de resultado

Edit:
Acabo de probar un c un simple código:
#include
int main(){

printf("resultao: d%", strcmp("gatete",NULL));

return 0;
}

Y recibo un segfault,no sabía que era responsabilidad del programador comprobar que no se le pasara un null como argumento.

Es más la manpage de mi maquina no dice nada de "Bytes following a null byte are not compared." que si se menciona en otros sitios que he leido.

Ni en la referencia de the Open group ni en el manual de la glibc se menciona nada.


¿Y esto por que es asi por ahorrarse una comparación?

wah_wah_69 escribió:Es más la manpage de mi maquina no dice nada de "Bytes following a null byte are not compared." que si se menciona en otros sitios que he leido.

Ni en la referencia de the Open group ni en el manual de la glibc se menciona nada.

Basicamente el NULL o 0x00 en una cadena indica el fin de cadena, por lo tanto, en una funcion de comparacion de cadenas, es normal que se pare en cuanto se encuentre un NULL.

Prueba:

Código: Seleccionar todo

[font=verdana, arial][size=90] #include <stdio.h>
int main(){

printf("resultao: %d", strcmp("gate\0te","gate\0miabuela"));

return 0;
}[/size][/font]

Deberia imprimir "" (iguales)

Saludos.

EDIT: Como comparacion de metodos:

Código: Seleccionar todo

#include <stdio.h>
int main(){
char *cadena1 = "gate\0te";
char *cadena2 = "gate\0la";
printf("resultao strcmp: %d
", strcmp(cadena1, cadena2));
printf("resultao memcmp: %d
", memcmp(cadena1, cadena2, 7));
system("PAUSE");
return 0;
}


Deberia imprimir:
resultao strcmp: 0
resultao memcmp: 1

La unica diferencia sustancial (en cuanto a prog con libc), es que con memcmp se debe indicar el tamaño de bytes a comparar.

wah_wah_69 escribió:
GameZelda se refiere al codigo de la implementacion de strcmp y tu te refieres a la llamada que hicieron en nintendo.

De todas formas si se hubiera comprobado correctamente el valor de entrada en strcmp no hubiera dado un resultado erroneo.

strcmp("gatete",NULL);

Debería devolver un entero mayor que 0 ,"gatete" es mayor que ,por lo que no serian considerados iguales.

Igual se trata de un error en la iniciacion de una variable de resultado

Edit:
Acabo de probar un c un simple código:
#include
int main(){

printf("resultao: d%", strcmp("gatete",NULL));

return 0;
}

Y recibo un segfault,no sabía que era responsabilidad del programador comprobar que no se le pasara un null como argumento.

Es más la manpage de mi maquina no dice nada de "Bytes following a null byte are not compared." que si se menciona en otros sitios que he leido.

Ni en la referencia de the Open group ni en el manual de la glibc se menciona nada.


¿Y esto por que es asi por ahorrarse una comparación?

Segun entiendo yo, el bug es algo así:

Código: Seleccionar todo

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char contenido1[10] = { 0xAA, 0xBB, 0xCC, 0xDD, 0x00, 0xAD, 0xCD, 0x12, 0x23, 0x45 };
    char contenido2[10] = { 0xAA, 0xBB, 0xCC, 0xDD, 0x00, 0x99, 0xF1, 0x98, 0x12, 0x09 };
   
    if (strncmp(contenido1, contenido2, 10) == 0)
    {
       printf("Cadenas: Valido!\n");
    }
    else
    {
        printf("Cadenas: Invalido!\n");
    }
   
    if (memcmp(contenido1, contenido2, 10) == 0)
    {
       printf("Memoria: Valido!\n");
    }
    else
    {
        printf("Memoria: Invalido!\n");
    }
   
    system("PAUSE");
   
    return 0;
}



Esta aplicación, da como resultado:

Cadenas: Valido!
Memoria: Invalido!

El fallo es que Nintendo esta usando método de las "Cadenas", entonces como se puede ver en este código, se da como valido aunque no es igual.

He estado googleando y...

http://www.cygwin.com/ml/libc-alpha/2004-08/msg00119.html

torito21 escribió:Basicamente el NULL o 0x00 en una cadena indica el fin de cadena, por lo tanto, en una funcion de comparacion de cadenas, es normal que se pare en cuanto se encuentre un NULL.

Prueba:

Código: Seleccionar todo

[font=verdana, arial][size=90] #include <stdio.h>
int main(){

printf("resultao: %d", strcmp("gate\0te","gate\0miabuela"));

return 0;
}[/size][/font]

Deberia imprimir "

resultao: 0

" (iguales)

Saludos.

No, no es normal,no deberia pararse al encontrar NULL...según el standar lo que debe hacer es petar y bien que peta.

Regla de oro en temas de seguridad comprobar siempre la entrada.

Pero por lo visto un null como parámetro esta definido como comportamiento no definido por lo que por eso se devuelve la señal segfault por que es lo que dice el estandar que debe suceder,es decir la funcion simplemente no esta definida para para esa entrada.

O lo que es lo mismo se pasa el marrón al usuario de esa función.


El fallo de los de nintendo esta en suponer que strcmp esta definido para valores null y el fallo de quien ha implementado la función strcmp que usan en nintendo esta en definir un comportamiento para esa entrada en vez de petar.

Supongo que el comportamiento estandar de stcmp sigue siendo asi por compatibilidad con codigo antiguo si no es algo que no tienes ni pies ni cabeza.

A mi me habían enseñado siempre a comprobar lo que le metia a una strcmp pero no sabía (o recordaba) es que la strcmp se lavaba las manos.

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 metodo 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 comienze por 0x00.

[quote="wah_wah_69"][/quote]
Hombre, esuqe haciendo:

Código: Seleccionar todo

[font=verdana, arial][size=90] strcmp("gatete",NULL);[/size][/font]


Le estas diciendo que compare la cadena "gatete" con la cadena que comienza en la direccion de memoria 0 (NULL == (void *)0), entonces da la excepcion SIGSEGV porque esa direccion esta reservada por el kernel, no es accesible a nivel de usuario, peligro tendria si no.

El tema que comente anteriormente se refiere a que el puntero pasado a strcmp SÍ tiene memoria reservada en espacio de usuario y que contiene un NULL como contenido, no como puntero; usease 4 bytes a 0x00 (en SO de 32bit), por lo que la funcion strcmp en cuanto ve un byte (caracter, al ser de comparacion de cadenas) a 0x00, para. Y solo compara hasta ahi.

Y no es que la funcion strcmp pete al pasarle un NULL como argumento por referencia, si que cualquier programa es espacio de usuario que intende acceder a la direccion 0 de memoria ((void *)0) va a petar si o si; cosa del kernel.

Saludos

Ya que ahora se sabe el fallo, no se puede aplicar a los canales wii?

torito21 escribió:Hombre, esuqe haciendo:

Código: Seleccionar todo

[font=verdana, arial][size=90] strcmp("gatete",NULL);[/size][/font]


Le estas diciendo que compare la cadena "gatete" con la cadena que comienza en la direccion de memoria 0 (NULL == (void *)0), entonces da la excepcion SIGSEGV porque esa direccion esta reservada por el kernel, no es accesible a nivel de usuario, peligro tendria si no.

El tema que comente anteriormente se refiere a que el puntero pasado a strcmp SÍ tiene memoria reservada en espacio de usuario y que contiene un NULL como contenido, no como puntero; usease 4 bytes a 0x00 (en SO de 32bit), por lo que la funcion strcmp en cuanto ve un byte (caracter, al ser de comparacion de cadenas) a 0x00, para. Y solo compara hasta ahi.

Y no es que la funcion strcmp pete al pasarle un NULL como argumento por referencia, si que cualquier programa es espacio de usuario que intende acceder a la direccion 0 de memoria ((void *)0) va a petar si o si; cosa del kernel.

Saludos

Exacto, ha sido un lapsus mio el no acordarme, era exactamente como dices como me lo explicaron,ese area de memoria se supone que esta protegida.

Lo que no entiendo es que no se advierta de eso en la manpage ni en la referencia del opengroup,que luego pasa lo que pasa...


@Waninoko:

Entiendo tu método aunque no se que info se lee y compara al comprobar la firma, ¿Qué es el TMD?

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

Al final lo del IOS 37 no era una broma?
Podria ser esto la continuación de la broma???

Porque hay dos cosas que no me cuadran:
1.- De donde se ha sacado que se usa el strcmp?? Supongo que es una suposición no? Que yo sepa hace falta tener el codigo fuente para conocer este tipo de detalles.

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.