Hacking Question How does one start with console hacking?

[Tybus]

Hello guys!.

I've been on the hacking scene as an expectator since long time ago (I think my first experience was with the Nintendo Wii).

Back with the 3ds I tried to be more active and made a homebrew game (It's ugly coded, but still some progress https://github.com/Tybus/3Dfrogr if you want to check it out)... But still nothing that made me feel like really doing anything (That's why it didn't took me long to get out of the developing comunity)

But right now it's like a new chance to start again. Bought my Nintendo switch, played with it for a while... and ofc I don't think I could be the first one to hacking (Because my lack of experience, and because all the amazing hackers doing their effort atm). But maybe I could go back to an older console and try to hack it.

Here you can find a bit of my backgroud:

Electrical Engineering student (Computers and networks emphasis) (Currently on my last year)
Knowledge in computer organization and design
Knowledge in programing (C, C++, Java, Python, TCL, (Maybe some others that I'm missing), mips assembly, Motorola S12 assembly)
Knowledge in hadware design (Both structural and logical design) (I do even know how to Verilog) -> In fact, I even work at a semiconductor company (Working on layout but still)

I feel like I have the capabilities to learn some reverse engineering (I know I still have a lot to learn, but I really dont know how)

if someone could really help me out and teach me how can I start that'll be lovely

 

[FAST6191]

Most of the old consoles are already hacked. That said a lot of things made for them were made with chips for the day and a lot of the designs carried through (prior to everdrive the designs for flash carts still resembled ones from the time).
If you wanted to remake them for all the nice chips we have today (I don't want to say an arduino could beat an FPGA from 1992 but I would not be surprised if it could) then that might be nice.

If you want to make a nice pinout of all the controllers and some open source libraries that would be nice.

A lot of the video out mods that do RGB do odd things like r2r ladders as a poor man's DAC (see the N64 RGB mods), make a design using a real dac that is likely to be manufactured for the next 12 years or so and it will be appreciated rather than trying to find close pairs in high tolerance resistors. Going a bit further if you wanted to make screen capture devices for the handhelds then many would enjoy that.

On the switch and co then while I can sit here and tell people about debug/bed of nails pads for control inputs I have done very little. If you take the time to wire up your scope or function generator into one and make it do something cool (we have seen whole game screens be decoded in real time on consumer hardware and then used to make robot players) then fantastic. Equally while the dock has a nice HDMI out if you wanted to make a screen capture for the tablet then you might make some friends as side by side shots for things would be an interesting one.

For something like a macbook I have a nice schematic I can look at to find that I need to replace this resistor/inductor/trace. For consoles you have a few things (see something like fuses on the DS, or the megadrive/genesis audio capacitors) but for the most part we fire the parts cannon or get a donor board. This is getting harder as the years go on, and things become retro and cool/expensive as a result. If you want to buy a bunch of broken ones, or do obvious modes of failure (someone wires up a power adapter wrong and of course there is no diode protection in most things) and accelerated failure.

Most modern hacking does seem to need heavy OS stuff. That said someone that knows their way around a high frequency scope probe is a rare person.

Some of those aren't hacking per se but they will allow you to flex your reverse engineering and failure analysis muscles, not to mention do some things that are going to be very much welcomed by the community.

 

[Tybus]

Thanks for your reply... I get what you are saying, but as you say, replicating a modchip for older consoles won't help me at all with newer ones because the hacking nowadays seem to be heavy OS stuff. I would also like to learn how to find vulns in software, for example, I could try to replicate the Twilight Princess hack, but how do I start in that way?, is Wiibrew info to get started?

Btw, the video capture device sounded like a very intersting proyect.

 

[starfox5194]

I'm more of a hobbyist coder and had similar questions you had. I have never had my hand at hacking, but I've picked up some things in my research. I would reccomed two things.

First: learn assembly and how "the stack" works. There are lots of YouTube videos.

Second and more importantly: get the source code for the twilight princess hack or the smash bros brawl hack. I think there are both overflow exploits that could be better understood by learning about "the stack".

After that, start basic. Make sure you can compile the twilight princess hack from source. Read all the code comments. Maybe you can optimize a step? Try reducing the code for the hack down to the bare necessities. I would try all of this using a dolphin emulator to avoid the frustration of potentially killing a Wii.

 

[FAST6191]

Hackmii (same peeps responsible at some level for wiibrew) had a source release and discussion of the various ways the hacks worked. https://hackmii.com/2010/01/the-stm-release-exploit/ is one such thing. The Wii is not a great option though for while it is OS based... there is a reason not every game supports voice chat, why there are but a handful of game updates and they are all launched from the menu, why most things involve a reset to get back to the menu and so forth.

Find the C3 presentations on the PS3, the 3ds and also more general current PC stuff (return oriented programming is a good one), there was an old one on the 360 but that notably ignored the thing that led to various later hacks.
I also like things like


https://vvvv.org/blog/17-mistakes-microsoft-made-in-the-xbox-security-system was a fascinating read.

Follow through enough of those and you start to learn the things to look for. You want to get the OS called to analyse, most of the time they will be encrypted but maybe not in RAM so build a RAM dumper, maybe it is encrypted in RAM so force a key (amusingly the 360 had a randomness checker), find a key, find a side channel... or maybe find that it is based on an already written OS, but now you have a hypervisor to get past.
Equally when you are watching those then especially for the the PS3 and 3ds ones watch when the people hand off to others. A lot of things are like that these days. Or if you prefer in your electronics stuff how often do you want to use some kind of radio/antenna only to remember that radio is its own world unto itself, you then take the reference design/suggested design, say thank you to the people that know how to make all that and use that rather than making your own?
Don't let me discourage you though. For this sort of thing running into and getting over your own walls is how a lot of it gets done.

 

[Tybus]

Okey. Thanks for your help. I think I'll have a look to the sources of the twilight hack. Perhaps any other sources I could review for that matter?

 

[ChaosRipple]

Well, first you need to attach some wires to your console, extract the internal nand data, and then use IDA Pro to reverse engineer the code. Also knowing how general operating systems work would be a requirement. Then, after you know exactly how the operating system on the console works, you come up with a flaw and write code to execute it. Not only does reverse engineering take a lot of time (especially if it's something an operating system), it also takes a lot of thought and creativity to discover something no one else has, at least publicly.

Edit:
Also, the concept of memory is important too.

 

[FAST6191]

Well, first you need to attach some wires to your console, extract the internal nand data, and then use IDA Pro to reverse engineer the code. Also knowing how general operating systems work would be a requirement. Then, after you know exactly how the operating system on the console works, you come up with a flaw and write code to execute it. Not only does reverse engineering take a lot of time (especially if it's something an operating system), it also takes a lot of thought and creativity to discover something no one else has, at least publicly.

Edit:
Also, the concept of memory is important too.

What if the NAND is encrypted (most is these days, and even when not it is probably signed), what if IDA does not have the instruction set for the console in question (memory addresses are one thing and you can ignore that to an extent, also there are other reverse engineering tools out there), while NAND might be nice do you want to go there before figuring out the boot chain?

 

[ChaosRipple]

What if the NAND is encrypted (most is these days, and even when not it is probably signed), what if IDA does not have the instruction set for the console in question (memory addresses are one thing and you can ignore that to an extent, also there are other reverse engineering tools out there), while NAND might be nice do you want to go there before figuring out the boot chain?

Yes you're right on that part. The idea is that you follow the console as close as you can, from when you push the power button. If the NAND is encrypted, it will be decrypted somehow and then you'd need to find out where and how it's decrypted. There's going to be a lot of reverse engineering - hardware or software, the former which will cost you at least one console. I mentioned the concept of memory, not just the addresses but how software would organize memory, etc.

 

[Im_Sarcastic_JackAzz]

What kind of wires like a usb cable attached to the console to a laptop or is it more complex like hardware hacking? Also how would I connect the console to my computer to find software vulnerabilities? Im a noob to all this stuff just looking to learn also sorry bad grammar.

 

[link270]

What kind of wires like a usb cable attached to the console to a laptop or is it more complex like hardware hacking? Also how would I connect the console to my computer to find software vulnerabilities? Im a noob to all this stuff just looking to learn also sorry bad grammar.

This thread is talking about things a little more advanced than that. I.E. sliding to the consoles main board to extract the Nand data and figuring out how to decrypt it via reverse engineering.

 

[guily6669]

You can always try to join a hacking team, but I think they are just closed groups and dont want anyone there ...

But the C# emulator 4 example I think they are adding more people, maybe with the Switch emulator you could understand more about it, but a lot of stuff is still unknown there, specially GPU wise.
https://gbatemp.net/threads/experimental-switch-emulator-in-c.495982/

 

[Im_Sarcastic_JackAzz]

You can always try to join a hacking team, but I think they are just closed groups and dont want anyone there ...

But the C# emulator 4 example I think they are adding more people, maybe with the Switch emulator you could understand more about it, but a lot of stuff is still unknown there, specially GPU wise.
https://gbatemp.net/threads/experimental-switch-emulator-in-c.495982/

I'm not interested on joining a group but thanks for the link. All I want to know is how do they find software bugs without a debugger and how do they extract the intenal nand data?

 

[:-infern:]

Hey,

Interested in hacking too. I've reading up on alot of vulnerabilities and how they work. I've spoken to hackers and I've worked in the industry, however I've never given a go at consoles.

The best way to learn is to practise. This means pikc up an older, vulnerable console and start reading up on its exploits. Then physically try write them yourself and test it. Do this for as many exploits through the consoles lifetime to see how far you get.

I would recommend that you start on the PSP or DS. The DS is the most easiest to pwn due to its tragic buffer overflows. Then from there move to the PSP and see how that works. To hack, you will need to understand the device it's hardware.

Don't start targeting new consoles, you are bound to fail. Reason is because the learning barrier is too high. Learn how previous consoles got hacked, do the hacks yourself. Then move on once you're comfortable.

Here are some reason I've found online. If you would like, you can join me and we can start looking at these together, that way wwe'l progress quicker.

https://cturt.github.io/DS-exploit-finding.html
https://github.com/Haaroon/console_exploits
https://github.com/bryankeller/PSP-Exploit-Super-Collapse-3
https://github.com/Cryptogenic/Exploit-Writeups/

 

[Im_Sarcastic_JackAzz]

This thread is talking about things a little more advanced than that. I.E. sliding to the consoles main board to extract the Nand data and figuring out how to decrypt it via reverse engineering.

What wires or equipment do I need to extract the nand data and my main question was how do I display it on my computer I.E. connect my consoles memory to my PC to reverse engineer it? Im really intrested in console hacking an am a noob at I appreciate the help.

--------------------- MERGED ---------------------------

Hey,

Interested in hacking too. I've reading up on alot of vulnerabilities and how they work. I've spoken to hackers and I've worked in the industry, however I've never given a go at consoles.

The best way to learn is to practise. This means pikc up an older, vulnerable console and start reading up on its exploits. Then physically try write them yourself and test it. Do this for as many exploits through the consoles lifetime to see how far you get.

I would recommend that you start on the PSP or DS. The DS is the most easiest to pwn due to its tragic buffer overflows. Then from there move to the PSP and see how that works. To hack, you will need to understand the device it's hardware.

Don't start targeting new consoles, you are bound to fail. Reason is because the learning barrier is too high. Learn how previous consoles got hacked, do the hacks yourself. Then move on once you're comfortable.

Here are some reason I've found online. If you would like, you can join me and we can start looking at these together, that way wwe'l progress quicker.

https://cturt.github.io/DS-exploit-finding.html
https://github.com/Haaroon/console_exploits
https://github.com/bryankeller/PSP-Exploit-Super-Collapse-3
https://github.com/Cryptogenic/Exploit-Writeups/

I understand what you are saying but im just intrested in the knowledge. Knowledge is power you know

 

[:-infern:]

What wires or equipment do I need to extract the nand data and my main question was how do I display it on my computer I.E. connect my consoles memory to my PC to reverse engineer it? Im really intrested in console hacking an am a noob at I appreciate the help.

--------------------- MERGED ---------------------------



I understand what you are saying but im just intrested in the knowledge. Knowledge is power you know

Well I've basically given you all the best resources. Whatever you do or say is really Upto you. Vast majority of people don't get into the console hacking scene because it's too much work or its just out of their depth.

 

[EclipseSin]

Honestly, I don't understand the whole process myself, but I've come to build myself a few pointers following others footsteps. May be helpful to others if not you, though this isn't going to get you hacking anything in of itself. Also feel free to correct me, I'm no good at RE without someone laying shit out before me.

It seems like you already understand most of what you need to do though. I'd start by looking at what processor you're dealing with and seeing what other components might be attached, such as memory controllers. It can be important because you may be able to find bugs on your own inside the white papers/datasheets that make an opening for you -- whether that be a side-channel attack, UAF, Black-box etc. Those should also help to get you reading what's going on in a disassembler/debugger, but you will still be blind and have to figure out what functions are doing unless they were nice enough to leave you labels and stuff. Once you know what it is doing to things in memory, you can see if it 'forgets' to clear something useful such as a service, whether this be due to not clearing, an instruction before the call/function to clear this useful area actually invalidating the function itself from firing (may not be accurate lol)

If you look at web browsers as an example, they all have memory leaks somewhere, whether it be a page, add-on, background service. Find something useful in them is another. I'd guess more-so with today's protection. If you look on switchbrew, you'll see that there are unpatched bugs still, but they are also still not useful and may never be.

For closed systems with encryption, it seems important to find an entrypoint that allows you to run privileged code, or elevate yourself from within a user-mode bug to access that level of trust (i.e. usermode exploit, then kernel exploit).

Sorry if not helpful. Just high and wanted to post on this good thread.

 

[Im_Sarcastic_JackAzz]

Honestly, I don't understand the whole process myself, but I've come to build myself a few pointers following others footsteps. May be helpful to others if not you, though this isn't going to get you hacking anything in of itself. Also feel free to correct me, I'm no good at RE without someone laying shit out before me.

It seems like you already understand most of what you need to do though. I'd start by looking at what processor you're dealing with and seeing what other components might be attached, such as memory controllers. It can be important because you may be able to find bugs on your own inside the white papers/datasheets that make an opening for you -- whether that be a side-channel attack, UAF, Black-box etc. Those should also help to get you reading what's going on in a disassembler/debugger, but you will still be blind and have to figure out what functions are doing unless they were nice enough to leave you labels and stuff. Once you know what it is doing to things in memory, you can see if it 'forgets' to clear something useful such as a service, whether this be due to not clearing, an instruction before the call/function to clear this useful area actually invalidating the function itself from firing (may not be accurate lol)

If you look at web browsers as an example, they all have memory leaks somewhere, whether it be a page, add-on, background service. Find something useful in them is another. I'd guess more-so with today's protection. If you look on switchbrew, you'll see that there are unpatched bugs still, but they are also still not useful and may never be.

For closed systems with encryption, it seems important to find an entrypoint that allows you to run privileged code, or elevate yourself from within a user-mode bug to access that level of trust (i.e. usermode exploit, then kernel exploit).

Sorry if not helpful. Just high and wanted to post on this good thread.

Thanks for the help

 

[51mmz0rz]

You can try microcorruption, and there are some decent explanations of the solutions on people's blogs:

https://microcorruption.com/login

http://writing.hcarver.com/fun with assembly/2015/01/10/fun-with-assembly-1/

 

[FAST6191]

I'm not interested on joining a group but thanks for the link. All I want to know is how do they find software bugs without a debugger and how do they extract the intenal nand data?

Your write your own debugger

The CPU type will tend to be known so that is easy enough, if you can get your hands on the SDK then that might tell you something (modern ones not so much but hey), you might have a hardware debugger attached so you can see where it returns to upon reset or a few choice actions. If you have disassembled code you can usually also see jump locations and start to get a picture of memory from those.

There are a few weak points common in most systems (save game checking, file hash checking, debug/factory restore routines and all the other things you see being used in hacks) so you find those and check them until you find one you can exploit.

NAND these days tends to be encrypted but you might try finding when it is not encrypted (see something like the original xbox hotswap), equally you probably don't care about the game partition/data at first and instead want the menu and all its code so see what you can find in RAM. Similarly you may look to find ones not out of the factory, things used in repair shops, things given to developers, prototypes and other things that might not have end stage security but will have things you can look at.
On top of this you also have side channel attacks which got popular again in recent years and can yield keys
Consider also that during this you don't need a reliable method for end users -- spending a week getting an exploit to run is no big deal.