1. YoshiInAVoid

    OP YoshiInAVoid GBAtemp Advanced Fan
    Banned

    Joined:
    Jan 10, 2011
    Messages:
    560
    Country:
    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

    Joined:
    Oct 25, 2008
    Messages:
    467
    Country:
    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

    Joined:
    Jan 10, 2011
    Messages:
    560
    Country:
    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

    Joined:
    Apr 28, 2007
    Messages:
    663
    Country:
    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

    Joined:
    Jul 4, 2013
    Messages:
    43
    Country:
    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 Advanced Member
    Newcomer

    Joined:
    Jan 7, 2006
    Messages:
    53
    Country:
    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

    Joined:
    Jul 4, 2013
    Messages:
    43
    Country:
    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

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

    lightenup Member
    Newcomer

    Joined:
    Jul 4, 2013
    Messages:
    43
    Country:
    Serbia, Republic of
  10. Naridar

    Naridar Excelsior!
    Member

    Joined:
    Oct 26, 2008
    Messages:
    344
    Country:
    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

    Joined:
    Oct 18, 2009
    Messages:
    682
    Country:
    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

    Joined:
    Jul 4, 2013
    Messages:
    43
    Country:
    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

    Joined:
    Feb 24, 2009
    Messages:
    26
    Country:
    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

    Joined:
    Jul 4, 2013
    Messages:
    43
    Country:
    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.
Draft saved Draft deleted
Loading...

Hide similar threads Similar threads with keywords - Questions, Gateway, exploit