Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
Zam Wesell
Mar 22, 2009

[Zam is suddenly shot in the neck by a toxic dart; Anakin and Obi-Wan see a "rocket-man" take off and fly away, and Zam dies]

hubris.height posted:

if i can manage to suffer through the 5ish hours of grinding money i can get plat on it this weekend.

cool life ur leading

Adbot
ADBOT LOVES YOU

stoutfish
Oct 8, 2012

by zen death robot
just watch the ending on youtube

Dodoman
Feb 26, 2009



A moment of laxity
A lifetime of regret
Lipstick Apathy
the anime in this thread shames me

01011001
Dec 26, 2012

stoutfish posted:

just watch the ending on youtube

hubris.height
Jan 6, 2005

Pork Pro
the ending is easy to get

the problem is that once i get it i will have gotten every trophy along the way except one. i will be one trophy from a platinum. just gotta grind 5 hours to finish that last piece off. if i don't do it, the shame will be overwhelming, and if i do the shame will also be overwhelming

Vintersorg
Mar 3, 2004

President of
the Brendan Fraser
Fan Club



saucepanman posted:

the anime in this thread shames me

stoutfish
Oct 8, 2012

by zen death robot

hubris.height posted:

the ending is easy to get

the problem is that once i get it i will have gotten every trophy along the way except one. i will be one trophy from a platinum. just gotta grind 5 hours to finish that last piece off. if i don't do it, the shame will be overwhelming, and if i do the shame will also be overwhelming

idk, play an hour a week while listening to a podcast

01011001
Dec 26, 2012

hubris.height posted:

the ending is easy to get

the problem is that once i get it i will have gotten every trophy along the way except one. i will be one trophy from a platinum. just gotta grind 5 hours to finish that last piece off. if i don't do it, the shame will be overwhelming, and if i do the shame will also be overwhelming

if either outcome brings shame, pick the one that doesnt take 5 hours imo

Space-Pope
Aug 13, 2003

by zen death robot

saucepanman posted:

the anime in this thread shames me
tbf its not like anything interesting is coming out of big western dev houses

Space-Pope
Aug 13, 2003

by zen death robot
also: another e3, another complete and utter lack of anything related to dragon quest

gj square-enix u loving incompetent idiots i bet ffxv is gonna suck poo poo w/ that kingdom hearts retard at the helm

Space-Pope
Aug 13, 2003

by zen death robot
dont even get me started on the lack of a new ogre battle

Katana Gomai
Jan 14, 2007

"Thus," concluded Miyamoto, "you must give up everything you have to be my disciple."

ff15 will still sell a million billion copies though, because teenagers and fat girls exist

prolly faster to learn Japanese than wait for western dq releases

Star War Sex Parrot
Oct 2, 2003

Space-Pope posted:

dont even get me started on the lack of a new ogre battle
i would like to get you started on this

hubris.height
Jan 6, 2005

Pork Pro

Katana Gomai posted:

ff15 will still sell a million billion copies though, because teenagers and fat girls exist

prolly faster to learn Japanese than wait for western dq releases

i am neither of those and will day one purchase it

that said, not even i was foolish enough to buy ffxii-13 waifu edition

Space-Pope posted:

also: another e3, another complete and utter lack of anything related to dragon quest

gj square-enix u loving incompetent idiots i bet ffxv is gonna suck poo poo w/ that kingdom hearts retard at the helm

tbfp and giant bomb both said jap games would probably be announced at that other big conference

Space-Pope
Aug 13, 2003

by zen death robot

Star War Sex Parrot posted:

i would like to get you started on this
ogre battle was a brilliant game that was amazing in its depth and complexity. removing direct unit control in battle made army management a top priority, and the myriad of things that affected it was awesome, in addition to the tons of choices u got to make during the course of the game that would affect both ur army and the final outcome of the game. it was legit ahead of its time

then they had the designer (who also made tactics ogre, vagrant story, and ff tactics) work on ff12 at which point the dude kinda went nuts

Liver Disaster
Mar 31, 2012

no more tears

im also not a teenager or a fat girl but ffxv looks really good and also fun and also im gay so im gonna buy it
e: ive also been told repeatedly in the past week that im not fat at all so i guess im doin p good

Liver Disaster fucked around with this message at 23:19 on Jun 13, 2014

Star War Sex Parrot
Oct 2, 2003

Space-Pope posted:

ogre battle was a brilliant game that was amazing in its depth and complexity. removing direct unit control in battle made army management a top priority, and the myriad of things that affected it was awesome, in addition to the tons of choices u got to make during the course of the game that would affect both ur army and the final outcome of the game. it was legit ahead of its time

then they had the designer (who also made tactics ogre, vagrant story, and ff tactics) work on ff12 at which point the dude kinda went nuts
i'm still expecting the PSP Tactics Ogre remake to make its way to iOS eventually. that would be neat

Katana Gomai
Jan 14, 2007

"Thus," concluded Miyamoto, "you must give up everything you have to be my disciple."

[citation needed] on all you buff adult ff lovers

Liver Disaster
Mar 31, 2012

no more tears

Katana Gomai posted:

[citation needed] on all you buff adult ff lovers

buff is the goal, the hermit life is the journey
im sure if i had friends i wouldnt even have time for jrpgs, let alone the final fantasy series

Knuc U Kinte
Aug 17, 2004

Star War Sex Parrot posted:

i'm still expecting the PSP Tactics Ogre remake to make its way to iOS eventually. that would be neat

This thread is for real Gamers, and real Gamers don't look forward to games making it to iOS, capiche?

Star War Sex Parrot
Oct 2, 2003

sorry

stoutfish
Oct 8, 2012

by zen death robot

Liver Disaster posted:

im also not a teenager or a fat girl but ffxv looks really good and also fun and also im gay so im gonna buy it
e: ive also been told repeatedly in the past week that im not fat at all so i guess im doin p good

you are a fat teenage girl on the inside

Liver Disaster
Mar 31, 2012

no more tears

stoutfish posted:

you are a fat teenage girl on the inside

oh yeah definitely, like 100% but thats not the point
on the outside im a tall vaguely interesting mountain man

theyre not dolls

Fabricated
Apr 9, 2007

Living the Dream
so a coworker I play games with gifted me and one of his friends with titanfall since he likes the game a lot

50 gigs later I am on my 5th attempt to see if the weird hosed up matchmaking thing will let me proceed to the later campaign levels so I can unlock some of the most basic poo poo in the game

yeah if you didn't know there's a 'campaign' mode that just adds some silly story poo poo to the opening/closing of maps and you play them in a certain order and completing this whole stupid loving thing is required to be able to unlock specific titans and some otehr poo poo and since no one now plays it and their matchmaking is hosed still you p much can't complete it great game glad someone wasted like $20-$30 or whatever giving it to me

stoutfish
Oct 8, 2012

by zen death robot
ded game

tis fun

corn in the bible
Jun 5, 2004

Oh no oh god it's all true!
Stoutfish who did you piss off to have that avatar

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe
beep beep NINTENDO EFFORTPOST COMING THROUGH WOW LOOK THE gently caress OUT

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe
I have not done one of these in a while.

Let's start with a recap. Nintendo wanted to make a new cheap console and have this fancy new controller, but also keep backwards compatibility with the Gamecube. They rearranged the internals of the hardware around, but mostly kept it the same. They upgraded the Flipper chip to the Hollywood, and in the process added a bunch of confusing new features for gamedevs as part of the "HW2" upgrade.

To support all the new hardware like the network interfaces, Bluetooth, USB, etc. they added a whole other ARM core that runs its own custom OS called "IOS". Unlike the Gamecube, they have a proper OS with apps ("channels"), and some custom functionality as part of the "System Menu". They also wanted to have an update system so they could add new features to the system at any point. So, they need a secure way of making sure that nobody else's code gets on the Wii. If they blindly downloaded an executable over the network and installed it or ran it, then nope, game over. You can now have people run custom code, and then when that happens, you basically own the system.

Remember, all the "game" code (including the System Menu) runs on the PPC, and that has raw access to all the hardware, including all the memory in the system, the GPU, the NAND flash, and other stuff. And if you have code running on the PPC, you can get stuff running on the ARM core too: just install your payload into an IOS version slot, and then tell the ARM core to run that. Boom, you're toast. (We'll talk about IOS versions in a bit, since that's the other hilarity).

Surprisingly, the Wii doesn't really have multiple defenses against rogue code running either. If a game is running, it's law. It can access the entire NAND flash through /dev/flash, and it can access the NAND FS with /dev/fs. There is no attempt to make sure that games can only access their own savefiles or stuff like that, that's all done through the official SDK and licensing and compliance. The system is toast once any unlicensed code is running.

So, they did what most people do: they use a signing infrastructure. They maintain a "secret" key somewhere on the ROM, and whenever trying to load any channel or app, the System Menu makes sure that the code has the correct signature. Since Nintendo manufacturers all discs, they can pull this off: gamedevs submit a final master image to Nintendo along with cover art and and disc art, and Nintendo signs it and presses a disc.

This should be completely unbreakable, as long as you aren't stupid.

However

HOWEVER

Nintendo is stupid. They completely hosed up. Completely. hosed. Up.

This is the biggest security bug known to man. It's the most colossal fuckup you could ever do, and it renders the security check completely useless. It's known as the "Trucha signing bug", as it was first published by a forum user who goes by the handle "Trucha", even though it had been privately found several times before.

Basically, Nintendo uses a combination of RSA encryption and RSA signature checking to make sure that the disc is actually from Nintendo. At the beginning of every disc is a little piece of data known as the "Title Metadata" (TMD) which tells the system what the name of the game is, what files are on the disc, among others. This is what's checked.

Since RSA only works on a maximum message length of 256 bytes (if you have an RSA-2048 key, that is), in order to compute a signature, you first hash it. Nintendo uses SHA-1 here to compute a 20-byte hash of the content, and then encrypts that with their private key.

What's supposed to happen is that the Wii will read the TMD from the disc, hash it by itself, and then decrypt Nintendo's value with its public key, and then make sure that its hash and the encrypted hash on the disc are the same. If they are, then we know that Nintendo created the disc, since they're the only ones who could have encrypted that same hash.

However, when the Wii compares the hash it computed with the hash on the disc, it uses strncmp instead of memcmp. For the non-programmers here, that means that whenever it sees a 0 as part of the hash, it thinks that the hash just ended. As long as it matched up to the point of the first 0, then the Wii thinks that the signatures are the same. This is even the case if it starts with a 0: all we have to make sure that the decrypted hash and the hash of the content both start with 0.

The TMD also has a lot of empty space which is never read, because the format is aligned to 32 byte boundaries. This leaves us with a lot of random unused bytes. We can keep modifying this data randomly until we get a 0 as the first byte. This can be done in seconds on a modern computer, however theoretically it can take an infinite amount of time (it doesn't).

Now for the second part. We have to modify the encrypted RSA bytes so that it decrypts to a 0 in the start. Since we don't know what will result in a 0 after encryption, we could just brute force like we did the SHA-1 hash and decrypt over and over until we get a 0, but the designers of RSA left us a secret present.

You see, RSA is based on multiplication. Lots and lots of multiplication. Ars Technica has a really good approachable introduction here:

quote:

In RSA, this maximum value (call it max) is obtained by multiplying two random prime numbers. The public and private keys are two specially chosen numbers that are greater than zero and less than the maximum value (call them pub and priv). To encrypt a number, you multiply it by itself pub times, making sure to wrap around when you hit the maximum. To decrypt a message, you multiply it by itself priv times, and you get back to the original number. It sounds surprising, but it actually works. This property was a big breakthrough when it was discovered.

You might notice something here. Anything times 0 is 0, right? So if we take a bunch of 0s and decrypt them, it will always result in 0s, no matter the public or private keys.

So, we no longer have to do any RSA decryptions at all. It doesn't really matter, since it would have only taken us a few more seconds anyway, but it's still another hilarious piece of incompetence that falls out.

This is how a good majority of Nintendo homebrew initially worked, including the Homebrew Channel. Nintendo later patched it out, but only in the latest version of IOS. The bug remained in older versions of IOS for at least two years. I'll talk about IOS version slots next time.

haveblue
Aug 15, 2005



Toilet Rascal

Suspicious Dish posted:

I have not done one of these in a while.

Let's start with a recap. Nintendo wanted to make a new cheap console and have this fancy new controller, but also keep backwards compatibility with the Gamecube. They rearranged the internals of the hardware around, but mostly kept it the same. They upgraded the Flipper chip to the Hollywood, and in the process added a bunch of confusing new features for gamedevs as part of the "HW2" upgrade.

To support all the new hardware like the network interfaces, Bluetooth, USB, etc. they added a whole other ARM core that runs its own custom OS called "IOS". Unlike the Gamecube, they have a proper OS with apps ("channels"), and some custom functionality as part of the "System Menu". They also wanted to have an update system so they could add new features to the system at any point. So, they need a secure way of making sure that nobody else's code gets on the Wii. If they blindly downloaded an executable over the network and installed it or ran it, then nope, game over. You can now have people run custom code, and then when that happens, you basically own the system.

Remember, all the "game" code (including the System Menu) runs on the PPC, and that has raw access to all the hardware, including all the memory in the system, the GPU, the NAND flash, and other stuff. And if you have code running on the PPC, you can get stuff running on the ARM core too: just install your payload into an IOS version slot, and then tell the ARM core to run that. Boom, you're toast. (We'll talk about IOS versions in a bit, since that's the other hilarity).

Surprisingly, the Wii doesn't really have multiple defenses against rogue code running either. If a game is running, it's law. It can access the entire NAND flash through /dev/flash, and it can access the NAND FS with /dev/fs. There is no attempt to make sure that games can only access their own savefiles or stuff like that, that's all done through the official SDK and licensing and compliance. The system is toast once any unlicensed code is running.

So, they did what most people do: they use a signing infrastructure. They maintain a "secret" key somewhere on the ROM, and whenever trying to load any channel or app, the System Menu makes sure that the code has the correct signature. Since Nintendo manufacturers all discs, they can pull this off: gamedevs submit a final master image to Nintendo along with cover art and and disc art, and Nintendo signs it and presses a disc.

This should be completely unbreakable, as long as you aren't stupid.

However

HOWEVER

Nintendo is stupid. They completely hosed up. Completely. hosed. Up.

This is the biggest security bug known to man. It's the most colossal fuckup you could ever do, and it renders the security check completely useless. It's known as the "Trucha signing bug", as it was first published by a forum user who goes by the handle "Trucha", even though it had been privately found several times before.

Basically, Nintendo uses a combination of RSA encryption and RSA signature checking to make sure that the disc is actually from Nintendo. At the beginning of every disc is a little piece of data known as the "Title Metadata" (TMD) which tells the system what the name of the game is, what files are on the disc, among others. This is what's checked.

Since RSA only works on a maximum message length of 256 bytes (if you have an RSA-2048 key, that is), in order to compute a signature, you first hash it. Nintendo uses SHA-1 here to compute a 20-byte hash of the content, and then encrypts that with their private key.

What's supposed to happen is that the Wii will read the TMD from the disc, hash it by itself, and then decrypt Nintendo's value with its public key, and then make sure that its hash and the encrypted hash on the disc are the same. If they are, then we know that Nintendo created the disc, since they're the only ones who could have encrypted that same hash.

However, when the Wii compares the hash it computed with the hash on the disc, it uses strncmp instead of memcmp. For the non-programmers here, that means that whenever it sees a 0 as part of the hash, it thinks that the hash just ended. As long as it matched up to the point of the first 0, then the Wii thinks that the signatures are the same. This is even the case if it starts with a 0: all we have to make sure that the decrypted hash and the hash of the content both start with 0.

The TMD also has a lot of empty space which is never read, because the format is aligned to 32 byte boundaries. This leaves us with a lot of random unused bytes. We can keep modifying this data randomly until we get a 0 as the first byte. This can be done in seconds on a modern computer, however theoretically it can take an infinite amount of time (it doesn't).

Now for the second part. We have to modify the encrypted RSA bytes so that it decrypts to a 0 in the start. Since we don't know what will result in a 0 after encryption, we could just brute force like we did the SHA-1 hash and decrypt over and over until we get a 0, but the designers of RSA left us a secret present.

You see, RSA is based on multiplication. Lots and lots of multiplication. Ars Technica has a really good approachable introduction here:


You might notice something here. Anything times 0 is 0, right? So if we take a bunch of 0s and decrypt them, it will always result in 0s, no matter the public or private keys.

So, we no longer have to do any RSA decryptions at all. It doesn't really matter, since it would have only taken us a few more seconds anyway, but it's still another hilarious piece of incompetence that falls out.

This is how a good majority of Nintendo homebrew initially worked, including the Homebrew Channel. Nintendo later patched it out, but only in the latest version of IOS. The bug remained in older versions of IOS for at least two years. I'll talk about IOS version slots next time.

lol

corn in the bible
Jun 5, 2004

Oh no oh god it's all true!
How does that compare to how, say, Microsoft does signing? Because I know they also sign their discs and that hasn't been circumvented in the pathetic way that Nintendo was.

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe
I also mentioned that the SHA-1 hash is 20 bytes, and the RSA blob is 256 bytes. Normally, you're supposed to put some arbitrary bytes in there, at least, and verify that those are what you put in, since that also makes it harder to brute force the signature. Nintendo doesn't do that and only checks the 20 bytes for the SHA-1 of the entire encrypted 256 byte blob. That's the other piece of the puzzle, because now we can throw out 236 of those bytes.

Signing things, when not done by Nintendo, actually works and is unbreakable. Literally no other company has got it this wrong before. It's an achievement to Nintendo to gently caress it up so badly in two ways. Microsoft is basically like literally every other company in the world for managing to implement this properly.

Stymie
Jan 9, 2001

by LITERALLY AN ADMIN
and yet nintendo didn't allow massive leaks of user data necessitating a year+ long damage control campaign that, at best, resulted in permanent damage to the brand

but sure some dudes made it so you could run emulators that's a real disaster there

stoutfish
Oct 8, 2012

by zen death robot

Stymie posted:

and yet nintendo didn't allow massive leaks of user data necessitating a year+ long damage control campaign that, at best, resulted in permanent damage to the brand

but sure some dudes made it so you could run emulators that's a real disaster there

on the best selling console of all time no less, a big, big gently caress up

haveblue
Aug 15, 2005



Toilet Rascal
breaking the original xbox was actually a really cool hack. some guy looked at its circuitry and found that part of the security code was transported between two chips as part of the verification process, then went to his college electronics lab and built a device from scratch that could read the code as it traveled along the traces on the motherboard while the system booted. once that was in hand there was enough information to build and install a modchip and the rest is history

Star War Sex Parrot
Oct 2, 2003

Suspicious Dish posted:

I have not done one of these in a while.

Let's start with a recap. Nintendo wanted to make a new cheap console and have this fancy new controller, but also keep backwards compatibility with the Gamecube. They rearranged the internals of the hardware around, but mostly kept it the same. They upgraded the Flipper chip to the Hollywood, and in the process added a bunch of confusing new features for gamedevs as part of the "HW2" upgrade.

To support all the new hardware like the network interfaces, Bluetooth, USB, etc. they added a whole other ARM core that runs its own custom OS called "IOS". Unlike the Gamecube, they have a proper OS with apps ("channels"), and some custom functionality as part of the "System Menu". They also wanted to have an update system so they could add new features to the system at any point. So, they need a secure way of making sure that nobody else's code gets on the Wii. If they blindly downloaded an executable over the network and installed it or ran it, then nope, game over. You can now have people run custom code, and then when that happens, you basically own the system.

Remember, all the "game" code (including the System Menu) runs on the PPC, and that has raw access to all the hardware, including all the memory in the system, the GPU, the NAND flash, and other stuff. And if you have code running on the PPC, you can get stuff running on the ARM core too: just install your payload into an IOS version slot, and then tell the ARM core to run that. Boom, you're toast. (We'll talk about IOS versions in a bit, since that's the other hilarity).

Surprisingly, the Wii doesn't really have multiple defenses against rogue code running either. If a game is running, it's law. It can access the entire NAND flash through /dev/flash, and it can access the NAND FS with /dev/fs. There is no attempt to make sure that games can only access their own savefiles or stuff like that, that's all done through the official SDK and licensing and compliance. The system is toast once any unlicensed code is running.

So, they did what most people do: they use a signing infrastructure. They maintain a "secret" key somewhere on the ROM, and whenever trying to load any channel or app, the System Menu makes sure that the code has the correct signature. Since Nintendo manufacturers all discs, they can pull this off: gamedevs submit a final master image to Nintendo along with cover art and and disc art, and Nintendo signs it and presses a disc.

This should be completely unbreakable, as long as you aren't stupid.

However

HOWEVER

Nintendo is stupid. They completely hosed up. Completely. hosed. Up.

This is the biggest security bug known to man. It's the most colossal fuckup you could ever do, and it renders the security check completely useless. It's known as the "Trucha signing bug", as it was first published by a forum user who goes by the handle "Trucha", even though it had been privately found several times before.

Basically, Nintendo uses a combination of RSA encryption and RSA signature checking to make sure that the disc is actually from Nintendo. At the beginning of every disc is a little piece of data known as the "Title Metadata" (TMD) which tells the system what the name of the game is, what files are on the disc, among others. This is what's checked.

Since RSA only works on a maximum message length of 256 bytes (if you have an RSA-2048 key, that is), in order to compute a signature, you first hash it. Nintendo uses SHA-1 here to compute a 20-byte hash of the content, and then encrypts that with their private key.

What's supposed to happen is that the Wii will read the TMD from the disc, hash it by itself, and then decrypt Nintendo's value with its public key, and then make sure that its hash and the encrypted hash on the disc are the same. If they are, then we know that Nintendo created the disc, since they're the only ones who could have encrypted that same hash.

However, when the Wii compares the hash it computed with the hash on the disc, it uses strncmp instead of memcmp. For the non-programmers here, that means that whenever it sees a 0 as part of the hash, it thinks that the hash just ended. As long as it matched up to the point of the first 0, then the Wii thinks that the signatures are the same. This is even the case if it starts with a 0: all we have to make sure that the decrypted hash and the hash of the content both start with 0.

The TMD also has a lot of empty space which is never read, because the format is aligned to 32 byte boundaries. This leaves us with a lot of random unused bytes. We can keep modifying this data randomly until we get a 0 as the first byte. This can be done in seconds on a modern computer, however theoretically it can take an infinite amount of time (it doesn't).

Now for the second part. We have to modify the encrypted RSA bytes so that it decrypts to a 0 in the start. Since we don't know what will result in a 0 after encryption, we could just brute force like we did the SHA-1 hash and decrypt over and over until we get a 0, but the designers of RSA left us a secret present.

You see, RSA is based on multiplication. Lots and lots of multiplication. Ars Technica has a really good approachable introduction here:


You might notice something here. Anything times 0 is 0, right? So if we take a bunch of 0s and decrypt them, it will always result in 0s, no matter the public or private keys.

So, we no longer have to do any RSA decryptions at all. It doesn't really matter, since it would have only taken us a few more seconds anyway, but it's still another hilarious piece of incompetence that falls out.

This is how a good majority of Nintendo homebrew initially worked, including the Homebrew Channel. Nintendo later patched it out, but only in the latest version of IOS. The bug remained in older versions of IOS for at least two years. I'll talk about IOS version slots next time.
ba da ba ba ba i'm lovin it

maniacdevnull
Apr 18, 2007

FOUR CUBIC FRAMES
DISPROVES SOFT G GOD
YOU ARE EDUCATED STUPID

Suspicious Dish posted:

I have not done one of these in a while.

Let's start with a recap. Nintendo wanted to make a new cheap console and have this fancy new controller, but also keep backwards compatibility with the Gamecube. They rearranged the internals of the hardware around, but mostly kept it the same. They upgraded the Flipper chip to the Hollywood, and in the process added a bunch of confusing new features for gamedevs as part of the "HW2" upgrade.

To support all the new hardware like the network interfaces, Bluetooth, USB, etc. they added a whole other ARM core that runs its own custom OS called "IOS". Unlike the Gamecube, they have a proper OS with apps ("channels"), and some custom functionality as part of the "System Menu". They also wanted to have an update system so they could add new features to the system at any point. So, they need a secure way of making sure that nobody else's code gets on the Wii. If they blindly downloaded an executable over the network and installed it or ran it, then nope, game over. You can now have people run custom code, and then when that happens, you basically own the system.

Remember, all the "game" code (including the System Menu) runs on the PPC, and that has raw access to all the hardware, including all the memory in the system, the GPU, the NAND flash, and other stuff. And if you have code running on the PPC, you can get stuff running on the ARM core too: just install your payload into an IOS version slot, and then tell the ARM core to run that. Boom, you're toast. (We'll talk about IOS versions in a bit, since that's the other hilarity).

Surprisingly, the Wii doesn't really have multiple defenses against rogue code running either. If a game is running, it's law. It can access the entire NAND flash through /dev/flash, and it can access the NAND FS with /dev/fs. There is no attempt to make sure that games can only access their own savefiles or stuff like that, that's all done through the official SDK and licensing and compliance. The system is toast once any unlicensed code is running.

So, they did what most people do: they use a signing infrastructure. They maintain a "secret" key somewhere on the ROM, and whenever trying to load any channel or app, the System Menu makes sure that the code has the correct signature. Since Nintendo manufacturers all discs, they can pull this off: gamedevs submit a final master image to Nintendo along with cover art and and disc art, and Nintendo signs it and presses a disc.

This should be completely unbreakable, as long as you aren't stupid.

However

HOWEVER

Nintendo is stupid. They completely hosed up. Completely. hosed. Up.

This is the biggest security bug known to man. It's the most colossal fuckup you could ever do, and it renders the security check completely useless. It's known as the "Trucha signing bug", as it was first published by a forum user who goes by the handle "Trucha", even though it had been privately found several times before.

Basically, Nintendo uses a combination of RSA encryption and RSA signature checking to make sure that the disc is actually from Nintendo. At the beginning of every disc is a little piece of data known as the "Title Metadata" (TMD) which tells the system what the name of the game is, what files are on the disc, among others. This is what's checked.

Since RSA only works on a maximum message length of 256 bytes (if you have an RSA-2048 key, that is), in order to compute a signature, you first hash it. Nintendo uses SHA-1 here to compute a 20-byte hash of the content, and then encrypts that with their private key.

What's supposed to happen is that the Wii will read the TMD from the disc, hash it by itself, and then decrypt Nintendo's value with its public key, and then make sure that its hash and the encrypted hash on the disc are the same. If they are, then we know that Nintendo created the disc, since they're the only ones who could have encrypted that same hash.

However, when the Wii compares the hash it computed with the hash on the disc, it uses strncmp instead of memcmp. For the non-programmers here, that means that whenever it sees a 0 as part of the hash, it thinks that the hash just ended. As long as it matched up to the point of the first 0, then the Wii thinks that the signatures are the same. This is even the case if it starts with a 0: all we have to make sure that the decrypted hash and the hash of the content both start with 0.

The TMD also has a lot of empty space which is never read, because the format is aligned to 32 byte boundaries. This leaves us with a lot of random unused bytes. We can keep modifying this data randomly until we get a 0 as the first byte. This can be done in seconds on a modern computer, however theoretically it can take an infinite amount of time (it doesn't).

Now for the second part. We have to modify the encrypted RSA bytes so that it decrypts to a 0 in the start. Since we don't know what will result in a 0 after encryption, we could just brute force like we did the SHA-1 hash and decrypt over and over until we get a 0, but the designers of RSA left us a secret present.

You see, RSA is based on multiplication. Lots and lots of multiplication. Ars Technica has a really good approachable introduction here:


You might notice something here. Anything times 0 is 0, right? So if we take a bunch of 0s and decrypt them, it will always result in 0s, no matter the public or private keys.

So, we no longer have to do any RSA decryptions at all. It doesn't really matter, since it would have only taken us a few more seconds anyway, but it's still another hilarious piece of incompetence that falls out.

This is how a good majority of Nintendo homebrew initially worked, including the Homebrew Channel. Nintendo later patched it out, but only in the latest version of IOS. The bug remained in older versions of IOS for at least two years. I'll talk about IOS version slots next time.

There are great by the way, thanks

hubris.height
Jan 6, 2005

Pork Pro

haveblue posted:

breaking the original xbox was actually a really cool hack. some guy looked at its circuitry and found that part of the security code was transported between two chips as part of the verification process, then went to his college electronics lab and built a device from scratch that could read the code as it traveled along the traces on the motherboard while the system booted. once that was in hand there was enough information to build and install a modchip and the rest is history

that is really neat

also i enjoyed reading that nintendo effort post that's p interesting

Mad Wack
Mar 27, 2008

"The faster you use your cooldowns, the faster you can use them again"

pseudorandom name
May 6, 2007

my favorite part of breaking the original xbox's security was microsoft relying on the CPU crashing when the instruction pointer incremented past the last possible address in memory, and then they switched from AMD to Intel at the last minute and never bothered to check what Intel CPUs do when the IP increments past the end of the address space

Adbot
ADBOT LOVES YOU

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe
OK. I've teased long enough. Time for IOS versioning and slots.

Basically, Nintendo wants to add new features to your console without breaking old games. A simple example of this is USB keyboard support they added in the System Menu 3.1 update. Since the USB drivers are in IOS, they have to be updated alongside the system to add the new /dev/usb/kbd interface to access the USB keyboard. But the appearance of this might break old games, so what do you do???

Their solution? Fork everything. I linked the TMD before in the last post — the metadata blob at the start of every disc or channel that tells the system about it. Eagle-eyed viewers might have noticed something.

uint64_t ios_title_id; //0x0004

Every game, in its TMD, describes exactly what version of IOS it wants, and the system goes ahead and launches it. The System Menu usually uses IOSx0, like IOS20, IOS30, IOS40, etc. Nintendo channels like the Photo Channel, News Channel, Weather Channel use IOSx1, like IOS21, IOS31, IOS41, etc.

IOS versions are always locked to distributed SDK versions, and again, Nintendo has never acknowledged the existence of IOS or even the ARM core ("Starlet") to developers. As far as developers are aware, if they want new features like USB keyboard functionality, they need to update their SDK.

This is a giant risk for Nintendo, since security bugs in one IOS need to be replicated every single IOS ever released. The Trucha signing bug, as mentioned, took two years before it was fixed in all IOSes, new and old. And even then, they made a mistake. You see, the way IOS updates work, the system makes sure that you can never downgrade an IOS version. So, Nintendo pushed out an updated for all slots with higher version numbers, and you can't overwrite it with older versions.

Official Nintendo Repair Centers got a disk to assist in recovery known as the Wii Backup Disc. This disc is completely unremarkable, it doesn't actually do anything useful. The one thing about it was that it had a secret IOS on it, "IOS16". There's nothing absolutely remarkable about this IOS, other than the fact that Nintendo never published an update to IOS16 as part of the update servers, since they completely forgot about it, and it was an signed IOS where the Trucha signing bug wasn't fixed. So, as a quick way to "reactive" the Trucha signing bug on your computer, you'd leaked take a copy of IOS16, install it, and convince the Wii to reload to IOS16, and now you have your Trucha signing bug reactivated and you can install whatever custom IOS you want.

If you've ever installed homebrew on your Wii, you might remember something about "cIOS" which is usually installed in slot 222, 223, 249, or 250. Nintendo isn't dumb, and eventually pushed stub preventative IOSes with the highest version number so that they could never be replaced, and if they ever loaded, they'd crash your Wii and intentionally brick it in a way where Nintendo recorded that you were trying to install cIOS, you disgusting pirate.

  • Locked thread