Pages: « 123456 »
Posted on 05-11-18, 08:22 am
Mariomaster

Karma: 8528
Posts: 1204/1681
Since: 06-09-12
All Nintendo consoles from the SNES until the GC used the same multi out.
It can carry Composite, S-Video and RGB but not all consoles it got used in supported all. Would be interesting to check which ones the Nitro units support.

More info about the multi out:
http://pinouts.ru/Game/n64video_pinout.shtml
Posted on 05-11-18, 10:13 am
Shyguy


Karma: 160
Posts: 74/90
Since: 07-10-12
Posted by RicBent
All Nintendo consoles from the SNES until the GC used the same multi out.
It can carry Composite, S-Video and RGB but not all consoles it got used in supported all. Would be interesting to check which ones the Nitro units support.

More info about the multi out:
http://pinouts.ru/Game/n64video_pinout.shtml

From what I know only composite and s-video are supported, just like on the gamecube (it uses the same video-out chips).
Posted on 05-11-18, 10:42 am
Mariomaster

Karma: 8528
Posts: 1205/1681
Since: 06-09-12
Hm, I can't really find any simmilar chips between the GC and the Nitro units. Got a tip which chips do the video out?

The Gamecube actually supported RGB in europe. So it might actually have that depending on the type of GC chips they used.
_________________________
GitHub - Kuribo64 - YouTube
Posted on 05-11-18, 10:50 am (rev. 1 by  Gericom on 05-11-18, 10:51 am)
Shyguy


Karma: 160
Posts: 75/90
Since: 07-10-12
Posted by RicBent
Hm, I can't really find any simmilar chips between the GC and the Nitro units. Got a tip which chips do the video out?

The Gamecube actually supported RGB in europe. So it might actually have that depending on the type of GC chips they used.

Oh, well, the unit in these pictures has n64 video out chips actually (mav-nus). Some have gcn chips. It can only output ntsc, so I doubt rgb would be available.
Posted on 05-11-18, 10:58 am
Mariomaster

Karma: 8528
Posts: 1206/1681
Since: 06-09-12
Yeah, all N64s and NTSC GCs have Composite/S-Video only.
_________________________
GitHub - Kuribo64 - YouTube
Posted on 05-11-18, 11:17 am
Shyguy


Karma: 160
Posts: 76/90
Since: 07-10-12
Posted by RicBent
Yeah, all N64s and NTSC GCs have Composite/S-Video only.

When I bought a cable I was so dumb to buy a composite cable. I didn't even think of using s-video, since I never used it before. In europe it was always either composite or scart (for all kinds of devices basically). I could have had better quality if I had bought s-video though.
Posted on 05-11-18, 11:55 am
Shyguy
bbomb64

Karma: 170
Posts: 42/85
Since: 12-17-17
Hmm, I wonder why they used a non RGB VC? Like Gericom said they could've used a European chip.

I doubt it was for cost.

No one would probably use it anyways.
Posted on 05-11-18, 01:37 pm
Mariomaster

Karma: 8528
Posts: 1208/1681
Since: 06-09-12
Considering all prior consoles in the regions where the Nitro units were disributed from (NOA/NOJ) did not support RGB it was a logical step for them to use the video chips form these regions I assume. Also RGB was never an established standard in the US.

Also yeah, did some more research and it'S confirmed that they do Composite and S-Video only.
_________________________
GitHub - Kuribo64 - YouTube
Posted on 05-11-18, 02:16 pm (rev. 1 by  Gericom on 05-11-18, 02:21 pm)
Shyguy


Karma: 160
Posts: 77/90
Since: 07-10-12
Posted by thegreenbomb
Hmm, I wonder why they used a non RGB VC? Like Gericom said they could've used a European chip.

I doubt it was for cost.

No one would probably use it anyways.

Probably also because the ntsc framerate is the closest to the native ds framerate.

The best though would be to get digital video capture working on is-nitro-emulator like the is-nitro-capture can. I'm almost sure it should be able to do that as well.
Posted on 05-11-18, 07:41 pm
Shyguy
bbomb64

Karma: 170
Posts: 44/85
Since: 12-17-17
Posted by Gericom
Probably also because the ntsc framerate is the closest to the native ds framerate.


True, didn't think about the framerate.
Posted on 05-11-18, 09:52 pm
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9979
Posts: 4419/4456
Since: 06-08-11
I've done more testing about writing commercial ROMs to gamecards, because I could only get it to work when changing the game code to "NTRJ, which seemed weird to me.

There's some interesting info in this thread (needs login, PDF)

To summarize:
- There is extra "encryption data" in the ROM region at 0x0200 - 0x3fff.
- Cards don't allow you to read out the encryption data, so this region is zerofilled in commercial ROM dumps.
- Cards NEED the encryption data to encrypt communications.

This encryption data is calculated from the game's code with Nintendo's Secret Algorithm that game developers didn't have access to. To allow devs to write their games during development, the is-nitro-debugger software has the security data for NTRJ game code embedded, and silently writes it for you when you write a NTRJ game to a card. THIS is why it worked only with NTRJ game code.

ndstool does have the algorithm to generate the encryption data! But it still doesn't work, why? Turns out ndstool has a bug, it writes some of the data to the wrong offset.

The bug is that it writes the "sbox data" to 0x2800 instead of 0x1c00. Note that the sbox data is 0x1000 bytes long, so ndstool is afterwards overwriting half of it when writing the test data at 0x3000. Due to that, encrypting with the current ndstool, then using an hex editor to move the data from 0x2800 to 0x1c00 is not going to work! You need to compile ndstool from source with the fix.

I sent a pull request. With that fix, encrypting and writing a ROM gives you a working flash game card!

Yay!
Posted on 05-11-18, 10:35 pm
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9979
Posts: 4420/4456
Since: 06-08-11
IS-NITRO-WRITER Teardown!

Top, with 8 DS slots.


Side, with power, DIP switches, USB.


Bottom, with serial sticker and option sticker. The "BACKUP" option allows you to write (or read?) the game card backup memory too (for game saves).


Taking out the cover reveals the structure: there are 4 boards with 2 slots each, plugged into a "main board".


Removing the 4 slot boards shows the connector board, with some huge heatsinks.


It can be unscrewed and taken out, revealing a NEC v850 CPU board.


The bottom of the case is just the 5 stand off screws soldered.


NEC V850 cpu board up close. It looks VERY similar to the one in the IS-NITRO-EMULATOR. Probably same design with different layout. Also interesting is it has space for another of these white huge connectors, unpopulated.


Slot adapter board. FPGAs and some RAM?


And finally, the slot boards. They have these black wires for grounding soldered into the slots' covers, that go to the grounding pin at the back of the case.

Posted on 05-12-18, 07:41 am
Shyguy


Karma: 160
Posts: 78/90
Since: 07-10-12
Posted by Dirbaio
I've done more testing about writing commercial ROMs to gamecards, because I could only get it to work when changing the game code to "NTRJ, which seemed weird to me.

There's some interesting info in this thread (needs login, PDF)

To summarize:
- There is extra "encryption data" in the ROM region at 0x0200 - 0x3fff.
- Cards don't allow you to read out the encryption data, so this region is zerofilled in commercial ROM dumps.
- Cards NEED the encryption data to encrypt communications.

This encryption data is calculated from the game's code with Nintendo's Secret Algorithm that game developers didn't have access to. To allow devs to write their games during development, the is-nitro-debugger software has the security data for NTRJ game code embedded, and silently writes it for you when you write a NTRJ game to a card. THIS is why it worked only with NTRJ game code.

ndstool does have the algorithm to generate the encryption data! But it still doesn't work, why? Turns out ndstool has a bug, it writes some of the data to the wrong offset.

The bug is that it writes the "sbox data" to 0x2800 instead of 0x1c00. Note that the sbox data is 0x1000 bytes long, so ndstool is afterwards overwriting half of it when writing the test data at 0x3000. Due to that, encrypting with the current ndstool, then using an hex editor to move the data from 0x2800 to 0x1c00 is not going to work! You need to compile ndstool from source with the fix.

I sent a pull request. With that fix, encrypting and writing a ROM gives you a working flash game card!

Yay!

Cool! Nice found. So this is data that is only needed on an actual cartridge and not on the is-nitro-emulator appearently. Is it known what the exact purpose of that data is?

Also great pictures again.
Posted on 05-12-18, 11:01 am
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9979
Posts: 4421/4456
Since: 06-08-11
Posted by Gericom
Cool! Nice found. So this is data that is only needed on an actual cartridge and not on the is-nitro-emulator appearently. Is it known what the exact purpose of that data is?


From what I understand, the DS encryption generates some data tables from the gamecode, then uses them to encrypt/decrypt commands. This data is what's in the rom at 0x1600 and 0x1c00.

You can see the details at gbatek key1 encryption details. This data is called "keybuf" there.

I can think of 2 reasons they did it this way.

1: efficiency. This way the card doesn't need to calculate the table, and doesn't need temporal ram to store it. Why require extra ram if the data never changes, and you have plenty of rom storage already?

2: more security: By doing it this way, deva never needed to encrypt/decrypt anything in their machines, so Nintendo's tools didn't need to have code for that, protecting it from getting reverse engineered.

Nintendo would assign the gamecode to the game, then give the deva the encryption data for that gamecode and the first 0x800 bytes of the secure area, already encrypted for the gamecode too (what they call the "syscall library").

Also interesting is that doing it this way didn't give devs info useful to pirate/dump other games than their own.
Posted on 05-12-18, 12:33 pm
Shyguy


Karma: 160
Posts: 79/90
Since: 07-10-12
Posted by Dirbaio
Posted by Gericom
Cool! Nice found. So this is data that is only needed on an actual cartridge and not on the is-nitro-emulator appearently. Is it known what the exact purpose of that data is?


From what I understand, the DS encryption generates some data tables from the gamecode, then uses them to encrypt/decrypt commands. This data is what's in the rom at 0x1600 and 0x1c00.

You can see the details at gbatek key1 encryption details. This data is called "keybuf" there.

I can think of 2 reasons they did it this way.

1: efficiency. This way the card doesn't need to calculate the table, and doesn't need temporal ram to store it. Why require extra ram if the data never changes, and you have plenty of rom storage already?

2: more security: By doing it this way, deva never needed to encrypt/decrypt anything in their machines, so Nintendo's tools didn't need to have code for that, protecting it from getting reverse engineered.

Nintendo would assign the gamecode to the game, then give the deva the encryption data for that gamecode and the first 0x800 bytes of the secure area, already encrypted for the gamecode too (what they call the "syscall library").

Also interesting is that doing it this way didn't give devs info useful to pirate/dump other games than their own.

Hmm, yes, quite smart indeed. How was it possible to reverse the algorithm? Was it in the bios? If so, that wasn't very smart of them.
Posted on 05-12-18, 12:39 pm
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9979
Posts: 4422/4456
Since: 06-08-11
Yeah, the arm7 bios has the algorithm and the key data, this is how the DS was originally cracked.
Posted on 05-12-18, 05:39 pm (rev. 1 by  bbomb64 on 05-12-18, 05:39 pm)
Shyguy
bbomb64

Karma: 170
Posts: 50/85
Since: 12-17-17
Posted by Dirbaio
Slot adapter board. FPGAs and some RAM?


Do you know exactly how much on-board RAM is there? It would be interesting to know how much they had.

Since it's RAM, this means if their game is in memory, and say a power surge were to happen, all memory would be lost, correct?,
Posted on 05-13-18, 12:35 am (rev. 1 by Myria on 05-13-18, 12:43 am)


Karma: 26
Posts: 1/1
Since: 05-13-18
Posted by Dirbaio
Posted by Gericom
Cool! Nice found. So this is data that is only needed on an actual cartridge and not on the is-nitro-emulator appearently. Is it known what the exact purpose of that data is?


From what I understand, the DS encryption generates some data tables from the gamecode, then uses them to encrypt/decrypt commands. This data is what's in the rom at 0x1600 and 0x1c00.


It looks like you've discovered all this too =)

An implication of this discovery is that it implies that almost all DS cartridge dumps are bad. The rare exceptions are Contra 4 prototype (as you discovered) and Virtual Console titles. Retail carts have the game-specific Blowfish tables at 1600-1647 and 1C00-2BFF, but there is no known way to dump them. Attempting to read this area on cartridges will just return mirrors of other parts of the ROM. Both retail and dev DS carts have this behavior.

We can't simply regenerate the data. While 1600-1647 and 1C00-2BFF are algorithmically generated, 1000-15FF, 1648-1BFF and 2C00-2FFF appear random with no known source. If you corrupt these seemingly unused areas of a cartridge and flash it to a dev cartridge, the dev cartridge still works. The random garbage might be chaff to make it less likely that hackers found it. But the annoying part is that it means we can't simply generate this data and attach it to existing dumps.

However, a ray of hope exists: if you flash a cartridge with corrupted unused data, it will work fine, but if you then ask the IS-NITRO-EMULATOR (etc.) to verify the dump, it will say that the flash is bad. Try again with the hacked image and it will say that it's correct. In other words, something is able to read the security data.

This is not visible in the USB communication with the IS devices. Whatever is happening has to be on the device's side. I don't have the electronics know-how to set up a logic analyzer on the cartridge protocol bus to see what's involved with verifying.

It's quite possible that only dev cartridges respond to whatever the IS devices are sending. But this is a ray of hope for correct dumps.

One more thing I should mention: DSi-enhanced games have a second security data block, before the second secure area. The data that the IS dev software burns to DSi flash carts for NTRJ does not have the Blowfish tables - something on the cartridge or IS device must be munging it. The actual format is the same, relative to the beginning of that area: Blowfish tables at +0600-+0647 and +0C00-+1BFF and byte pattern at +2000-+2FFF. The Blowfish tables are generated slightly differently, but GodMode9 has the correct algorithm.
Posted on 05-13-18, 09:37 am
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9979
Posts: 4423/4456
Since: 06-08-11
Posted by Myria
We can't simply regenerate the data. While 1600-1647 and 1C00-2BFF are algorithmically generated, 1000-15FF, 1648-1BFF and 2C00-2FFF appear random with no known source. If you corrupt these seemingly unused areas of a cartridge and flash it to a dev cartridge, the dev cartridge still works. The random garbage might be chaff to make it less likely that hackers found it. But the annoying part is that it means we can't simply generate this data and attach it to existing dumps.

Is it that important if that data is entirely 100% useless though?

Posted by Myria
However, a ray of hope exists: if you flash a cartridge with corrupted unused data, it will work fine, but if you then ask the IS-NITRO-EMULATOR (etc.) to verify the dump, it will say that the flash is bad. Try again with the hacked image and it will say that it's correct. In other words, something is able to read the security data.

This is not visible in the USB communication with the IS devices. Whatever is happening has to be on the device's side. I don't have the electronics know-how to set up a logic analyzer on the cartridge protocol bus to see what's involved with verifying.

Very interesting. Maybe Gericom's REing of the nitroemu firmware can shed some light in this too? I'd be very very interesting to see how the dev card protocol works, for flashing, erasing and verifying. Maybe it's possible to program them from regular DS's if it's just special commands (as opposed to special voltages or weird stuff?)

Posted by Myria
It's quite possible that only dev cartridges respond to whatever the IS devices are sending. But this is a ray of hope for correct dumps.

This is what I fear too, yup. It's very likely, otherwise it'd probably mean you can use that to break encryption...
Posted on 05-13-18, 10:43 am (rev. 2 by  Gericom on 05-13-18, 02:17 pm)
Shyguy


Karma: 160
Posts: 80/90
Since: 07-10-12
Posted by Dirbaio
Posted by Myria
We can't simply regenerate the data. While 1600-1647 and 1C00-2BFF are algorithmically generated, 1000-15FF, 1648-1BFF and 2C00-2FFF appear random with no known source. If you corrupt these seemingly unused areas of a cartridge and flash it to a dev cartridge, the dev cartridge still works. The random garbage might be chaff to make it less likely that hackers found it. But the annoying part is that it means we can't simply generate this data and attach it to existing dumps.

Is it that important if that data is entirely 100% useless though?

Posted by Myria
However, a ray of hope exists: if you flash a cartridge with corrupted unused data, it will work fine, but if you then ask the IS-NITRO-EMULATOR (etc.) to verify the dump, it will say that the flash is bad. Try again with the hacked image and it will say that it's correct. In other words, something is able to read the security data.

This is not visible in the USB communication with the IS devices. Whatever is happening has to be on the device's side. I don't have the electronics know-how to set up a logic analyzer on the cartridge protocol bus to see what's involved with verifying.

Very interesting. Maybe Gericom's REing of the nitroemu firmware can shed some light in this too? I'd be very very interesting to see how the dev card protocol works, for flashing, erasing and verifying. Maybe it's possible to program them from regular DS's if it's just special commands (as opposed to special voltages or weird stuff?)

Posted by Myria
It's quite possible that only dev cartridges respond to whatever the IS devices are sending. But this is a ray of hope for correct dumps.

This is what I fear too, yup. It's very likely, otherwise it'd probably mean you can use that to break encryption...

My guess is that dev cartridges allow to read the whole rom with the 00 command or something. Verifying the rom probably takes place in the fpga, for speed reasons. I have not really researched anything related to flashcards (since I didn't have one myself ofc so I didn't know which commands would be used), but I'll try to send the idb as soon as I can access my pc.

My guess is that writing the cartridges is just through special commands and thus should be doable from a normal ds.

Edit:
Here's the ida pro database of the nec firmware: https://nsmbhd.net/file/qxzBFyTNaKstfbh9/IsNitroEmulatorNecFirm.idb
Document about the fpga registers accessible from the nec chip: https://nsmbhd.net/file/lByV6On9gWarg7Ch/registers.pdf
Ida pro database of the nec firmware of the is-nitro-capture: https://nsmbhd.net/file/P2tc32K3dtYhHgJB/capture_firmware_dec.idb
Pages: « 123456 »