Hacking Question regarding DS profile exploit

[Coto]

The mset haxx vuln exist, even in 6.3, but no ARM9 vuln exist.

Have not tried to do something with mset haxx >4.5, because i don't have useful ROP-gadget's. And yes, mset haxx works a bit different after the 5.X update, but it is not fixed or updated since 5.X.

what do you mean, a bit different?

 

[profi200]

The return adress is stored at an other place on the mset stack. But it is still exploitable.

 

[Foxi4]

In other words, the exploit is still there but the necessary offset changed, which is why it no longer works.

The way DS profiles work is simple - if Profile #1 is corrupt, the system loads Profile #2 which is where the last authenticated iteration of the Profile is stored. This means that if you inject code with enough offset to push it into the area of memory where executables (binaries) are stored into Profile #2 and purposely corrupt Profile #1, the system will attempt to fix Profile #1 by loading the Profile #2 and rebooting, assuming that the data stored there is valid. Upon a reboot, the system has a binary in the exeution area so it executes it. The exploit is still there, but due to firmware changes, the offset has changed.

 

[drfsupercenter]

Out of curiosity, is this exploit fully documented somewhere? I'm curious how it even works - running something in DS mode and getting access to 3DS native features.

Is it basically a stack smash of sorts, running from DS software?

 

[Foxi4]

Out of curiosity, is this exploit fully documented somewhere? I'm curious how it even works - running something in DS mode and getting access to 3DS native features.

Is it basically a stack smash of sorts, running from DS software?

The DS sandbox is only used to write data into NVRAM, the actual exploit is taking place solely in 3DS Mode. Currently there is no known method of elevating access or leaving the sandbox.

For more information, browse 3DBrew or ask on IRC.

 

[drfsupercenter]

Is there a page on 3DBrew about how the NVRAM exploit works? Not that I know enough to do anything with it, just curious

 

[profi200]

That's not how it works. The first profile is overwritten with an ROP-chain. The second works, but the lengh field is set to high, so the system settings app reads to much data and overwrites the stack. Gateway places an adress to an ROP-gadget at exactly the place on the second profile, which overwrites the return adress. The 3DS jumps to that location and executes the code. After the execution the ROP-gadget pops the next adress from the ROP in the pc (program counter) register and the 3DS jumps to the next ROP-gadget. One of the next ROP-gadget reads the first profile and place it in RAM. Then it sets the stack pointer to that location and the processor continues execution on the second ROP-chain. This ROP-chain then mounts the SD card as YS:/, reads 0x9000 bytes from the Launcher.dat file, decrypts the data using OpenSSL and finally sets sp to the adress of the third ROP-chain.

 

[Oxybelis]

Is not it possible to dump 6.3 memory now and analyse kernel calls for bugs?
How did they found out so many kernel bugs in PSP?

 

[Foxi4]

That's not how it works. The first profile is overwritten with an ROP-chain. The second works, but the lengh field is set to high, so the system settings app reads to much data and overwrites the stack. Gateway places an adress to an ROP-gadget at exactly the place on the second profile, which overwrites the return adress. The 3DS jumps to that location and executes the code. After the execution the ROP-gadget pops the next adress from the ROP in the pc (program counter) register and the 3DS jumps to the next ROP-gadget. One of the next ROP-gadget reads the first profile and place it in RAM. Then it sets the stack pointer to that location and the processor continues execution on the second ROP-chain. This ROP-chain then mounts the SD card as YS:/, reads 0x9000 bytes from the Launcher.dat file, decrypts the data using OpenSSL and finally sets sp to the adress of the third ROP-chain.

I tried to simplify the nomenclature so that everyone understands what's going on behind the scenes. Long story short, one profile overwrites the other. But yes, your description is more "educational".

 

[profi200]

It's not very complicated, if you read a bit about ARM assembly

The ground idea is to chain code chunks to do what you want. If you have enough, you can theoretically program an homebrew app, but it is very limited.

Is not it possible to dump 6.3 memory now and analyse kernel calls for bugs?

You can dump memory with an ROP-chain, but you need ROP-gadgets. In 6.3 they are on completely different locations. If you try to access kernelcode, the kernel calls kernelpanic(), because you have no permission to access it at all.

 

[Coto]

ARMv7 extensions are hardcoded on ARM11, that's why i was asking. LR address is reachable from user mode, read only, writing xn to 0 would require an entrypoint.

>LR is stored
>ROP so your resemble a new address,and store it somewhere(patch) (user mode).
>find the segfaulted link register, so branch LR+patch

 

[Oxybelis]

You can dump memory with an ROP-chain, but you need ROP-gadgets. In 6.3 they are on completely different locations. If you try to access kernelcode, the kernel calls kernelpanic(), because you have no permission to access it at all.

Gateway installed 6.3 emunand has kernel access to memory, is not it?

 

[profi200]

What they do is, loading firm0 from the emuNAND partition, decrypt it, patch it and run it. This is possible, because they have kernelmode access on <=4.5.

 

[Oxybelis]

What they do is, loading firm0 from the emuNAND partition, decrypt it, patch it and run it. This is possible, because they have kernelmode access on <=4.5.

If it's possible to decrypt 6.3 firmware or patch its kernel, unencrypted 6.3 firmware can be dumped and analysed, is not it?

 

[yifan_lu]

If it's possible to decrypt 6.3 firmware or patch its kernel, 6.3 firmware can be dumped and analysed, is not it?

Afaik, some people have 6.3 dumped and analyses. For the rest of us, it's not possible until either gateway releases a way to run homebrew, someone leaks a 6.3 memory dump, or someone releases a way to hack 4.5 publically.

 

[profi200]

Yeah, if you have kernelmode code execution.

Note: You can't install a patched firm0 because of the broken RSA signature (=bricked 3DS). You can only run it from an booted system.

 

[Oxybelis]

Afaik, some people have 6.3 dumped and analyses. For the rest of us, it's not possible until either gateway releases a way to run homebrew, someone leaks a 6.3 memory dump, or someone releases a way to hack 4.5 publically.

I do not think Gateway would release homebrew loader with kernel access. It'll be the end of GW

 

[yifan_lu]

Can someone check if gateway installer still freezes/crashes DS profile in system menu on 7.0? If not, they fixed it.

 

[The Free Coder]

Since the official games also run in 3ds mode, wouldn't 3ds mode code execution be enough to run homebrew games?

 

[profi200]

Ok, got the confirmation. mset haxx is finally fixed. So, no way to use Gateway and clones above 4.5 anymore. All firmwares above 4.5 have no kernelmode vuln and 7.0 finally fixed the entrypoint.