[HO] Exploits en Nintendo 3DS

1, 2, 3
Hilo Oficial Exploits en Nintendo 3DS por egarrote en 2015
Muy buen artículo. [oki] Perfecto para los que tenemos un lío con los exploits. Ahora ya sé cómo se provoca el MSET Exploit. [360º]
Jordi V. escribió:Muy buen artículo. [oki] Perfecto para los que tenemos un lío con los exploits. Ahora ya sé cómo se provoca el MSET Exploit. [360º]

Gracias, precisamente eso espero, que ayude a los usuarios a aclararse algo mas con el lio de exploits. [+risas]

Salu2!
Me decian que con el exploit del cubic ninja, no hacia falta internet y al final es que si. Es mejor el del oot sin internet, si es solo para la gw, si es con la n3ds. Con la sky uso los dos y asi puedo instalar homebrew tambien sin problemas.
sev39lora escribió:Me decian que con el exploit del cubic ninja, no hacia falta internet y al final es que si. Es mejor el del oot sin internet, si es solo para la gw, si es con la n3ds. Con la sky uso los dos y asi puedo instalar homebrew tambien sin problemas.

Con el Ninjhax si hace falta internet pero solo para la instalación del exploit, luego ya queda instalado en el cartucho del Cubic Ninja y ya no es necesario para cargarlo.
El OOT3D es mas rápido para cargar el Gateway pero también es necesario un dongle o una Old3DS para copiar el save al cartucho del Zelda, ademas de que no sirve para cargar el Homebrew Loader.
Así que supongo que sera cuestión de gustos usar el que mas se adapte a las posibilidades de cada uno. [+risas]

Salu2!
para segun que xploit el cn y para la gw, oot. La sky3ds viene bien para tener los dos xploit a la vez.
Buen articulo, a ver si vemos pronto en esa lista un exploit para al menos la 9.5-22
Estaba yo pensando, que raro que no exista un post que recopile todo los Exploit.
Y TACHANN. Si que estaaa.
Gran trabajo Elgarrote. Y muy necesario.
Nuevo exploit en el bootrom de la consola:
ARM9/ARM11 bootrom vectors point at unitialized RAM

Description
ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc. The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.
This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).

Fixed with hardware model/revision
None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.

Newest hardware model/revision this flaw was checked for
New3DS

Timeframe this was discovered
End of February 2014

Discovered by
derrek, WulfyStylez (May 2015) independently

Fuente

Mas info:
First, I would like to thank WulfyStylez for making public this incredible hax.
Each morning, I actualize the Recent Changes, and then I see this... wow.
From a dev perspective, it's 10000 times more useful than releasing KARL3DS.

To everyone that don't understand this hax, I will try to explain what I understood.
First, there is a special register, called SYSPROT9, that is set-only (once you set a bit, you can't clear it) and that protect bootrom/OTP registers.
The only way to clear it is a hard reboot.
BUT, in a hard reboot, bootroms are launched again, and will re-enable SYSPROT9.
It's a chicken-and-egg loop that can be only broken by exploiting the bootrom.

The hax exploit two hardware vulnerabilities :
The first is that the RAMs/ARM9 memory are NOT cleared at hard reboots (it should).
The second is that the ARM9 bootrom does not immediatly relocate the ARM9 exception vectors to itself. So, for a (very quick) time, the ARM9 exception vectors point to the ARM9 memory... that we control!

The tricky part : the exception vectors are triggered by a fault. So we must inject a fault. It's easy if we have code execution, but we don't have code execution.
So we can't inject a fault with software means. Let's inject it with hardware means!

If the fault is injected within the short time window that is exploitable, the processor will jump to the RAM and execute our code.
It will execute our code BEFORE any bits of SYSPROT9 are set!
Finally, our code has to dump the parts protected by SYSPROT9.

Fuente

Todavía no se sabe si sera aprovechable, pero se trata de un exploit que en teoría funcionaría en cualquier firmware.

Salu2!
egarrote escribió:Nuevo exploit en el bootrom de la consola:
ARM9/ARM11 bootrom vectors point at unitialized RAM

Description
ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc. The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.
This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).

Fixed with hardware model/revision
None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.

Newest hardware model/revision this flaw was checked for
New3DS

Timeframe this was discovered
End of February 2014

Discovered by
derrek, WulfyStylez (May 2015) independently

Fuente

Mas info:
First, I would like to thank WulfyStylez for making public this incredible hax.
Each morning, I actualize the Recent Changes, and then I see this... wow.
From a dev perspective, it's 10000 times more useful than releasing KARL3DS.

To everyone that don't understand this hax, I will try to explain what I understood.
First, there is a special register, called SYSPROT9, that is set-only (once you set a bit, you can't clear it) and that protect bootrom/OTP registers.
The only way to clear it is a hard reboot.
BUT, in a hard reboot, bootroms are launched again, and will re-enable SYSPROT9.
It's a chicken-and-egg loop that can be only broken by exploiting the bootrom.

The hax exploit two hardware vulnerabilities :
The first is that the RAMs/ARM9 memory are NOT cleared at hard reboots (it should).
The second is that the ARM9 bootrom does not immediatly relocate the ARM9 exception vectors to itself. So, for a (very quick) time, the ARM9 exception vectors point to the ARM9 memory... that we control!

The tricky part : the exception vectors are triggered by a fault. So we must inject a fault. It's easy if we have code execution, but we don't have code execution.
So we can't inject a fault with software means. Let's inject it with hardware means!

If the fault is injected within the short time window that is exploitable, the processor will jump to the RAM and execute our code.
It will execute our code BEFORE any bits of SYSPROT9 are set!
Finally, our code has to dump the parts protected by SYSPROT9.

Fuente

Todavía no se sabe si sera aprovechable, pero se trata de un exploit que en teoría funcionaría en cualquier firmware.

Salu2!

Pillo sitio XD
Buff eso puede ser muy interesante, si realmente hay un exploit funcional en el bootrom eso permitiría el uso de CFW reales (que carguen directamente al arrancar la consola)

Por cierto @egarrote si me permites una sugerencia yo cambiaria esto lo de "el exploit hace que la consola se quede congelada y en ese momento es cuando se puede cargar código" por algo como "en ese momento se produce un desbordamiento de buffer controlado que permite cargar codigo.

Saludos
Cualquier firmware [babas]

Quiero poder hacer backups de mis savs, usar hackroms y el maldito coinsetter [carcajad]

Y si eso, usar emunand en mi 3DS y estar al dia, nada de backups "legitimos", solo Scene y Homebrew a patadas [buenazo]
¿Con ese exploit podríamos cargar la emuNAND mientras la 3DS se abre? :O ¡LO QUIERO!
Parar el carro XD, estais confundiendo exploit con CFW XD
Esto simplemente es la puerta para hacer algo, y ese algo puede ser un CFW que alguien se tendra que currar, o un editor de RAM, un Homebrew Channel...
CrusardGameamos escribió:Parar el carro XD, estais confundiendo exploit con CFW XD
Esto simplemente es la puerta para hacer algo, y ese algo puede ser un CFW que alguien se tendra que currar, o un editor de RAM, un Homebrew Channel...

¿Eso va para mí? Pero si @Raugo dijo:
Raugo escribió:Buff eso puede ser muy interesante, si realmente hay un exploit funcional en el bootrom eso permitiría el uso de CFW reales (que carguen directamente al arrancar la consola)
Jordi V. escribió:
CrusardGameamos escribió:Parar el carro XD, estais confundiendo exploit con CFW XD
Esto simplemente es la puerta para hacer algo, y ese algo puede ser un CFW que alguien se tendra que currar, o un editor de RAM, un Homebrew Channel...

¿Eso va para mí? Pero si @Raugo dijo:
Raugo escribió:Buff eso puede ser muy interesante, si realmente hay un exploit funcional en el bootrom eso permitiría el uso de CFW reales (que carguen directamente al arrancar la consola)

Pos si XD, va pa ti XD
Una cosa no quita la otra XD, esto simplemente es un metodo de ejecucion, lo que hace que exista la emuNAND (por decirlo de una manera) es algo que se ejecuta usando una vulnerabilidad del sistema, es decir, un exploit XD

Vamos, que con este exploit puede haber muchas posibilidades, y si tiene acceso al kernel, pues infinitas, como por ejemplo, nada mas abrir la consola que haga un spoof a la eShop, o que inicie la GW directamente, y demas cosas, pero como he dicho antes, esto son posibilidades, no lo que hace el exploit.
Un exploit en el bootrom "lo unico" que permite es cargar una nand modificada durante el arranque ya que el bootrom solo se ejecuta cuando se enciende la consola para cargar la nand.

Saludos
@CrusardGameamos @Raugo Muchas gracias, ahora lo tengo más claro, gracias a los dos. ;)
Raugo escribió:Un exploit en el bootrom "lo unico" que permite es cargar una nand modificada durante el arranque ya que el bootrom solo se ejecuta cuando se enciende la consola para cargar la nand.

Saludos


Pues vamos, perfecto, no deja de ser una emunand, podemos actualizar y no pasa nada, lo que yo me pregunto ¿Es facil de modificar esa nand para usar homebrew aunque este actualizada?
¿Por qué será que cada vez que hay un exploit tiene que caer algún Zelda? XD
Lo bueno que con la sky3ds, si salen más xploit con otros juegos, es la mejor para tenerlo todo en uno.
Ahora me entero que el zelda ocarina tiene exploit xDDDD yo ya tengo el cartucho desde hace mucho tiempo ahora solo falta ver como paso el save del exploit a mi cartucho de zelda.
se podria cargar los xploit tipo cn, sin tener internet?, lo digo por si sequiere cargar el xploit y no se tiene internet y si el qr.
sev39lora escribió:se podria cargar los xploit tipo cn, sin tener internet?, lo digo por si sequiere cargar el xploit y no se tiene internet y si el qr.

que yo sepa para cargar Ninjhax no necesitas internet
CrusardGameamos escribió:
sev39lora escribió:se podria cargar los xploit tipo cn, sin tener internet?, lo digo por si sequiere cargar el xploit y no se tiene internet y si el qr.

que yo sepa para cargar Ninjhax no necesitas internet


la primera vez si hace falta. Porque lo digo que si se depende de internet, para cargarlo la primera vez, pasa como ahora que supuestamente esta saturado y quien no lo tenga cargado, pues.
CrusardGameamos escribió:No hace falta, solo con tener el QR a mano ya lo puedes instalar.


Que raro, sino me equivoco a cuando salio el ninjhax a muchos se les quedaba pillado el porcentaje de instalación y era precisamente porque no tenían conectado la consola a internet en ese momento.

Ademas en la propia pagina de smea pone en el 4º paso:

4. Make sure your 3DS's wifi connection is enabled and connected to the internet (this is important!).
Maleajo escribió:
CrusardGameamos escribió:No hace falta, solo con tener el QR a mano ya lo puedes instalar.


Que raro, sino me equivoco a cuando salio el ninjhax a muchos se les quedaba pillado el porcentaje de instalación y era precisamente porque no tenían conectado la consola a internet en ese momento.

Ademas en la propia pagina de smea pone en el 4º paso:

4. Make sure your 3DS's wifi connection is enabled and connected to the internet (this is important!).

Si cierto XD, pense que no hacia falta XD
El team KARL ha conseguido aprovechar el exploit del bootrom?

Ayer un miembro del team KARL colgo esta foto:

Y otro desarrollador de Pasta CFW le respondió:
So you finally exploited that bootrom flaw?
Fuente

Traducción:
Así que por fin has conseguido aprovechar el exploit del bootrom?


El desarrollador del team KARL no ha comentado que es lo que significa esa foto dejando el tema en el aire...
Pero la foto no se debe a una actualización de los módulos que definen la versión de firmware:
Dazzozo (KARL) escribió:
motezazer (Pasta) escribió:They could just install latest CVER/NVER.
But I trust them.
An it's a New 3DS!
If it was CVER/NVER we would've bullshitted you all sooner. It is certainly not that.

Traducción:
Podrían haber instalado simplemente el último CVER/NVER.
Pero confió en el.
Y es una New3DS!

Si fuera una actualización del CVER/NVER lo habríamos dicho antes. Definitivamente, no es eso.

Estaremos mas cerca de Custom Firmware permanente? [babas]

Salu2!
egarrote escribió:El team KARL ha conseguido aprovechar el exploit del bootrom?

Ayer un miembro del team KARL colgo esta foto:

Y otro desarrollador de Pasta CFW le respondió:
So you finally exploited that bootrom flaw?
Fuente

Traducción:
Así que por fin has conseguido aprovechar el exploit del bootrom?


El desarrollador del team KARL no ha comentado que es lo que significa esa foto dejando el tema en el aire...
Pero la foto no se debe a una actualización de los módulos que definen la versión de firmware:
Dazzozo (KARL) escribió:
motezazer (Pasta) escribió:They could just install latest CVER/NVER.
But I trust them.
An it's a New 3DS!
If it was CVER/NVER we would've bullshitted you all sooner. It is certainly not that.

Traducción:
Podrían haber instalado simplemente el último CVER/NVER.
Pero confió en el.
Y es una New3DS!

Si fuera una actualización del CVER/NVER lo habríamos dicho antes. Definitivamente, no es eso.

Estaremos mas cerca de Custom Firmware permanente? [babas]

Salu2!


Ojala seria la ostia como psp xd
egarrote escribió:Estaremos mas cerca de Custom Firmware permanente? [babas]

Salu2!


No van por ahi los tiros, el exploit del bootron no sirve para crear un cfw permanente ya que no tiene ningun bug el bootloader, Lo que permite el exploit del bootloader es poder hacer un dump de esos archivos y con ellos se puede obtener la nueva keyX de la new 3ds y asi poder tener emunand en 9.7

Saludos
Al final tantos avances en forma de rumores y así no sale nada. cawento
Raugo escribió:No van por ahi los tiros, el exploit del bootron no sirve para crear un cfw permanente ya que no tiene ningun bug el bootloader, Lo que permite el exploit del bootloader es poder hacer un dump de esos archivos y con ellos se puede obtener la nueva keyX de la new 3ds y asi poder tener emunand en 9.7

Saludos

Ciertamente, no se que es lo que se podría llegar a sacar del bootrom exploit, pero en GBAtemp algunos usuarios comentaban que podría servir para hacer downgrade por hardware de cualquier versión (y modelo de consola) y que Nintendo no podría taparlo mediante una actualización de firmware, solo podrían taparlo con una nueva revisión de la consola.
Si esto sale adelante sería la hostia, algo así como el despertar del cementerio del gran DAX [plas]

Salu2!
En teoria si se puede acceder al exploit si que se podria donwgradear por hardware ya que permite acceder a las keys de la consola por lo que se podria descifrar la nand y usar una nand donada para hacer el downgrade.

Saludos
egarrote escribió:
Raugo escribió:No van por ahi los tiros, el exploit del bootron no sirve para crear un cfw permanente ya que no tiene ningun bug el bootloader, Lo que permite el exploit del bootloader es poder hacer un dump de esos archivos y con ellos se puede obtener la nueva keyX de la new 3ds y asi poder tener emunand en 9.7

Saludos

Ciertamente, no se que es lo que se podría llegar a sacar del bootrom exploit, pero en GBAtemp algunos usuarios comentaban que podría servir para hacer downgrade por hardware de cualquier versión (y modelo de consola) y que Nintendo no podría taparlo mediante una actualización de firmware, solo podrían taparlo con una nueva revisión de la consola.
Si esto sale adelante sería la hostia, algo así como el despertar del cementerio del gran DAX [plas]

Salu2!


Guau, por mi de lujo, mi 3DS esta en el cajon esperando para ello [babas]
Feroz El Mejor escribió:
egarrote escribió:
Raugo escribió:No van por ahi los tiros, el exploit del bootron no sirve para crear un cfw permanente ya que no tiene ningun bug el bootloader, Lo que permite el exploit del bootloader es poder hacer un dump de esos archivos y con ellos se puede obtener la nueva keyX de la new 3ds y asi poder tener emunand en 9.7

Saludos

Ciertamente, no se que es lo que se podría llegar a sacar del bootrom exploit, pero en GBAtemp algunos usuarios comentaban que podría servir para hacer downgrade por hardware de cualquier versión (y modelo de consola) y que Nintendo no podría taparlo mediante una actualización de firmware, solo podrían taparlo con una nueva revisión de la consola.
Si esto sale adelante sería la hostia, algo así como el despertar del cementerio del gran DAX [plas]

Salu2!


Guau, por mi de lujo, mi 3DS esta en el cajon esperando para ello [babas]


lo malo que seria por hardware y cualquiera no podria hacerlo. Solo serviria para quien tubiera mano para ello, o fuese preparado en electronica. Por eso estoy haciendo un curso de electronica, para esto y muchas cosas mas.
hay alguna noticia del MSET Downgrade??
richter64 escribió:hay alguna noticia del MSET Downgrade??

En la 2DS no se puede.
No pierdo la esperanza de que haya un MSET para 2ds [buuuaaaa]
Yo tengo una duda: en una 2DS recién comprada se puede usar el GO exploit con el navegador? O hace falta actualizar algo para ello? Hablo de que no tengo ningún cartucho y mi intención es instalar el rx modificado.
JesTelZz escribió:Yo tengo una duda: en una 2DS recién comprada se puede usar el GO exploit con el navegador? O hace falta actualizar algo para ello? Hablo de que no tengo ningún cartucho y mi intención es instalar el rx modificado.

Depende del firmware que tenga esa 2DS, si el último número es superior a 7 quiere decir que tiene instalado el navegador, por lo que si podrás utilizar el GO Exploit o cualquier otro que requiera el uso de este.

Salu2!
Como puedo ejecutar el MSET en Version 7.1
gersonmarinm escribió:Como puedo ejecutar el MSET en Version 7.1

Tendrías que downgradearlo con rxMode (aunque ahora mismo no se puede acceder a los servidores de Nintendo por lo que lo tendrás difícil).
Que tal amigos,

Después de mucho averiguar, no he hallado la solución a mi duda. Tengo una old 3ds XL [sysnand 4.2U] [cfw Rxtools c/emunand 9.9], y me gusta jugar juegos DS de vez en cuando, y como uso MSET exploit, cada vez que juego algún juego de DS debo volver a instalar el exploit para entrar a emuNAND.

Al día de hoy ¿existirá alguna forma de entrar a emuNAND, sin internet, y haciendo uso del modo DS? o bien ¿existe algún modo de que el MSET exploit no se desinstale tras jugar juegos de DS?

Cualquier información será bien recibida, un saludo a todos
Ackermann escribió:Que tal amigos,

Después de mucho averiguar, no he hallado la solución a mi duda. Tengo una old 3ds XL [sysnand 4.2U] [cfw Rxtools c/emunand 9.9], y me gusta jugar juegos DS de vez en cuando, y como uso MSET exploit, cada vez que juego algún juego de DS debo volver a instalar el exploit para entrar a emuNAND.

Al día de hoy ¿existirá alguna forma de entrar a emuNAND, sin internet, y haciendo uso del modo DS? o bien ¿existe algún modo de que el MSET exploit no se desinstale tras jugar juegos de DS?

Cualquier información será bien recibida, un saludo a todos

El problema es que al parecer cada vez que se carga el Modo DS se restaura esta parte que se vuelve "inválida", para así decirlo, tras instalar el exploit. Con las New 3DS es posible evitarlo, poniendo el abecedario o un mensaje muy largo en el Perfil de DS, pero con las old 3DS no es posible.
Entiendo. ¿y habrá otra forma de ejecutar emuNAND sin internet? revisé el tutorial para hacerlo con Android, pero igual requiere de internet (el móvil)
Ackermann escribió:Entiendo. ¿y habrá otra forma de ejecutar emuNAND sin internet? revisé el tutorial para hacerlo con Android, pero igual requiere de internet (el móvil)

A parte del MSET Exploit, el Ninjhax/OOTHax.
Ackermann escribió:Entiendo. ¿y habrá otra forma de ejecutar emuNAND sin internet? revisé el tutorial para hacerlo con Android, pero igual requiere de internet (el móvil)

No es que se requiera de Internet, puesto que se crea una red y un servidor local que carga los archivos necesarios para el exploit. Pero sí puede ser algo engorroso tener que depender de una red wifi a cada momento (con o sin internet).
fmkid escribió:
Ackermann escribió:Entiendo. ¿y habrá otra forma de ejecutar emuNAND sin internet? revisé el tutorial para hacerlo con Android, pero igual requiere de internet (el móvil)

No es que se requiera de Internet, puesto que se crea una red y un servidor local que carga los archivos necesarios para el exploit. Pero sí puede ser algo engorroso tener que depender de una red wifi a cada momento (con o sin internet).


La verdad es que el xploit con Android me viene bien, pero no me funciona. Tengo la app en mi teléfono, activo el servidor (RXtools.dat), pero cuando escaneo la imagen en la 3ds me dice que no me encuentro conectado a internet (lo mismo si anoto la URL manualmente)

Estoy en 4.2U.

Si sabes cómo arreglar el error sería fantástico!

Saludos
Ackermann escribió:La verdad es que el xploit con Android me viene bien, pero no me funciona. Tengo la app en mi teléfono, activo el servidor (RXtools.dat), pero cuando escaneo la imagen en la 3ds me dice que no me encuentro conectado a internet (lo mismo si anoto la URL manualmente)

Estoy en 4.2U.

Si sabes cómo arreglar el error sería fantástico!

Saludos

¿Tienes los datos móviles activados?
116 respuestas
1, 2, 3