How do they find exploits/pull files/etc?

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

  1. accountname
    OP

    accountname Newbie

    Newcomer
    1
    0
    Aug 15, 2013
    United States
    I don't know if this is exactly the right part of the forum for this, but I've been curious.

    How do homebrew authors, flash cart makers, and the like, actually get files from their systems and view the contents within them?

    I wanted to try to limit this to a Google search but I couldn't think of how to phrase it, and I doubt there are many comprehensive sources.
     
  2. Rinnux

    Rinnux GBAtemp Advanced Fan

    Member
    655
    313
    Aug 3, 2010
    United States
    I would like to know as well. If anyone cares to share their knowledge it would be appreciated
     
  3. Rydian

    Rydian Resident Furvertâ„¢

    Member
    27,883
    8,111
    Feb 4, 2010
    United States
    Cave Entrance, Watching Cyan Write Letters
  4. nukeboy95

    nukeboy95 Leave luck to heaven.

    Member
    2,273
    1,086
    Aug 24, 2010
    United States
    not sure
    and using this

    [​IMG]
     
    RedCoreZero likes this.
  5. cloud1250000

    cloud1250000 Advanced Member

    Newcomer
    78
    8
    Dec 18, 2008
    Canada
    Once they found an exploit using this kind of hardware, they can create a tool(homebrew) to get exactly what they want quickly. This kind of hardware is useful to start the exploitation. You can expect a ram dumper and a nand dumper in this type of hardware. When they run the glitch they found, with the ram dumper, they see what's happening in the memory, I think they also have some kind of thing to get actively the instructions sent to the cpu. That way, they are trying to influence the memory buffer and send specific instruction to the cpu. Then they can launch the unofficial code they have thrown in the ram.

    In the case of the 3ds, it's hard to send unofficial code in memory, they need more access to do so :/ so they are using rop command and that way, they are using the code already in the system to do what they want... It needs more creativity then anything else ahah. (Well skills are needed too ahah)

    The picture in ridyan post is purely amazing, it comes from who?
     
  6. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,696
    9,564
    Nov 21, 2005
    United Kingdom
    I wrote a basic overview of various things http://gbatemp.net/threads/some-hacking-concepts-and-links.287721/

    For the most part though there are methods you can use that I can break down into about 8 steps said list is not that useful unless you know most of what goes with it. It changes a tiny bit if the would be defender uses some more modern defences too.

    All that said many hackers that break into things quite like talking about such things at length at various conferences.
    http://www.youtube.com/user/ChRiStIaAn008/videos?view=1&sort=dd&shelf_index=2 is a nice channel that contains a lot of them.
     
    accountname and pelago like this.
  7. cloud1250000

    cloud1250000 Advanced Member

    Newcomer
    78
    8
    Dec 18, 2008
    Canada
    Wow fast, such an amazing post *-*

    Add a paragraphe about reverse engineering and it would be perfect xD (didn't see one)
     
  8. Duo8

    Duo8 I don't like video games

    Member
    3,440
    1,140
    Jul 16, 2013
    A question I've been wondering:
    Why are crashes/freezes considered exploits? What can you do with them?
     
  9. cloud1250000

    cloud1250000 Advanced Member

    Newcomer
    78
    8
    Dec 18, 2008
    Canada
    They are potential exploit, if there is a crash, it's because something in the memory want wrong. If you can control what's happening in the memory, you have an exploit.
     
    Duo8 likes this.
  10. Rydian

    Rydian Resident Furvertâ„¢

    Member
    27,883
    8,111
    Feb 4, 2010
    United States
    Cave Entrance, Watching Cyan Write Letters
    In general, a crash/freeze is not an exploit, it's just that (like cloud said), if you can manipulate certain things it can become one... but most crashes (and especially freezes) are useless on modern systems (since not everything is in a single block of data anymore, and there's NX/DEP and stuff to specifically stop the way people tend to exploit things).

    People are just used to bugs being exploited in systems like the PSP/Vita/360, etc. and know that a crash or freeze is a bug. So people make the mental jump "Crash = exploit!".
     
    Duo8 likes this.
  11. cloud1250000

    cloud1250000 Advanced Member

    Newcomer
    78
    8
    Dec 18, 2008
    Canada
    Rop chain, which consists of exploiting the actual information contained in the memory (without pushing your own code)

    You can use this kind of thing to pass over the nx protection... But it's kinda limited... And that's why you need to be creative ahah
     
  12. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,696
    9,564
    Nov 21, 2005
    United Kingdom
    Reverse engineering in what sense? The materials stuff seemed kind of outside the scope of that post (and most of the time reads have a set of callipers and know the basics of materials science), much of the security/electronics stuff I thought was kind of implied and software wise.... well we have a whole other thread/doc for that http://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-rewritten-for-2012.73394/

    Unless you meant something like "normal order of operations for cracking a system"

    Find where the code comes from (CD, SD, USB, memory, custom cartridge, LAN, Flash memory somewhere on PCB....). Try to get a copy of this for analysis.
    Can you mimic it or subvert it to read from somewhere else? This might be a later step.
    What type of processor/instruction set does the device use? Realistically it will probably be a well known one (intel x86 family, intel 8080/Z80, 68K, some form of powerpc, ARM...)
    Can you inject your own code in there anywhere?
    Is there any security preventing you from doing as you please? Attack the implementation (quite possible but not surefire) or attack the hardware controlling it (harder and more expensive but usually doable if you are willing to invest enough). There may also be levels of code where you can only do a limited amount without cracking higher up in the system (see userland vs kernel).
    Feel out the rest of the hardware and setup (graphics, network, controls, storage, any BIOS/firmware/inbuilt libraries/hypervisor commands) and document them. You may also want to alter/remake the BIOS/firmware/library/hypervisor stuff according to your particular whims.

    Congratulations you have a hacked device.

    By the way for the others reading something like that would be a variation on the 8 steps thing I was on about earlier. The order might change and it might instead resemble more or a "choose your own adventure" type book or flow chart in practice but that is basically it.

    Edit. Wait you did not mean "this is a protocol debugger", "this is a digital storage oscilloscope", "this is how to read the numbers on top of chips" type thing? If so then I would probably say http://www.eevblog.com/episodes/ <- watch all of it and continue watching it as he puts new stuff out.
     
    Cyberdrive likes this.
  13. cloud1250000

    cloud1250000 Advanced Member

    Newcomer
    78
    8
    Dec 18, 2008
    Canada
    well I was talking about compiled stuff, reversing them and reading through the machine code
     
  14. ichichfly

    ichichfly GBAtemp Advanced Fan

    Member
    618
    159
    Sep 23, 2009
    Gambia, The
    There is a DSi in the picture. Not a 3ds.
    For DS flashcards read this http://nocash.emubase.de/gbatek.htm (you need more to run DS cards on a DSi/3DS) for 3DS this http://www.3dbrew.org/wiki/Main_Page DSi http://www.dsibrew.org/wiki/Main_Page
     
  15. cloud1250000

    cloud1250000 Advanced Member

    Newcomer
    78
    8
    Dec 18, 2008
    Canada
    still It gives a nice idea about how it's done.. no?
     
  16. shepe

    shepe GBAtemp Regular

    Member
    113
    1
    Feb 2, 2009
    swindon
    So the main one that got the Wii was a buffer overflow, this initially worked because of an over site by the developers where they failed to sanitise user input, so where you could name your horse whatever you liked if you entered a sufficiently long enough string then you would overwrite the portion of memory allocated with that, the exploit overwrote it with custom code and then through the guy you had to turn and talk to then trying to use the newly entered horses name it overwrite the stack and caused the stack pointer to jump to exploit code, this was then combined with another cryptographic flaw in the wii to allow us to sign packages and install the homebrew channel.

    The big console manufacturers have learnt a lot from the last round of consoles and how they were exploited and I guess this is why the likes of the 3ds have taken so long to get anywhere with.

    Im sure 99% of people have already seen this but the source code for the wii hacks was released a long while back if your interested

    http://git.infradead.org/users/segher/savezelda.git
     
  17. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,696
    9,564
    Nov 21, 2005
    United Kingdom
    That risks oversimplifying the process a bit -- even on the Wii it was a meeting of several failures, and continued bad practice after that, which led to its domination.

    You have the save. Though technically it was signed per console too (albeit with a key stored on the console itself).
    You have the backwards compatibility leading to a reveal of the public key thanks to uncleared memory. This gains decryption.
    You have the trucha bug where an improper check was used allowing bypass of signing/fakesigning.

    Later hacks did some other things as well with regards to the IOS and boot2 stuff but that is later stuff and not quite so relevant to the "find" part of this thread.

    All that despite I am sure Team Twiizers and the like would be the first to tell us that despite flirting with good security practice even the theoretical implementation leaves a lot to be desired, and as such I am sure your "learnt a lot" comment will ring true.