Code:
<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? :P
...
<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.
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.
@
Xdqwerty:
