Hacking DEAD [Shutdown]DragonInjector - Game Cart Payload Injector (Trinket M0 Clone)

[tyler004]

Time for another update. Bad news. Skip to the second last paragraph if you want a TL;DR.

So, I thought I'd do some further testing on game card slot power behavior, so I soldered some more tiny wires to an unpopulated V2 PCB and wrote down the results. It's looking like I won't be able to grab power from the game card slot like I wanted to.

Previously, as I didn't have any kind of game card breakout adapter (since one didn't exist), I soldered tiny wires to an actual game cartridge and did my tests that way. You can find that post here: https://gbatemp.net/threads/dragoni...r-trinket-m0-clone.511780/page-2#post-8171816 but the long and short of it is, I was able to measure a constant 3.06v from the game card slot anytime the Switch wasn't sleeping. Generally, something like a game card slot will either have constant power or have some physical mechanism to enable power when a cartridge is inserted, and there was no real reason to assume the Switch would be any different. Unfortunately, it seems Ninty is doing things a little differently now.

Much like the USB Type C connector I was dealing with earlier, The Switch does not keep it's VCC terminal hot for the game card slot. As it turns out, there exists a 17th pin in the game card slot that I couldn't find documented anywhere. I've attached the best picture I could get to this post. This pin shares the same pad as the ground pin, but sits at negative 1.8v. When a game card is inserted into the Switch, "Pin 17" is shorted to ground and is effectively "pulled up", which lets the Switch know there's a game card inserted so it can start sending power. At this point, VCC becomes hot and 3.3v is sent to the cartridge.

Now, is where the trouble begins. Once the game card starts receiving power, the Switch expects it to start communicating. It sends a few commands and then listens for a response. In my tests, the Switch will send power for anywhere between 2 to 10 seconds, and once it decides a response isn't coming, it shuts down power to the game card slot and displays an "error reading cartridge" message on the screen. The Switch won't send power to the card slot again until "Pin 17" becomes floating once more, followed by getting "pulled up" to 0v (ground) again. In a perfect world, I'd do my best to emulate a cartridge using the ATSAMD21, but almost nothing about the proprietary data format is known, and that's not even considering that at some point shortly after the initial handshake, the data becomes encrypted with an unknown algorithm. It's also likely this approach would involve code copyrighted by Ninty, which is just asking for trouble.

As it stands, charging via the game card slot is not really viable. It is very possible a software solution to this could be made, since it's software that's controlling the power to the game card slot. To test this, I booted into the SX OS boot menu, and no matter what I did I could not get 3.3v from the card slot. Something in Horizon is reading "Pin 17" and deciding to send power when it shorts to ground. Unfortunately, I don't have the coding skills to even try to figure out how to implement a possible software fix.

In summary, card slot charging is probably a bust without a software fix I don't know how to make. I'm still going to continue with the project, as you can still charge the dongle via the Switch's USB port when not in RCM or via a computer, and it's still really convenient to have the dongle on you all the time along with the RCM jig and not have to worry about losing it. The downside is that now you have to boot the Switch normally every dozen or so times to charge the dongle, or charge it in something else. The V3 set of PCBs arriving tomorrow will work with no issues aside from the card slot pins serving only to make it look more like a real game cart. No other feature is affected by this - only the ability to charge the dongle via the game card slot, so I think it's still a worthwhile project. (Technically you still could charge it in the game card slot port, but you'd have to insert and remove it a couple of times and clear that annoying error, which is rather inconvenient - at that point you might as well just plug it in to the Type C port.)

I'd really like to hear what you all think, or if anyone might have a lead on a software solution. Normally, something like this would've been a brief bump in the road for me and then I'd keep moving on without thinking much on it, but this project has garnered a lot of attention now and it's hard to say exactly what people were most excited about. Is this a dealbreaker for most, or just a minor annoyance? A lot of people had requested the ability to disable charging from the card slot, so perhaps it was just a "nice to have" feature, or perhaps not.

Let me know!

Thanks everyone!

View attachment 140590

yea im still interested in trying the test batch, I like the form factor of it even if it won`t charge from the cart slot its fine with me thanks, for letting me know

 

[blaze5]

Right now none of the card slot data pins are broken out to the ATSAMD21, but if someone really wants to pursue this angle and has the skills to handle the software side of things, I can easily make them a dongle specifically tailored to reading and manipulating and reverse engineering the card slot pins easily. I could even build something you could add a real cartridge into that piggybacks the data lines to sniff out the raw data. Custom hardware is no problem, I just need a software genius partner.

The key to RE the cartridge system would be figuring out which steps are the same for every cartridge and then determine the cartridge specific components. It helps that you've already started looking into it.

I'd probably need to get a logic analyzer or oscilloscope, but I've got a cartridge of 1-2 Switch I wouldn't mind dumping and soldering on some wires to see how it works. I would assume an XCI dump would contain cartridge specific info (name, thumbnail, cert?, etc.) needed to emulate inserting a valid game. I don't know what backdoor through the cartridge pins would be available to flag CFW not to try booting the fake cart, but maybe with CFW (and the right keys) we could add in a game entry and thumbnail stored locally on the console. This would most likely involve crypto keys we don't have though and could be detected more easily making a donor cart the best option. I guess with CFW if you told it you were specifically using 1 donor cart, you could maybe set a flag to make that cart with that cert unbootable. Reverse engineering the cart system and setting up a donor cart seems viable but I'm not sure what's possible on the CFW side. It'd be nice to have some protection built-in to prevent accidentally starting the game since the game data wouldn't actually be present and the emulation would be barebones.

 

[KTroopA]

So, the only issue is, no charging via gamecard slot.. Not an issue for me. I love it because it is tiny and can de carried with out an issue. Im still down, just take it out, place it into the usb-c port a few seconds to charge before shutting down, then just boot into RCM and done. No issues there.

I concur

 

[MatinatorX]

Just did the math quickly, at the new safe current limit of 500mA for USB charging, by cutting out card slot charging (27.5mA max) the new charging times for the dongle are: 5 seconds for a full charge when brand new (0v to 3.2v), 4 seconds for a full charge from low power shutdown (1.7v to 3.2v) and half a second for 3 or 4 injections (1.7v to 2.2v).

--------------------- MERGED ---------------------------

The key to RE the cartridge system would be figuring out which steps are the same for every cartridge and then determine the cartridge specific components. It helps that you've already started looking into it.

I'd probably need to get a logic analyzer or oscilloscope, but I've got a cartridge of 1-2 Switch I wouldn't mind dumping and soldering on some wires to see how it works. I would assume an XCI dump would contain cartridge specific info (name, thumbnail, cert?, etc.) needed to emulate inserting a valid game. I don't know what backdoor through the cartridge pins would be available to flag CFW not to try booting the fake cart, but maybe with CFW (and the right keys) we could add in a game entry and thumbnail stored locally on the console. This would most likely involve crypto keys we don't have though and could be detected more easily making a donor cart the best option. I guess with CFW if you told it you were specifically using 1 donor cart, you could maybe set a flag to make that cart with that cert unbootable. Reverse engineering the cart system and setting up a donor cart seems viable but I'm not sure what's possible on the CFW side. It'd be nice to have some protection built-in to prevent accidentally starting the game since the game data wouldn't actually be present and the emulation would be barebones.

Someone has actually already taken a logic analyzer to one. This is where I was getting my info initially: https://reswitched.tech/hardware/gamecard

No mention of that danged secret pin though.

At that point it would end up being a third party solution to the problem as it would likely be Ninty copyrighted code or IP used to "emulate" a real cart, and I couldn't include it with the project for sure. I'd still be perfectly willing to build and donate hardware towards the development of such a thing!

Being able to have it recognize the dongle with a cool custom icon would sure be awesome, though.

 

[bundat]

I also still want the Dragoninjector whether it charges from the card slot or not.
But now I'm conflicted on the possibilities.

On one hand, the potential of cutting down charging speed to a few seconds (like the SX pro) if the card slot charging is omitted completely, as stated here, is enticing. As compared to the much slower USB charge times stated here.

On the other hand, solving the card slot charging problem really piqued my curiosity. And right now there are already people here helping to solve it. And even if they don't, if the functionality isn't completely cut out (i.e. by omitting the current limiting resistor), a CFW solution might even be possible e.g. a .kip file, similar to the nogc one, that bypasses the handshake and just forces 3.3v as long as pin 17 is shorted. Then all hekate/RajNX/ReiNX users can use this .kip file to charge their DragonInjectors via card slot (sorry SX OS users, unless TX adds loading custom sysmodules in the future).
Also being able to do that adds to the cool factor.

Not really sure which possibility I prefer now...
If it were only possible to only use the current limiting resistor if it was charging via game card slot (if/when that problem gets a solution), and to skip it and use the full 500mA when charging via USB... but that would be asking too much.

 

[XiorgON]

it will be a great anyway

thanks

keep me on the list

 

[blaze5]

Just did the math quickly, at the new safe current limit of 500mA for USB charging, by cutting out card slot charging (27.5mA max) the new charging times for the dongle are: 5 seconds for a full charge when brand new (0v to 3.2v), 4 seconds for a full charge from low power shutdown (1.7v to 3.2v) and half a second for 3 or 4 injections (1.7v to 2.2v).

--------------------- MERGED ---------------------------



Someone has actually already taken a logic analyzer to one. This is where I was getting my info initially: https://reswitched.tech/hardware/gamecard

No mention of that danged secret pin though.

At that point it would end up being a third party solution to the problem as it would likely be Ninty copyrighted code or IP used to "emulate" a real cart, and I couldn't include it with the project for sure. I'd still be perfectly willing to build and donate hardware towards the development of such a thing!

Being able to have it recognize the dongle with a cool custom icon would sure be awesome, though.

That's good to know someone else has already looked into that I'll have to check it out. No sense retreading the same ground and it's a good starting point.

Regarding IP I would think as long as no copyrighted material is distributed (as is the case with a legit donor cart which people dump themselves) it might work (I'm not a lawyer though). Custom title and thumbnail (beyond some fancy substitution by CFW for a donor cert) may require a global Nintendo key (I'm only assuming since anyone would be able to play the same cartridge) and distributing that if we could even figure it out would be a definite no no.

This encryption might be a pain to figure out though and the protocol is proprietary. I'd be curious if the encrypted payload is always the same for a specific cart (but maybe the encrypted messages sequence varies) or if there is some sort of SSL type handshake with a nonce (involving the cart cert and/or another cert stored somewhere locally on the cart for symmetric encryption possibly).

 

[MatinatorX]

I also still want the Dragoninjector whether it charges from the card slot or not.
But now I'm conflicted on the possibilities.

On one hand, the potential of cutting down charging speed to a few seconds (like the SX pro) if the card slot charging is omitted completely, as stated here, is enticing. As compared to the much slower USB charge times stated here.

On the other hand, solving the card slot charging problem really piqued my curiosity. And right now there are already people here helping to solve it. And even if they don't, if the functionality isn't completely cut out (i.e. by omitting the current limiting resistor), a CFW solution might even be possible e.g. a .kip file, similar to the nogc one, that bypasses the handshake and just forces 3.3v as long as pin 17 is shorted. Then all hekate/RajNX/ReiNX users can use this .kip file to charge their DragonInjectors via card slot (sorry SX OS users, unless TX adds loading custom sysmodules in the future).
Also being able to do that adds to the cool factor.

Not really sure which possibility I prefer now...
If it were only possible to only use the current limiting resistor if it was charging via game card slot (if/when that problem gets a solution), and to skip it and use the full 500mA when charging via USB... but that would be asking too much.

That would be fantastic and a really good solution. It's actually really easy to skip the current limiting resistor for charging via USB, I only put it behind the resistor to be extra safe and because charging via the card slot was supposed to be the default way.

The hard part is finding a way to separate the detection pin from ground in such a way that a firmware update could re-enable this connection. The fact that the voltage on the detection pin is negative 1.8v makes it a bit of a pain, since both a logical 0 and a logical 1 on an ATSAMD21 digital pin will be seen as a logical 1 by the detection pin. I could do it with a transistor, but space is already at too much of a premium. Without separating these, every time you put the dongle in your card slot you would get the annoying "card could not be read" error message.

It's definitely a really interesting problem and one I'd love to be a part of solving!

 

[Victor866]

It’s not a deal breaker for me.
Obviously it will be cool if it can charge via game card slot. But in my case is not the primary feature why I want to support this project.
If I need to charge trough the usbc every while then I will do and that’s it.

So you still can count with me

 

[Enkuler]

I'd really like to hear what you all think, or if anyone might have a lead on a software solution. Normally, something like this would've been a brief bump in the road for me and then I'd keep moving on without thinking much on it, but this project has garnered a lot of attention now and it's hard to say exactly what people were most excited about. Is this a dealbreaker for most, or just a minor annoyance? A lot of people had requested the ability to disable charging from the card slot, so perhaps it was just a "nice to have" feature, or perhaps not.

As far as I'm concerned, what I loved most about this project was the form factor so it's a minor annoyance if the "battery life" of this thing is long enough. Which should be the case I guess, it's not like we need to draw power out of it for long periods of time. Though yeah, charging from the cart slot would have been better in my opinion.

You're saying cart power is controlled by software so wouldn't it be possible for Atmosphère/ReiNX/etc to change the behaviour of that cart slot, like "don't expect data and keep charging"? That's probably out of the scope of your project, but if the thousands of people who bought this opened an issue on github, maybe we'd get it lol. Obviously as an option, so people can still use carts.

 

[mav2010]

In my tests, the Switch will send power for anywhere between 2 to 10 seconds

2 short questions:

Aren’t the 2 to 10 seconds not enough to top off the inserted injector enough for the next power up? I could easily live with the error message then, if it is only coming up once after inserting the card / rebooting.

And have you tested if this interferes with SX OS? SX OS complains when you try to launch an XCI game and a cart is inserted.

 

[MatinatorX]

2 short questions:

Aren’t the 2 to 10 seconds not enough to top off the inserted injector enough for the next power up? I could easily live with the error message then, if it is only coming up once after inserting the card / rebooting.

And have you tested if this interferes with SX OS? SX OS complains when you try to launch an XCI game and a cart is inserted.

Unfortunately I can only safely pull 27.5mA from the game card slot, which takes from 70 to 90 seconds for a full charge.

I did test that actually, and despite the game cart not being real and the switch whining about it, SX OS did complain and ask me to remove it.

 

[blaze5]

As far as I'm concerned, what I loved most about this project was the form factor so it's a minor annoyance if the "battery life" of this thing is long enough. Which should be the case I guess, it's not like we need to draw power out of it for long periods of time. Though yeah, charging from the cart slot would have been better in my opinion.

You're saying cart power is controlled by software so wouldn't it be possible for Atmosphère/ReiNX/etc to change the behaviour of that cart slot, like "don't expect data and keep charging"? That's probably out of the scope of your project, but if the thousands of people who bought this opened an issue on github, maybe we'd get it lol. Obviously as an option, so people can still use carts.

That's a valid point this may be possible completely in CFW. Maybe define a custom message type before the cart would start encrypted communication and have the DragonInjector identity itself to prevent the invalid cart error (and maybe load in custom image as a bonus). That'd certainly be easier than emulating a cartridge. Maybe someone on the Reswitched or Reiswitched Discord has an idea on how feasible this would be to keep power on and prevent game boot of the DragonInjector. A new thread on this cart power control via CFW or cart emulation might not be a bad idea either.

 

[hhamlet90]

Could you define the problem in a few words, I'm already looking for support in several discord channels ^^

 

[bundat]

Could you define the problem in a few words, I'm already looking for support in several discord channels ^^

I *THINK* all that's needed is this:

a .kip file, similar to the nogc one, that bypasses the handshake and just forces 3.3v as long as pin 17 is shorted

 

[darkten]

Eh.

It's fine. Everything in the world pretty much charges over usb, anyway. I'd vote for "ever forward".

 

[mav2010]

Unfortunately I can only safely pull 27.5mA from the game card slot, which takes from 70 to 90 seconds for a full charge.

I did test that actually, and despite the game cart not being real and the switch whining about it, SX OS did complain and ask me to remove it.

Ok, too bad.

But when you remove the ground pin from your casing, then neither the switch nor SX OS see it, right?

I am still in anyway. Ideally you figure out a way to keep the GC slot functionality and disable it via a tiny switch. That way we would not need a new hardware revision when someone figures out a software way around the problem.

 

[blaze5]

I *THINK* all that's needed is this:

a .kip file, similar to the nogc one, that bypasses the handshake and just forces 3.3v as long as pin 17 is shorted

@hhamlet90

Yeah something along those lines. Basically the console and cartridge send messages to each other to ensure that a valid cartridge is present (as described in https://reswitched.tech/hardware/gamecard) and otherwise shuts off power and prints out an invalid cartridge error. Pin 6 VCC 3.3v should be the correct pin to keep high since the IO logic level is 1.8V and 0V. We want to keep that 3.3V supply on whenever the DragonInjector is inserted in the card slot and bypass the legitimate/safety validation by the console.

 

[banzipan]

It's fine. Everything in the world pretty much charges over usb, anyway. I'd vote for "ever forward".

so true the form factor is what making this project so great. I hope someone can help you unfortunaly i don t have the knowledge necessary and if no solutions are found i can deal with usb charge.

 

[Triptamine]

I'd really like to hear what you all think, or if anyone might have a lead on a software solution. Normally, something like this would've been a brief bump in the road for me and then I'd keep moving on without thinking much on it, but this project has garnered a lot of attention now and it's hard to say exactly what people were most excited about. Is this a dealbreaker for most, or just a minor annoyance? A lot of people had requested the ability to disable charging from the card slot, so perhaps it was just a "nice to have" feature, or perhaps not.View attachment 140590

For me it was the least essential feature so no worries here. Nice to have sure but the container design to keep everything safe in one place and the stylish looking designs are far more important. You definately haven't lost my sale.