Hacking Questions about Gateway exploit

[YoshiInAVoid]

It seems 3DBrew isn't listing the exploit, despite presumably being the same one Neimod and Yellows8 found last year.

1. Which exact DS setting is vulnerable to the buffer overflow? EG: The nickname? Birthday? Favorite color? Etc...

2. The Loader.dat file, this is just compiled ARM 11, no? Is there a header? What exactly does it contain which disables real 3DS games from showing up and allows the Gateway card?

Unless I'm missing something, it seems one could modify the exploit to run a ROM from the SD card rather than running the Loader.dat code to do whatever enables the Gateway card. Or alternately, change the Loader.dat code to run a ROM on the SD card.

 

[megazig]

3DBrew does list it and has for months. see too long nickname length message length

 

[YoshiInAVoid]

Ah, the "to long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings cause (System Settings/Other Settings/Profile/Nintendo DS Profile to crush) (this is still 3DS mode)" under the current efforts section. So I see they still haven't fully worked it out yet.

 

[yifan_lu]

Essentially, the patcher uses the message to overflow and write a ROP payload into 3ds stack memory. That rop payload will load Loader.dat and also modify it to run (right now it's obfuscated in some way). Because we don't have a 3ds ram dump or decrypted NAND dumps, we can't see what the rop gadgets they used, and therefore can only guess at how Loader.dat is constructed. I have a hunch that even if we do deobfuscate Loader.dat we will find very complex code that tries to hide what the kernel exploit is, because 1MB can do a lot of work.

 

[lightenup]

if its done clever (i.e., in a way that someone w/o access to the 3ds sw cannot do much with it), that Loader.dat is also a ROP-chain and that what looks like messed up/obfuscated arm code in there are just patches to the 3ds software loaded in RAM.

 

[dmdsoftware]

Obfuscation is not security though. One who writes code to obfuscates what is really going on is bound to have someone figure it out. Many people have aptitudes/abilities to see through them easily. It might take a while before someone comes across it, or rather, someone decides to release what they know. Look at the PS3 as an example.

 

[lightenup]

Obfuscation is not security though.

Assuming we deal mostly with ROP chains the 'obfuscation' is mainly in our lack of knowledge about the 3ds software which has been kept away from the public for a pretty long time. You can picture a ROP chain as a sequence of calls into the *exisiting* 3ds software.. without knowing what gets called and how, I'd say that obfuscation is pretty secure.

\edit: yellows8 just confirmed an additional 'obfuscation'-layer: Loader.dat is also AES encrypted (and a second ROP chain): goodbye easy entry point for custom code execution.

 

[YoshiInAVoid]

Does the 3DS use ASLR? Or anything else to prevent certain memory being executable like OS' do?

 

[lightenup]

no ASLR, but XN.
http://www.3dbrew.org/wiki/Memory_layout

 

[Naridar]

\edit: yellows8 just confirmed an additional 'obfuscation'-layer: Loader.dat is also AES encrypted (and a second ROP chain): goodbye easy entry point for custom code execution.

Wait a minute, does that mean that the gateway team somehow encrypted the file with a key so that the 3DS can decrypt it with its' common key? Or is loader.dat not created by them?

EDIT: What I mean is, did they get their hands on the private key (or a spoof of it) somehow?

 

[CollosalPokemon]

Wait a minute, does that mean that the gateway team somehow encrypted the file with a key so that the 3DS can decrypt it with its' common key? Or is loader.dat not created by them?

EDIT: What I mean is, did they get their hands on the private key (or a spoof of it) somehow?

No, they probably use their own key.

Remember, they're using an exploit so they don't need the loader to be signed or encrypted with a retail key since they have control over it (the obfuscation and encryption is probably for 1 of 2 reasons*, or maybe both).

*probably :

1) To make it harder for Nintendo to figure out what they did (although Nintendo sort of figured out what they did, since it doesn't work on 5.1+, it's probably to slow down being permanently blocked on higher firmware, if it even has a tiny chance of becoming compatible that is).
2) To make it harder for other flashcart teams to clone the cart and attempt to pass it off as their own.

 

[lightenup]

1) To make it harder for Nintendo to figure out what they did (although Nintendo sort of figured out what they did, since it doesn't work on 5.1+, it's probably to slow down being permanently blocked on higher firmware, if it even has a tiny chance of becoming compatible that is).
2) To make it harder for other flashcart teams to clone the cart and attempt to pass it off as their own.

Yes, they probably even only use an arbitrary data string found somewhere in the original 3ds sw to mainly keep others out from reusing their ROP chain based exploit. 'Loader.dat' presumably contains lots of RAM patches to
-) make their red cart work
-) tie the red cart to the process
-) keep the system still tightly closed by preventing custom code execution
That RAM patches ROP chain would have revealed a certain structure, so they encrypted it.

I don't think that they did any of this to prevent Nintendo finding out about their method. Nintendo will close the security bug related to the user settings overflow and be done with it. imo the flaw is still open up until 6.2.: The ROP chain is only very 3ds software specific and it's for sure quite some work to get it right for any other vulnerable software version too.

 

[goldensox]

Yes, they probably even only use an arbitrary data string found somewhere in the original 3ds sw to mainly keep others out from reusing their ROP chain based exploit. 'Loader.dat' presumably contains lots of RAM patches to
-) make their red cart work
-) tie the red cart to the process
-) keep the system still tightly closed by preventing custom code execution
That RAM patches ROP chain would have revealed a certain structure, so they encrypted it.

I don't think that they did any of this to prevent Nintendo finding out about their method. Nintendo will close the security bug related to the user settings overflow and be done with it. imo the flaw is still open up until 6.2.: The ROP chain is only very 3ds software specific and it's for sure quite some work to get it right for any other vulnerable software version too.

Ok, this is what I got from you explanations:
1. The loader.dat thing is encrypted so Nintendo and other teams don't crack it.
2. This also ties the crack to the red cart.

So like, if they crack loadert.dat maybe we can execute other kinds of codes? And maybe a CFW could be devised out of it, because in the way you said it looks like the custom code makes the red cart necessay when actually it is not.

 

[lightenup]

Ok, this is what I got from you explanations:
1. The loader.dat thing is encrypted so Nintendo and other teams don't crack it.

mostly others; for Nintendo this is irrelevant, because they just fix the buffer overflow bug.

2. This also ties the crack to the red cart.

So like, if they crack loadert.dat maybe we can execute other kinds of codes? And maybe a CFW could be devised out of it, because in the way you said it looks like the custom code makes the red cart necessay when actually it is not.

The group behind GW revealed only the buffer overflow and the basic exploitation method (ROP chains). However, without the 3ds software (that the ROP chains take advantage of) their exploit cannot be 'cracked' or reused for other stuff like custom code execution. Unfortunately the only method known to get to the 3ds software is neimod's ram dumping setup.