The Switch Flashcart Thread (Mig Switch etc.)

  • Thread starter Thread starter TheStonedModder
  • Start date Start date
  • Views Views 771,605
  • Replies Replies 2,812
  • Likes Likes 25
I’m curious to see how you designed the shell to actually attach together and still be easily printable

See if you took a different approach. I took all of my replacement files down after people where selling them on Etsy
thats a shame :( i m sure it would be useful to others.
 
  • Like
Reactions: impeeza

I’m curious to see how you designed the shell to actually attach together and still be easily printable

See if you took a different approach. I took all of my replacement files down after people where selling them on Etsy
e3d454c6e5b1ad6a7b1776993efa192a.png
df592128d0f9e0818707766318c3ac7c.jpg
d47a09f960a8a4ee3bd58d087ccd9918.jpg
 
Hello everyone,

I've been spending some time recently doing a deep dive into the M1gSwitch hardware, and I took a few hours to measure and completely redraw the PCB. After I finished, I discovered that another member of the community had already done the same work, haha.

But since the project is complete, I wanted to share my version and my thoughts on what could be done next.

1. My Replicated PCB Design

My goal was to create a low-cost version, so the design is based on JLC's free prototyping service, using 0402 components to match the original's form factor.

  • I've created two versions of the board: one minimalist version without a physical button, and a second version that includes one for switching games.
  • I also designed a 3D-printable shell to house the board and protect it.

View attachment 525921View attachment 525922View attachment 525924View attachment 525926View attachment 525927View attachment 525928

2. Theory on the FPGA Firmware

I haven't been able to find any public firmware dumps for the FPGA. However, after analyzing the connections between the ESP32 and the FPGA, I saw that the layout perfectly matches the standard for an FPGA's slave configuration mode.

Combined with the fact that the MigSwitch team has released firmware updates, this leads me to a theory: The FPGA chip likely arrives blank from the factory. On each power-up, the ESP32 is responsible for loading the firmware directly onto the FPGA.

To test this theory, I've ordered new, blank FPGA chips of the same model. There's a slight shipping delay, but I will post an update here as soon as they arrive and I've had a chance to test them.

3. Offering Help to the Community

I'm based near Shenzhen, which allows me to source a wide variety of electronic components and get PCBs manufactured quickly and at a very low cost.

If anyone in the community has a new concept or needs assistance with hardware validation, I'm happy to help.

4. Next Steps: Side-Channel Analysis

Beyond just verifying the FPGA theory, I have some further plans.

  • Development Board: I have already created a custom Switch cartridge-style dev board that breaks out all the key interfaces (Power, JTAG, USB, GPIOs) to make debugging and analysis easier.
  • Tools: I'm planning to acquire a good oscilloscope and a ChipWhisperer-Husky for this purpose.
  • Goal: My objective is to use this setup to perform side-channel analysis and attempt to extract the firmware via non-invasive methods.
  • Promise: If I successfully extract a usable firmware, I will release it publicly for the community.
As a side note, the total hardware cost for this replication project is under 40 RMB (about $5-6 USD), making it very accessible.

5. A Long-Term "Moonshot" Idea

Finally, there's a more ambitious, long-term idea. A friend of mine who works in the semiconductor industry suggested that we could potentially use their lab's FIB (Focused Ion Beam) and electron microscope to directly read the eFuse data from the chip's die. This is a highly advanced physical attack. Their equipment is in constant use, so this is more of a future possibility than a concrete plan, but it remains an interesting option.

Amazing work! I'm sorry you had to redesign the board from scratch though, haha.

You mentioned using JLC's assembly service, is that just for the passives like the capacitors and resistors, or does it also include parts like the RGB LED and microSD slot? I made my BOMs for DigiKey and Mouser, but if LCSC has all of the parts too that would help with distribution choices. Also, do you intend on working on the Dumper board in any capacity?

As far as the blank FPGA, I tried a few boards with MIG ESP32 and blank FPGA and they did not work, I needed to transplant both chips.

Great work on your project and I'm excited to see your updates!
 
  • Like
Reactions: Blythe93
Afaik, the video and slides will be published on the talk page within a week or two

The bootloader has an option to load FPGA firmware, probably for initial debug during development. But the firmware I dumped does not contain FPGA firmware, so the interface is used for communication only
Post automatically merged:


I used the courk.cc side channel hardware to dump the ESP32
Thanks for the details. I was wondering if you've ever tried to analyze the firmware update process
Post automatically merged:

Amazing work! I'm sorry you had to redesign the board from scratch though, haha.

You mentioned using JLC's assembly service, is that just for the passives like the capacitors and resistors, or does it also include parts like the RGB LED and microSD slot? I made my BOMs for DigiKey and Mouser, but if LCSC has all of the parts too that would help with distribution choices. Also, do you intend on working on the Dumper board in any capacity?

As far as the blank FPGA, I tried a few boards with MIG ESP32 and blank FPGA and they did not work, I needed to transplant both chips.

Great work on your project and I'm excited to see your updates!
Thanks for the info. The service I'm using only covers PCB manufacturing, so the component soldering has to be done manually. Discounts for SMT assembly services are rare. For batch production, it's possible to mail the chips to the factory.

My next plan is still to try replacing the FPGA and to analyze the firmware update process and the data exchange between the two chips.
 
Last edited by cuberwr,
  • Like
Reactions: Blythe93
I was wondering if you've ever tried to analyze the firmware update process
It's just decryption of the update file and writing the data right into the ESP internal flash. FPGA cannot be updated, its NVCM can be written only once
(although the bootloader still has feature to load FPGA bitstream into its SRAM I'm sure the retail firmware updates will never have the bitstream inside)
 
It's just decryption of the update file and writing the data right into the ESP internal flash. FPGA cannot be updated, its NVCM can be written only once
(although the bootloader still has feature to load FPGA bitstream into its SRAM I'm sure the retail firmware updates will never have the bitstream inside)
Do you know if the firmware on the chips for the flashcart and dumper are the same, or does the update differentiate between the two?
This is a really cool model. Do you have one for the button model too?
 
  • Like
Reactions: Blythe93
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.
 
  • Like
Reactions: _iggyman_
Here's a pretty good thread by hexkyz detailing some new information they have regarding the MIG (original thread here, posted below for convenience).



All around it looks like a pretty secure firmware but it's good that researchers are able to understand it more and more.



One of the comments in the twitter thread says basically I think it can run on cheaper hardware if the security is removed and it would be easier to write the new firmware from scratch rather then decrypt / clone the Mig Switch firmware. Hopefully it happens.

https://nitter.poast.org/hexkyz/status/1965087742486020506#m
 
nice share 25 bucks:glare:
There really isn’t much I can do about that unfortunately

Filament, shipping and electric usage are not free. There’s like 30 cents of overhead here lol the only way to do it cheaper would be if I made these large batches en masse
 
Last edited by TheStonedModder,
There really isn’t much I can do about that unfortunately

Filament, shipping and electric usage are not free. There’s like 30 cents of overhead here lol the only way to do it cheaper would be if I made these large batches en masse
I think was 10 bucks for the STL file!
 
  • Like
Reactions: Razorbacktrack
The STL file is purely digital and doesn’t have to worry about any of the details I listed

Even sending that STL to someone like pcbway for printing will cost more. My clear MiG flash shelll cost me $40 from them
I you have a3d printer (like me self) the STL file will cost no much.
 
  • Like
Reactions: Razorbacktrack
I you have a3d printer (like me self) the STL file will cost no much.
I agree, that’s why I initially offered the file for free (about a year) but then Etsy folks stole it and my hours of hard work

If you have a better solution please tell me. That sounds mean and I genuinely do not mean it as such.

I figured replacement parts will be useful for some still instead of not offering them at all like I was for a minute. I’m not profiting off of those links or well I am it’s 20 cents but that’s because it’s the lowest I could put. Otherwise it would be costing me more in shipping and filament

Just to explain my thought process if you have any other solution, I genuinely would love to hear it. I am just don’t want to cater to the leeches no more while also not screwing over the community.
 
Etsy has new rules when it comes to 3D printed items. You are no longer allowed to sell 3D printed items that you didn't personally design. They should allow prints that the seller has a license to sell commercially even if they didn't make the model.
 
  • Like
Reactions: Blythe93

Site & Scene News

Popular threads in this forum