Stargate 3DS - PCB and firmware

[moon_rabbit]

Will you make it run the later AP games?

Converting ROM to card2 will make it work.

Post automatically merged: Nov 22, 2024

what happens though?

if you're able to reproduce the problem, can you test if converting to card2 bypasses the problem and lets it work correctly?

what about resetting the save data to factory default with save data filer or something?

Failed to read the save.
It turns out that UP flash is the save itself, so card2 should not be affected.
I think the cause might be a poorly soldered UP flash.

 

[ovns_ub3]

Sorry to jump in the conversation but you seem the only person to understand this cart. Now I have a problem related that most of the times when I want to play a Rom of 3ds I get the error of the cart ejected. This is happening basically most of the times. I tried already everything possible I formatted the sd again changed the roms but I get the same result. Thank you if you can give my some sort of advice to how fix it

 

[moon_rabbit]

Sorry to jump in the conversation but you seem the only person to understand this cart. Now I have a problem related that most of the times when I want to play a Rom of 3ds I get the error of the cart ejected. This is happening basically most of the times. I tried already everything possible I formatted the sd again changed the roms but I get the same result. Thank you if you can give my some sort of advice to how fix it

Is it ejected every time?
I've never seen this before, so I don't have a solution, but here are some suggestions

1. Check the condition of the cartridge pins and the pins on your 3DS.
2. Try using a different SD card.
3. Try another 3DS, 2DS if you have one, test it with that.
4. If everything is ok, you should try reflow or reball the solder on the cartridge.

If it doesn't happen every time, I would expect it to be a cold solder joint issue.

 

[amomo]

Hi,

Looking at the Atmel SAM D11 datasheets, this device has SWD (Serial Wire Debug, a JTAG-like interface) on PA30 (SWDCLK) and PA31 (SWDIO).

Considering the QFN form factor and the markings on the chip, this looks similar to the SAM D11D. Orient the circle marker north east, and on the top would be, from left to right: VDD, GND, PA25, PA24, PA31/SWDIO and PA30/SWDCLK. There must be test points on the board to access those, and I'd expect them to be near the chip (you should be able to check them with a multimeter).

I don't believe there's a way to disable SWD on those chips, but I could certainly be wrong, as I can't find a matching datasheet for the D11U. SWD would let you dump/debug the firmware and more. You can make yourself a OpenOCD-compatible USB device that can connect to SWD using a RP2040/RPi Pico using Raspberry Pi's debugprobe firmware, or using a Flipper Zero.

I'm not sure about the FPGA/SoC itself. They can be programmed over SPI and it might be what's being done here; I don't know if we can dump the bitstream and/or the built-in Cortex-M3's firmware. It should have JTAG, but that might not be exposed and might be disabled. I'm guessing the built-in Cortex-M3 is used to do the actual flashcart logic and accessing the microSD (and that feature is probably using the FPGA). I'm somewhat surprised they're not using the built-in USB OTG feature and instead most likely using another chip.

I'm still waiting on mine to arrive to try out stuff, but I'd be able to look at the firmware if any of this works. Thank you for your work on dumping the SPI chips so far

 

[SylverReZ]

I'm not sure about the FPGA/SoC itself. They can be programmed over SPI and it might be what's being done here; I don't know if we can dump the bitstream and/or the built-in Cortex-M3's firmware. It should have JTAG, but that might not be exposed and might be disabled. I'm guessing the built-in Cortex-M3 is used to do the actual flashcart logic and accessing the microSD (and that feature is probably using the FPGA). I'm somewhat surprised they're not using the built-in USB OTG feature and instead most likely using another chip.

It's very possible that it's encrypted as an anti-counterfeiting measure, just like when Gateway did everything they can to brick systems that used clone carts. You would have to use something like a logic analyzer to dump the bitstream and/or firmware.

 

[amomo]

It's very possible that it's encrypted as an anti-counterfeiting measure, just like when Gateway did everything they can to brick systems that used clone carts. You would have to use something like a logic analyzer to dump the bitstream and/or firmware.

The bitstream is most definitely encrypted as the FPGA/SoC supports it, but I don't know how the Cortex-M3 firmware is protected. I'm also not sure why they're using the SAM D11 as the USB device chip, because the FPGA/SoC can do USB too... Its presence is quite odd to me. The JTAG on the FPGA/SoC is also most likely disabled by fuse. The bitstream has to be on the internal flash, which I believe is not encrypted at rest.
It's possible that the SAM D11 provides other functionality than firmware updates, which is why it could be interesting to look at it.

The GW Red card uses a ProASIC 3, which has been broken before; and it's apparently possible to recover the bitstream encryption keys with a hardware attack.

I don't believe the SmartFusion 2 firmware can be extracted as you say (or it will be encrypted), but I do wonder if it could be overriden with custom firmware, though that's probably unlikely.

EDIT: I had to rewrite and shorten this message a lot because GBAtemp would not let me post it for "banned keywords", even though there were no links and only technical terms...

 

[moon_rabbit]

The bitstream is most definitely encrypted as the FPGA/SoC supports it, but I don't know how the Cortex-M3 firmware is protected. I'm also not sure why they're using the SAM D11 as the USB device chip, because the FPGA/SoC can do USB too... Its presence is quite odd to me. The JTAG on the FPGA/SoC is also most likely disabled by fuse. The bitstream has to be on the internal flash, which I believe is not encrypted at rest.
It's possible that the SAM D11 provides other functionality than firmware updates, which is why it could be interesting to look at it.

The GW Red card uses a ProASIC 3, which has been broken before; and it's apparently possible to recover the bitstream encryption keys with a hardware attack.

I don't believe the SmartFusion 2 firmware can be extracted as you say (or it will be encrypted), but I do wonder if it could be overriden with custom firmware, though that's probably unlikely.

EDIT: I had to rewrite and shorten this message a lot because GBAtemp would not let me post it for "banned keywords", even though there were no links and only technical terms...

I don't expect the SAM D11 ARM chip to have anything but USB SERIAL related functionality.
USB micro pin, which is the same as the pin location found in the sam d11 manual.
And I would expect it to be connected to the FPGA, but it's a BGA so I haven't checked.
I can't really explain why they use a SAM D11 instead of an FPGA, other than lack of internal capacity.


I thought about dumping the firmware inside the SAM D11 but gave up, maybe someone who has done some hacking with openocd or something can do it.

 

[ghjfdtg]

The likely reason why that SAM D11 chip is used is because implementing USB on the FPGA is a pain in the ass. It's certainly not a problem with capacity for the bitstream and internal Cortex-M3 firmware. Another reason could be to make it more brick proof. Or they were just lazy.

 

[amomo]

I took a look at the SPI flash contents (the one marked as "DOWN(fpga)"). I believe it reasonable to call it the "SPISYS" considering the header magic.

Here's what I found:

• The "SPISYS" structure defines where each data region is located in the SPI, and what size it is. This mean we could resize and move the structures as needed, if it is indeed read by the firmware.
• The "PMAP" structure defines a virtual address map for a cartridge's data. It is used for both NTRboot and the game data used to bypass anti-flashcart checks. This lets them save on space on the SPI and keep things flexible (more on this a bit later).
• The first section is the NTRboot production (as-in, for production consoles) FIRM. It seems to be a minor fork of boot9strap, and I'm not sure why they did this. The PMAP for this section is odd, as it contains two entries; the first one is fairly valid and maps the FIRM data at block 3Fh (address 7E00h) as expected by boot9, and the second one is the same entry; but goes out of bounds if my understanding of the PMAP structure is correct. I'm not sure why it's here, or if it's even used at all.
• The second section is the NTRboot production Blowfish context.
• The third section is the game PMAP. It doesn't contain the full game, and the sections are somewhat randomized in some ways (not sure why). The sections match a retail game's dump, except for two sections: C200h-C201h (addresses 1840000h-1840200h) and C201h-C20Ah (addresses 1840200h-1841400h). They seem to be the DS-mode flashcart bootloader (as in, what loads and starts up the flashcart menu). I'm not sure why they're located at those addresses, and I'm not yet sure how the flashcart determines when to start it.
• The fourth section is the game's Blowfish context.
• And now, the more interesting part. The fifth section seems to contain the SmartFusion 2 design data. I'm not sure what format that is yet, and it is likely encrypted.
• The sixth section contains a *cleartext* part of the Atmel SAM D11 firmware. Looking a bit at it, it's very incomplete/messy and requires the internal flash contents to be dumped so we can fully understand what it does. The SAM D11 chip seems to be responsible for 1 UART stream and 2 SPI streams. The UART stream is most certainly coming from the USB serial device, and seems to be used to flash *at least* the internal SPI; probably more. I'm not sure what the UART settings are, but there is some half of the code that seems to be related. It seems to be expecting some magic values DEADFACEh (maybe at address 0h?) and CAFEBABEh (maybe at at address FF0h?) in little-endian. I'm not too sure about what's going on without the internal Atmel SAM D11 flash contents.

I wrote a quick/dirty ImHex pattern file to reverse-engineer the SPI format, and might be useful if you want to edit your own/take a look:

#pragma endian little
import type.magic;

u32 pmap_addr = 0;
u32 pmap_curpos = 0;

fn format_sector(u32 value) {
    return std::format("#{:06X} ({:08X}h)", value, value * 0x200);
};

struct PMAP_Mapping {
    u32 block_vaddr [[format_read("format_sector")]];
    u32 block_count [[format_read("format_sector")]];
 
    u8 region[block_count * 0x200] @ (pmap_addr + pmap_curpos);
 
    pmap_curpos += 0x200 * block_count;
} [[format_read("format_mapping")]];

fn format_mapping(PMAP_Mapping mapping) {
    return std::format("{:08X}h-{:08X}h",
        0x200 * mapping.block_vaddr,
        0x200 * (mapping.block_vaddr + mapping.block_count));
};

struct PMAP {
    type::Magic<"PMAP"> magic;
    u32 count; // real count - 1?
    u32 b; // ?
    u32 c; // ?
 
    pmap_addr = addressof(this);
    pmap_curpos = 0x200;
 
    PMAP_Mapping mappings[count + 1];
};

struct SPISYS_Section {
    u32 offset; // not relative; absolute on the SPI flash
    u32 length;
 
    try {
        PMAP map @ offset;
        u8 data[length] @ offset [[highlight_hidden]];
    }
    catch {
        u8 data[length] @ offset;
    }
};

struct SPISYS {
  type::Magic<"SPISYS"> magic;
  padding[10];
  SPISYS_Section ntrboot_firm;
  SPISYS_Section ntrboot_blowfish;
  SPISYS_Section game;
  SPISYS_Section game_blowfish;
  SPISYS_Section unknown_bitstream;
  SPISYS_Section atmel_d11_firmware;
};

SPISYS spisys @ 0x1000;

Note that because the Atmel SAM D11 firmware is cleartext and contains the lower-half of the internal flash + the exception vectors, it is likely possible to take control of it without knowing what it contains by flashing the SPI. It should then be possible to dump the contents to the UART via USB; though I still do believe SWD would be easier, faster and less risky.

Post automatically merged: Dec 27, 2024

I've also received my Stargate 3DS flashcart and made a few interesting observations.

First of all, I was interested in the reports that some games didn't work. People seemed to say it was for games over 4GB, but I haven't had any issues there (in the very incomplete testing I've done for those). The flashcart supports exFAT, even in NDS mode, which is pretty nice. However... there does seem to be a correlation between 4GB games and what I call "anti-piracy stage 2" games. What I call "AP stage 2" games have ID2[0] = 2h (e.g. "Persona Q2", "Pokémon Ultra Moon"). Those games apparently work on Sky3DS+, but I don't have one to check (they're difficult to find now and somewhat expensive otherwise). It does support "AP stage 1" games, which are games that have ID2[0] = 1h (e.g. "Mario & Luigi: Paper Jam Bros"). Those games don't work on the Sky3DS non-Plus, from what I'm seeing online. Older games have ID2[0] = 0h (e.g. "The Legend of Zelda: Ocarina of Time 3D").

The reason for that is fairly simple (and disappointing). ID2[0] is used to determine which cartridge protocol encryption keys to use.[^devunits] Here's the kicker: the Stargate 3DS only supports keys 0h and 1h. When a game has ID2[0] = 2h, the Stargate 3DS defaults to key 0h, meaning the 3DS and the cartridge can't communicate as the keys don't match, and they both see garbage. I'm also not sure exactly how the Stargate 3DS determines which ID2 to send, as it doesn't use the "Gateway private header" value for this.[^id1][^godmode9]

[devunits]: For dev units, that value is forced to be 3h, and to my knowledge, dev cartridges have ID2[0] = 3h as well. Production unit software does not allow that key to be used.
[id1]: When the ID1 value in the "Gateway private header" is FFFFFFFFh, the Stargate 3DS seems to deterministically generate an ID1 to reply with instead. I'm not sure how it calculates them, but they differ from file to file.
[godmode9]: Note that the "private header" dumps in GodMode9 are incomplete. GodMode9 does not dump the ID2 (it seems someone had made a PR about this, see PR #862). Apparently, Gateway does dump it, but I haven't checked. This is probably why the Stargate 3DS firmware does not use the "private header" value.

---

Other tidbits and observations while toying around:

• GodMode9 NCSD verifications almost always fail, at the exact same spot. I haven't diagnosed why.
• If you try to read (with command BFh) at towards end of the cartridge or past the end, the Stargate 3DS crashes and stops responding.
• If you don't send NAND self-refresh commands (command C5h) frequently enough, the Stargate 3DS stops responding. This does not happen on real cartridges.
• If you send some DS-mode commands (such as 00h) while the Stargate 3DS is in 3DS mode, it switches to DS flashcart mode until it loses power.
• As per the OP, when you hold the outwardsmost button, the Stargate 3DS enables a "serial device mode" with a red LED. If you plug it in without holding any buttons (or by holding the inwardsmost button, which seems to be ignored here) and without a SD card, the Stargate 3DS waits for you to insert a SD card with a purple LED, and blinks to green when inserting a SD card. This is probably used for some updating mechanism?

 

[4d1xlaan]

yeah, we figured out a while ago that the problem was newer ap. but it's cool to know exactly why the newer ap fails

 

[FR0ZN]

Is it possible to modif, the SPI contents?
Do you guys see a chance to add support for the later AP games?

 

[SylverReZ]

Is it possible to modif, the SPI contents?
Do you guys see a chance to add support for the later AP games?

3DS games don't really have AP measures, but games like Pokemon Sun and Moon need to be converted to card-2 to work.

DS games on the other hand you can use the DS-Scene ROM Tool to manually patch them.

 

[FR0ZN]

3DS games don't really have AP measures, but games like Pokemon Sun and Moon need to be converted to card-2 to work.

DS games on the other hand you can use the DS-Scene ROM Tool to manually patch them.

Is there any issue like getting banned, when converting them to Card 2?

 

[SylverReZ]

Is there any issue like getting banned, when converting them to Card 2?

You can't get banned as Nintendo pulled the plug on 3DS online services. So you can use both legitimate and pirate ROMs without modification. Before that, you had to extract the certificates from your legitimate game before converting to card-2 to avoid possible ban risks.

 

[FR0ZN]

You can't get banned as Nintendo pulled the plug on 3DS online services. So you can use both legitimate and pirate ROMs without modification. Before that, you had to extract the certificates from your legitimate game before converting to card-2 to avoid possible ban risks.

Is this the converter?
https://gbatemp.net/threads/realease-card1-card2-converter.405915/

 

[SylverReZ]

Is this the converter?
https://gbatemp.net/threads/realease-card1-card2-converter.405915/

Yes, or you can use the one from EZ-Flash's website (here).

 

[SylverReZ]

I bought another one and it arrived today, but it has a save issue.

I am having the same problem saving and restoring my save state. I tried Super Mario 3D Land and it saved without issue. However, starting another game it tells me that 'the save file is corrupted' and it completely overwritten not just the save file for SM3DL but other save files on the SD card, making it impossible for me from restoring them back. That is, unless I back up the save files onto my PC after closing out, in which case afterwards, copying the backup saves back onto the card and resuming from where I left off.

I'm not sure whether it happens on the Stargate 3DS itself, or because I ordered the one from AliExpress, but this is a total bummer.

 

[amomo]

I am having the same problem saving and restoring my save state. I tried Super Mario 3D Land and it saved without issue. However, starting another game it tells me that 'the save file is corrupted' and it completely overwritten not just the save file for SM3DL but other save files on the SD card, making it impossible for me from restoring them back. That is, unless I back up the save files onto my PC after closing out, in which case afterwards, copying the backup saves back onto the card and resuming from where I left off.

I'm not sure whether it happens on the Stargate 3DS itself, or because I ordered the one from AliExpress, but this is a total bummer.

This is an issue on the Cortex-M3 firmware (which is part of the FPGA SoC). It seems to have a buggy filesystem driver; I've encountered issues using exFAT where the flashcart would create files that the Samsung exFAT Linux driver would mark as "unreadable" until running fsck.

I don't see a good way to fix this, and I'm not sure it would be possible to flash a custom bitstream and firmware; unless we're fairly lucky with the way the SoC was configured (e.g. we're able to use UEK2, or the UEK1 passcode is crackable).

---

I've also tested a few DS-mode commands (all commands with byte 0 from 00h to FFh). There doesn't seem to be any command that lets us write to the SPI, unless it's some unknown 8-byte magic command.
Otherwise, the DS-mode flashcart seems to be a R4-style clone. There are a few differences, though, and most commands seem to have another command to wait for the flashcart to be ready.

The commands which set the DS-mode game (B400h) and savedata mappings (B401h) take a 200h bytes UCS-2-encoded file path instead. This command should be followed by poking command B1h repeatedly until it returns 00000000h, which seems to indicate whether or not the flashcart is ready.

The DS-mode flashcart menu also lets you select a 3DS game to switch to. The menu contains production NCCH content keys to decrypt the icon and name data. For some reason, the DS-mode commands for that also allow setting which ID1 and ID2 to use, so I now know how the flashcart decides which ones to use:

• If the "private header" section of the 3DS file is FFFFFFFFh or 00000000h, it "generates" an ID1. It then checks if the cartridge should be a Cart2 (cartridge with a writable section) type by looking at 200h-204h. If it's a Cart1, the ID1 base is 900000C2h, and if it's a Cart2, the ID1 base is 980000AEh. ID1[1] (the part of ID1 which specifies the size of the cartridge) is set via a lookup table from how many sectors the cartridge's NCSD has.
• ID2 is always programmatically set, and the "private header" ID2 is ignored. Bits 1-2 of the byte at 1FEh of the NCSD are used to set ID2[0]'s bits 0-1; but only if that NCSD byte's bit 0 is set, otherwise it defaults to zero.

DS-mode command AF0000yyxxxxxxxxh, where yy = ID2[0] and xxxxxxxx = ID1, sets up the 3DS flashcart mode's target, along with a 200h bytes UCS-2-encoded file path of the 3DS file. Command ADh is then sent repeatedly until it returns 00000001h.

The switch to 3DS flashcart mode is done by sending command ACh, and sending command ADh repeatedly until it returns 00000001h.

 

[moon_rabbit]

I am having the same problem saving and restoring my save state. I tried Super Mario 3D Land and it saved without issue. However, starting another game it tells me that 'the save file is corrupted' and it completely overwritten not just the save file for SM3DL but other save files on the SD card, making it impossible for me from restoring them back. That is, unless I back up the save files onto my PC after closing out, in which case afterwards, copying the backup saves back onto the card and resuming from where I left off.

I'm not sure whether it happens on the Stargate 3DS itself, or because I ordered the one from AliExpress, but this is a total bummer.

In my testing, this only happens if there is a problem with the Stargate 3ds.
I did a swap test using the same SD card and only got the save error on the problematic cartridge.
My guess is that resoldering or reprogramming the SPI FLASH(labeled UP) could be the answer.