Post by Fatman X. Jones on Dec 16, 2012 20:52:42 GMT -5
So, according to reputable sources at GBATemp, we possibly have the first true exploit for the Nintendo 3DS that has been found to work! Famed Team Twiizers member yellows8 has found the exploit. Team Twiizers is known for their work in making Nintendo Wii homebrew possible, so it's from a reputable source.
<delroth> [06:10:31] yellows8: finally found a kernel exploit or is that still done through ram haxx / ROP?
<yellows8> [06:10:54] not the kernel
<delroth> [06:11:23] trust chain broken?
...
<yellows8> [06:11:37] no
...
<yellows8> [06:47:04] there's only *two* vulns currently known which allow code exec and is usable from arm11 userland ROP. since the two vulns are basically identical, both would surely be fixed in a single sysupdate.
<yellows8> and the 3D LED is disabled, because that text was displayed by patching text in errdisp, then triggering an error. could try to figure out where in errdisp the LED is disabled however.
<yellows8> it's still unknown how to use the gfx service to display anything.
SOURCE:GBATemp
<delroth> [06:10:31] yellows8: finally found a kernel exploit or is that still done through ram haxx / ROP?
<yellows8> [06:10:54] not the kernel
<delroth> [06:11:23] trust chain broken?
...
<yellows8> [06:11:37] no
...
<yellows8> [06:47:04] there's only *two* vulns currently known which allow code exec and is usable from arm11 userland ROP. since the two vulns are basically identical, both would surely be fixed in a single sysupdate.
<yellows8> and the 3D LED is disabled, because that text was displayed by patching text in errdisp, then triggering an error. could try to figure out where in errdisp the LED is disabled however.
<yellows8> it's still unknown how to use the gfx service to display anything.
Basically, the 3DS uses a security mechanism where only certain parts of memory can be executed. This means you can't load your own code and execute it. However, you can use a technique called "ROP", which as I understand it basically means executing parts of code already loaded in executable memory. So for example, say you want to run a particular instruction; you find somewhere that instruction is loaded, then do smash the stack and make execution jump to that location. Obviously, this isn't an ideal situation as you are limited to using what is loaded in memory, and it's not very straight forward. So the best option would be to use ROP to execute a kernel exploit, disable the security system and thus allow executing code from anywhere in memory (or at least from somewhere you can influence from code). Then you can load code into memory and run it freely.
However, yellows8 said it's not a kernel exploit, but then says there are two vulnerabilities that allow code execution from ROP; I guess there must be some other way of doing it other than a kernel exploit. I don't know the technical details of the vulnerability being exploited here.
It's worth noting that this is *two* exploits; one userland exploit (which allows ROP; this is probably a savegame exploit or something similar), and the other vulnerability to allow code execution (this vulnerability is exploited via ROP).
EDIT: Oh yeah, and I should have mentioned that as seen above, there are only two known vulnerabilities for code execution, and both would most likely be patched at once, so I'd guess it's unlikely there'll be a release unless another, more unique, vulnerability found for yellows8 (and those he chooses to share with) to use for further exploration once the released exploit is patched.
However, yellows8 said it's not a kernel exploit, but then says there are two vulnerabilities that allow code execution from ROP; I guess there must be some other way of doing it other than a kernel exploit. I don't know the technical details of the vulnerability being exploited here.
It's worth noting that this is *two* exploits; one userland exploit (which allows ROP; this is probably a savegame exploit or something similar), and the other vulnerability to allow code execution (this vulnerability is exploited via ROP).
EDIT: Oh yeah, and I should have mentioned that as seen above, there are only two known vulnerabilities for code execution, and both would most likely be patched at once, so I'd guess it's unlikely there'll be a release unless another, more unique, vulnerability found for yellows8 (and those he chooses to share with) to use for further exploration once the released exploit is patched.
<yellows8>the code which patched errdisp was loaded from SD card btw.
<shlee>Save game? random binary? FS glitch?
<yellows8>savegame for the arm11 userland ROP.
...
<yellows8>it's a gamecard savegame yes.
<shlee>Save game? random binary? FS glitch?
<yellows8>savegame for the arm11 userland ROP.
...
<yellows8>it's a gamecard savegame yes.
SOURCE:GBATemp
