The Switch Flashcart Thread (Mig Switch etc.)

  • Thread starter Thread starter TheStonedModder
  • Start date Start date
  • Views Views 771,368
  • Replies Replies 2,812
  • Likes Likes 25
Has any progress been made after the hacker that dumped the mig firmware after decrypting it directly from the chip on a Mig Switch? I mean it seems he was banned from Github for posting the complete dump with the secret keys under github "mig_research" that was also deleted, so it shouldn't have taken long for someone in china to make a clone.
User still has his GitHub account. That repo probably was deleted but I don't know reasons.
On his X account status maybe you find the scripts some are looking for. Gists.
 
DMCAs got sent out even forks got deleted and hit

It had keys In t
I think the ones I am seeing, still online, as gists, have keys too ;)
Some vars called
tea_key+aes_key0-7
1770504411520.png


But looks like some funcions/methods have been truncated. Don't really understand most of the script. Decrypt logic/function complete/not truncated
 
Last edited by Kapeas,
Quick questions:

Do certification files dumped from nxdumptool still work with v2 with the latest firmware?
Can you use any XCI file from the internet so long as it matches the game the certs were dumped from?
 
I think the ones I am seeing, still online, as gists, have keys too ;)
Some vars called
tea_key+aes_key0-7
View attachment 555506

But looks like some funcions/methods have been truncated. Don't really understand most of the script. Decrypt logic/function complete/not truncated

Even though the repo got taken down, there is still a good Twitter thread that gave lots information on how it worked.

Here's a pretty good thread by hexkyz detailing some new information they have regarding the MIG (original thread here, posted below for convenience).

Mike Heskin @hexkyz
Sep 6
Thanks to the great work done by 15432, we can finally decrypt the MIG flashcart firmware code. Here's what we've learned so far. https://github.com/15432/mig_research

1) MIG is TX/GW, unsurprisingly. As explained by 15432, the exact same MIPS-like VM code is used within the firmware. A number of other similarities can also be found such as the FPGA communication code stack being the exact same as the one used by the SX Core.

2) The gamecard communication protocol (which is based on SNOW 2 and AES-CCM) is entirely implemented in the ESP32 firmware. MIG included a piece of previously unobtainable key material (the IV used for SNOW) in the firmware code, which could only be extracted by decapping.

3) However, a crucial piece of key material, the Lotus3 hardware AES key, is not visible to the ESP32. Instead, they've hid it inside the FPGA and request it to do the decryption of the relevant data. This alone makes it impossible to clone their hardware, but there's more.

4) Both the bootloader and firmware have multiple layers of verification. Aside from using the ESP32 Secure Boot system (which uses RSA-PSS), the firmware itself double checks signatures during the update process.

5) Additionally, there's a small MIPS VM handling some critical tasks which include verifying another RSA signature that lives inside a "secure block" (flash address 0x1FF000). This block also contains their firmware keys (encrypted) and other important material.

6) The firmware keys are stored encrypted and the key to decrypt them is generated by hashing (HMAC-SHA256) a chip unique IV in the bootloader with a chip unique HMAC key. The latter is programmed to efuses and locked from reading.

7) Decrypting the "update.s2" file is a matter of stripping away a first layer of TEA encryption, parsing metadata, decrypting the actual firmware code with the right AES key and, finally, deobfuscating the resulting plaintext through their custom XOR-based algorithm.

8) This last XOR-based algorithm is an absolute abomination of mixing random values and multiple seed sources just to make it as hard as possible to reverse engineer (even Ghidra wasn't able to produce an accurate decompilation of it, despite having support for Xtensa).

All around it looks like a pretty secure firmware but it's good that researchers are able to understand it more and more.
 
Can you use any XCI file from the internet so long as it matches the game the certs were dumped from?
I can speak from experience that not all XCI files are the same size (speaking of the same game). I have made dumps of my own personal legit Switch games using the Mig Dumper, and the XCI files I made have different file sizes from the same game found in that giant public Mig torrent file.

I think it has something to do with the fact that different dumps were made from different region releases (with a different product code)? Check this page: https://old.reddit.com/r/NintendoSw...de_to_nintendo_switch_dlc_regions_and_how_to/
Some games are identical in every region (thus, compatible with cross-region DLC), but some are not. If the game is the same in every region, then it should have a matching XCI file.
 
Last edited by chubbysquid,
  • Like
Reactions: Kapeas
I can speak from experience that not all XCI files are the same size (speaking of the same game). I have made dumps of my own personal legit Switch games using the Mig Dumper, and the XCI files I made have different file sizes from the same game found in that giant public Mig torrent file.

I think it has something to do with the fact that different dumps were made from different region releases (with a different product code)? Check this page: https://old.reddit.com/r/NintendoSw...de_to_nintendo_switch_dlc_regions_and_how_to/
Some games are identical in every region (thus, compatible with cross-region DLC), but some are not. If the game is the same in every region, then it should have a matching XCI file.
XCI format can be trimmed or not. For the same game.
I mean, there are games (cartridges) of 8Gb, 16Gb, 32Gb and so on.
Companies will use a 8Gb cartridge for games under 8gb, a 16 gb one for games 8 to <16gb... But some of the cartridge blank space is never written/used. So, you may find games in a 8gb card that, if trimmed when dumped, will take just over 4gb, "wasting" almost another 4gb if you dump them in raw/complete format.
For example, original Witcher 3 cartridge is 32 GB.
A normal dump of this cartridge will take 32GB of space. But you can dump with the trim option and it will only take the real space needed (around 29-30 GB).
This goes for legally obtained/your own dumps. Not sure how mig people trim or share "theirs".
Also, most dumping methods (software) allow config to remove certificate or other software parts besides the game itself, not really sure why or when to use those, never did, those will affect output xci file size, I presume. But the trimming option is useful, otherwise you will be wasting space on every dump, adding 1-N Mb/Gb of 0s.
 
Last edited by Kapeas,
You are supposed to dump the game files yourself. We cannot help you find the unique per cartridge files.
so other than "backups" it serves nothing... there is a lot on people saying that can be used as a "pi rat" cart... i was thinking it was like a R4. im better off with athosphere then
 
  • Like
Reactions: Blythe93
so other than "backups" it serves nothing... there is a lot on people saying that can be used as a "pi rat" cart... i was thinking it was like a R4. im better off with athosphere then
That’s what backups are..if sourced for elsewhere …

Either way doing so will ban your system
 
already banned. its a switch to use at work in lunch hours to play with coworkers. was thinking using a "r4" for the switch was easier. but guess not
if you are already banned and the system is not modded it should be a lot easier.

The game files you asked about are not exactly hard to find or locate.
 
.I can find the xci or nsp but not the certs and bins. Either that or im dumb as fuck...
respectfully, its that last one. The files are common

We can't share them here or point you in the direction as that is considered distributing warez since its copyrighted content
 

Site & Scene News

Popular threads in this forum