gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > RSA Encrypted ROMs?

#30026 - mclysenk - Sat Nov 27, 2004 8:13 pm

I haven't seen this mentioned anywhere else, but on the side of the DS box and on the back of the system it has a little "RSA Secured" logo. Since it seems that wireless is likely unencrypted, it is probable that the ROMs are digitally signed by Nintendo using RSA.

If every ROM comes RSA encrypted, it would be very difficult (impossible) to develop third party roms and run them through the cartridge interface, effectively locking out all third party cartridges. This would do little to stop piracy / emulation, since exact binary copies of games could still be extracted and decrypted using the public key stored on the DS itself.

For the sake of homebrew development, I hope this is not the case, but it should be considered. Otherwise it may become necessary to modify the DS hardware in order to get it to play home made cartridge ROMs.

#30031 - bcforn64 - Sat Nov 27, 2004 9:33 pm

Assuming that the wireless protocols are hacked and someone is able to get a homemade program to be able to upload to the DS and run over wireless transmission we're good.


If you read this acticle:
http://www.gamespot.com/ds/adventure/kiminotamenarashineru/review.html

you'll find that DS software is able to read from the GBA's cartridge port. So a bootloader the could take control of the system wirelessly could be uesd to load homebrew DS software from a GBA flash cart.

#30034 - LOst? - Sat Nov 27, 2004 9:54 pm

you'll find that DS software is able to read from the GBA's cartridge port. So a bootloader the could take control of the system wirelessly could be uesd to load homebrew DS software from a GBA flash cart.[/quote]
But GBA compiled programs can only use GBA hardware right?

#30036 - bcforn64 - Sat Nov 27, 2004 10:01 pm

LOst? wrote:
But GBA compiled programs can only use GBA hardware right?


Correct....well so far, I expect for hackers to be able to get around that. But this isn't GBA software, this is DS software loaded off the network to load DS homebrew off of the GBA cart. The GBA cart would only be used for DS homebrew storage, not for GBA software.

#30046 - tepples - Sat Nov 27, 2004 11:05 pm

But even if you can multiboot the DS wirelessly and then have the multibooted program load DS code from a GBA flash card, then what would you load the bootloader from if you're nowhere near a PC with WiFi? If you expect users of homebrew DS software to purchase and carry laptops just to multiboot the DS, then homebrew developers might as well just give up and make DirectX games to run directly on the laptop.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#30048 - bcforn64 - Sat Nov 27, 2004 11:17 pm

True, but it's a solution to those without DS falsh cards, while waiting for one. Who ever said the PSO Gamecube hack is efficient? It works for the time being though.

#30054 - tepples - Sun Nov 28, 2004 12:26 am

bcforn64 wrote:
Who ever said the PSO Gamecube hack is efficient?

But the lack of any non-PC-tethered solution is one of the reasons that the GameCube never got hacked to be a media player or an emulator the way the Xbox is. It's even worse with portables, as I'd guess a smaller fraction of DS owners play their DS close to a laptop than GameCube owners play their GameCube close to a PC.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#30065 - crossraleigh - Sun Nov 28, 2004 2:01 am

One hopes that the DS is able to run unsigned code as well as signed code. Commercial games would be protected by some challenge-response authentication, and private developers could run there own code unencrypted.

#30067 - tepples - Sun Nov 28, 2004 2:32 am

If a computer requires the computer maker's digital signature for proprietary commercial software but doesn't require a signature for homebrew, then what would prevent a pirate or other license-evader from lying to the system, claiming that a commercial game is a homebrew?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#30079 - crossraleigh - Sun Nov 28, 2004 3:10 am

Well, good point. I guess Nintendo would never set up such a system unless they were confident commercial games couldn't be decrypted.

#30099 - mclysenk - Sun Nov 28, 2004 5:48 am

I think there is a widespread misconception that homebrew development creates piracy. I'm not sure what the guys at Nintendo think about homebrew, but they could think that locking us out will decrease the amount of piracy overall. Even if commercial games could be decrypted and copied (which is guaranteed to happen), without the large toolbase created by the homebrew scene, the pirates will have a harder time.


Well, this is all speculation anyway. We won't know exactly what's going on with the cartridges until someone figures out the pinouts.

#30103 - bcforn64 - Sun Nov 28, 2004 7:48 am

tepples wrote:
bcforn64 wrote:
Who ever said the PSO Gamecube hack is efficient?

But the lack of any non-PC-tethered solution is one of the reasons that the GameCube never got hacked to be a media player or an emulator the way the Xbox is. It's even worse with portables, as I'd guess a smaller fraction of DS owners play their DS close to a laptop than GameCube owners play their GameCube close to a PC.


I.m going to have to agree with you, the main reason why Dreamcast homebrew is so abundent is because it's extremely easy to hack, just pop in a compiled homebrew disc without doing anything else and BAM, you're good to go.

#30107 - PhoenixSoft - Sun Nov 28, 2004 11:15 am

It would be nice if they let code be downloaded from the PC via an official loader so they could distribute demos for free. I'm sure that the ability to send 4 MB files from your PC won't cause rampant piracy...

#30119 - tepples - Sun Nov 28, 2004 4:31 pm

PhoenixSoft wrote:
I'm sure that the ability to send 4 MB files from your PC won't cause rampant piracy...

How big is Super Mario Advance (for GBA) again? And aren't there some GBA ROMs that are on a 32 Mbit (4 MByte) Game Pak but use about half that?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#30120 - rapso - Sun Nov 28, 2004 4:59 pm

mclysenk wrote:
I haven't seen this mentioned anywhere else, but on the side of the DS box and on the back of the system it has a little "RSA Secured" logo. Since it seems that wireless is likely unencrypted, it is probable that the ROMs are digitally signed by Nintendo using RSA.

maybe someone could find out how many bit the RSA key has (or even extract the public key?). maybe it's just 128 or 256 bit, but even 512 could be encrypted by our community ;). I would code the programm and setup a server for a distributed attac :D.

greets
rapso

#30154 - keldon - Sun Nov 28, 2004 11:12 pm

Homebrew development and piracy go hand-in-hand in one sense because what you gain in one you gain in the other. So us creating compilers that perfectly mimmick the DS so that we have a better idea of how it would run also serve as ways to better play commercial games. Even if it was limited to playing only Homebrew games it doesn't take much more than debugging the program and extracting its code that way - although there are ways to block debuggers.

#30323 - rapso - Tue Nov 30, 2004 8:22 am

rapso wrote:

maybe someone could find out how many bit the RSA key has (or even extract the public key?).

*push*

#30354 - ampz - Tue Nov 30, 2004 6:35 pm

The DS cards are not RSA encrypted.
It is some kind of dynamic runtime encryption.

#30361 - tepples - Tue Nov 30, 2004 7:28 pm

RSA Public Key Cryptosystem isn't RSA Security's only product. It's entirely possible that the title key is encrypted with RSA Public Key Cryptosystem, which takes longer to encrypt and decrypt a message than a typical symmetric cipher, and the code and assets are encrypted with RSA's implementation of something else (AES? RC4?) based on the title key.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#30368 - ampz - Tue Nov 30, 2004 7:40 pm

tepples wrote:
RSA Public Key Cryptosystem isn't RSA Security's only product. It's entirely possible that the title key is encrypted with RSA Public Key Cryptosystem, which takes longer to encrypt and decrypt a message than a typical symmetric cipher, and the code and assets are encrypted with RSA's implementation of something else (AES? RC4?) based on the title key.

I think none of RSA's encryption schemes are suited for runtime implementation in hardware. But I could be wrong.

#30369 - tepples - Tue Nov 30, 2004 7:47 pm

WEP uses Rivest Cipher 4, a symmetric stream cipher, and it certainly runs in real time. (Rivest is the R in RSA.) It could be possible that the DS and the cart uses RSA PK crypto to exchange RC4 keys.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#30370 - ampz - Tue Nov 30, 2004 7:51 pm

tepples wrote:
WEP uses Rivest Cipher 4, a symmetric stream cipher, and it certainly runs in real time. (Rivest is the R in RSA.) It could be possible that the DS and the cart uses RSA PK crypto to exchange RC4 keys.

The fact that a cipher can run in realtime does not mean it is suited for hardware implementation.
I don't think they would use anything that requires more than perhaps 5000 gates.

#30374 - tepples - Tue Nov 30, 2004 8:04 pm

Wikipedia's description of RC4 makes it appear as if not much combinational logic is required for RSA. By a limitation on the number of gates, are you referring to the ca. 10K gates that would be needed to make SRAM to hold the 2048 bits of state used for RC4's PRGA? And for relative size comparison, how many gates would a mask ROM have?

Or perhaps it uses a key-sequenced block cipher such as TEA or RC5 (another Rivest cipher).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#30377 - ampz - Tue Nov 30, 2004 8:33 pm

tepples wrote:
Wikipedia's description of RC4 makes it appear as if not much combinational logic is required for RSA. By a limitation on the number of gates, are you referring to the ca. 10K gates that would be needed to make SRAM to hold the 2048 bits of state used for RC4's PRGA? And for relative size comparison, how many gates would a mask ROM have?

Or perhaps it uses a key-sequenced block cipher such as TEA or RC5 (another Rivest cipher).

You are right, RC4 could be implemented fairly efficiently in hardware. But the required memory is a bit high.

But as it says in the wiki: "Many stream ciphers are based on linear feedback shift registers (LFSRs), and, while efficient in hardware, are much slower in software. The design of RC4 is quite different, and is ideal for software implementations, as it requires only byte-length manipulations"

RC4 is a software replacement for LFSR's, which are much better suited for hardware implementations.