Twilight Hack!! Por Fin!!!!!

N3TKaT escribió:No. A ver, voy a intentar de explicarlo de forma sencilla.

Los saves van cifrados con una clave (sd-key) solamente. Después se firman con la clave privada de tu consola. Para poder comprobar la firma se incluye en el save la clave pública de tu consola, pero para evitar que esta se modifique a su vez va firmada por la clave privada de nintendo.

Como ves es imposible inventarse las claves, ya que necesitas que la pública este firmada por nintendo (y no tenemos la privada de nintendo para poder firmar). Así que la única forma de tener las claves validas es sacarlas de una wii, que es lo que han hecho esta gente, realmente utilizan una clave autentica sacada de una wii.

Probablemente DATEL hizo esto mismo, pero tampoco han soltado las claves, nada de este hack tiene que ver con ellos.

Un saludo.

Que bueno verte de nuevo .

blackgem escribió:
Antes edite y dije que en el loader.bin desencriptado estaba mas claro..., pero esto texto no es mas que la parte de texto plano que se mostrara en pantalla(pasa asi en casi todos los casos). El resto hasta que no se libere... donde pone %algo son variables que pueden ser mas texto o numeros normalmente que varian dependiendo de datos externo del archivo normalmente (ej: una direccion de memoria)

Hasta donde tengo entendido (yo al menos)...
El save de TP es muy semejante al de GC (muy investigado), en TP en vez de llamar a referencias fijas llamaba a punteros (direcciones de memoria, modificables), en esa direccion de memoria en vez de decir que cargue el nombre de Epona (se le puede cambiar el nombre al comenzar una partida) han provocado un error que han redirigido al archivo loader.bin
Este loader.bin ya se encarga de mostrar el texto en pantalla y llamar a otro codigo almacenado por ej en la SD.

Asi que apenas el juego intenta cargar el nombre de Epona (el caballo que se tiene desde el principio inculto ) que lo hace apenas intentas cambiar de zona o hablar con el primer tio que encuentras... CRASH, ya teneis exploit.

Mas alla solo tengo suposiciones que desde el loader.bin (encriptado) dentro del save llamar a otro archivo .elf almacenado en una SD

Mas claro no se como sacarle, pero seguro que otros en poco tiempo lo haran

Bueno en realidad el hack no funciona del todo así..... En realidad el .dat es por así decirlo el savegame, lo que han hecho como bien dices es modificar el nombre de EPONA creando un stack overflow en la stack call con lo que han conseguido que la siguiente intrucción que se ejecute sea la que a ellos les dé la gana, esta siguiente instrucción parece que se encuentra ya en este mismo .dat, y las siguientes tambien, así como todas las intrucciones del hack, estas instrucciones en ocasiones requiere datos grandes, estos datos grandes como las largas cadenas o el maravilloso pingüinito es lo que está contenido en el .bin, de ahi que en las cadenas aparezcan los %s que indican a las funciones de impresion con formato como printf que imprima la variable pasada.

Lo que estoy intentando sacar ahora es el metodo exacto con el que hacen el stack overflow.... para eso hay que enteder el formato de los savegame, por si alguien está interesado que se mire las herramientas de segher yo por ahora no tengo ni idea por que no tenia gc ni nada....

Mucho nivel en los últimos 3 posts.

Para equilibrar mando mi pregunta de noob.

Siendo utilizada la clave de la wii (creo que de bushing), Nintendo puede simplemente banear esa clave en el proximo firm revocandola ¿no?

_harry_ escribió:Mucho nivel en los últimos 3 posts.

Para equilibrar mando mi pregunta de noob.

Siendo utilizada la clave de la wii (creo que de bushing), Nintendo puede simplemente banear esa clave en el proximo firm revocandola ¿no?

Si no recuerdo mal la clave es de tmbinc, pero eso da igual. Pasa una cosa con los saves que evita que puedan hacer esto, una vez lo copias a la consola no se guarda la firma ni nada de la original. Así que si después de copiarlo a la consola lo vuelves a copiar a la SD, se vuelve a firmar pero con la firma de TU consola. Si baneasen esa clave (cosa casi imposible) bastaría con pasar el save por otra consola y ya lo tendrías con otra clave.

_harry_ escribió:Mucho nivel en los últimos 3 posts.

Para equilibrar mando mi pregunta de noob.

Siendo utilizada la clave de la wii (creo que de bushing), Nintendo puede simplemente banear esa clave en el proximo firm revocandola ¿no?

A bushing le importan 3 pimientos el juego online de esa wii.
A bushing le importan otros 3 la actualizacion (seguro que esa wii la usa solo para indagar y si juega con alguna wii, sera con otra de la que no se le ocurrira publicar nigun dato)

_harry_ escribió:Mucho nivel en los últimos 3 posts.

Para equilibrar mando mi pregunta de noob.

Siendo utilizada la clave de la wii (creo que de bushing), Nintendo puede simplemente banear esa clave en el proximo firm revocandola ¿no?

Ten en cuenta que el encriptado/desencriptado se hace con algoritmos muy fuertes, modificar estos algoritmos para que no funcionen con una clave sería un poco estupido por parte de N.... imaginate tener que sacar un nuevo firm para cada key que se use.... Banearías una unica consola por cada firm... lo que se puede solucionar no actulizando la consola en cuestion y cambiando la key del hack....

Coste para los hacker 251€

coste para N pfffff€

N3TKaT escribió:Si no recuerdo mal la clave es de tmbinc, /.../se vuelve a firmar pero con la firma de TU consola. Si baneasen esa clave (cosa casi imposible) bastaría con pasar el save por otra consola y ya lo tendrías con otra clave.

Comprendido e implementado en mi sistema nervioso.

Lo que si puede hacer N es hacer un firmware que automaticamente inutilice las consolas que tenemos el hack en la memoria... Eso seria menos costoso para ellos, pero no lo van a hacer, perderian muchisimos clientes...

omnitron escribió:
Bueno en realidad el hack no funciona del todo así..... En realidad el .dat es por así decirlo el savegame, lo que han hecho como bien dices es modificar el nombre de EPONA creando un stack overflow en la stack call con lo que han conseguido que la siguiente intrucción que se ejecute sea la que a ellos les dé la gana, esta siguiente instrucción parece que se encuentra ya en este mismo .dat, y las siguientes tambien, así como todas las intrucciones del hack, estas instrucciones en ocasiones requiere datos grandes, estos datos grandes como las largas cadenas o el maravilloso pingüinito es lo que está contenido en el .bin, de ahi que en las cadenas aparezcan los %s que indican a las funciones de impresion con formato como printf que imprima la variable pasada.

Lo que estoy intentando sacar ahora es el metodo exacto con el que hacen el stack overflow.... para eso hay que enteder el formato de los savegame, por si alguien está interesado que se mire las herramientas de segher yo por ahora no tengo ni idea por que no tenia gc ni nada....

Supongo que han desencriptado un savegame normal, con un nombre conocido para Epona y han buscado la dirección donde está almacenado ese nombre (en Unicode o UTF8, supongo). Una vez obtenida la dirección solo han tenido que modificarla para meter un nombre que tuviera el código PPC a ejecutar, y la nueva dirección de retorno (que apunta al espacio de la pila donde saben que va a estar el buffer estático que provoca el overflow) y supongo que terminar ese troncho en un caracter fin de retorno para que el código de parseo del savegame del twilight princess se lo tragara. Luego solo han tenido que encriptarla con la SD Key, firmarla con la ECC Key privada, añadir la ECC Key pública firmada por la super-secreta Key privada de nintendo

Si consigues averiguar la dirección donde está el nombre de Epona en el savegame pégalo por aquí que me interesa echarle un vistazo al código PPC, pero no tengo paciencia pa buscarla yo mismo xD

IorIYagami escribió:
Supongo que han desencriptado un savegame normal, con un nombre conocido para Epona y han buscado la dirección donde está almacenado ese nombre (en Unicode o UTF8, supongo). Una vez obtenida la dirección solo han tenido que modificarla para meter un nombre que tuviera el código PPC a ejecutar, y la nueva dirección de retorno (que apunta al espacio de la pila donde saben que va a estar el buffer estático que provoca el overflow) y supongo que terminar ese troncho en un caracter fin de retorno para que el código de parseo del savegame del twilight princess se lo tragara. Luego solo han tenido que encriptarla con la SD Key, firmarla con la ECC Key privada, añadir la ECC Key pública firmada por la super-secreta Key privada de nintendo

Si consigues averiguar la dirección donde está el nombre de Epona en el savegame pégalo por aquí que me interesa echarle un vistazo al código PPC, pero no tengo paciencia pa buscarla yo mismo xD

La verdad es que no he entendido muy bien lo que quieres decir, pero creo que es algo más complicado que eso de hacer...

Lo que han hecho es poner el nombre de Epona a muchos treses (esto se puede ver en el savegame muy claramente) y al final de esos treses han puesto una dirección de memoria, lo que han conseguido con esto es en la funcion que obtiene el nombre de Epona (en la stack call que es donde se guardan los datos de cada procedimiento) sobreescribir todo el codigo hasta que han llegado al area donde se dice la direccion de retorno de esta funcion (seguramente todos los treses esos sean una implementacion en ASM de un idle o algo asi) la consecuencia de todo esto es que tras ejecutar la funcion que lee el nombre de Epona, se ejecuta los treses esos (idle) y cuando se acaban se lee la direccion de retorno (que es la que ellos hayan puesto tras los treses) y se va a esa dirección

000002a3:33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
000002b3:33 33 80 45 25 a0

Eso en negrita debe ser la dirección de retorno que debe ser un trozo del dat (donde empieza las instrucciones de este)

Esto es un poco suposición la verdad pero creo que la estructura del exploit debe ser algo parecido a eso.

Despues de divagar un poco liarme un rato mas...
¿Que sucede en realidad?

a) El loader.bin se llama en vez de llamar a la variable que contiene el nombre de Epona.

b) Nombre_de_Epona_demasiado_largo=Crash_error_del_sistema y en ese estado de error pueden llamar a loader.bin

Hay queda la duda, uno u otro podrian significar distintas maneras de incursion en la Wii.

P.D.: Por aqui pasan muchos curiosos, no todos somos informaticos o investigadores , poned al final si puede ser un resumen simplon o aclaraciones entre parentesis.

blackgem escribió:Despues de divagar un poco liarme un rato mas...
¿Que sucede en realidad?

a) El loader.bin se llama en vez de llamar a la variable que contiene el nombre de Epona.

b) Nombre_de_Epona_demasiado_largo=Crash_error_del_sistema y en ese estado de error pueden llamar a loader.bin

Esta clarísimo un buen bug mires por donde lo mires.

blackgem escribió:Despues de divagar un poco liarme un rato mas...
¿Que sucede en realidad?

a) El loader.bin se llama en vez de llamar a la variable que contiene el nombre de Epona.

b) Nombre_de_Epona_demasiado_largo=Crash_error_del_sistema y en ese estado de error pueden llamar a loader.bin

Hay queda la duda, uno u otro podrian significar distintas maneras de incursion en la Wii.

P.D.: Por aqui pasan muchos curiosos, no todos somos informaticos o investigadores , poned al final si puede ser un resumen simplon o aclaraciones entre parentesis.

a) No no es así, el loader.bin no contiene más que por asi decirlo las constantes del programa grandes, como son las cadenas de caracteres y la imagen del pingüino, es decir que el dat importa datos del bin, pero todo el trabajo y el programa en si esta en el .dat, han dicho que esto lo hacen así para que puedan encajar bien el programa en el savegame, seguramente por que haya un limte en los savegame o algo asi

b) Si pero en vez de de llamar a loader.bin llaman al .dat en un determinado sitio donde contiene instrucciones

blackgem escribió:Despues de divagar un poco liarme un rato mas...
¿Que sucede en realidad?

a) El loader.bin se llama en vez de llamar a la variable que contiene el nombre de Epona.

b) Nombre_de_Epona_demasiado_largo=Crash_error_del_sistema y en ese estado de error pueden llamar a loader.bin

Hay queda la duda, uno u otro podrian significar distintas maneras de incursion en la Wii.

P.D.: Por aqui pasan muchos curiosos, no todos somos informaticos o investigadores , poned al final si puede ser un resumen simplon o aclaraciones entre parentesis.

No te preocupes, yo soy ingeniero tecnico informático y tb me cuesta entender bien lo que dicen.

(Como yo lo veo) En resumen es que cuando un trozo del programa falla en algún punto, el programa debe saber como seguir. A esos problemas se le llaman exception, la cosa es que si nosotros conseguimos las dos cosas, ya sea que falle, y en la exepción decir nosotros lo que quiera que haga... podemos meter mano por ahí. La idea es sencilla, en la excepción no podemos hacer que cargue un programa casero ni nada así, pero si podemos decirle una cosa pequeñita, esa cosa es una direccion de donde seguir a ejecutando, creo que eso es lo que hablaban del .bin, y desde hay poner de nuevo un enlace a que cargue en la sd. Un resumen que no tengo ni idea si es correcto


si alquien me corrige le doy las gracias

chipi_ron escribió:
No te preocupes, yo soy ingeniero tecnico informático y tb me cuesta entender bien lo que dicen.

(Como yo lo veo) En resumen es que cuando un trozo del programa falla en algún punto, el programa debe saber como seguir. A esos problemas se le llaman exception, la cosa es que si nosotros conseguimos las dos cosas, ya sea que falle, y en la exepción decir nosotros lo que quiera que haga... podemos meter mano por ahí. La idea es sencilla, en la excepción no podemos hacer que cargue un programa casero ni nada así, pero si podemos decirle una cosa pequeñita, esa cosa es una direccion de donde seguir a ejecutando, creo que eso es lo que hablaban del .bin, y desde hay poner de nuevo un enlace a que cargue en la sd. Un resumen que no tengo ni idea si es correcto


si alquien me corrige le doy las gracias

Te podría corregir, pero me temo que sería repetir lo que he escrito unas cuantas veces ya, lo mejor es que os leais bien como funciona un buffer overflow sobre una call stack y luego os leais lo que he puesto seguro que os queda un poco más claro.

Tu error principal está en que en realidad no se produce ninguna excepción, de hecho lo que hacen es aprovechar que no hay exccepción ,al haber una vulnerabilidad sin handler definido aprovechan para sobreescribir una dirección de retorno, si se lanzara excepción entonces no existiria vulnerabilidad

Entonces a simple vista comprendo que hay error del sistema y cuando el TP se "cuelga" la wii se traga el codigo que le echen, en este caso segun se dice la direccion de memoria del mismo archivo .dat (el save en si) que contiene el codigo que debe utilizarse (que por limites preestablecidos debe cargar info del .bin)

Mas o menos ya me voy quitando nubes de confusion

Como analfabeto informático profundo, sólo puedo agradecer estas interesantísimas últimas aportaciones. Sé que este mensaje entorpece las conversaciones, pero no he podido resistirme a agradeceros vuestras explicaciones.

N3TKaT escribió:No. A ver, voy a intentar de explicarlo de forma sencilla.

Los saves van cifrados con una clave (sd-key) solamente. Después se firman con la clave privada de tu consola. Para poder comprobar la firma se incluye en el save la clave pública de tu consola, pero para evitar que esta se modifique a su vez va firmada por la clave privada de nintendo.

Como ves es imposible inventarse las claves, ya que necesitas que la pública este firmada por nintendo (y no tenemos la privada de nintendo para poder firmar). Así que la única forma de tener las claves validas es sacarlas de una wii, que es lo que han hecho esta gente, realmente utilizan una clave autentica sacada de una wii.

Probablemente DATEL hizo esto mismo, pero tampoco han soltado las claves, nada de este hack tiene que ver con ellos.

Un saludo.

Gracias.

Me aclarare un poco mas

explicacion buffer overflow

(leida por encima) Como el nombre de Epona es tan largo coge al final la parte donde se almacena "volver al codigo que llamo al nombre de Epona del juego" y en su luga acaba almacenado "ve a la parte del save donde esta el hack".

P.D.: Me gusta este tema

blackgem escribió:Entonces a simple vista comprendo que hay error del sistema y cuando el TP se "cuelga" la wii se traga el codigo que le echen, en este caso segun se dice la direccion de memoria del mismo archivo .dat (el save en si) que contiene el codigo que debe utilizarse (que por limites preestablecidos debe cargar info del .bin)

Mas o menos ya me voy quitando nubes de confusion

Exactamente solo que como he puesto antes no se produce ningún error, eso es lo dificil tongar a la máquina sin que esta se entere...

Mirad, he encontrado un wiki que esplican increiblemente bien como se hacen los buffer overflow:

http://en.wikipedia.org/wiki/Stack_buffer_overflow

Si no sabeis que es una stack call leeros esto:

http://en.wikipedia.org/wiki/Call_stack

blackgem escribió:Me aclarare un poco mas

explicacion buffer overflow

(leida por encima) Como el nombre de Epona es tan largo coge al final la parte donde se almacena "volver al codigo que llamo al nombre de Epona del juego" y en su luga acaba almacenado "ve a la parte del save donde esta el hack".

P.D.: Me gusta este tema

Exacto!

omnitron escribió:

Te podría corregir, pero me temo que sería repetir lo que he escrito unas cuantas veces ya, lo mejor es que os leais bien como funciona un buffer overflow sobre una call stack y luego os leais lo que he puesto seguro que os queda un poco más claro.

Tu error principal está en que en realidad no se produce ninguna excepción, de hecho lo que hacen es aprovechar que no hay exccepción ,al haber una vulnerabilidad sin handler definido aprovechan para sobreescribir una dirección de retorno, si se lanzara excepción entonces no existiria vulnerabilidad

Duda aclarada... Gracias!

buenas, queria comentar que ya han hecho un pong a traves del hack; cargandolo desde la sd, quizas ya ha salido pero no lo he seguido mucho por los examenes. bueno lo he visto en otro foro de consoloas español y no es que sea gran cosa pero por algo se empieza

Y creeis que seria posible cojer el save que tengamos de nuestra partida, y "insertar" el hack en uno de los archivos del save?, es decir, yo si entro con el archivo 1 o 2 puedo jugar normal, y si le tiro al 3 carge el hack, esto estaria guay, porque sino tenemos todo lo que queramos, pero perdemos el jugar al zelda xDDD (o ir moviendo saves cada vez..)

Si no es posible sacais una Magnum 44 y me pegais un tiro xD



EDIT

Con lo del pong no te referiras a esto verdad?
http://www.youtube.com/watch?v=-daUQD8iojo

omnitron escribió:
La verdad es que no he entendido muy bien lo que quieres decir, pero creo que es algo más complicado que eso de hacer...

Lo que han hecho es poner el nombre de Epona a muchos treses (esto se puede ver en el savegame muy claramente) y al final de esos treses han puesto una dirección de memoria, lo que han conseguido con esto es en la funcion que obtiene el nombre de Epona (en la stack call que es donde se guardan los datos de cada procedimiento) sobreescribir todo el codigo hasta que han llegado al area donde se dice la direccion de retorno de esta funcion (seguramente todos los treses esos sean una implementacion en ASM de un idle o algo asi) la consecuencia de todo esto es que tras ejecutar la funcion que lee el nombre de Epona, se ejecuta los treses esos (idle) y cuando se acaban se lee la direccion de retorno (que es la que ellos hayan puesto tras los treses) y se va a esa dirección.


Eso en negrita debe ser la dirección de retorno que debe ser un trozo del dat (donde empieza las instrucciones de este)

Esto es un poco suposición la verdad pero creo que la estructura del exploit debe ser algo parecido a eso.

Esos treses nunca se llegan a ejecutar si no se pone el puntero de instrucción sobre ellos, así que lo más probable es que no sean nada.
Todos los Stack Smashing se basan en modificar la dirección de retorno en la pila para que vaya a una dirección en la que tú has escrito tu código. Lo que yo estaba asumiendo es que habían puesto ese código en el propio nombre de Epona, y que habían cambiado la dirección de retorno a la dirección en la que empezaba el buffer estático (el nombre de Epona), donde habían metido instrucciones PPC (por supuesto, en código máquina PPC directamente). Asumía esto porque me parecía el sitio más seguro donde meter código sin cargarte el savegame y que el juego petara antes al leerlo. Pero claro, en realidad no tengo ni idea de qué hace el juego cuando carga el savegame, puede que lo vuelque entero en memoria y lo lea a posteriori, o puede que lo parsee en estructuras de juego.

Por lo que me has dicho, podemos asumir entonces que han encontrado una zona del savegame que se carga en memoria directamente, que pueden modificar sin que pete nada y cuya dirección en memoria en runtime saben de antemano. Eso tiene mejor pinta que lo que yo decía, porque el código para cargar el ejecutable de loader.bin se me antoja mucho código para un buffer estático pensado para un nombre. Ahora lo interesante sería averiguar en qué zona del savegame han metido ese código (antes de que lo digáis: esa dirección indicada en el nombre de epona no se puede buscar en el savegame, ya que es una dirección de memoria cuando el juego se está ejecutando. No se si la Wii usa big-endian o little-endian, así que igual hay que invertirla).

Si sabéis algo de eso y lo localizáis, ponedlo, por favor, tengo mucha curiosidad por verlo.

N3TKaT escribió:
[n3tkat:~/wii/keys]$ md5sum *
8d1a2ebcd82a3469b77facf15d9c8e50 common-key
4582417d623c81fca07a46a570c8969e md5-blanker
d9f2b2e045d22d3805a67fe0c340ccd2 sd-iv
ef33e224e45c8d8c35ce32d8a810b603 sd-key

La sd-key está en el IOS del Starlet.

Con esas pistas debería ser cuestión de minutos que la sacases xDD.

Depende de lo que se te atranque el C DDDDDDDDDDDD

Y creeis que seria posible cojer el save que tengamos de nuestra partida, y "insertar" el hack en uno de los archivos del save?, es decir, yo si entro con el archivo 1 o 2 puedo jugar normal, y si le tiro al 3 carge el hack, esto estaria guay, porque sino tenemos todo lo que queramos, pero perdemos el jugar al zelda xDDD (o ir moviendo saves cada vez..)

Sobre esto, si, es posible, ellos dejan en blanco el resto del hack, pero no se hasta que punto te afecta al resto del save el hack. Creo incluso que podrias grabar los saves por debajo del hack, intentalo y nos cuentas...

no no el pong el twilight hack es decir... en vez de quedarse en las letras y no hacer "nada" pues empieza a cargar el pong lo unico que no lo controlan todavia pero bueno cargan algo desde la sd....

Buenas, una pregunta que tengo, he estado mirando por los foros de Gamecube, haber si habia algo relacionado... pero no me aclaran mis dudas y mi problema.

He probado el Hack en Wii y funciona correctamente, pero hay una cosita que nop. Tengo un "WiiKey SD Adapter" y nada, cuando lanzo el Hack, pone que no reconoce el "SD Gecko" no se supone que es exactamente lo mismo? necesita algun formateado especial la SD como he leido por ahi?

Gracias y espero que podais responder.

1Saludo

ddf escribió:Sobre esto, si, es posible, ellos dejan en blanco el resto del hack, pero no se hasta que punto te afecta al resto del save el hack. Creo incluso que podrias grabar los saves por debajo del hack, intentalo y nos cuentas...

A evr si alguien puede probar que no tengo ninguna SD por aqui ahora

@xirtam8 pues no encuentro nada, dinos de donde (o enviame el link por PM) pk interesa =D

IorIYagami escribió:
Esos treses nunca se llegan a ejecutar si no se pone el puntero de instrucción sobre ellos, así que lo más probable es que no sean nada.
Todos los Stack Smashing se basan en modificar la dirección de retorno en la pila para que vaya a una dirección en la que tú has escrito tu código. Lo que yo estaba asumiendo es que habían puesto ese código en el propio nombre de Epona, y que habían cambiado la dirección de retorno a la dirección en la que empezaba el buffer estático (el nombre de Epona), donde habían metido instrucciones PPC (por supuesto, en código máquina PPC directamente). Asumía esto porque me parecía el sitio más seguro donde meter código sin cargarte el savegame y que el juego petara antes al leerlo. Pero claro, en realidad no tengo ni idea de qué hace el juego cuando carga el savegame, puede que lo vuelque entero en memoria y lo lea a posteriori, o puede que lo parsee en estructuras de juego.

Por lo que me has dicho, podemos asumir entonces que han encontrado una zona del savegame que se carga en memoria directamente, que pueden modificar sin que pete nada y cuya dirección en memoria en runtime saben de antemano. Eso tiene mejor pinta que lo que yo decía, porque el código para cargar el ejecutable de loader.bin se me antoja mucho código para un buffer estático pensado para un nombre. Ahora lo interesante sería averiguar en qué zona del savegame han metido ese código (antes de que lo digáis: esa dirección indicada en el nombre de epona no se puede buscar en el savegame, ya que es una dirección de memoria cuando el juego se está ejecutando. No se si la Wii usa big-endian o little-endian, así que igual hay que invertirla).

Si sabéis algo de eso y lo localizáis, ponedlo, por favor, tengo mucha curiosidad por verlo.

Me temo que eso treses (siempre que sean el nombre del caballito) si que se ejecutan, ten en cuenta que tu sobreescribes todas las instrucciones que van despues del nombre del caballo pero lo que es el CPI no lo tocas así que el CPI apuntará a instrucción de lectura del caballo + 1 es decir los treses, a no ser que tubieran la suerte de que fuera la última instrucción de la función en ese caso no se ejecutaría ningun "3" y solo se sobreescribirían los metadatos del procedimiento hasta la dirección de retorno

En cuanto a lo que es la direccíon seguramente haga referencia al CPI +/- un determinado offset pero bueno todo esto ya es especulación

Pregunta sobre el "tachtig.exe"; ¿ cómo puedo abrir y ver el contenido del rzdp.bin ?

Es que no lo consigo.

PiratePila escribió:Pregunta sobre el "tachtig.exe"; ¿ cómo puedo abrir y ver el contenido del rzdp.bin ?

Yo tampoco sé, supongo que para que el programa arranque hay que meter dentro de la carpeta las sd keys que no tengo.

Yo ando muy perdido con esto, a ver si alguien aclara un poco como funciona.

Efectivamente las claves no te vienen hay que meterlas en un .bin lo que nose si es exactamente ese que comentais

omnitron escribió:
Me temo que eso treses (siempre que sean el nombre del caballito) si que se ejecutan, ten en cuenta que tu sobreescribes todas las instrucciones que van despues del nombre del caballo pero lo que es el CPI no lo tocas así que el CPI apuntará a instrucción de lectura del caballo + 1 es decir los treses, a no ser que tubieran la suerte de que fuera la última instrucción de la función en ese caso no se ejecutaría ningun "3" y solo se sobreescribirían los metadatos del procedimiento hasta la dirección de retorno

En cuanto a lo que es la direccíon seguramente haga referencia al CPI +/- un determinado offset pero bueno todo esto ya es especulación

CPI? no será PC (Program Counter) o IP(Instruction pointer)? weno, da igual, se a lo que te refieres.

Al desbordar un buffer estático lo único que haces es escribir en espacio de la pila de llamadas. Ahí no hay código, solo datos. Y el instruction pointer está apuntando a otra zona completamente distinta de memoria.

La pila de llamadas contiene información acerca de las subrutinas que se están ejecutando, entre ellas la dirección de retorno de la subrutina. El principal objetivo al sobrecargar el buffer con un ataque como este es sobreescribir la dirección de retorno con una tuya propia. Entonces, cuando la subrutina termina (que no tiene porqué ser en cuanto se desborda el buffer) se "retorna", que no es ni más ni menos que quitar ese frame de la pila y saltar a la dirección de retorno especificada, que es la que tú quieras (y que será donde sepas que se encuentra tu código personalizado).

Ergo, los treses no se ejecutan

Edit: Bueno, se podrían ejecutar si la dirección de retorno fakeada apuntara al espacio en memoria donde se encuentran, pero no por la razón que tu exponías

Wau por fin, opte por no piratear mi wii asi que a ver si ay suerte y se llega a algo estilo a la psp, y al ser posible con el wii sports o algo asi xD por ke yo el zelda como que no le tengo asi que me tocara esperar pero bien me alegro de que esto marche y aver si ay suerte. Un saludo y mis felicitaciones para todos los ke lo acen posible

Un apunte respecto al video donde se ve como se carga el pong, se ve como el puntero del mando se mueve despues de cargar la partida cuando antes eso no pasaba. Esto significa que tienen una version "mejorada" en la q consiguen q funcione el mando.

PD: Perdon si he dicho una tonteria...

PD1:Gracias por la aclaracion, no me acordaba que en el primer video tb se movia

Simonchu, en el primer video ke sakaron ya se movia el puntero despues de kargar la partida, lo ke no se es porke nosotros no podemos moverlo. Tal vez peuda ser por la version del Zelda, pero vamos ni idea, todo hipotesis....

Salut!

IorIYagami escribió:
CPI? no será PC (Program Counter) o IP(Instruction pointer)? weno, da igual, se a lo que te refieres.

Al desbordar un buffer estático lo único que haces es escribir en espacio de la pila de llamadas. Ahí no hay código, solo datos. Y el instruction pointer está apuntando a otra zona completamente distinta de memoria.

La pila de llamadas contiene información acerca de las subrutinas que se están ejecutando, entre ellas la dirección de retorno de la subrutina. El principal objetivo al sobrecargar el buffer con un ataque como este es sobreescribir la dirección de retorno con una tuya propia. Entonces, cuando la subrutina termina (que no tiene porqué ser en cuanto se desborda el buffer) se "retorna", que no es ni más ni menos que quitar ese frame de la pila y saltar a la dirección de retorno especificada, que es la que tú quieras (y que será donde sepas que se encuentra tu código personalizado).

Ergo, los treses no se ejecutan

Edit: Bueno, se podrían ejecutar si la dirección de retorno fakeada apuntara al espacio en memoria donde se encuentran, pero no por la razón que tu exponías

Ties toda la razón se me coló que el segmento de datos evidentemente no se encuentra en la call stack

Aunque soy completamente analfabeto en estos temas, el hilo me resulta tremendamente adictivo, y leo con avidez todo lo que explicáis en el.

[Modo chistoso on]
Lo más curioso del asunto es que hayan encontrado un bug en el Zelda, con lo fácil que es encontrarlos en el Red Steel
[modo chistoso off]

A perdonar por el pésimo chiste, pero llevo con el en mente desde que se publicó el hack. Si no lo digo en público reviento.... xD
Saludos.

Africa escribió:[Modo chistoso on]
Lo más curioso del asunto es que hayan encontrado un bug en el Zelda, con lo fácil que es encontrarlos en el Red Steel
[modo chistoso off]

El problema del Red Steel es que no son bugs, son "features"

ArangeL escribió:
El problema del Red Steel es que no son bugs, son "features"

Jajajaja desde luego.... esos modelos voladores atascados no tienen precio.

Perdon por el Offtopic pero no me pude resistir

Cachondeo.enabled=true

Probablemente con el Gears of War para PC tambien se pueda hacer exploit en WII, y creo que casi en cualquier sistema

Cachondeo.enabled=false

Pues yo creo que los vectores en un espacio vectorial se expresan generalmente con respecto a una base (un conjunto concreto de vectores que "expanden" el espacio, a partir de los cuales se puede construir cualquier vector en ese espacio mediante una combinación lineal).
Si esta base se indexa con un conjunto discreto (finito, contable),
la representación vectorial es una "columna" de números.
Cuando un vector de estado mecanocuántico se representa frente a una base continua, se llama función de ondas.

Asi me quedo yo cuando os leo... ...

Perdon por el offtopic, pero es que me leo todo lo que escribis y de verdad que me siento un completo inutil... por lo menos intento amenizar esto...

Saludos y animo a la comunidad...

TRIPON escribió:Pues yo creo que los vectores en un espacio vectorial se expresan generalmente con respecto a una base (un conjunto concreto de vectores que "expanden" el espacio, a partir de los cuales se puede construir cualquier vector en ese espacio mediante una combinación lineal).
Si esta base se indexa con un conjunto discreto (finito, contable),
la representación vectorial es una "columna" de números.
Cuando un vector de estado mecanocuántico se representa frente a una base continua, se llama función de ondas.

La representación vectorial no es una "columna" de números, sino un cubo en el que se almacena todos los vectores de fusión cuánticos, que a su vez fornican en estado sólido a los vectorianos

yo no llevo siguiendo esto mucho ke digamos, pero, se ha probado a hacer un "swich"? osea un elf k cargue un programa k cargue cierta parte de un original, y luego t diga inserta la copia y arrea, se ha probado? xD

Bueno, ahora que estoy pensando...

Si esta peña ha conseguido cifrar el save.... se podrá cifrar un canal de la misma manera?

La cuestión estaba en que una de las claves que se usan para el cifrado es el ID de la consola (o algo he entendido yo asi) pero que se estaba poniendo un numero cualquiera.
Ya que como todos sabemos, los saves se pueden compartir. Pero en el caso de los canales es distinto, porque en este caso si que se cifra con la ID de la consola...

Entonces, por esa regla de tres sería posible modificar el canal, inyectandole la clave de la consola de cada uno?

Es una pregunta que suelto para los mas "sabeores" del tema

Los creadores del hack se niegan en rotundo hablar sobre carga de backups, y a mi me parece perfecto; hay muchísimas personas que en vez de aportar algo o aprender, estorban con los mismos comentarios una y otra vez sobre si se podrá cargar backups, o si ya no hace falta modchips, etc.

Por lo que hablar en este hilo una y otra vez sobre si se podrá cargar backups por este método es perder el tiempo, enojar al personal y pasar un mal rato con los comentarios de la gente.

Si la pregunta es si se podrá cargar backups por este método, pues no se sabe a ciencia cierta, pero juegos de GC sí se podría en el momento que estas personas dejaran cargar ELFs, ya que existe un loader para ISOs de GC, por lo que la carga también para ISOs de Wii no estaría muy lejos. Pero por favor, parad de preguntar lo mismo una y otra vez.

No empecéis ahora a preguntar si hace falta un SDGecko o porqué no lo liberan ya, o porque no permiten la carga por puerto SD de la Wii, por favor. No se investiga ese asunto ni se investigará por ahora.

Gracias, y a disfrutar aprendiendo algo nuevo .
Yo recomiendo más leer y menos postear .

PD: Qué pena que no esté por la labor de aprender programación para la plataforma de Wii , me encantaría poder hacer algún homebrew para ella . ¿Alguna novedad desde el canal de IRC?

uhm? hay un ELF de la GC k carga Backups? O.o

Ni idea de la mayoria de cosas que hablan, pero parecen interesante :$
Sobre crear partidas y que el hack siga funcionando, confirmo que funciona, he creado una partida en el slot 3, guardado, y cargado el slot 1 y sigue habiendo hack

Una duda que tengo... A mi y a un amigo (No conozco de nadie mas), al cargar el Zelda por primera vez con ese savegame, antes de aparecer la pantalla de "Colocate bien la correa, etc", paso un buen ratote que la pantalla se quedo en negro, hasta que por fin llego a dicha pantalla... Eso solo ocurrio la 1ª vez, por que?
Gracias por darme algo que leer tan interesante :$

ArangeL, con lo de que hay un ISO Loader de GC te refieres a los GCOS y demás ?

A mi también me parece muy bien que no quieran decir nada sobre backup's, ya que la mayoria de gente solo quiere jugar a juegos sin comprarlos.

Por cierto, como puedo entrar en el IRC, es que nunca sé como hacerlo.