Hacking How do they find exploits/pull files/etc?

[accountname]

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.

 

[Rinnux]

I would like to know as well. If anyone cares to share their knowledge it would be appreciated

 

[Rydian]

Stuff like this.
http://gbatemp.net/threads/nand-flash-dump-3ds-xl.350668/

Or this.

Or using homebrew and telling it to manually read from all sorts of locations and save anything read to a file on the SD/whatever?

Or are you talking about opening ROMs to edit them?

 

[nukeboy95]

Stuff like this.
http://gbatemp.net/threads/nand-flash-dump-3ds-xl.350668/

Or this.

Or using homebrew and telling it to manually read from all sorts of locations and save anything read to a file on the SD/whatever?

Or are you talking about opening ROMs to edit them?

and using this

 

[cloud1250000]

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?

 

[FAST6191]

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.

 

[cloud1250000]

Wow fast, such an amazing post *-*

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

 

[Duo8]

A question I've been wondering:
Why are crashes/freezes considered exploits? What can you do with them?

 

[cloud1250000]

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.

 

[Rydian]

A question I've been wondering:
Why are crashes/freezes considered exploits? What can you do with them?

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!".

 

[cloud1250000]

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

 

[FAST6191]

Add a paragraph about reverse engineering and it would be perfect xD (didn't see one)

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.

 

[cloud1250000]

well I was talking about compiled stuff, reversing them and reading through the machine code

 

[ichichfly]

Stuff like this.
http://gbatemp.net/threads/nand-flash-dump-3ds-xl.350668/

Or this.

Or using homebrew and telling it to manually read from all sorts of locations and save anything read to a file on the SD/whatever?

Or are you talking about opening ROMs to edit them?

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

 

[cloud1250000]

still It gives a nice idea about how it's done.. no?

 

[shepe]

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

 

[FAST6191]

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

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.