#31950 - nomad40 - Thu Dec 16, 2004 5:56 am
If I was the Nintendo development engineer I would have left a control
bit in the rom header to turn off the encryption during development.
Is anyone pursing this possibility?????
#31954 - TJ - Thu Dec 16, 2004 6:44 am
They don't do development on retail hardware, they use the development versions of the DS.
Like this one:
http://www.planetgamecube.com/news.cfm?action=item&id=5611
They wouldn't have included the ability to use unencrypted ROM cards on the retail DS's, as that would defeat the point of the encryption.
#31967 - yackom - Thu Dec 16, 2004 9:22 am
yeah no company wants to repeat the dreamcast mistakes of doing just that.
#31975 - netdroid9 - Thu Dec 16, 2004 11:50 am
Yeah.
But it could be done with some sort of exploit...
*Thinks* Could we buffer-overflow the GBA BIOS and see what we can do with it?
#31977 - Dib - Thu Dec 16, 2004 11:55 am
Again, if there were a way to bypass the encryption it would defeat the point of having encryption in the first place. You don't add fifty locks and bolts to your front door then leave the first story window open every time you leave the house.
#31979 - netdroid9 - Thu Dec 16, 2004 12:00 pm
<.<
>.>
...
Unless you forget, but by the time it reaches AUS there will be no chance of it being there :(.
Note to all Japanese/American/Chinese people: When a game hits europe though, it supports at least three changes and adds at least seven extra languages, and australia generally gets the european version...
#31981 - darkfader - Thu Dec 16, 2004 12:07 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#31982 - MumblyJoe - Thu Dec 16, 2004 1:36 pm
Although I think everyone is forgetting mod chips. If the DS can't run unencrypted code I would be willing to modify mine so it could.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!
#31984 - vseznajko - Thu Dec 16, 2004 3:42 pm
| darkfader wrote: |
| The ROM data itself might be pre-encrypted (per game title) because I can't dump super mario with commands that were sent to metroid. |
i think is more likeliy that commands are also encripted with the same LFSR stream.
#32004 - yackom - Thu Dec 16, 2004 11:21 pm
i think its most likely the commands use the LFSR too (but not necessarly so).. its fair to assume they didnt plan on the metriod cart getting hacked like darkfader did.
#32018 - Dib - Fri Dec 17, 2004 7:28 am
| MumblyJoe wrote: |
| Although I think everyone is forgetting mod chips. If the DS can't run unencrypted code I would be willing to modify mine so it could. |
From a development standpoint that's meaningless. You're willing to open up your DS and tinker with the internals, so that makes one target person to develop software and games for. What about the rest of the population whom owns a DS?
In others words, without the ability to provide our software to people and not require them to void warranties, break the law, or have a technical knowledge, there's not going to be much software made. It has to be as simple as flashing the software to a cartridge or inserting a custom cartridge or there's just no point.
#32020 - willgonz - Fri Dec 17, 2004 8:38 am
Because DarkFader has successfully extracted a rom and it was encrypted. From what I heard the encryption changes everytime you extract the data.
It is my thinking that the DS or ROM would encrypt the data based on time. My theory is, there is logic on the ROM which encrypts the game based on time. If someone were able to remove the data and stick it on another card, it would indeed have the game data, but not the logic to encrypt it, so the DS would read it. I bet the only way the DS would accept data is if it comes in it's encrypted form. In order to send the data from a PC, you would have to unencrypt the data and then encrypt it again by the PC. The PC would encrypt the data based on time, which is in sync with the DS. Two DS'es setting side by side with two of the same memory cards and the time in perfect sync with each other. Is the data that is pulled from the card the same? Change them a min or two off, does the data change? Or use one DS. Set the date and time to 11-11-2004 12:00. Pull data every minute for five mins. Set the time back to 11-11-2004 12:00. Again, Pull data every minute for five mins. Is the data that is pulled off the same?
RSA has been doing Time based algorithms for years now with their SecurID cards.
_________________
│?ig │
All of this is research. You are going to see theories come and go. Things you think can't be done, will be done. But because you are here, you'll be the first to know.
#32022 - yackom - Fri Dec 17, 2004 8:48 am
using time is how they generate the key to seed the LFSR stream, which it passes to the cartridge during bootup and reading the header. the cartridge isnt aware of the time and the commands sent to the cartridges are encrypted as well. you can read the other threads to get a better idea of that process.
#32025 - mymateo - Fri Dec 17, 2004 9:20 am
Besides, I'm not sure how accurate that would be if it DID work. I don't pretend to know much on the subject, in fact I probably know less than just about everyone here (having never bothered to learn anything about circutry and encryption etc), but it seems to me that you couldn't expect to be reliably accurate in any timing less than a second, half a second at best.
By this, I mean that you would probably have to start extracting the data at the exact same time, and in the same exact increments each time you reset the time. I somehow doubt that if Nintendo did use the current time to decrypt the data / encrypt the command (or whatever), they would take the seconds from the RTC. More likely, they would take the full time, or just the milliseconds (or smaller).
But like I said, I don't know much about this stuff... anyone who does, how accurate are my doubts? :)
#32026 - Sebbo - Fri Dec 17, 2004 9:38 am
i'm really not sure if this would help, and i'm about as inexperienced as mymateo, but i just finished my senior year of high school, and with that advanced maths. one thing i learned was that matrices are really useful for encrypting data and aren't apparently obvious to crack, so how likely would it be that the ROM dump was encrypted by some sort of matrix? it sure would be the smart thing to do
#32044 - EaDS Milliways - Fri Dec 17, 2004 3:05 pm
Just a bit more information from the SecureID side of things (which MAY be related, or maybe not). Say a company has 5 keyfobs. EACH one gets a different number every 60 seconds. However, even though you have 5 different numbers, ALL of them are valid. After another 60 seconds you have 5 new numbers and they are all valid as well. Expand this to 50, 100, 10,000 and it's possible that you have that many valid numbers for that one time period.
Add to this that the 60 second rule may only apply for the keyfob (ie, something a human has to see and enter) and there may be a different valid code for each beat (however long that is) in embedded devices.
Note that what the clock is set for would have no bearing on the encryption just like a computer's clock chip doesn't say anything about time, but just gives information that the software can use to determine the duration of a second.