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!

 

[MatinatorX]

Regarding repartitioning eMMCs, I am making modified versions of gptrestore.

The idea is to use the one corresponding to your chip size.

eg there will be versions for 16GB, 32(the standard one), 64, 128 and 256.

Just crunching the lz4 gpt prefix and suffix`s now. Might be done tonight, but more than likely tomorrow now.

Ah nice, so rather than scanning the size of the NAND and expanding to fill available space, you're going to have pre-configured options to expand the user partition to a finite size?

Also, don't know if you managed to invade Discord yet but Stuck added LZ4 support to intermezzo for dragonboot to decompress payloads after injection, if you need any tips on working with it I'm sure they can help.

 

[pLaYeR^^]

Oh yeah, completely doable. Since they're just blank modules you can do whatever you want with them. If you have no need for OFW you could even run three separate CFW environments if you wanted, each with a dedicated MicroSD card.

Yes, that's what I want. Thanks for the good work!

 

[ANTONIOPS]

SHUT UP AND TAKE MY MONEY!!!!!!

 

[simbin]

Sounds interesting - can't wait to see how the project matures. Having quite a bit of experience with 3M conductive tape, it never holds up unfortunately. Hopefully that can be fixed in the next revision. Keep up the good work!

 

[MatinatorX]

Sounds interesting - can't wait to see how the project matures. Having quite a bit of experience with 3M conductive tape, it never holds up unfortunately. Hopefully that can be fixed in the next revision. Keep up the good work!

That's why I'm using it sparingly on only the USB D+ and D- pads and doing everything I can to give it the best chance by mating two clean ENIG surfaces via a 1cm square PCB, with only two square millimeters actually needing Z conductivity.

Worst case it doesn't work well in testing and payload injection can be achieved by soldering to the two exposed USB pads on DragonMMC. I left them there just in case.

 

[mattytrog]

Ah nice, so rather than scanning the size of the NAND and expanding to fill available space, you're going to have pre-configured options to expand the user partition to a finite size?

Also, don't know if you managed to invade Discord yet but Stuck added LZ4 support to intermezzo for dragonboot to decompress payloads after injection, if you need any tips on working with it I'm sure they can help.

Precisely

Ah nice, so rather than scanning the size of the NAND and expanding to fill available space, you're going to have pre-configured options to expand the user partition to a finite size?

Also, don't know if you managed to invade Discord yet but Stuck added LZ4 support to intermezzo for dragonboot to decompress payloads after injection, if you need any tips on working with it I'm sure they can help.

Im all up and running with LZ4 sir.
I`m assuming you mean compressing payloads that are over 126236b, decomping to the heap and moving the pointer accordingly? In theory should allow bigger payloads? My C is getting better from such a looooong break but getting there now.

I am making versions for set sizes in case people do not want to use the whole eMMC. Could just make it fill the entire area like you said, but I wanted to give people the choice.

Great project you are doing. Put me down for one! Let me know £.

Will do a how-to / update my work accordingly.

 

[mrissaoussama]

nice project, sounds like it took a lot of time to make

If I am understanding correctly, this only works on hackable switches right? or just switches with access to rcm?

 

[MatinatorX]

Precisely


Im all up and running with LZ4 sir.
I`m assuming you mean compressing payloads that are over 126236b, decomping to the heap and moving the pointer accordingly? In theory should allow bigger payloads? My C is getting better from such a looooong break but getting there now.

I am making versions for set sizes in case people do not want to use the whole eMMC. Could just make it fill the entire area like you said, but I wanted to give people the choice.

Great project you are doing. Put me down for one! Let me know £.

Will do a how-to / update my work accordingly.

What we do now is compress the payloads via LZ4, and then convert them to the payload.h file that's part of the firmware. The new intermezzo then gets sent during injection, takes the compressed payload that is also then sent, and decompresses it before running it. I do believe doing it this way would get up a bit past the normal size limit, however we're doing it because the DragonInjector has a grand total of 64kb of flash space including bootloader, wear-levelling, payload, user code...

Happy to send you one as long as you let me do so for free. If you really want to contribute, you can buy some NAND modules for it.

 

[mattytrog]

What we do now is compress the payloads via LZ4, and then convert them to the payload.h file that's part of the firmware. The new intermezzo then gets sent during injection, takes the compressed payload that is also then sent, and decompresses it before running it. I do believe doing it this way would get up a bit past the normal size limit, however we're doing it because the DragonInjector has a grand total of 64kb of flash space including bootloader, wear-levelling, payload, user code...

Happy to send you one as long as you let me do so for free. If you really want to contribute, you can buy some NAND modules for it.

With pleasure sir! Got loads here (all 32gb). Let me know when you are ready and we will sort it!



EDIT: Forgot the E16 has 64kb flash!

 

[MatinatorX]

nice project, sounds like it took a lot of time to make

If I am understanding correctly, this only works on hackable switches right? or just switches with access to rcm?

As of now that's correct. However, there are 4 extra GPIOs exposed via pads or FFC connector, with 2 of them also going to a nice little plug on the backside. In short, if an open-source method is found for Mariko/iPatched consoles, DragonMMC is ready to make use of it.

Sadly, the Lite is a completely different layout, and the NAND and SD are soldered directly to the mainboard. It will never be supported by DragonMMC.

 

[JonJaded]

There was a time, when I thought DragonInjector was just some sort of dream, yet it's brought to life.

I believe the same for this and I'm waiting to be blown away!

 

[technaustin]

Just to be clear, if you have some sort of auto-RCM and a payload on your SD, this device will run the payload, and for all intensive purposes, could make your device sort of untethered, or am I misunderstanding?

Edit: looks amazing by the way!

 

[MatinatorX]

Just to be clear, if you have some sort of auto-RCM and a payload on your SD, this device will run the payload, and for all intensive purposes, could make your device sort of untethered, or am I misunderstanding?

You are correct! The primary purpose is multiple NAND and MicroSD switching, but it also functions as a basic internal payload injector when used with the (hopefully solderless, pending testing) USB interface board. Similar to the DragonInjector, it will launch whatever payload you have in /dragonboot/ on whichever MicroSD card you have selected.

 

[lordelan]

I'm really speechless. This is the most exciting hardware addition I've seen for the Switch so far.
It let's me use sysNAND, emuNAND, Android, L4T Ubuntu and Lakka easier than ever.

I'm only curious about one thing which I don't know whether I got that right from your opening post:
Well we be able to do a tetherless (aka dongle-less and jig-less) coldboot to hekate with this?

 

[callmebob]

Unfortunately not. The test points for the MicroSD slot are very small and don't include VCC_SD. The best I can do is give you the part number of the motherboard side connector if you want to try to replace it yourself or get a shop that can handle microsoldering to do it.[/QUOTE]


Okay, thanks for the reply! Unfortunately that is something I cannot do myself. Between my old eyes, and my fat paws those days are gone.

 

[MatinatorX]

I'm really speechless. This is the most exciting hardware addition I've seen for the Switch so far.
It let's me use sysNAND, emuNAND, Android, L4T Ubuntu and Lakka easier than ever.

I'm only curious about one thing which I don't know whether I got that right from your opening post:
Well we be able to do a tetherless (aka dongle-less and jig-less) coldboot to hekate with this?

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.

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.

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.

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.

 

[Dominator211]

Well heres a Idea for you, could you make it so microsd cards could replace the NAND of the switch or potentially design somthing that could allow for a bunch of MicroSD cards to be in BORD (Bunch of Random Disks) Mode

 

[Beerus]

2020 so far we got WW3, Fires and now this! of to a great start

 

[MatinatorX]

Well heres a Idea for you, could you make it so microsd cards could replace the NAND of the switch or potentially design somthing that could allow for a bunch of MicroSD cards to be in BORD (Bunch of Random Disks) Mode

MicroSD cards are painfully slow compared to NAND chips. In theory it could be done, but I don't plan on doing it. If someone really wants to try, the hardware sources will be available soon after release.

As for any kind of JBOD or RAID, nothing that can do this currently exists, so an FPGA or similar would need to be programmed from scratch, and that's beyond my abilities. Besides, there's no guarantee that the Switch can supply enough power on VCC_SD for 3 MicroSD cards, and I don't feel like adding wires to steal power from other places.

If somehow the power and FPGA hurdles were overcome, then something like RAID could be employed to improve the read/write performance. However, this would come at the cost of reliability - a RAID0 would make the data on all 3 MicroSD cards irrecoverable if even one of them failed or went missing.

 

[Alex658]

Wouldn't the switch overheat without the heatsink?