#30641 - cullend11 - Fri Dec 03, 2004 1:42 am
the guys and girls at http://dslinux.cssourcefiles.com/forums/index.php?showtopic=45&st=0
are figuring out how to make a ds flash cartridge! you guys should work with them, your both good with C++ and are working at the DS!
#30643 - keldon - Fri Dec 03, 2004 2:04 am
Iif anyone will make the most progress it'll be those linux guys trying to install a distro onto the system. And I'm being serious.
They've managed to kickstart the PS2 homebrew community, and have even got Sony to officially support it and release bucketloads of technical data they would never have figured out themselves.
#30646 - mclysenk - Fri Dec 03, 2004 2:22 am
Didn't ampz already figure out most of that stuff? I think he posted a complete pinout in the cart thread. He also mentioned something about the ROM using encryption, so I don't think we're that close to getting a flash cart yet.
#30647 - ravuya - Fri Dec 03, 2004 2:59 am
I don't really see what making a flash cart has to do with C++.
_________________
Rav (Win/Mac/Linux games for free)
#30650 - Xtreme - Fri Dec 03, 2004 5:26 am
I don't think it's a good idea to get all the ppl on the same forum. I believe the way thing are going now is the best way. However co-operation is good and speeds up things a lot.
Who knows, maybe big N's workers are spying on the forums to keep up on how things are progressing.
I really like to see Linux in the NDS and also homebrew games.
#30652 - ChaosKnight - Fri Dec 03, 2004 5:54 am
Looks like cullend11 has been working on both sides trying to pull this together. I've been doing quite a lot and because of ampz and Tau Zero's work I have been able to perfect my pinout.
Maybe working together we can solve the data problem. And as far as making a flash cart, that's what I'm doing, it's more or less just a test and possibly the random data may mess it all up, but I'd rather try and fail then never try at all.
However, it would be good to make a group out of all the people who are seriously working on this... I'd be up for it for sure.
#30696 - benjamin - Fri Dec 03, 2004 5:35 pm
| Xtreme wrote: |
I don't think it's a good idea to get all the ppl on the same forum. I believe the way thing are going now is the best way. However co-operation is good and speeds up things a lot.
Who knows, maybe big N's workers are spying on the forums to keep up on how things are progressing.
I really like to see Linux in the NDS and also homebrew games. |
Why does splintering people on different forums help the effort? And areyou suggesting that if it doesn't help the effort that its a positive thing because it somehow minimizes Nintendo's ability to gauge the public's progress? I am not sure that a) it really matters if they know how far the progress is, and b) that they are so limited that two or three forums will somehow confuse them where as one would be easy.
I just don't understand your point at all. I am a proponent of centralizing communication points at the very least, if not the people working on the same thing. I can see benefits in having a few small groups working towards the same goal since they may take different approaches, but I do not see the benefit of at least not having one central repository of both groups' (or all groups') findings. I think it is very frustrating.
#30703 - ampz - Fri Dec 03, 2004 6:35 pm
They don't have enough info to build a card, and the guy is working under the assumption that there is no encryption (he assume that we have all been misreading our LA results..).
He also obviously don't know much about eeprom, flash and integrated circuits in general. (claims that eeprom and flash need high voltage programming, and says that a mask rom chip cannot contain encryption logic). I'am sorry, but they are nowhere close to building a working flash card.
#30705 - keldon - Fri Dec 03, 2004 7:35 pm
| ampz wrote: |
They don't have enough info to build a card, and the guy is working under the assumption that there is no encryption (he assume that we have all been misreading our LA results..).
He also obviously don't know much about eeprom, flash and integrated circuits in general. (claims that eeprom and flash need high voltage programming, and says that a mask rom chip cannot contain encryption logic). I'am sorry, but they are nowhere close to building a working flash card. |
aww bless their cotton socks
#30708 - ChaosKnight - Fri Dec 03, 2004 7:57 pm
| ampz wrote: |
| He also obviously don't know much about eeprom, flash and integrated circuits in general. (claims that eeprom and flash need high voltage programming, and says that a mask rom chip cannot contain encryption logic). I'am sorry, but they are nowhere close to building a working flash card. |
It's pretty obvious that all you did was scan the thread and only read the old posts. And yes, many EEPROMs and Flash devices require ~5-12 volts to write data. I'm not experianced with low-voltage programable units.
Also I realize that is is possible for a custom MaskROM to contain encryption logic, however that would raise the cost per unit significantly and since they are selling these things for $30 each and I assume not losing money on them I don't think they had a custom chip made.
#30718 - kerrle - Fri Dec 03, 2004 9:26 pm
I also agree that Nintendo would not shell out for encryption on chip, but really, the argument is silly if anyone is willing to sacrifice their Metroid demo.
If we could x-ray or even just view the magnified chip from the top, we should be able to see any encryption unit on the substrate - as it's not a standard component, any part dedicated to encryption would likely be a separate element, somewhat removed from the actual storage. Even given the layers present in this type of memory, it should be visible.
#30719 - ecurtz - Fri Dec 03, 2004 9:40 pm
Doesn't the initial "random" messages imply that the mask rom is storing some sort of state? I'm not a hardware guy, but I'd guess this "ROM" actually has a tiny amount of volatile memory and a little state machine in it. It would be pretty easy for it to be munging some signals and feeding back the data.
Here's the simplest case example.
A) One random byte is sent to the ROM and stored in its single 1 byte "register"
B) Every byte read is XORed with the register value on return
C) register is XORed with Byte returned >> 4
I doubt the cost for the chip would be much greater, and you've got a guarenteed buyer for 10s of millions of the things. (Yes I know this is common sense, it seemed clever as I started writing it.)
eli
#30720 - ampz - Fri Dec 03, 2004 9:48 pm
| ChaosKnight wrote: |
| ampz wrote: | | He also obviously don't know much about eeprom, flash and integrated circuits in general. (claims that eeprom and flash need high voltage programming, and says that a mask rom chip cannot contain encryption logic). I'am sorry, but they are nowhere close to building a working flash card. |
It's pretty obvious that all you did was scan the thread and only read the old posts. And yes, many EEPROMs and Flash devices require ~5-12 volts to write data. I'm not experianced with low-voltage programable units.
Also I realize that is is possible for a custom MaskROM to contain encryption logic, however that would raise the cost per unit significantly and since they are selling these things for $30 each and I assume not losing money on them I don't think they had a custom chip made. |
I'am sorry, this was not meant as criticism at you personally.
Yes, very old flash and eeprom devices require high programming voltage, but that is mostly history. Only a few modern flash devices support high voltage programming as an option to speed up the programming process a few percent.
The savegame unit is low voltage eeprom, but it looks like the main ROM might be OTP rather than mask ROM, perhaps some kind of antifuse. It also looks like they use high voltage programming for the OTP memory.
Integrated encryption logic would not increase production costs, it would significantly decrease them compared to external encryption hardware. With a volume of tens or perhaps even hundreds of millions of DS game cards, custom silicon is always the cheapest solution.
And no, I doubt we would be able to see the encryption logic in a microscope. The number of gates required for the encryption logic is very low, probably fewer than the addressing and databus handling logic in the chip. It would be a thousand gates or so on a line along the edge of the memory mixed in with the addressing and databus logic.
#30721 - ampz - Fri Dec 03, 2004 10:29 pm
| ecurtz wrote: |
Doesn't the initial "random" messages imply that the mask rom is storing some sort of state? I'm not a hardware guy, but I'd guess this "ROM" actually has a tiny amount of volatile memory and a little state machine in it. It would be pretty easy for it to be munging some signals and feeding back the data.
Here's the simplest case example.
A) One random byte is sent to the ROM and stored in its single 1 byte "register"
B) Every byte read is XORed with the register value on return
C) register is XORed with Byte returned >> 4
I doubt the cost for the chip would be much greater, and you've got a guarenteed buyer for 10s of millions of the things. (Yes I know this is common sense, it seemed clever as I started writing it.)
eli |
Your example is somewhat close to the principle of a LFSR chiper.
And you are right, it would not take many logic gates to implement sufficient encryption in hardware. Nintendo don't need state-of-the-art encryption, they just need something that will take about 5years or more to break. A sufficiently complex LFSR based chiper would accomplish that.
#30723 - ChaosKnight - Fri Dec 03, 2004 11:07 pm
I maintain my optimism. It's worth a try and even encrypted data is worth something to me. It's worth knowing for sure that it's encrypted. As far as custom logic, it's possible. The Micronix guy was pretty dodgy, however I am assuming it's a MaskROM part because the package follows thier naming convention for MaskROM.
Even so... isn't a custom silicon more expensive than a mass produced? Custom is pretty expensive compared to mass produced and combine that with advertising, packaging, retail, quantity, and more... the bills add up and nobody is making money.
Although it is possibly encrypted, I'm not sure that it is. Besides, I think I remember reading something about Nintendo being cool with private developers. After all, one of the WiFi hacking threads is hosted on thier own forum.
Either they are laughing, or they just don't care.
#30724 - SimonB - Fri Dec 03, 2004 11:27 pm
| ChaosKnight wrote: |
| Besides, I think I remember reading something about Nintendo being cool with private developers. After all, one of the WiFi hacking threads is hosted on thier own forum. |
Would this be the same forum where they also claim that talking about sourcecode and emulators is illegal (sure if they had said it was breaking the forum rules...but illegal...heh..)?
Simon
#30729 - leonard_ - Sat Dec 04, 2004 12:09 am
| Quote: |
A) One random byte is sent to the ROM and stored in its single 1 byte "register"
B) Every byte read is XORed with the register value on return
C) register is XORed with Byte returned >> 4
|
Could you explain a bit more on your idea ? To me, if encryption system use not many logic gates it will be very simple to break. I mean, your "one byte" xor method (I know that's only an exemple) is very easy to break.
To me, BIOS use software RSA routine to check a digital signature on the cartridge. So maybe we can copy cartridges one day, but not execute our own code without digital signature. If there is no weakness in implementation, we can wait a very, very long time. ( XBox digital signature is not cracked yet ! and there is *tons* of people trying the challenge since a long time !)
#30735 - Dwedit - Sat Dec 04, 2004 1:44 am
Use a switch to boot one rom then swap it with another?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#30744 - Joat - Sat Dec 04, 2004 4:07 am
As far as custom silicon goes, every mask ROM chip *is* custom silicon, they make a new mask per ROM, hence the name! If the chips are OTP instead of mask, then every single NDS cart that is 128 mbit ends up using the exact same chip, putting the number of identical MX23L12808's into the millions *already*, after just a few weeks.
It *is* encrypted, it reads a block in plaintext, sends a pair of commands, and then every damn byte after that has a perfect random distribution. And while really really good compression gives you close to random distributions, 1) the commands are also random, which they wouldn't be if data were compressed, and 2) we're talking *really* random, well under 1% difference between # of 1's and 0's.
If you don't send those commands, just about all it will let you do is read the header over and over again.
A LFSR is a psuedo-random number generator, and for any state length m, you can make one with a period of 2^m - 1 (all 0's is always a degenerate state). There are 2^(m-1)/m different maximal length sequences for any given length m (iirc, could have messed that equn up). You clock one, and it produces a new bit out the bottom. This sequence of bits for a maximal generator has lots of nice properties, like looking incredibly random (at least until the generator period repeats). You can gather up 8 bits of state, either by clocking it 8 times, or grabbing 8 bits from the state vector in some other way, and use that as the pad to XOR against your plaintext.
A straight LFSR isn't secure, you only need 2m bits of the pad to recover the taps, but there are a million and one different ways you can take this simple idea and make it more secure, like using 3, with the 3rd picking which data bit to use from the other two as they get clocked, or 5, with 3 muxers, and so forth. The amount of hardware needed is pretty minimal, some shift registers, xor gates and multiplexers, but the potential number of combinations are insane.
Without an idea of what the configuration is, who knows where to even start? I'm just hoping that the header contains some flag that indicates whether the rest of the rom is encrypted or not, that way we can make carts with homebrew on them without having to crack the encryption.
_________________
Joat
http://www.bottledlight.com
#30751 - ChaosKnight - Sat Dec 04, 2004 5:55 am
| Joat wrote: |
| It *is* encrypted, it reads a block in plaintext, sends a pair of commands, and then every damn byte after that has a perfect random distribution. |
Interesting. If this is true, then why would they not encrypt the game data coming across the WiFi? Not that anyone here would know the answer unless there are Nintendo ninjas hanging around...
#30759 - Abscissa - Sat Dec 04, 2004 9:16 am
| leonard_ wrote: |
| To me, BIOS use software RSA routine to check a digital signature on the cartridge. So maybe we can copy cartridges one day, but not execute our own code without digital signature. |
I doubt that, it just seems kind of backwards from Nintendo's perspective. Why would they bother with all the effort of preventing people from running their own code if it didn't stop people from copying cartridges? Regardless of what their opinion of homebrew might be, piracy is certainly a bigger concern for them.
| Joat wrote: |
| I'm just hoping that the header contains some flag that indicates whether the rest of the rom is encrypted or not, that way we can make carts with homebrew on them without having to crack the encryption. |
That does seem to make sense, probably a real possibility. It wouldn't really suprise me if it worked like that (unless I'm overlooking a way that it would make piracy significantly easier)
All this talk about the headers, has anyone actually been able to extract one yet? If so, any progress on deciphering any of it? Is it posted somewhere I could take a look?
#30760 - Abscissa - Sat Dec 04, 2004 9:25 am
| ChaosKnight wrote: |
| Joat wrote: | | It *is* encrypted, it reads a block in plaintext, sends a pair of commands, and then every damn byte after that has a perfect random distribution. |
Interesting. If this is true, then why would they not encrypt the game data coming across the WiFi? Not that anyone here would know the answer unless there are Nintendo ninjas hanging around... |
- Maybe the DS and/or its dev tools don't privide their own way of encrypting the WiFi stuff, and the developer has to do it theirself.
- Or maybe the wireless portion of the game is small enough compared to the whole game that they don't care enough.
- Maybe they're not particularly concerned about piracy of the smaller multi-boot portion, and just care about piracy of the main cart.
- Maybe they didn't care because they knew intercepting it wasn't something that could be done on all WiFi cards.
- Maybe it's wasn't a "must-have" feature and just didn't make it into the release titles by the laungh date. ;)
Just stabs in the dark...
#30763 - ampz - Sat Dec 04, 2004 11:14 am
| ChaosKnight wrote: |
| Even so... isn't a custom silicon more expensive than a mass produced? Custom is pretty expensive compared to mass produced and combine that with advertising, packaging, retail, quantity, and more... the bills add up and nobody is making money. |
DS games are produced in tens or hundreds of millions of units. You don't consider that "mass produced"??
Things don't get more mass produced than that!
At thoose volumes, there is no cost difference between "custom" and already existing silicon.
| ChaosKnight wrote: |
| Although it is possibly encrypted, I'm not sure that it is. Besides, I think I remember reading something about Nintendo being cool with private developers. After all, one of the WiFi hacking threads is hosted on thier own forum. |
Trust me, it is encrypted. I have made plenty of LA dumps, after encryption is turned on, not a single byte is the same as last time the DS was booted.
#30765 - keldon - Sat Dec 04, 2004 12:07 pm
| _leonard wrote: |
| To me, BIOS use software RSA routine to check a digital signature on the cartridge. So maybe we can copy cartridges one day, but not execute our own code without digital signature. If there is no weakness in implementation, we can wait a very, very long time. ( XBox digital signature is not cracked yet ! and there is *tons* of people trying the challenge since a long time !) |
If anything, I'd guess that Nintendo are working on an asynchronous encryption routine. Using bit rotation and adds plays into modular arithmetic; which plays hand in hand with asynchronous encryption. And the reason behind using asynchronous encryption is that manufacturers can encode a cartridge, but only the DS can decode.
Possibly reading the same byte continously will reveal something about the cartridge encryption. For example it can tell you whether the DS provides a random seed, or if the seed is stored on the cartridge and changed with every boot?
#30770 - leonard_ - Sat Dec 04, 2004 3:12 pm
| Quote: |
It *is* encrypted, it reads a block in plaintext, sends a pair of commands, and then every damn byte after that has a perfect random distribution.
|
You mean that you can't easyly read ROM with external rom reader device ? But, you can maybe read the DS bios rom (probably not encrypted ?), and then see ARM9 code to read the game rom ( pair of commands). do you think BIOS is encrypted ?
| Quote: |
And while really really good compression gives you close to random distributions, 1) the commands are also random, which they wouldn't be if data were compressed, and 2) we're talking *really* random, well under 1% difference between # of 1's and 0's.
|
Compression has nothing to do with "random". A well packed data is "similar" to random in a sense the data contains high entropy, but it's not random. The "pseudo random" chips you mention (generally use shift and XOR) are theorically not so hard to reverse. ( these kinds of devices are NOT considered secure in cryptography)
But I agree with you it can slow down the process of getting a mario's rom binary image !
#30794 - ChaosKnight - Sat Dec 04, 2004 7:38 pm
Okay, so there are a few theories on encryption, here are some of my thoughts:
1) If the key is generated by the DS and the ROM uses this key for encryption purposes, then not only is the key somehow sent in plaintext but also we can make our own key to send to the ROM. I doub Nintendo woould use this method as it provides little to no security and is essentially as useless as
2) No encryption. Nintendo has never encrypted anything but muti-boot GBA carts in the past and it's new multi-boot (wireless download) is unencrypted so why encrypt the carts? Sure we are getting 1s and 0s... maybe we interpreted the pins wrong and got hooked up to the clock. Real perfect distribution there.
3) We use some kind of buffer overflow attack on a save game. Neat huh? The EEPROM is unencrypted, and it uses a standard SPI interface which is dead easy to emulate over any high enough speed connection (USB anyone?).
Just some thoughts, maybe someone can expound on them.
BTW... I found a picture of a 2Gbit cart with a 64Kbit eeprom... fun, huh?
#30809 - tepples - Sun Dec 05, 2004 1:43 am
That is, unless the EEPROM contents are hashed and signed. Many Nintendo titles already store a checksum; for example, I've cracked Mario Paint's checksum to get it to load custom stamps in ZSNES. From there, it's just a small step to a cryptographic checksum such as MD5 or (shudder) SHA-256 and from there to an RSA encrypted checksum, which is called a digital signature. That's how Xbox games signed their savegames, which worked until someone extracted the signing keys from Agent Under Fire and MechAssault for Xbox to make the buffer-overflow exploits for those games.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#30814 - Joat - Sun Dec 05, 2004 3:26 am
ChaosKnight, no offense, but you really do seem clueless.
| Quote: |
1) If the key is generated by the DS and the ROM uses this key for encryption purposes, then not only is the key somehow sent in plaintext but also we can make our own key to send to the ROM. I doub Nintendo woould use this method as it provides little to no security and is essentially as useless as
|
This is exactly what is happening, and yes, it does provide plenty of security, *if* we don't know the encryption strategy being used, which we don't. Its not a straight LSFR, but we can assume its a relatively simple stream cipher, probably some screwy cascaded series of LSFR's like a Geffe generator.
| Quote: |
2) No encryption. Nintendo has never encrypted anything but muti-boot GBA carts in the past and it's new multi-boot (wireless download) is unencrypted so why encrypt the carts? Sure we are getting 1s and 0s... maybe we interpreted the pins wrong and got hooked up to the clock. Real perfect distribution there.
|
Why encrypt the carts? To prevent piracy. And by 'we', do you mean people who aren't you? The traces aren't *all* random, there is some perfectly readable ASCII text before encryption is enabled, and a clock doesn't give you a random distribution, it alternates every cycle, very low information content (or if the trace is only on rising edges, zero content, since it'd always be high). Why not try looking at a trace before comming up with some new theories?
| Quote: |
3) We use some kind of buffer overflow attack on a save game. Neat huh? The EEPROM is unencrypted, and it uses a standard SPI interface which is dead easy to emulate over any high enough speed connection (USB anyone?).
|
A buffer overflow would do the trick, but finding one without being able to disasm the game code that loads that data would be a total pain in the ass. You could use a USB micro with code to pretend that it's a SPI device, but you don't just wire something else up to a USB jack and expect it to work, it's a sophisticated serial protocol.[/quote]
_________________
Joat
http://www.bottledlight.com
#30823 - ChaosKnight - Sun Dec 05, 2004 6:40 am
Wow... that was pointless. In case you're wondering, I'm not really as clueless as your ego wants me to be. I understand cryptography is sophisticated, I understand USB is a complex and involved serial connection. However unlike yourself, instead of theorizing about unknowns I just try to come up with simple solutions first and then grow in complexity.
USB is pretty simple when you have a single chip doing all the work for you, or even a simple embedded system. Do you have to write software and design the hardware? Yes, but why should I detail that whole process in a simple brainstorm?
And yes, if I had expensive equipment I would be getting 1s and 0s, but because I'm a hobbyist... well, I haven't collected that just yet.
#30841 - ampz - Sun Dec 05, 2004 1:21 pm
It is technically impossible to emulate a SPI slave using USB.
USB is waaaaay too slow.
There are two things that can be reffered to as "speed". 1: Bandwidth, 2: latency.
USB 1.1 have low to medium bandwidth, but absolutely awful latency.
USB 2 only improves the bandwidth.
In order to emulate a SPI salve you need a latency in the order of 50nanoseconds. USB have a latency of 10ms or more.
Let's see, USB is off by at least five orders of magnitude... :)
If you send a 100pack of DVD discs by mail every day, you get incredibly good bandwidth, but your latency is several days.
Would you call this "fast" ?
#30846 - ChaosKnight - Sun Dec 05, 2004 2:38 pm
I understand what you mean. I hadn't really looked as far as the timing. That would be a problem for a man in the middle attack unless your slave acted as more of a datalogger and your USB connection was really just for recieving that log. Sending would definately suck, but then again like you said, until we know more about the code that's running it's hard to do anything related to buffer overflow.
By the way: Are all of the commands that the DS sends to the ROM custom or are there normal commands sent before the custom ones? I'm not clear on that.
#30847 - darkfader - Sun Dec 05, 2004 2:45 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:41 pm; edited 1 time in total
#30881 - ChaosKnight - Sun Dec 05, 2004 8:25 pm
So what if we never send a 3C... And for those that like to jump to conclusions I will expound. This is (of course) assuming that one would build a custom interface to the chip. Say if I built some kind of custom system maybe a SX or a reasonably powered PIC or AVR to talk to it and never send 3C, would it never encrypt?
#30886 - tepples - Sun Dec 05, 2004 8:48 pm
What if reading pages past, say, 64 KB is possible only once encryption has begun?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#30888 - Abscissa - Sun Dec 05, 2004 9:05 pm
| ChaosKnight wrote: |
| So what if we never send a 3C... And for those that like to jump to conclusions I will expound. This is (of course) assuming that one would build a custom interface to the chip. Say if I built some kind of custom system maybe a SX or a reasonably powered PIC or AVR to talk to it and never send 3C, would it never encrypt? |
Probably worth at least a try.
Although, there is the problem tepples mentioned. Also, I wonder if there are custom commands that you would need that the DS never sends until after it's set the encryption, hence you wouldn't be able to discover required commands without beng able to decrypt.
#30905 - ChaosKnight - Mon Dec 06, 2004 12:17 am
| Abscissa wrote: |
| Also, I wonder if there are custom commands that you would need that the DS never sends until after it's set the encryption, hence you wouldn't be able to discover required commands without beng able to decrypt. |
That's just plain evil, Ab.
#31037 - Xtreme - Tue Dec 07, 2004 4:05 am
| benjamin wrote: |
| Xtreme wrote: |
I don't think it's a good idea to get all the ppl on the same forum. I believe the way thing are going now is the best way. However co-operation is good and speeds up things a lot.
|
Why does splintering people on different forums help the effort?
|
I only meant that ppl who cracks the hardware and software could keep on their own communitys. The reason for that is simply that hardware and software is not a same thing, but of course they do mix in some part of the DS console.
How the things are now... :D... almost all ppl who are working on the DS are posting on all forums. I believe that will speed up things a lot. I don't think my oppinion was the right one since I'm not hardware/software cracker. My intention was only to build some conversation here, but you seem to stuck on my words, no offence dude. ;)
_________________
My Theme
DS Lite (FM_V8a) ** R4 Revolution (2GB Transcend) ** SuperCard Lite (2x 2GB Transcend)
#31104 - bmfrosty - Tue Dec 07, 2004 10:28 pm
If we're aiming for homebrew development, then do we even need to read past 512 bytes of ds cart? Might we be able to just use those 512 of unencrypted code that the DS allows to be read from the DS cart to redirect execution to a GBA flash cart?
I know the answers aren't there yet, but this may be a loophole that would allow homebrew development.
#31120 - Duodreamer - Wed Dec 08, 2004 1:28 am
Well, the header that gets read unencrypted isn't data that the DS executes, its just information about the cart, plus the DS doesn't run directly from the game pak, it loads resources into internal RAM and then runs from there.
It would be nice if there was a parameter in the cart header that would tell the DS to load data from the GBA slot, or that the cartridge was unencrypted. That would make homebrew alot easier, could just make a DS dongle that you could use your GBA flash card with.
#31126 - Abscissa - Wed Dec 08, 2004 2:08 am
| Duodreamer wrote: |
| It would be nice if there was a parameter in the cart header that would tell the DS to load data from the GBA slot, or that the cartridge was unencrypted. |
I'm really hoping for a "data is unencrypted" flag.
#31135 - mymateo - Wed Dec 08, 2004 3:02 am
| Duodreamer wrote: |
| That would make homebrew alot easier, could just make a DS dongle that you could use your GBA flash card with. |
Why use a dongle, out of curiosity? Couldn't you just put the cart into the GBA slot? I dunno, just a thought...
YAY! Proud to announce my 200th post! I have to celebrate it 'cause I missed my 100, and by the time I noticed it was too late... guess I could've looked up the history, but... YAY! 200 POSTS!
#31137 - dagamer34 - Wed Dec 08, 2004 3:22 am
| mymateo wrote: |
| Duodreamer wrote: | | That would make homebrew alot easier, could just make a DS dongle that you could use your GBA flash card with. |
Why use a dongle, out of curiosity? Couldn't you just put the cart into the GBA slot? I dunno, just a thought...
YAY! Proud to announce my 200th post! I have to celebrate it 'cause I missed my 100, and by the time I noticed it was too late... guess I could've looked up the history, but... YAY! 200 POSTS! |
I'm still waiting for the big 1000... Only a few here have managed to post that much and not be considered spamming. :)
_________________
Little kids and Playstation 2's don't mix. :(
#31139 - tepples - Wed Dec 08, 2004 5:11 am
| mymateo wrote: |
| Why use a dongle, out of curiosity? Couldn't you just put the cart into the GBA slot? |
It appears the point is to use the dongle that either fits in the DS slot (if that's cracked) or attaches to the case (if the wireless is cracked) to boot the DS into a state where it can read DS code from a GBA flash cart.
And spam is in the eye of the beholder. There are things that gbadev.org doesn't consider spam but a bunch of stricter boards do, such as answering a problem with a link to how I solved it in my own project, or asking others to help debug a project with a link to download the project *cough*webmasterworld rules 13 and 21*cough*.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31153 - TauZero - Wed Dec 08, 2004 12:03 pm
I have been looking at the (I assume) LA dumps on Dark Faders site, and I have noticed an interesting pattern of when the commands are sent. They always seem to come in groups of 8, and after encryption is turned on, the first non command byte allways seems to be the same as the last command byte.
The space between the first 2 command blocks is 8192 (8K) bytes, and is all FF's (unprogrammed space...) The space between the next 2 commands is 512 bytes and corresponds to the header (I believe).
After that there is an 8 byte command that is to read device ID (command is 0x90 00 00 00 00 00 00 00) Following that is 8 bytes of data (0xC2 0F 00 00), then 2 more 8 byte commands back to back, which the last command byte is the same as the next data byte. This trend seems to continue through the whole file (but I have not checked it all yet, just the first few commands after encryption is enabled).
The rest of the commands seem to appear at varying intervals (2320 bytes for the first section, 2324 bytes for the second, 2324 bytes for the 3rd, 6584 bytes for the 4th, 6584 bytes for the 5th...)
These are just some observations I have made on the file dsstart_metroid0.bin, other files may be different. Hopefully they will help someone figure this out...
If someone tells me what the LA connections were (bits in the dump to pins on the cart) I can make a cart dumper that I can try and use to issue the commands to the cart and see what I can get out.
#31157 - ChaosKnight - Wed Dec 08, 2004 1:47 pm
| TauZero wrote: |
| If someone tells me what the LA connections were (bits in the dump to pins on the cart) I can make a cart dumper that I can try and use to issue the commands to the cart and see what I can get out. |
I'd be extremely interested in working with you on this. As far as I can tell, the most likely pins the LA would be connected to are IO ports 0-7 as they seem to be used for command, address, and data. It is also possible that the chip select line plays a vital part in sending data as in most chips like this it is used to instruct the chip that a command will be transmitted.
#31264 - darkfader - Thu Dec 09, 2004 12:04 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:41 pm; edited 4 times in total
#31271 - ChaosKnight - Thu Dec 09, 2004 1:38 pm
| darkfader wrote: |
| Dongle! that's a good idea. but only works if the data is XOR encrypted. |
Hopefully it is. It can't be too heavily encrypted or else decryption would take too much time. Unless they have specialized hardware just for that. Although I doubt they'd waste the real estate on it. Even so, if it can be read without sending the encrypt command, you idea may be very possible.
Also on a side note, I did find a USB<->SPI bridge made by Atmel. Guess building an eeprom emulator wasn't such a stupid idea after all. A microcontroller, some sram, and one of those wouldn't be so hard to conjure up.
#31282 - TauZero - Thu Dec 09, 2004 4:01 pm
Here is my crazy idea... I noticed in the LA dumps that the DS requests the ROM ID code right before enabling encryption. Now I asked myself, why on earth would they even ask for such info, much less why right before enabling encryption? Maybe because they want to know if the cart supports it or not!!! My idea is to take an FPGA or CPLD and program it to be a man in the middle watching for the ID command to go by, and when it does it would hyjack the DS - ROM link and fake an ID code. We can pick ID codes at random or whatever, but there are only (?!) 4 billion possibilities (32 bits) or 16 million possibilities if we stay within Macronix ID land (24 bits). I think that may take much less time then trying to figure out the encryption for building our own carts, because if we can disable it all together we can figure out the command structure and do away with it. Its only an idea, but I think the person with the right hardwre (and time) can accomplish it.
I have an FPGA board, but I do not know if its fast enough to do this. Anyone else out there have hardware capable of this task?
What do you guys think?
#31283 - darkfader - Thu Dec 09, 2004 4:03 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:41 pm; edited 1 time in total
#31305 - Megaman - Thu Dec 09, 2004 9:23 pm
| Quote: |
| The 9F and 90 are standard command codes. |
Where are they documented?
TauZero wrote:
| Quote: |
| If someone tells me what the LA connections were (bits in the dump to pins on the cart) I can make a cart dumper that I can try and use to issue the commands to the cart and see what I can get out. |
Looking through the code of main.cpp, (http://darkfader.net/ds/files/dumpstuff.tmp/main.cpp) this is what i found out:
16 bits are sampled at a time.
Bit 12 is connected to CLK (cart pin 2)
Bit 11 is connected to NC (cart pin 3)
Bit 10 is connected to ROM CS (cart pin 4)
Bit 9 is connected to RESET (cart pin 5)
Bit 8 is connected to EEPROM CS (cart pin 6)
Bit 7-0 is connected to I/O 7-0 (cart pin 9-16)
(Using darkfaders names for the pins)
| Quote: |
| I have an FPGA board, but I do not know if its fast enough to do this. Anyone else out there have hardware capable of this task? |
I think that any fpga or even cpld will be able to do it quick enough.
#31325 - TauZero - Fri Dec 10, 2004 1:00 am
Well I have the D2E board listed on this page:
https://digilent.us/Materials/BoardProducts.html
The only reason I am worried about speed is I am not sure what the setup and hold times with reference to the CLK are for the ROM chip, and inserting a device between the ROM and the DS may violate the times. Surly 5 or 10ns delay would not be bad, but im pretty sure that say 100ns would be.
#31332 - ChaosKnight - Fri Dec 10, 2004 4:20 am
Altium sells a kit for FPGA that's very attractive for this sort of thing at thier site. They have two packages using thier LiveDesign Eval Kit (for those who don't have one yet including me):Altera? Cyclone? FPGA Device (EP1C12F324C8) - US $99 + Shipping
Xilinx? Spartan?-3 FPGA Device (XC3S400-4FG456C) - US $99 + Shipping
I'm a Xilinx fan myself, however Andre Lamothe has recommended the Cyclone device, so I might give that a try. Either way $99 for an eval board + FPGA + software (albiet demo) is not a bad deal.
#31562 - darkfader - Sun Dec 12, 2004 7:34 am
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#31571 - ampz - Sun Dec 12, 2004 11:16 am
The first byte in the result is not the same as the last byte of the command, it just looks that way.
After some commands there is a dummy clock-cycle before the response, neither the DS nor the card are driving the bus during this dummy cycle, the bus is left floating. This is why you get the last value entered on the bus.
#31576 - darkfader - Sun Dec 12, 2004 2:02 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#31592 - Megaman - Sun Dec 12, 2004 9:04 pm
| Quote: |
| The only reason I am worried about speed is I am not sure what the setup and hold times with reference to the CLK are for the ROM chip, and inserting a device between the ROM and the DS may violate the times. Surly 5 or 10ns delay would not be bad, but im pretty sure that say 100ns would be. |
With a good design i think you'll at least be able to get down to 10 ns.
| darkfader wrote: |
About the type-2 requests... an invalid command gives all zero's xorred with the LFSR stream. You can use that to decrypt the actual data. I've just done that.
Block reads repeat per 4 KB.. |
Nice work! Glad to hear that progress is made.
#31673 - vseznajko - Mon Dec 13, 2004 6:11 pm
| darkfader wrote: |
I think it's possible to extract the LFSR stream (not until infinity though) by using the ID command.
The LFSR is updated after each byte transfer that's not part of a command.
After the LFSR stream for one init key is known, the problem lies in the init sequence.
It's just a transfer that happens in a different way.
About the type-2 requests... an invalid command gives all zero's xorred with the LFSR stream. You can use that to decrypt the actual data. I've just done that. |
Is it clear where is the init key? It should be sent by DS at the begining of comunication I guess, so encoded data is always different... Or LFSR stream is allways the same, but transfer is different each time? Or maybe both are different...
Is it possible to use low clock frequency to dump the catridge with some PIC/AVR?
#31689 - darkfader - Mon Dec 13, 2004 10:07 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#31715 - vseznajko - Tue Dec 14, 2004 2:01 am
| darkfader wrote: |
Oh... an invalid command does give the LFSR stream... but after that, the cartridge won't allow any more commands. But good news is that the ID command still works, but outputs a repeating C2 0F 00 00 instead of 00's.
I'm not sure why they allowed that command in encrypted mode. Perhaps they implemented it to verify the contents during production. (?)
|
So if you get proper encoded stream, you can issue same initialization sequence with invalid command, and get LFSR stream. XOR those two and get decrypted DS program (part of it actualy). This is under asumption that LFSR stream is only XOR-ed with the program, and that invalid command encodes 0's.
Did you got such dump? Does it look like nice ARM code?
| Quote: |
The ways to run our own code:
2-cartridge solution: give one the original command, the other xorred with 0x0F to use the ID command. Then you can search & replace code whenever is it loaded. I've just ordered another GB connector since this
solution is easier to hack with. Also should work with 2 different games.
1-cartridge solution: pre-xor own code with part of the LFSR stream, so you can inject code at a specific time. This method would require a romdump and doesn't work if block read sizes are random. (but it probably isn't) |
Is the key 1. part of the command, or 2. it's actualy updated during the whole type-1 reading at the start? So, what makes runtime encoding different each time - comands issued to the card, or address range and the data that is read each time?
The last but not least - good job indead, very good job!
#31721 - darkfader - Tue Dec 14, 2004 2:52 am
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 2 times in total
#31723 - netdroid9 - Tue Dec 14, 2004 3:10 am
This has probably already been tried, but you can run homebrew GBA code can't you? Why not try and dump the BIOS through the GBA cartridge. It might only need the same program as for the GBA.
#31724 - tepples - Tue Dec 14, 2004 3:22 am
Dumping the DS's GBA BIOS through a GBA flash cart results in an identical BIOS to that stored on the production GBA, GBA SP, and Game Boy Player, except for one bit of difference.
darkfader: http://darkfader.net/ds/files/dumpds.cpp is 404.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31758 - netdroid9 - Tue Dec 14, 2004 8:42 am
I wonder... Has anyone disassembled the GBA BIOS and the DS-GBA BIOS and done a compare?
#31766 - caitsith2 - Tue Dec 14, 2004 10:00 am
DS-GBA Bios other than one bit, is exactly the same, because changing any code would have the potential to break any gba games out there. Heck, they could not even fix the MidiKey2Freq bug, as that would alter its timing, even if ever so slightly, and that would (god forbid), potentially break some games depending on the original timing.
Only one bit has changed, and of course, the get bios checksum function was not documented, so as to not break any games that depend on a specific bios with checksum equel to whats in the GBA. The only reason that bit has changed, was so that the GBA programmers can detect if their game is running on a DS, for potential DS color enhancement, or to allow the game to unlock certain features. (not likely access to x/y buttons, or touch screen, or anything like that).
#31767 - darkfader - Tue Dec 14, 2004 10:36 am
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#31777 - vseznajko - Tue Dec 14, 2004 1:12 pm
OK this makes everything clear!
With the risk to get boring, but to clear my last doubts... Did you get same dump with different set of initial seed/sniffed commands? Does the dump look like - ARM9 code/ASCII text/2D,3D objects?
Some commads encryption speculation - they may be encoded with the same LSFR as data read from catridge, especialy if the stream is self synchronizing...
#31808 - darkfader - Tue Dec 14, 2004 10:40 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#31822 - yackom - Wed Dec 15, 2004 12:18 am
why would you need 2 carts?
#31831 - netdroid9 - Wed Dec 15, 2004 2:05 am
To compare them.
#31857 - darkfader - Wed Dec 15, 2004 10:19 am
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#31858 - netdroid9 - Wed Dec 15, 2004 10:22 am
We really need an emulator :(
#31869 - vseznajko - Wed Dec 15, 2004 3:13 pm
| netdroid9 wrote: |
| We really need an emulator :( |
i think we need lot of dumps of the same game (let's say 1000 or 10000) with different initial seed to break the encription...
i wonder is some of the guys able to sniff, would be willing to do it, and host it somewhere...
#31875 - yackom - Wed Dec 15, 2004 4:26 pm
couldnt you recover the taps from the xor table you built? or am i way off?
#31881 - vseznajko - Wed Dec 15, 2004 5:55 pm
| yackom wrote: |
| couldnt you recover the taps from the xor table you built? or am i way off? |
i don't quite belive that LSFR depends only on init sequence and clock pulses, and that is possible to get it by issuing slightly modified command. sounds too easy to me. am i way off now?
#31914 - darkfader - Wed Dec 15, 2004 10:40 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 4 times in total
#31920 - ghettron - Wed Dec 15, 2004 11:03 pm
your pass-throug jpg is 404
#31934 - mymateo - Thu Dec 16, 2004 2:31 am
| darkfader wrote: |
I need 2 of the same game because the encryption seems to different for each game. The encryption is probably also seeded with something in the header data. But I can't run 2 different games simultaneously.
So please, if someone has a spare metroid cartridge or something... don't hesitate to help me out a bit :( My mail address is on my page. |
Ask, and ye shall receive. I'm not overy excited about playing the Metroid demo... I got bored of it seconds after finishing the training mission. But two conditions:
(1) You return the game when you are done
(2) I'll pay to ship to you, you pay to ship back.
And if the cartridge will be destroyed in the process, then:
(1b) You PROMISE that it'll be a big help!
(2b) You pay half the shipping cost.
... and this is assuming it's not going to cost an arm and a leg to ship... I like to help, but I'm not made of money either. PM me w/ mailing address if this sounds good.
#31936 - darkfader - Thu Dec 16, 2004 2:34 am
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#32006 - yackom - Thu Dec 16, 2004 11:26 pm
darkfader, have you tried to read the LFSR long enough to loop? because if you can get it to loop we can get a better idea of how many bits the taps are, and also how many bits the seed is. or have you tried messing with the seed yet?
#32093 - darkfader - Sat Dec 18, 2004 3:02 am
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#32100 - djemergency - Sat Dec 18, 2004 4:01 am
hey darkfader I would like to do an interview with you conserning your projects. you can contact me through AIM or Yahoo.
_________________
DS Paparazzi!
Get Nintendo DS News:
When you want or how you want...
http://dspaparazzi.blogspot.com/
#32102 - yackom - Sat Dec 18, 2004 4:13 am
| darkfader wrote: |
Another update... I can modify the header information.
Effects seen so far:
- game does not get detected.
- DS won't even show the Nintendo logo.
- game hangs at start.
- logo and game title don't show up, but still can run. |
do you have any speculation of why this is? do is there checksums in the headers? or the headers are used to generate a seed along with the time?
#32124 - netdroid9 - Sat Dec 18, 2004 6:45 am
[quote=darkfader]Another update... I can modify the header information.
Effects seen so far:
- game does not get detected.
- DS won't even show the Nintendo logo.
- game hangs at start.
- logo and game title don't show up, but still can run.[/quote]
| Code: |
Game does not get detected - Invalid header, so the DS doesn't recognise the format and ignores it.
DS won't even show the Nintendo logo - Header causes DS to crash because of some sort of access violation?
Game hangs at start - Easy, the seed is invalidated because of a modification.
Logo and game title don't show up, but still can run - Changed the bit that tells the DS where to begin searching. |
This is what I see it as. I'm probably wrong.
#32127 - yackom - Sat Dec 18, 2004 7:19 am
if the ds doesnt start wouldnt that mean the header made the ds bios crash or otherwise hang? if thats so, that might mean the bios is subjectable to a exploit. but then again we probably wont know until there is much more known about the system.
#32185 - netdroid9 - Sun Dec 19, 2004 3:49 am
| yackom wrote: |
| if the ds doesnt start wouldnt that mean the header made the ds bios crash or otherwise hang? if thats so, that might mean the bios is subjectable to a exploit. but then again we probably wont know until there is much more known about the system. |
Not quite. An exploit can be exploited, a recoverable crash isn't really exploitable. it could just send the DS to an invalid memory address somehow.
#32190 - dankydoo - Sun Dec 19, 2004 5:59 am
| netdroid9 wrote: |
| yackom wrote: | | if the ds doesnt start wouldnt that mean the header made the ds bios crash or otherwise hang? if thats so, that might mean the bios is subjectable to a exploit. but then again we probably wont know until there is much more known about the system. |
Not quite. An exploit can be exploited, ... it could just send the DS to an invalid memory address somehow. |
??? an exploit can be exploited? how insightful. Usually, exploits involve invalid memroy addresses....ever hear of a buffer overflow? the memory addresses aren't exacltly invalid, they are in the original executing application's context, but usually code is place there to be executed by the exploiter....
#32192 - Abscissa - Sun Dec 19, 2004 6:29 am
| dankydoo wrote: |
| netdroid9 wrote: | | yackom wrote: | | if the ds doesnt start wouldnt that mean the header made the ds bios crash or otherwise hang? if thats so, that might mean the bios is subjectable to a exploit. but then again we probably wont know until there is much more known about the system. |
Not quite. An exploit can be exploited, ... it could just send the DS to an invalid memory address somehow. |
??? an exploit can be exploited? how insightful. Usually, exploits involve invalid memroy addresses....ever hear of a buffer overflow? the memory addresses aren't exacltly invalid, they are in the original executing application's context, but usually code is place there to be executed by the exploiter.... |
But in the case of the GBA and DS it could very well be a "truely" invalid address, for instance anything at or above 0x1000 0000. Ya can't put any code there since it isn't mapped to anything.
The "invalid addresses" that exploits use are only invalid in the sense that code is not *supposed* to be executed from there. But if a portion of memory is invalid in the sense that it just doesn't exist and isn't mapped to anything else that does exist, then there's not much you can do short of rewiring the hardware.
#32213 - netdroid9 - Sun Dec 19, 2004 1:49 pm
| Abscissa wrote: |
| dankydoo wrote: | | netdroid9 wrote: | | yackom wrote: | | if the ds doesnt start wouldnt that mean the header made the ds bios crash or otherwise hang? if thats so, that might mean the bios is subjectable to a exploit. but then again we probably wont know until there is much more known about the system. |
Not quite. An exploit can be exploited, ... it could just send the DS to an invalid memory address somehow. |
??? an exploit can be exploited? how insightful. Usually, exploits involve invalid memroy addresses....ever hear of a buffer overflow? the memory addresses aren't exacltly invalid, they are in the original executing application's context, but usually code is place there to be executed by the exploiter.... |
But in the case of the GBA and DS it could very well be a "truely" invalid address, for instance anything at or above 0x1000 0000. Ya can't put any code there since it isn't mapped to anything.
The "invalid addresses" that exploits use are only invalid in the sense that code is not *supposed* to be executed from there. But if a portion of memory is invalid in the sense that it just doesn't exist and isn't mapped to anything else that does exist, then there's not much you can do short of rewiring the hardware. |
??? an exploit can be exploited? how insightful.
I'll pretend I never read that.
I meant pretty much what Abscissa said, it's invalid because there ISN'T any data there to execute, and the DS stops either because of an invalid address, or because their isn't anything for it to execute.
#32236 - sillyb - Sun Dec 19, 2004 11:46 pm
Here is an idea I got for figuring out a bit more about the encryption scheme:
1) Hook up two catridges (same game) in parallel with the proper buffering so only one can send data back to the DS (to prevent line contention). But capture the data sent back by both catridges.
This ensures both catridges get the same header info, (possibly same encryption key if its sent in header) etc, Comparing these two sets of data: and then we will know for sure if encryption is done on a per game basis or per catridge basis.
2) Same as above with (two different games), capturing both data coming back
Any similarities between the returned data from two different games could be unenecryped replies that didnt make sense in previous contexts.
Anyone have a good link describing RSA encryption? Is that the method utilizing a public and private key?
#32245 - Abscissa - Mon Dec 20, 2004 2:18 am
| sillyb wrote: |
Here is an idea I got for figuring out a bit more about the encryption scheme:
1) Hook up two catridges (same game) in parallel with the proper buffering so only one can send data back to the DS (to prevent line contention). But capture the data sent back by both catridges.
This ensures both catridges get the same header info, (possibly same encryption key if its sent in header) etc, Comparing these two sets of data: and then we will know for sure if encryption is done on a per game basis or per catridge basis.
2) Same as above with (two different games), capturing both data coming back
Any similarities between the returned data from two different games could be unenecryped replies that didnt make sense in previous contexts.
|
Maybe someone with more hardware knowledge than me would disagree, but that actually sound like a pretty good idea.
| sillyb wrote: |
| Anyone have a good link describing RSA encryption? Is that the method utilizing a public and private key? |
I don't know of any links, but I'm pretty sure RSA is one type of encryption that uses a public and a private key.
#32264 - willgonz - Mon Dec 20, 2004 9:12 am
Hook two DS'es Side by Side with the Same time/date synced. Then extract the game data at the same time, using the same game but on two different game carts. Is the data the same or different for each one? My guess is the encryption is based on time and date. Which can be done multiple ways to convert date and time to a formula. So you have figured out the formula that it is using; right? Big Deal???? It is a very big deal. Because you could use a basic stamp (http://www.parallax.com/html_pages/products/basicstamps/basic_stamps.asp) module to program your encryption. Which now means you could make a small external box which would read Flash Memory cards say CF cards. And then encrypt them so the DS will take them. On the CF cards would be some sort of BIN file for example that would contain your code.
_________________
│?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.
#32265 - blinky465 - Mon Dec 20, 2004 9:32 am
| Abscissa wrote: |
| sillyb wrote: | | Anyone have a good link describing RSA encryption? Is that the method utilizing a public and private key? |
I don't know of any links, but I'm pretty sure RSA is one type of encryption that uses a public and a private key. |
Abcissa is right - RSA is just one type of cipher used in PKE encryption.
#32277 - EaDS Milliways - Mon Dec 20, 2004 1:46 pm
| willgonz wrote: |
| Hook two DS'es Side by Side with the Same time/date synced. Then extract the game data at the same time, using the same game but on two different game carts. Is the data the same or different for each one? |
I would think that it's different for each one. Just looking at some of their other technology it is possible to have MANY different valid keys for each beat. Potentially, they could use a separate valid key for each DS made such that no two will ever yield the same results. Yet all will still be compatible with every cart made.
Since their technology can be built into devices that don't have clocks, I would imagine that the time you can view on the device has nothing to do with the encryption.
#32805 - qwertycho - Tue Dec 28, 2004 6:27 am
Sorry, but I'm a newb, and I don't really understand what you guys are talking about. But I do have a GBA flash cart, and I have the metroid NDS rom, how do I get it to run on my NDS? I tried flashing just the rom but I assume there is something more that I have to put on the card besides just the rom.
please help,
thanx
#32807 - netdroid9 - Tue Dec 28, 2004 7:17 am
| qwertycho wrote: |
Sorry, but I'm a newb, and I don't really understand what you guys are talking about. But I do have a GBA flash cart, and I have the metroid NDS rom, how do I get it to run on my NDS? I tried flashing just the rom but I assume there is something more that I have to put on the card besides just the rom.
please help,
thanx |
I assume you own the demo, and know that the rom is a demo. Sorry, nobody knows how to do that without a DS game to load it, and I'm not sure how that works.
#32809 - sillyb - Tue Dec 28, 2004 7:19 am
I think you won't be able to run DS rom from the gba slot.
At least not without some kind of (As yet nonexistant) bootloader catridge in the NDS slot.
#32811 - ravuya - Tue Dec 28, 2004 7:47 am
| qwertycho wrote: |
Sorry, but I'm a newb, and I don't really understand what you guys are talking about. But I do have a GBA flash cart, and I have the metroid NDS rom, how do I get it to run on my NDS? I tried flashing just the rom but I assume there is something more that I have to put on the card besides just the rom.
please help,
thanx |
You can't boot DS code off the GBA flash carts yet. Also, what does this have to do with the rest of this thread?
_________________
Rav (Win/Mac/Linux games for free)
#32895 - qwertycho - Wed Dec 29, 2004 1:14 am
on the dspaparazzi site it said that you could play DS games through the flash card... those liars!!!
#32896 - phantomdjp - Wed Dec 29, 2004 1:21 am
| qwertycho wrote: |
| on the dspaparazzi site it said that you could play DS games through the flash card... those liars!!! |
No, it's true, you just need to say to the DS "Hello, don't read in DS port, but in the GBA one". That is what Darkfader actually do. The real problem is to say that to the DS. Actually darkfader a home made hardware but maybe later it could be done directly with a specific DS card, a bit like with doctor 64 on Nintendo 64 which make it read "Hi I'm a fake card, please read in the CD-Rom player in the extension bay"
#32905 - darkfader - Wed Dec 29, 2004 3:16 am
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:38 pm; edited 2 times in total
#32908 - ravuya - Wed Dec 29, 2004 4:26 am
| qwertycho wrote: |
| on the dspaparazzi site it said that you could play DS games through the flash card... those liars!!! |
Well, you can't boot code off the GBA flash cart by itself. You have to do what Darkfader did, and rig up an FPGA dealie that interfaces with the DS port to push a bootloader in.
_________________
Rav (Win/Mac/Linux games for free)
#32930 - osirisx11 - Wed Dec 29, 2004 9:17 am
I got a DS for Christmas...man is it nice...and of course being the computer enthusiast that I am I immediatley wanted to hack it... I can definatley tell you guys are doing a great job in progressing...especially darkfader...good work man!
I am here and just waiting and watching closely for each new hack/modification.. I program too but I am a web developer....C# (similar to java)..I don't think I could help with this..I'm open to trying though.
Anyways I just wanted to congratulate everyone here at gbadev and the fine folks at xlink on all your progress, I know it can be very frustrating, but lets keep the communication open, post as much data as we can for each other ...screenshots...movies...hex dumps ;)...and anything else..
eventually we will crack this cookie and taste the wonderful goodness that is DS.
-OsirisX11
OsirisX11 on AIM/Y
ihatemicrosoft@hotmail.com on MSN
#32945 - ryuryan - Wed Dec 29, 2004 2:15 pm
| darkfader wrote: |
| Ok... I cut the trace of the clock input and tied it to VCC. ...snip |
do you get the same encrypted code from two different metroid demo cartridges with the time fixed?
#32960 - yackom - Wed Dec 29, 2004 6:16 pm
how is it you are fixing the time?
#32962 - abigsmurf - Wed Dec 29, 2004 6:20 pm
it would probably save money with the encryption giving them all identical keys but programming the encryption chips/sections to use the size of the code in bits/bytes/kb to find the initial key (along with the timer function)
#32964 - osirisx11 - Wed Dec 29, 2004 6:25 pm
Couldn't it be set up in a fashion which multiple keys can unlock the encryption, but it has to match a specific formula?
Like CD keys....there's a bunch of them...but they all fit an algorithm.
#32967 - abigsmurf - Wed Dec 29, 2004 6:31 pm
I would've thought that method would be too 'easy' to brute force.
#32968 - osirisx11 - Wed Dec 29, 2004 6:34 pm
Would someone be so kind as to restate what we know/have learned so far about the method and protocol of the DS encryption?
I get a bit lost trying to keep track of multiple pages of multiple threads. :)
#60169 - darkfader - Mon Nov 07, 2005 9:12 pm
Moo... It's still inside my head.
Last edited by darkfader on Mon Nov 07, 2005 11:01 pm; edited 5 times in total
#60174 - tepples - Mon Nov 07, 2005 9:29 pm
[sarcasm]Way to give us a lot to go on.[/sarcasm]
"moo" doesn't have anything to do with the distributed.net mascot, does it? Do you mean you're about to release some new distributed cracking tool?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#60200 - NEiM0D - Tue Nov 08, 2005 1:12 am
what is up with darkfader deleting his posts..
we need more people quoting him.
#60262 - MaHe - Tue Nov 08, 2005 2:53 pm
OMG?
| Quote: |
We soon announce new products! It can work all firmware. No other DS card need!
KeyMe run from GBA cart like EonFlash.
SuperKey run from SD card directly!.
FlashKey run from internal flash (16Gb!), supersmall!
SuperFlashKey is secret! much $$$ hahaha! |
DF, can you explain your posts?
And DF - are you sure you're stable?
#60277 - darkfader - Tue Nov 08, 2005 4:33 pm
It's just supposed to be a funny signature :)
#60284 - MaHe - Tue Nov 08, 2005 5:33 pm
Ah, OK.