Questions about Gateway exploit

Discussion in '3DS - Flashcards & Custom Firmwares' started by YoshiInAVoid, Aug 9, 2013.

  1. YoshiInAVoid
    OP

    YoshiInAVoid GBAtemp Advanced Fan

    Banned
    560
    336
    Jan 10, 2011
    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.
     
  2. megazig

    megazig SU

    Member
    467
    93
    Oct 25, 2008
    United States
    3DBrew does list it and has for months. see too long nickname length message length
     
  3. YoshiInAVoid
    OP

    YoshiInAVoid GBAtemp Advanced Fan

    Banned
    560
    336
    Jan 10, 2011
    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.
     
  4. yifan_lu

    yifan_lu @yifanlu

    Member
    642
    1,325
    Apr 28, 2007
    United States
    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.
     
  5. lightenup

    lightenup Member

    Newcomer
    43
    60
    Jul 4, 2013
    Serbia, Republic of
    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.
     
  6. dmdsoftware

    dmdsoftware Member

    Newcomer
    21
    3
    Jan 7, 2006
    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.
     
    YoshiInAVoid and yuyuyup like this.
  7. lightenup

    lightenup Member

    Newcomer
    43
    60
    Jul 4, 2013
    Serbia, Republic of
    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.
     
    f0rCe likes this.
  8. YoshiInAVoid
    OP

    YoshiInAVoid GBAtemp Advanced Fan

    Banned
    560
    336
    Jan 10, 2011
    Does the 3DS use ASLR? Or anything else to prevent certain memory being executable like OS' do?
     
  9. lightenup

    lightenup Member

    Newcomer
    43
    60
    Jul 4, 2013
    Serbia, Republic of
  10. Naridar

    Naridar Excelsior!

    Member
    328
    83
    Oct 26, 2008
    Hungary

    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?
     
  11. CollosalPokemon

    CollosalPokemon ばん。。。かい

    Member
    682
    342
    Oct 18, 2009
    United States

    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.
     
    f0rCe likes this.
  12. lightenup

    lightenup Member

    Newcomer
    43
    60
    Jul 4, 2013
    Serbia, Republic of
    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.
     
  13. goldensox

    goldensox Member

    Newcomer
    26
    8
    Feb 24, 2009
    United States

    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.
     
  14. lightenup

    lightenup Member

    Newcomer
    43
    60
    Jul 4, 2013
    Serbia, Republic of
    mostly others; for Nintendo this is irrelevant, because they just fix the buffer overflow bug.
    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.
     
    goldensox likes this.