Gathering DS flashcard knowledge - DIY "opencard" idea

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
237
Country
Belgium
Okay, the selection of analysis hardware is still open but it will simply depend on what't the easiest to learn and what fits for the job the best. If a logic analyser is simply cheaper for multi channel communication than I will get a logic analyser.

Now, if I can skip the logic through signal analysing that would be even better. It's just that so far, I have not found any documentation on e.g. how a cartridge (or flashcard for that matter) can understand (e.g. "decode") the signals sent to it. The I/O maps don't indicate how the 8 data pins communicate, and the 8 data pins protocol aren't as straight forward as e.g. a pin named "RST" :P.

I'm really just looking for a way to interact with the commands sent to the cartridge and reply to them from within an emulated cartridge (RP pico, FPGA). The analysing looked like a logical step to me but if I can get there another way (documentation, some libraries) that would be excellent too!
Post automatically merged:

Next up:

I chewed through enough learncpp that I want to try and make a barebones homebrew application.

I have found some of my old nds homebrew projects (just some simple write to hello.txt and some other stuff). I've updated my devkitPro install and confirmed it working (can compile e.g. their hello world and run on my DSi and DS).

Now: the card (EEPROM.nds) example is what interests me the most currently.

First hurdle: it does not work on a DSi, apparently. I remember reading somewhere that ejecting a cartridge on the DSi had some side effects not present on a DS, but I'm unsure if I remember correctly and I'm also not sure if there's a workaround for this.

So basically what happens in my DS:

1) I run the homebrew off my flashcard, it asks me to eject the card and insert another card to read EEPROP info from.

2) I eject my flashcard and insert a retail card

3) info (game title, eeprom size) is reported correctly by the homebrew.

On my DSi on the other hand:

1) I run the homebrew off my flashcard, it asks me to eject the card and insert another card to read EEPROM info from.

2) I eject my flashcard and insert a retail card

3) info is displayed incorrectly, all values seem to be null and the game title is not reported.

A discussion on the DevkitPro forum about this very issue was started but doesn't seem to ever have come to a conclusion: here.

Can anyone explain to me why this is the case? I'm sure I've come across an explanation related to this already but I can't remember where or when...

I'd really like to know why this doesn't work on a DSi, and if there are any workarounds to make this work (or if that is for a technical reason impossible - e.g. a non-changeable bit that's set once the card is ejected or something - I think it had something to do with that but I just don't remember).

Anyways any explanation please, I'm really interested!
Post automatically merged:

I've found it - GBATEK does cover it! (It was just hidden very well in my annotations):

Screenshot_20230131-220550-308~2.png


There seems to be a solution to this: the DSi provides a software-controlled method to cut and return power to the cartridge resulting in the same behavior as an eject but without disabling the card slot. I'm only unsure if this feature was ever worked into DevkitARM's codebase.

I'll look for it - and report back if I find if DevkitPro has a command to manipulate this reset behavior documented in GBATEK. If any of you know what I'm looking for, please share :) !
 
Last edited by xbmbmx,

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
237
Country
Belgium
Hello everyone,

Very short update again: I have not really progressed on any part since my last post as I recently changed my OS from Windows to Linux (debian specifically). I am now looking to migrate to yet another distro (Manjaro) as the Debian repositories are somewhat outdated (latest stable is pretty old) and devices like my Nvidia card are not playing nice with the older software versions.

I have been trying to get eeprom working on my DSi but I haven't gotten it right yet - I'm fairly sure it's just an order of commands thing that I am messing up and I'll just keep trying untill I get it right.

Next up: I'm looking for a logic analyser and I'd like to ask here for recommendations/things to consider when looking for one.

Apparently the Pi Pico can be used as a logic analyser as well but I've read mixed things about it online and I'm not confident it even samples fast enough to be usefull for the Cartridge analysis at all.

So - any input or information on the topic of logic analysers is welcome! I'm a noob on the topic - I have used one in an exam one time to explain why line X is hi and line Y is lo in a hardware assignment a while back. Reading a hi/lo line is not comparable to what I'm trying to get done here though.
 
  • Like
Reactions: Blythe93

master801

Well-Known Member
Member
Joined
Feb 24, 2011
Messages
1,184
Trophies
1
XP
2,551
Country
United States
Hello everyone,

Very short update again: I have not really progressed on any part since my last post as I recently changed my OS from Windows to Linux (debian specifically). I am now looking to migrate to yet another distro (Manjaro) as the Debian repositories are somewhat outdated (latest stable is pretty old) and devices like my Nvidia card are not playing nice with the older software versions.

I have been trying to get eeprom working on my DSi but I haven't gotten it right yet - I'm fairly sure it's just an order of commands thing that I am messing up and I'll just keep trying untill I get it right.

Next up: I'm looking for a logic analyser and I'd like to ask here for recommendations/things to consider when looking for one.

Apparently the Pi Pico can be used as a logic analyser as well but I've read mixed things about it online and I'm not confident it even samples fast enough to be usefull for the Cartridge analysis at all.

So - any input or information on the topic of logic analysers is welcome! I'm a noob on the topic - I have used one in an exam one time to explain why line X is hi and line Y is lo in a hardware assignment a while back. Reading a hi/lo line is not comparable to what I'm trying to get done here though.
For something cheap, I'd recommend getting a DSLogic Plus ($110) since it does 100MHz (or 20MHz) using all 16 channels (inputs) which is more than enough for the DS, considering the bus probably doesn't run any more than the ARM9's 67MHz.
https://www.dreamsourcelab.com/product/dslogic-series/

imo it's not really worthwhile getting the cheap $15 24MHz logic analyzers (although there is a place for them) or the super-expensive DSLogic U3Pro16 ($370!!!) considering better options (they "may" cost more) exist.
 

Ryccardo

Penguin accelerator
Member
Joined
Feb 13, 2015
Messages
7,696
Trophies
1
Age
28
Location
Imola
XP
6,926
Country
Italy
a non-changeable bit that's set once the card is ejected
Pretty much, and the command to turn it back on is privileged (ie needs to be sent from the DSi Menu or equivalent like a suitable homebrew opened from Unlaunch or installed title with the right permissions, it's kinda like AHBPROT on the Wii)

Or you can short together the mechanical card inserted switch (aka the fucker that broke on my Nikon D7000) :D

It's been no secret that DSTT was created by remaining members of the SuperCard team.
Isn't the ordinary TTDS (= popular 2008 SDHC card, stock kernel with the windows xp icons and extinfo/savlib/etc, the clone bricker update) a clone of the white DSTT by Neoflash?
 
Last edited by Ryccardo,

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
237
Country
Belgium
For something cheap, I'd recommend getting a DSLogic Plus ($110) since it does 100MHz (or 20MHz) using all 16 channels (inputs) which is more than enough for the DS, considering the bus probably doesn't run any more than the ARM9's 67MHz.
https://www.dreamsourcelab.com/product/dslogic-series/

imo it's not really worthwhile getting the cheap $15 24MHz logic analyzers (although there is a place for them) or the super-expensive DSLogic U3Pro16 ($370!!!) considering better options (they "may" cost more) exist.

I am back from quite a long pause and am taking this project back on. Thank you for your advice, I will look into this. Still haven't got my hands on a proper logic analyzer so this might be the one I go with. As always I will update this thread when I find something interesting enough to share.
 

Sono

cripple piss
Developer
Joined
Oct 16, 2015
Messages
2,834
Trophies
2
Location
home
XP
9,476
Country
Hungary
What about making your flashcart compatible with the DSi up to the 3DS? They have additional signature checks.

DSi is just DS, but afaik some extra data in the secure area, and the header format is a bit different + signed, but other than that very little modification is needed to make a DS flashcart DSi-compatible, and even better it will be backwards-compatible with DS games as well.

3DS on the other hand... oh boy...
3DS cartridges have an undumpable area, which contains secret keys. I don't think they are needed for a repro cart, but certainly needed on real ASICs.
Anyway, for 3DS carts, you need to steal a lot of insider info from Nintendo, which some people have, but it's not well known still. I should perhaps add it to my queue to decrypt the encrypted commands on 3dbrew.
 

Valery0p

Well-Known Member
Member
Joined
Jan 16, 2017
Messages
560
Trophies
0
XP
1,646
Country
Italy
DSi is just DS, but afaik some extra data in the secure area, and the header format is a bit different + signed, but other than that very little modification is needed to make a DS flashcart DSi-compatible, and even better it will be backwards-compatible with DS games as well.
On the other hand I think there was only one flashcard that ever supported the DSi/TWL mode, and it required roms in an encrypted format, so maybe there were some challenges...
 

Ryccardo

Penguin accelerator
Member
Joined
Feb 13, 2015
Messages
7,696
Trophies
1
Age
28
Location
Imola
XP
6,926
Country
Italy
On the other hand I think there was only one flashcard that ever supported the DSi/TWL mode, and it required roms in an encrypted format, so maybe there were some challenges...
While the iEvolution had plenty of problems (having to build your own firmware, team disappeared with no updates, clunky DS/DSi mode switching and you'd better have both consoles) - I don't think the most significant one could have been addressed in the first place: DSi headers are used for setting permissions at the hardware level and no (0) retail titles have all of them enabled...
 
  • Like
Reactions: Valery0p

Valery0p

Well-Known Member
Member
Joined
Jan 16, 2017
Messages
560
Trophies
0
XP
1,646
Country
Italy
While the iEvolution had plenty of problems (having to build your own firmware, team disappeared with no updates, clunky DS/DSi mode switching and you'd better have both consoles) - I don't think the most significant one could have been addressed in the first place: DSi headers are used for setting permissions at the hardware level and no (0) retail titles have all of them enabled...
Yup, I'm well aware, and even the DSi menu had some permissions but not others; I think it was only solved with the release of the Unlaunch boot exploit. (If we exclude RocketLauncher... that could actually be useful for flashcards, but I don't think @Apache Thunder ever released it)

edit: I was wrong lol, if anyone's interested: https://github.com/ApacheThunder/RocketLauncher
 
Last edited by Valery0p,

Apache Thunder

I have cameras in your head!
Member
Joined
Oct 7, 2007
Messages
4,478
Trophies
3
Age
36
Location
Levelland, Texas
Website
www.mariopc.co.nr
XP
6,931
Country
United States
Yup, I'm well aware, and even the DSi menu had some permissions but not others; I think it was only solved with the release of the Unlaunch boot exploit. (If we exclude RocketLauncher... that could actually be useful for flashcards, but I don't think @Apache Thunder ever released it)

edit: I was wrong lol, if anyone's interested: https://github.com/ApacheThunder/RocketLauncher
Yeah RocketLauncher needed a tool for safely installing it to nand and unfortunately at the time the folks who helped make the RocketLauncher payloads were too busy to sort that out. Then a wild nocash appeared and released something better (aka Unlauncher). While I couldn't program the payload itself, I handled the process for aligning the payloads and such when creating the exploited DS cart whitelist SRL and the DS flashcart image which was the only thing I handled my self when they were helping create the payloads.


Now that I think about it, Unlaunch + HiyaCFW would be a nice safe way to test RocketLauncher stuff since it should be testable via SD card redirect that HiyaCFW uses. That's if anyone was ever interested in messing with it in this day and age. :P

One optimization RocketLauncher could have had was exploiting arm9 instead of arm7. Getting to the exception handler IRQ address via the memory overflow took like 10 seconds because almost 7mb+ of data needed to overflow into it. I think arm9 memory is reached much sooner but due to cache issues and such it would be tricky to get that working. Arm7 just ended up being easier to do since it doesn't have cache feature that Arm9 had. Now that I think about it RocketLauncher would have been one of the few exploits that exploited arm7 first. Most other exploits exploided arm9 and used tricks to take over arm7. At least from what I vaguely recall. Though maybe Unlaunch is pwning arm7 first like RocketLauncher does but I forget the details on how Unlaunch works.

EDIT: and yeah I eventually did release the code behind RocketLauncher once Unlaunch made it obsolete. :P
 
Last edited by Apache Thunder,

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
237
Country
Belgium
Hello everyone!

I have made some visualizations for myself and am also sharing them here so people can review them (I probably made one or more mistakes copying the information over from GBATek, so a second pair of eyes can't hurt):

First Image: Sequence Diagram of command interaction between console and cartridge. Expressed in simple words, detailed descriptions for each message type can be found in the GBATek document that I based this on (here).

[EDIT: note: first line of each "message" represents the encryption application for that message, RAW means plain, KEY1 means encrypted with KEY1, KEY2 means encrypted with KEY2 method, may be unclear reading the diagram for the first time.)

diag.jpg



Second image: bytefield diagram of the header for a Nintendo DS cartridge. Zeroed (reserved) datafields are indicated in gray. Each column (tiny column numbers are at the top) represents 1 byte. The last (huge) zeroed data block is not completed (hence no bottom line) because it is usually not transferred anyways according to GBATek.
View attachment mem-diag.jpg

If anyone spots a mistake in these diagrams, let me know! I'm currently back on writing a homebrew application that I can use to get a feel for the cartridge to console interaction. I'm also looking to make a DS cartridge breakout board PCB that sticks more out of the DS than a usual cartridge so I can fit female headers onto it, to use it for various types of testing (hope I don't short my DS lmao).
 

DobaMuffin

Active Member
Newcomer
Joined
Mar 2, 2018
Messages
26
Trophies
1
XP
421
Country
Canada
Hello everyone!

I have made some visualizations for myself and am also sharing them here so people can review them (I probably made one or more mistakes copying the information over from GBATek, so a second pair of eyes can't hurt):

First Image: Sequence Diagram of command interaction between console and cartridge. Expressed in simple words, detailed descriptions for each message type can be found in the GBATek document that I based this on (here).

[EDIT: note: first line of each "message" represents the encryption application for that message, RAW means plain, KEY1 means encrypted with KEY1, KEY2 means encrypted with KEY2 method, may be unclear reading the diagram for the first time.)

View attachment 393273


Second image: bytefield diagram of the header for a Nintendo DS cartridge. Zeroed (reserved) datafields are indicated in gray. Each column (tiny column numbers are at the top) represents 1 byte. The last (huge) zeroed data block is not completed (hence no bottom line) because it is usually not transferred anyways according to GBATek.
View attachment 393275

If anyone spots a mistake in these diagrams, let me know! I'm currently back on writing a homebrew application that I can use to get a feel for the cartridge to console interaction. I'm also looking to make a DS cartridge breakout board PCB that sticks more out of the DS than a usual cartridge so I can fit female headers onto it, to use it for various types of testing (hope I don't short my DS lmao).

In all honesty, I recommend trying to make a cartridge dumper using something like the pi pico and a ds cartridge slot. Would help you fully understand the decryption protocols used by the console while also allowing you to test the encryption on a future flash cartridge without needing to boot up a ds every time. It's something I once tried, and want to go back too. I have all the parts on hand to accomplish it, just not enough free time.
 
  • Like
Reactions: xbmbmx

SylverReZ

I am funny
Member
GBAtemp Patron
Joined
Sep 13, 2022
Messages
7,513
Trophies
3
Location
The Wired
Website
m4x1mumrez87.neocities.org
XP
21,335
Country
United Kingdom
In all honesty, I recommend trying to make a cartridge dumper using something like the pi pico and a ds cartridge slot. Would help you fully understand the decryption protocols used by the console while also allowing you to test the encryption on a future flash cartridge without needing to boot up a ds every time. It's something I once tried, and want to go back too. I have all the parts on hand to accomplish it, just not enough free time.
I remember the days of Gateway where dumping carts would come with brick risks (especially if you were using Omega) :D
 

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
237
Country
Belgium
In all honesty, I recommend trying to make a cartridge dumper using something like the pi pico and a ds cartridge slot. Would help you fully understand the decryption protocols used by the console while also allowing you to test the encryption on a future flash cartridge without needing to boot up a ds every time. It's something I once tried, and want to go back too. I have all the parts on hand to accomplish it, just not enough free time.

I'm currently trying to do that too, but I don't have a spare slot (yet).

Also in contact with someone who is guiding me through this a bit (they have quite a bit more knowledge on it all than me). If I make significant progress I'll share it here as always!

I'm also learning how I can design my female-header breakout board and any future layout for a PCB for when I get to actually designing one (will be far future though). Have been playing around with Verilog too but the Chinese Actel ProAsic devboard I have only has documentation in Chinese and the customer support is as useful as talking to a wall so it takes a while to figure pins out and such.
 

DobaMuffin

Active Member
Newcomer
Joined
Mar 2, 2018
Messages
26
Trophies
1
XP
421
Country
Canada
I'm currently trying to do that too, but I don't have a spare slot (yet).

Also in contact with someone who is guiding me through this a bit (they have quite a bit more knowledge on it all than me). If I make significant progress I'll share it here as always!

I'm also learning how I can design my female-header breakout board and any future layout for a PCB for when I get to actually designing one (will be far future though). Have been playing around with Verilog too but the Chinese Actel ProAsic devboard I have only has documentation in Chinese and the customer support is as useful as talking to a wall so it takes a while to figure pins out and such.
ProAsic is fairly old these days no? I would be much more inclined to try out a different form of control. I wonder how much we could abuse the pi pico. PIO should make interfacing with the ds easier, and the dual core arm processor should help with computation while also ensuring the proper response times are met.
 
  • Like
Reactions: SylverReZ

xbmbmx

Well-Known Member
OP
Newcomer
Joined
Feb 18, 2019
Messages
59
Trophies
0
XP
237
Country
Belgium
Definitely true but as most flashcards use the ProAsic3 it is definitely up for the task. That's why I bought it all that time back. Microcontrollers are still in my notes and as they're generally way cheaper I could buy one or more later to test around with.

Anyways, microcontrollers (Especially the RP2040, which powers the Pi Zero) have already been discussed here and are definitely an option. A downside of the RP2040 as a standalone (on e.g. the PCB of a future flashcard) is that it's startup time is apparently too long. Sono (member who has replied to this thread and who I have chatted with too) explained some of this here and to me privately.

Another person I'm chatting with is currently trying to use an STM32H750VBT to create a self-made cart for a homebrew. An attempt was already made with a lower-clock microprocessor but it was too slow. This one should (in theory) be overkill and leave enough space to make this possible. They do not intend (currently) to use an SD card in their design. I do intend to do this, so my eventual implementation will differ, but their work is viable and valuable nonetheless.

I have ordered a replacement SLOT1, I have a few pico's and a RPi 4 and an Arduino Uno too so I can, once I receive the SLOT1, get going with the self-written card dumper etc. I am also close to KiCad-ing the breakout board with female headers.
 

SylverReZ

I am funny
Member
GBAtemp Patron
Joined
Sep 13, 2022
Messages
7,513
Trophies
3
Location
The Wired
Website
m4x1mumrez87.neocities.org
XP
21,335
Country
United Kingdom
ProAsic is fairly old these days no? I would be much more inclined to try out a different form of control. I wonder how much we could abuse the pi pico. PIO should make interfacing with the ds easier, and the dual core arm processor should help with computation while also ensuring the proper response times are met.
https://github.com/SonoSooS/pico-ntrbootleg
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    K3Nv2 @ K3Nv2: I'd love to live in Germany fuckin five star prisons sign me up +1