#29714 - Deathwind - Wed Nov 24, 2004 7:12 am
The GBA carts have 32 pins, layed out like:
1 -> Vcc (power)
2 -> PHI (don't care in the case of dumping, actually not sure what this is for)
3 -> WR (write data line)
4 -> RD (read data line)
5 -> CS ROM (chip select, addressing ROM)
6...29 -> AD0...AD23 (address lines)
30 -> CS2 RAM (chip select, addressing (S)RAM)
31 -> IRQ (Interrupt Request, don't care for dumping)
32 -> GND (ground)
24 and up appear to be don't cares for some dumper designs.
The GBA can access addresses up to 2^16 = 65,536.
We know the DS carts have 17 pins, probably layed out in a somewhat similar fashion. However, as you've probably noticed, there's almost a reduction by half in pin count. So how many address and data lines are on the cart? How is the design different? They could possibly eliminate PHI (again, not sure here). They've probably made it so that each address addresses a larger section of data (2x-4x the amount would seem to be reasonable). The GBA strobes RD 16 times to get 16 bits off each read, with 24-bit addresses, 2^24 = 16,777,216, times 16 = 32Mbytes. Assuming the DS used half the addressing (doubtful, as 12 address lines yields a whopping 4,096 available addresses if they're doing it straight up, but let's run with it). They could also probably eliminate one of the WR/RD lines and combine them onto one bidirectional line, since the CS chips would indicate what operation would be needed,
1 -> Vcc (power)
2 -> RD/WR (read/write data line)
3 -> CS RAM (chip select, addressing ROM)
4...15 -> AD0...AD11 (address lines)
16 -> CS2 ROM (chip select, addressing (S)RAM)
17 -> IRQ (Interrupt Request, don't care for dumping)
18 -> GND (ground)
That's about as small as I can get a theoretical DS cart pinout (possibly they could eliminate one of the CS lines, but that might require some trickery to latch the address lines properly in that case), and it has an absolutely miniscule number of standard addressable memory locations. while still being one pin too large. Any suggestions, information, multimeter readings, etc. might be of help. The plan being to get enough information to provide an accurate DS pinout, usable for dumping or running custom code (assuming and hoping the DS doesn't use encryption/signing on the carts). The massively reduced pin count would seem to point to them using some sort of radically different addressing of the ROM, anyone have any ideas?
#29717 - ampz - Wed Nov 24, 2004 7:43 am
It most likely has a 8bit bus with multiplexed adress and data.
#29773 - iguanaman - Wed Nov 24, 2004 11:10 pm
I would agree with a totally different bus, probably similar to MMC/SDCARD. You probably transfer an address by writing it in blocks to the cart, and then read back the data in several bus transactions.
If someone buys me a DS :) I'll hook it up to the logic analyser here and let everyone know what the bus specifications are within a week.
#29780 - ravuya - Thu Nov 25, 2004 1:20 am
What is the power on the GBA slot anyway, 3.3V? If they're planning on letting you plug accessories into the GBA slot on the DS they must have jumped the power up on its slot. Wonder if that'll damage some cheaper flash carts.
_________________
Rav (Win/Mac/Linux games for free)
#29782 - tepples - Thu Nov 25, 2004 1:52 am
| ravuya wrote: |
| What is the power on the GBA slot anyway, 3.3V? |
No, that's the voltage. Power is voltage times current.
| Quote: |
| If they're planning on letting you plug accessories into the GBA slot on the DS they must have jumped the power up on its slot. Wonder if that'll damage some cheaper flash carts. |
If a flash cart's resistance is constant, and the voltages don't change from system to system, the flash cart won't see the extra current that the DS may be able to put out. The official Game Paks depend on 3.3V anyway.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#29783 - ravuya - Thu Nov 25, 2004 2:02 am
| tepples wrote: |
| ravuya wrote: | | What is the power on the GBA slot anyway, 3.3V? |
No, that's the voltage. Power is voltage times current.
| Quote: | | If they're planning on letting you plug accessories into the GBA slot on the DS they must have jumped the power up on its slot. Wonder if that'll damage some cheaper flash carts. |
If a flash cart's resistance is constant, and the voltages don't change from system to system, the flash cart won't see the extra current that the DS may be able to put out. The official Game Paks depend on 3.3V anyway. |
OK. :) Sorry, I kind of forgot my high-school physics there. So, has anyone taken a multimeter to their DS to see how much wattage the little bugger pumps out on that line?
_________________
Rav (Win/Mac/Linux games for free)
#29800 - ampz - Thu Nov 25, 2004 7:12 am
| ravuya wrote: |
| So, has anyone taken a multimeter to their DS to see how much wattage the little bugger pumps out on that line? |
It does not work that way.
#29804 - FluBBa - Thu Nov 25, 2004 9:21 am
I suspect that the GBA port has reduced power on the DS seeing as the really old FA carts doesn't work properly on it (and they needed more power than the newer ones/commercial carts).
It might be a long shot though.
_________________
I probably suck, my not is a programmer.
#29813 - ampz - Thu Nov 25, 2004 11:40 am
If there is less power available, then that apply for the entire DS, not just the GBA cart port.
Dual backlit screens, dual CPUs, 802.11, and touchscreen indicates that the DS powersupply must be capable of handle higher peak power requirements than the GBA SP.
The fact that the DS use the same battery as the SP while having roughly the same battery life indicates that while the peak power requirements of the DS are likely to be alot higher than the SP, the average power requirements are about the same.
#29853 - bveina - Fri Nov 26, 2004 4:09 am
im just trying to put together a diagram of the cart. but i dont have a picture of what is underneath the chip. i also dont really have the cash to unsotter the chip off of mine(i like playing M64). but someone here probably already has. if amyone has a pic of the naked cart could they post it?
#29855 - TurningJapanese - Fri Nov 26, 2004 4:41 am
A simple alternative is taking apart the Metroid demo that came with the system, and some answers can be gained by comparing the main mask ROM with similar models found here:
http://www.mxic.com.tw/QuickPlace/hq/PageLibrary48256D9D002BA613.nsf/h_Toc/D5DEB2894B2922DB48256DA600836B77/?OpenDocument#3.0/3.3V%20Standard%20ROM
Notably the MX23L12810 and MX23L12811 - those are the models most similar to the custom chip. Be sure to look at the 44SOP package and not the 48TSOP.
And while the standard ROM's of this type are available in 3.0 or 3.3V - you can't be 100% certain due to the custom nature of the thing. Though it looks like, in the 44SOP package, it may be 3.0.
#29878 - Joat - Fri Nov 26, 2004 7:23 am
Both SM64DS and Metroid Prime Hunters: First Hunt have a 128 Mbit custom ROM chip inside.
The chips are labelled MX23L12808-15D. Note: Although this seems similar to the datasheets they have on their website (10,11,13), it is NOT similar. The format is MX23Lxxxyy-zzw, where xxx is capacity (128 mbit), yy is part type, and they are radically different (04 was pokemon mini ROMs, 08 is NDS, 10 is flat linear ROM, 13 has address and data multiplexed, seems similar to the GBA bus), zz is access speed. There is also an EEPROM chip in each cartridge, probably 4 K.
The MX23L12808-15 rom (possibly OTP, but probably mask) chips store 128 mbit of data, have a access cycle of 150 ns (6.67 MHz), and use some sort of command oriented communication mode. Despite the fact the package has 44 pins, most of these are grounded. There are 8 i/o pins and a few control signals, two of which we think are a comms clock and eeprom chip select.
They are likely encrypted, but whether its a static encryption before programming carts or a key-challenge system is currently unknown.
_________________
Joat
http://www.bottledlight.com
#29916 - ravuya - Fri Nov 26, 2004 4:23 pm
| ampz wrote: |
| ravuya wrote: | | So, has anyone taken a multimeter to their DS to see how much wattage the little bugger pumps out on that line? |
It does not work that way. |
I'm obviously not an electrical engineer, just here to code. I'll shut up now.
_________________
Rav (Win/Mac/Linux games for free)
#30333 - TauZero - Tue Nov 30, 2004 2:02 pm
Ok, I took the plunge and desoldered the ROM and the EEPROM from my Metroid cart and here is the pin mapping I get...
Starting from the left, pins facing you:
Pin 1 -> GND
Pin 2 -> pin 5 of ROM and pin 6 of the EE (EE CLK)
Pin 3 -> pin 17 of ROM
Pin 4 -> pin 44 of ROM
Pin 5 -> pin 42 of ROM
Pin 6 -> pin 1 of EE (EE CS)
Pin 7 -> GND
Pin 8 -> VCC
Pin 9 -> pin 18 of ROM
Pin 10 -> pin 19 of ROM
Pin 11 -> pin 20 of ROM
Pin 12 -> pin 21 of ROM
Pin 13 -> pin 24 of ROM
Pin 14 -> pin 25 of ROM
Pin 15 -> pin 26 of ROM and pin 2 of EE (EE DOUT)
Pin 16 -> pin 27 of ROM and pin 5 of EE (EE DIN)
Pin 17 -> GND
I think the EE is similar to an M95040-W by STmicro, atleast the pinout makes sense with the connections (grounds and supplies are in the correct place and the write protect and halt lines are pulled high to disable them).
I do not think that its a coincidence that pins 9-16 of the connector go to sequential pins on the ROM, I think they may be data lines. That would leave pins 3-5 as some sort of control lines (RD, CS, and ALE or something maybe?) and pin 2 very well may be a clk for both devices, but I would not know until I hooked a scope up to it.
What do you guys think?
#30336 - jgkspsx - Tue Nov 30, 2004 5:27 pm
| TauZero wrote: |
| Ok, I took the plunge and desoldered the ROM and the EEPROM from my Metroid cart and here is the pin mapping I get... |
Good job!
| Quote: |
| I think the EE is similar to an M95040-W by STmicro, atleast the pinout makes sense with the connections (grounds and supplies are in the correct place and the write protect and halt lines are pulled high to disable them). |
That seems probable.
| Quote: |
| I do not think that its a coincidence that pins 9-16 of the connector go to sequential pins on the ROM, I think they may be data lines. |
I agree, though MXIC didn't do sequential data lines on the other chips in this line, IIRC. Odd.
| Quote: |
| That would leave pins 3-5 as some sort of control lines (RD, CS, and ALE or something maybe?) and pin 2 very well may be a clk for both devices, but I would not know until I hooked a scope up to it. |
But how is it addressed? Could they be using the data lines for address selection and for data transfer? Otherwise... hm.
Last edited by jgkspsx on Tue Nov 30, 2004 5:47 pm; edited 1 time in total
#30337 - tepples - Tue Nov 30, 2004 5:44 pm
| jgkspsx wrote: |
| But how is it addressed? Could they be using the data lines for address selection and for data transfer? |
That'd be my guess, given how both the GBA cart bus and parallel ATA work.
But if the /WE line is just pulled high by the PCB, then it might not even be truly OTP at all: either it's rewritable flash memory, or even if not, we could desolder the ROM and put code in an unused space (like Castlevania's 12 Mbits of unused space) and then carefully change some of the game's 1 bits to 0 to get it to jump to the unused space.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#30351 - ampz - Tue Nov 30, 2004 6:32 pm
| tepples wrote: |
| jgkspsx wrote: | | But how is it addressed? Could they be using the data lines for address selection and for data transfer? |
That'd be my guess, given how both the GBA cart bus and parallel ATA work.
But if the /WE line is just pulled high by the PCB, then it might not even be truly OTP at all: either it's rewritable flash memory, or even if not, we could desolder the ROM and put code in an unused space (like Castlevania's 12 Mbits of unused space) and then carefully change some of the game's 1 bits to 0 to get it to jump to the unused space. |
There is no /WE line on the DS cards, there are only two control lines used for ROM access: CS and CLK.
Here are the pins used by the ROM:
Pin 2 = CLK
Pin 4 = ROM CS
Pin 5 = RESET (Just a normal power-up reset line)
Pin 9-16 = D0-7 (This is the 8bit data bus)
Pin 3 = VPP (Looks like this might be a VPP line for high-voltage programming of the OTP memory. It is left floating on both the card and the DS)
Data transfers between the DS and the card are initiated by the DS pulling ROM CS low, followed by a 8byte transfer from the DS to the card (one cycle on CLK for each byte). Looks like the initial 8byte transfer select type of transfer, direction and address.
After that, depending on the type of transfers, there can be a delay of several microseconds, or the actual data transfer can start immediately. The data transfer is of course block based, with what looks like a block size of 512Byte. However, it is not necessary to transfer a complete block, and it is possible to transfer more than one block at the same time.
After the transfer is complete, ROM CS is pulled high again.
The data bus is encrypted at runtime with a random key. The data transfered is different each time you power up your DS. Both the 8Byte commands and the transfered data blocks are encrypted.
Only a few blocks in the beginning are transfered unencrypted, the header is one of them.
I do agree that it might be possible to use leftover memory areas for our own software. But the memory is OTP, so it can only be done once for each card.
The encryption must also be cracked before we can do anything at all (except reading and writing the EEPROM, which is unencrypted)
#30357 - jgkspsx - Tue Nov 30, 2004 7:00 pm
| ampz wrote: |
| Data transfers between the DS and the card are initiated by the DS pulling ROM CS low, followed by a 8byte transfer from the DS to the card (one cycle on CLK for each byte). Looks like the initial 8byte transfer select type of transfer, direction and address. |
Mystery solved, good work. Have you figured out how many bits addressing is? 8bit just doesn't make sense, and transfer type/directionality shouldn't require more than two or three bits each, eh?
| Quote: |
| The data bus is encrypted at runtime with a random key. The data transfered is different each time you power up your DS. Both the 8Byte commands and the transfered data blocks are encrypted. Only a few blocks in the beginning are transfered unencrypted, the header is one of them. |
Damn. Enter RSA? The encryption must be done in a repeatable way. Are you sure data loading from the cart is encrypted differently each time? That doesn't make sense to me off the top of my head.
| Quote: |
| I do agree that it might be possible to use leftover memory areas for our own software. But the memory is OTP, so it can only be done once for each card. |
Er, stupid question, but isn't it likely that they've already programmed the leftover areas with null data? Or was this not the case in the past?
| Quote: |
| The encryption must also be cracked before we can do anything at all (except reading and writing the EEPROM, which is unencrypted) |
Hopefully we can get around it, but this is rather depressing news. Great work with the logic analyzer, though.
#30363 - ampz - Tue Nov 30, 2004 7:33 pm
| jgkspsx wrote: |
| ampz wrote: | | Data transfers between the DS and the card are initiated by the DS pulling ROM CS low, followed by a 8byte transfer from the DS to the card (one cycle on CLK for each byte). Looks like the initial 8byte transfer select type of transfer, direction and address. |
Mystery solved, good work. Have you figured out how many bits addressing is? 8bit just doesn't make sense, and transfer type/directionality shouldn't require more than two or three bits each, eh?
|
Impossible to say since almost all the commands are encrypted as well.
| jgkspsx wrote: |
| Quote: | | The data bus is encrypted at runtime with a random key. The data transfered is different each time you power up your DS. Both the 8Byte commands and the transfered data blocks are encrypted. Only a few blocks in the beginning are transfered unencrypted, the header is one of them. |
Damn. Enter RSA? The encryption must be done in a repeatable way. Are you sure data loading from the cart is encrypted differently each time? That doesn't make sense to me off the top of my head.
|
No, it's not RSA (RSA is not runtime).
Yes, data is completely different each time. Both the data packets and the 8byte commands are completely random each time you boot the system.
The DS is most likely sending a new random key to the card each time you boot.
| jgkspsx wrote: |
| Quote: | | I do agree that it might be possible to use leftover memory areas for our own software. But the memory is OTP, so it can only be done once for each card. |
Er, stupid question, but isn't it likely that they've already programmed the leftover areas with null data? Or was this not the case in the past? |
Normally you leave unused memory areas unprogrammed. I don't see why they would do it any different.
| jgkspsx wrote: |
| Quote: | | The encryption must also be cracked before we can do anything at all (except reading and writing the EEPROM, which is unencrypted) |
Hopefully we can get around it, but this is rather depressing news. Great work with the logic analyzer, though. |
I doubt we can get around it that easily, I can't see any obvious flaws we can use to our advantage.
#30364 - ravuya - Tue Nov 30, 2004 7:35 pm
| ampz wrote: |
| The data bus is encrypted at runtime with a random key. |
I wonder why it does that, maybe it's an attempt to prevent ROM dumping or something. I really can't find any decent reason for that, and even ROM dumping would succeed if you just popped the ROM chip off the card and dumped it that way.
_________________
Rav (Win/Mac/Linux games for free)
#30366 - ampz - Tue Nov 30, 2004 7:38 pm
| ravuya wrote: |
| ampz wrote: | | The data bus is encrypted at runtime with a random key. |
I wonder why it does that, maybe it's an attempt to prevent ROM dumping or something. I really can't find any decent reason for that, and even ROM dumping would succeed if you just popped the ROM chip off the card and dumped it that way. |
Obvious reason: With static encryption, you can simply copy the encrypted data to a flash card and run it.
You can't "pop the ROM chip off the card" to solve the problem. The encryption logic is integrated with the ROM.
#30380 - ravuya - Tue Nov 30, 2004 8:42 pm
| ampz wrote: |
| ravuya wrote: | | ampz wrote: | | The data bus is encrypted at runtime with a random key. |
I wonder why it does that, maybe it's an attempt to prevent ROM dumping or something. I really can't find any decent reason for that, and even ROM dumping would succeed if you just popped the ROM chip off the card and dumped it that way. |
Obvious reason: With static encryption, you can simply copy the encrypted data to a flash card and run it.
You can't "pop the ROM chip off the card" to solve the problem. The encryption logic is integrated with the ROM. |
I was actually coming back here to edit that post because I hit upon that thought as well.
_________________
Rav (Win/Mac/Linux games for free)
#30651 - ChaosKnight - Fri Dec 03, 2004 5:33 am
TauZero - You are the man. I have been workingunder a false assumption for some of these pins. Do you have any high resolution scans of your chip-less card? If so could you either post them or e-mail them to me? I have been posting much of my research on the dslinux forums along with images.
Some clarification on the 8 bit bus thing. It's a serial bus, so there might not seem to be any logic to it, but I assure you there is:
"The I/O pins are used to input command, address and data, and to output data during read operations. The I/O pins float to high-z when the chip is deselected or when the outputs are disabled."
This is pretty standard for 1Gbit memory devices, or so it seems from my research.
#30671 - TauZero - Fri Dec 03, 2004 12:59 pm
| ChaosKnight wrote: |
TauZero - You are the man. I have been workingunder a false assumption for some of these pins. Do you have any high resolution scans of your chip-less card? If so could you either post them or e-mail them to me? I have been posting much of my research on the dslinux forums along with images.
Some clarification on the 8 bit bus thing. It's a serial bus, so there might not seem to be any logic to it, but I assure you there is:
"The I/O pins are used to input command, address and data, and to output data during read operations. The I/O pins float to high-z when the chip is deselected or when the outputs are disabled."
This is pretty standard for 1Gbit memory devices, or so it seems from my research. |
No, but I could make some. How high a res?
I knew it was 'serial', I was guessing its similar to MXIC's serial flash chip, but it does not quite seem to be. Has anyone figured out waht the /wr and /rd pin(s) are yet? Obviously you would need the ability to write the command so /wr (or r/w) is needed.
#30672 - TauZero - Fri Dec 03, 2004 1:45 pm
I don't know if anyone has done it yet, but the ROM interface seems slow enough that you should not need an expensive Logic Analyzer to figure it out. What someone could do is hook a PIC/AVR (my choice would be an AVR) up to a clocked (synchronus) FIFO where the PIC/AVR is on the output, and the ROM interface is on the input. You could even use a 9 or 18 bit FIFO to try and capture the pins other then the 'data' pins. Hook the FIFOs clk and CS lines up to the ROM's clk and CS lines and go from there. To start with we could capture the CART ID phase that happens during power up (while the warning screen is loading) and atleast see if we can get any significant data from that (like ROM command structure ETC). All the data you capture could be spit out a byte at a time to the PC's serial port for dissection.
Hopefully the ROM interface is not dual edge clocked...
What do you guys think?
#30673 - ChaosKnight - Fri Dec 03, 2004 1:59 pm
| TauZero wrote: |
| No, but I could make some. How high a res? |
600 dpi would be good. Nicely cropped and saved as a JPG at quality 3 in photoshop it'll end up being about 55k.
| TauZero wrote: |
| I don't know if anyone has done it yet, but the ROM interface seems slow enough that you should not need an expensive Logic Analyzer to figure it out |
The whole DS card runs at 4MHz... so yeah, pretty slow. I found a chip that will let me hook up to it using the IO 0-7 pins to a USB port. I was going to attach this chip to it and dump it to a raw file under linux.
What do you think?
Last edited by ChaosKnight on Fri Dec 03, 2004 2:04 pm; edited 1 time in total
#30674 - TauZero - Fri Dec 03, 2004 2:04 pm
| ChaosKnight wrote: |
The whole DS card runs at 4MHz... so yeah, pretty slow. I found a chip that will let me hook up to it using the IO 0-7 pins to a USB port. I was going to attach this chip to it and dump it to a raw file under linux. |
Are you refering to the FTDI FT245 chip? I do not think it can operate this fast. You would still need the FIFO. Remember USB is 12Mbps which after overhead is only about 1MBps 4 MHZ would be 4MBps for this flash chip assuming its 8 bits at a time (per clock cycle). Now if you found a USB2 version that did the full 480Mbps, then that might work ;)
#30675 - ChaosKnight - Fri Dec 03, 2004 2:07 pm
| TauZero wrote: |
| Are you refering to the FTDI FT245 chip? |
FT245? I only have and MX chip (MaskROM) and an ST chip (EEPROM). For sure the EEPROM can't handle it, and I think the USB chip would run the MaskROM at 12MHz when it does it's stuff... but normally because of the EEPROM the card would run at 4MHz.
#30676 - TauZero - Fri Dec 03, 2004 2:24 pm
| ChaosKnight wrote: |
| TauZero wrote: | | Are you refering to the FTDI FT245 chip? |
FT245? I only have and MX chip (MaskROM) and an ST chip (EEPROM). For sure the EEPROM can't handle it, and I think the USB chip would run the MaskROM at 12MHz when it does it's stuff... but normally because of the EEPROM the card would run at 4MHz. |
Sorry, what I meant was, whats the USB chip? is it an FT245?
The issue with clocking the ROM at 12MHZ (in this instance) would not necessarily be the speed of the ROM, but the speed of USB. USB is 12 megaBITS per second, the rom (at 12MHz, assuming its not double edge clocked) would be 12 megaBYTES per second. Thats 8 times faster. Remember USB is clocking 1 bit every clock, the ROM is clocking 8...
I am gathering that you just want to set up a ROM reader of some sort? My origional idea was to use a sort of 'man in the middle' attack to decypher what the traffic was thats going across the 8 datalines between the DS and the ROM. I think that may need to be done first to figure out how to even read the thing in the first place, since its obvious (atleast to me) that its a command oriented interface. Maybe its not... I donno yet :)
#30688 - gb_feedback - Fri Dec 03, 2004 4:31 pm
I've been following the discussion with interest. I just wanted to throw in one thing. My company makes device programmers and I usually get to write the algorithms. If anyone who had unsoldered their EEPROM and wasn't too fussy about what happened to it, I would love to try to identify it more accurately. Downside is that I'm in the UK. Just a thought.
_________________
http://www.bookreader.co.uk/
#30689 - ChaosKnight - Fri Dec 03, 2004 4:31 pm
| TauZero wrote: |
| Sorry, what I meant was, whats the USB chip? is it an FT245? |
No, it's an OTi part. Sorry, I'm at work and don't have the part number on me. I can send you the datasheet at some point.
| TauZero wrote: |
| ... its obvious (atleast to me) that its a command oriented interface. Maybe its not... I donno yet :) |
You are 100% correct, it's a command oriented protocol. But it's a standard protocol, nothing special there. A USB -> Flash controller that's capable of handling 1GBit devices should be fine. However it's possible (albiet unlikely) that because it's a special part there are special commands, in that case a man in the middle attack will definately be required. For a job like that I'd personally use an SX instead of a PIC. SX are crazy powerful processors, good for man in the middle datalogging type stuff.
#30733 - yackom - Sat Dec 04, 2004 1:32 am
Ampz ive been following your work, very good.. now i wanna try to sober the situation up a bit.
But I?m messaging you now because I want to talk more about the encryption? and im offering my programming help, what you would need programming for ill explain in a bit. And excuse me if this is entirely obvious to you, but I haven?t seen anything in the forum to lead me to believe this.
**I want to give you my take of the encryption situation** (you obviously know all of this)
1) the DS boots up, gains entropy from most likely the system clock.
-from the pictures ive seen (lik sang open ds pictures) the machine only has 1 really significant chip, it looks both processors arm7 and 9 and its ram, sys clock and all of that crap is in that one package.
2) So all internally, it grabs the time does some function to make the encryption key for the ds?s cart.
3) Sends the key to the cart
4) The cart takes that key and puts it some where, either the smaller or bigger chip. This I do not really know, I didn?t look into the rom chip at all, your guess on this would be better than mine.
5) The cart now uses this key, the ds must know how to undo this data, so the encryption format must be invertible. Since it is based solely on one key, generated by the ds. Since the cartridges have no way of actually gaining entropy, except by the data the ds sends it.
**Now what does all this garbage mean**
Since the encode function is on the DS processor we have basically no chance in hell of getting it out, im sure Nintendo wasn?t dumb enough to put it in the bios, and we cant get the encode function from the cartridge. but we can get around that. Granted its not easy but let me explain.
-As a mathematical look:
The ds has one function to: make_key(time) = encryption seed.
The cartrages has a function : encode_data(data,seed) = encrypted data.
The ds has another function : decode_data (encrypted data) = data.
Ok, now, since the decode_data function is invertible, then encode_data = decode_data^(-1). and since invertible is both one to one, and onto.
How can we exploit this? We know that data for an address on the cartridge is a constant obviously, but the keys are not, but who says we need to let the DS assign the keys? If we can figure out what the format for the key setting of the cartridge we can actually build a very large logic table by enumerating the entire set of keys and reading from the same location of data (and we might need to read from more than one location of data to get the true encode function). Then from that table build an encode function and from there we can build the inverse of that to make the decode function if we so desired.
**in practice**
There are obvious concerns, how do we know the data format for the key, how many bits is the key, if its 32 bits then there will be 4.096 billion entries in the table, causing for a very large table.
We need to know what we are trying to read from the cartridge so that means we actually know what the rom is, so we most likely need to pray they can get the data off from a wireless exploit, or a gba dev cart to boot arm9 code exploit.
We also need to know how to tell were to read from off of the cartridge... we might even have to build a table on how to encrypt the commands, so basically do all of this work just for the command decoding to ensure we can get accurate information on what data is being read off of the cartridge. Well what choice do we have? None of us have the access to reverse engineer chips (I would think, unless you guys got major pull in intel, amd or some other very large chip researcher company) but this is all within our power.
And all of this is assuming your current analysis is correct Ampz, which it does seem the most likely to me.
**my questions**
Do you know the role of the smaller 8 pin chip on the top yet?
Do you know where the encryption takes place? most likely and I would assume it would be on the bigger chip otherwise it would be useless to make this whole encryption gig anyway cause we could just rip off those smaller chips off of our metroid demos and use those.
Can any of you make a system to send keys we generate to the cartridges? I am not a EE or CE person, I do programming.
#30745 - jgkspsx - Sat Dec 04, 2004 4:22 am
If I may butt in...
| yackom wrote: |
| Do you know the role of the smaller 8 pin chip on the top yet? |
That is a standard EEPROM memory for storing game data. It has nothing to do with encryption.
#30747 - yackom - Sat Dec 04, 2004 4:49 am
thanks jgkspsx,
ok so yeah, little eeprom. doesnt do any encryption.
#30764 - ampz - Sat Dec 04, 2004 11:24 am
I think the key is somewhere around 56-64bits.
If the encryption is LFSR based, which it probably is, then simply reading only a few bytes, and building a table of thoose few bytes with all possible keys will not solve the encryption. Besides, a table with all possible combinations of a 56bit key is not exactly something you can do in a coffee break ;)
Oh, and yes, I can send custom commands to a DS card.
#30778 - mclysenk - Sat Dec 04, 2004 4:53 pm
If it's an xor encryption, you can always check for it easily enough. Just xor any 2 binary streams together and you get a binary pattern.
Example, let A be data and B, C be random keys:
(A ^ B) ^ (A ^ C) = (B ^ C)
So if the keys are xors, there should be some pattern in (B^C). You could also test for shifts by rotating blocks in one of the streams. I'm no electronics whiz though, so I'm not sure if everyone already tried this or not.
#30818 - darkfader - Sun Dec 05, 2004 5:25 am
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:41 pm; edited 1 time in total
#30824 - ChaosKnight - Sun Dec 05, 2004 6:47 am
Looks like DF holds a lot of cards as usual... good to see you here. I'd ask how you got this stuff... but I'm not sure I want to know.
#30843 - ampz - Sun Dec 05, 2004 2:04 pm
| darkfader wrote: |
| I had the pinout before anyone else! :) |
Except you got a few control signals wrong :)
#30858 - darkfader - Sun Dec 05, 2004 4:57 pm
<deleted>