DragonMMC replaces the stock MicroSD and NAND boards, and adds a slide switch to choose between up to 3 MicroSD cards/NAND modules. This slide switch protrudes slightly from the original MicroSD card slot, while a replacement kickstand houses 3 MicroSD card slots. Installation does not require soldering, but will require some disassembly of your Switch. All required tools will be included. Removal of the heat shield is currently required. Addons for the DMMC are planned, including fully internal Bluetooth audio streaming, and you can easily make your own thanks to the expansion connector and solderless USB passthrough. (Note that the DMMC itself has no USB capabilities and only passes the USB lines to the expansion connector.)

DragonMMC is modular, with 3 NAND module slots available. An adapter module for the OEM NAND is included. Extra NAND modules of 64GB and 256GB will be available on the web store. The modules are snap-in and do not require soldering. An MCU handles NAND module and MicroSD card detection, as well as safe switching. The slide switch can be moved at any time to change the desired NAND module and MicroSD card. A restart or power cycle of the console will be required to enact the changes. If the selected MicroSD slot or NAND module is empty, DragonMMC will look for the next populated slot and enable it instead.

DragonMMC will be based on the ESP32-PICO microcontroller. More info to come soon!

 

[osaka35]

excellent! Absolutely adore you for this. I'll have my second switch ready to sell once the release day is announced.

 

[Deleted User]

He's a mad man.... A MAD MAN!

 

[RandomUser]

Ooh, this looks interesting!
Will the NAND chip be propitiatory in due part of having a snap in clip to it, or the snap in clip will be on the DragonMMC itself?
Also I can see the idea of having microSD slot in place of the NAND chip for cheaper and easier sourcing for SD, but supposed that may not be easy to accomplish.

Hopefully someone will make a side by side comparison to this project and this one at some point like when both product comes to fruition.

Edit:
I think both the DragonMMC and the chip will have a snap on clip by looking at the pics again. So it will be for the most part preparatory.

 

[MatinatorX]

Ooh, this looks interesting!
Will the NAND chip be propitiatory in due part of having a snap in clip to it, or the snap in clip will be on the DragonMMC itself?
Also I can see the idea of having microSD slot in place of the NAND chip for cheaper and easier sourcing for SD, but supposed that may not be easy to accomplish.

Hopefully someone will make a side by side comparison to this project and https://gbatemp.net/threads/reload-modchip-quadnand-more.546535/']this one[/url] at some point like when both product comes to fruition.

The NAND chip itself is just a standard BGA-153 eMMC 5.1 chip. I'm specifically going to use new Samsung KLMCG4JENB-B041 (64GB) and KLMEG8UCTA-B041 (256GB) chips for the modules.

The modules themselves snap in to DragonMMC using a pair of B2B connectors in such a way that it can't be installed backwards. They're different than the normal eMMC board connector solely because space is at a premium and it's just too big. It's not proprietary though - it's the same connector the SD board uses. It's actually a really good connector when it's used properly and not twisting in it's socket thanks to poor design decisions.

As for ReLOAD, it's not a competing product. It aims to do a lot more than DragonMMC does. In fact, the two solutions are designed to work together - @TariqSoftDev and I help each other out quite frequently, and as such the DragonMMC modules can also be used with the ReLOAD NAND board. This means less dev time and taking advantage of better bulk discounts when ordering NAND chips. Good things happen when we all work together!

 

[RandomUser]

The NAND chip itself is just a standard BGA-153 eMMC 5.1 chip. I'm specifically going to use new Samsung KLMCG4JENB-B041 (64GB) and KLMEG8UCTA-B041 (256GB) chips for the modules.

The modules themselves snap in to DragonMMC using a pair of B2B connectors in such a way that it can't be installed backwards. They're different than the normal eMMC board connector solely because space is at a premium and it's just too big. It's not proprietary though - it's the same connector the SD board uses. It's actually a really good connector when it's used properly and not twisting in it's socket thanks to poor design decisions.

As for ReLOAD, it's not a competing product. It aims to do a lot more than DragonMMC does. In fact, the two solutions are designed to work together - @TariqSoftDev and I help each other out quite frequently, and as such the DragonMMC modules can also be used with the ReLOAD NAND board. This means less dev time and taking advantage of better bulk discounts when ordering NAND chips. Good things happen when we all work together!

That is cool that you're all working together, and do hope both product do come to fruition, This looks very interesting.
Thank you for clearing up the connectors portion.

 

[vampi]

Mindblowing!! Must keep an eye on this

 

[Adran_Marit]

He's a mad man.... A MAD MAN!

I've been watching this dev stuff from the inside and you have no idea lol

 

[insomniac45177]

Correct me if im wrong. But this handles micro sd through the nand? I have a switch the micro sd connector was broken away from the board. Will this allow me to use this switch again with micro sd???

Sorry guess i didnt read deep enough in comments before commenting. And damn. Oh well. Still would buy this for my good switch.

 

[Sunnyboy]

also for patched console?

 

[lordelan]

The idea here is to actually replace emuNAND completely. If your CFW is running off of a completely separate NAND chip, it's no longer emuNAND. More like... alterNAND, or something even more less cheesy.

Understood.

Now, while this is technically tetherless and jigless, it is NOT a new exploit. It's only tetherless in the way that you don't need a dongle or Android phone to inject the payload, however there is still a "tether" inside your Switch in the form of the USB interface board connecting the DragonMMC to your USB port, similar to other internal modchips. Thus, it is still considered a tethered exploit and not coldboot.

I see. That's what I wanted to hear. By tetherless I really just meant "Do I need to carry a jig + dongle with me any longer?" and you answered that. I don't really mind what's happening inside my Switch. As long as I won't ever need them again I'm happy.

As for needing the jig, there is actually more than one way for the console to enter RCM mode. Besides using a jig and Vol+, AutoRCM is another common way, which safely modifies part of your NAND to trick the console into thinking there's a problem with it, kicking it into RCM for recovery on boot.

I'm aware what (Auto)RCM is.

However, the same thing can be done by simply unplugging the NAND module entirely - or, as is the case with DragonMMC, we can simulate unplugging it by introducing a programmed delay between when the console expects to read the NAND, and when we actually power it up. In this way, we can enter RCM without a jig and without using AutoRCM. Then, we power up the NAND, and then inject the payload.

Understood this as well now. This is really clever and an awesome solution!

I only wonder how all that works software-wise. You said you have your own chainloading payload? Since you wrote, eMMCs are way faster than mSD cards, we most likely will prefer eMMCs for stock NAND, CFW NAND and at least Android but I wonder if Android can be booted from an eMMC and/or if hekate can boot from there. I'm curious how all this turns out.
However I really can't wait for a showcase video.

 

[Rune]

I can't get over how ridiculously awesome this is.

 

[Adran_Marit]

Understood.

I see. That's what I wanted to hear. By tetherless I really just meant "Do I need to carry a jig + dongle with me any longer?" and you answered that. I don't really mind what's happening inside my Switch. As long as I won't ever need them again I'm happy.

I'm aware what (Auto)RCM is.

Understood this as well now. This is really clever and an awesome solution!

I only wonder how all that works software-wise. You said you have your own chainloading payload? Since you wrote, eMMCs are way faster than mSD cards, we most likely will prefer eMMCs for stock NAND, CFW NAND and at least Android but I wonder if Android can be booted from an eMMC and/or if hekate can boot from there. I'm curious how all this turns out.
However I really can't wait for a showcase video.

There was talk of something like booting hekate from the eMMC with a different partition, though I have no idea how it would work

 

[Danker301090]

For what? This isn't illegal in anyway shape or form.

Not in there eyes it will be classed as illegal methods to obtain CFW.

For what? We don't include, link to, provide instructions for or support any particular payload besides our chainloader, and this goes double for anything piracy related. You cannot commit piracy with any of my projects on their own, and we actively discourage piracy and restrict discussion of it within our circles. I buy the games I want to play and the software I want to use, and I think everyone should do the same. If you decide to use a certain CFW and certain tools that allow you to commit piracy, you need to find them on your own and learn how to use them yourself, and that's a choice you make on your own.

At it's core, DragonMMC is designed to let you expand the utility of your console by making it easier to run different environments like Android or Linux. The actual concept came about because I wanted to run Android on my console and became frustrated with all the steps involved and the performance loss from running off SD. Payload injection was actually an afterthought, and was added as a "why not" feature, since my choice of MCU already supported it.

EDIT: I should mention that a bunch of people I know who had gotten bored of their Switch have had their interest reinvigorated by the the thought of dead-simple Android dual-booting. Rekindled interest inevitably leads to more game or hardware sales for Ninty.

Again in Nintendo's eyes they would see it as modifying their property. I wish this will come to reality but i will see this end up in a lengthy court battle.

 

[Adran_Marit]

Not in there eyes it will be classed as illegal methods to obtain CFW.



Again in Nintendo's eyes they would see it as modifying their property. I wish this will come to reality but i will see this end up in a lengthy court battle.

If it uses the same code as for launching payloads that the DI uses, then I assume its fully legal in canada

 

[MatinatorX]

Not in there eyes it will be classed as illegal methods to obtain CFW.



Again in Nintendo's eyes they would see it as modifying their property. I wish this will come to reality but i will see this end up in a lengthy court battle.

I wish people wouldn't profess to be experts on these matters when they clearly aren't.

You are legally entitled to make whatever modifications to your console you want to, and I am legally allowed to sell you products that help you do so, as long as the modifications either of us are using do not violate DRM laws nor TPM laws in your country.

The only thing legally questionable here at all is the RCM exploit itself, which can be argued to be breaking DRM laws in certain countries, even if no payloads are included, due to the bootloader being possibly considered a TPM in those countries.

To this end we are actively researching whether payload injection is something I can include myself or if it will require some effort on the part of the user to find a third party firmware with this feature added. Even if I can't provide/support it myself, you can be sure that since the DragonMMC will be open source and uses a general purpose MCU, someone will add the feature to it.

As the DragonMMC uses the UF2 bootloader, flashing new firmware is as simple as connecting a USB cable to it, waving a magnet over it to make it show up as a USB drive, and copying a single file to it.

It is also possible I may be able to ship the device without payload injection capability, but with instructions on how to add it, with a warning and the condition that the user must confirm the legality of doing so in their country and assumed the risks of adding the feature in areas where it's not considered lawful.

 

[Shadow_The_Hedgehog82]

I can't make any promises, but I am going to try to get custom heat shields made. I have no idea yet what the cost would be yet though - to get my own kickstand hinges made I think it ended up costing me around $500 for 1000, and a heat shield would be a lot more complex.

I dont think the heat shield is necessary i dont have one in my console and have never had the console overheat

 

[Rune]

what are the performance differences between using a OEM NAND and a micro SD card in its place via the adaptor?

 

[MatinatorX]

what are the performance differences between using a OEM NAND and a micro SD card in its place via the adaptor?

The adapter does not let you use a MicroSD card as a NAND module. The adapter allows you to read a NAND module from a MicroSD reader. The speed comparison between MicroSD and NAND is as follows:

I want to make this clear - I have no plans to support using a MicroSD in place of a NAND module. The speed is abysmal, but beyond that, the command table for MicroSD cards is completely different versus NAND chips. An FPGA or similar would have to be programmed from the ground up to do the command translation to have any hope of it working properly, and that's completely beyond my abilities.

 

[Deleted-515458]

OMG
I am really excited...
Just WOW

 

[Idaho]

Very interesting product we have here and if TX wasn't teasing an exploit that could probably achieve the same thing I'd insta buy it but for now I'll have to wait and see to compare which of both solutions is the best...