Hacking Discussion Bricking your Switch on purpose or: How AutoRCM works

[CapitanSburro]

If I read correct in another thread TX cfw won't allow online at the moment.

Link to thread? Haven't heard about this yet, not by TX nor by GaryOPA

 

[aslk]

hmm I guess that's an interesting point, if its a 1 time install and no dongle required I guess they have some additional exploit at play, I guess when its out it will probably be copied by open source devs, there is only so much TX can do to protect that kind of exploit

no "jig" required. dongle still needed on every boot

 

[willdunz]

No, the bootrom can not be modified. If it could. Nintendo would simply patch out Fusee Gelee. That is in fact what they are doing with the new Mariko revision of the Switch, which features a new board that is very likely immune against the FG exploit.

I've heard they can simply patch bootrom during the manufacturing process. No new hardware revision required. True of false?

 

[mnemonicpunk]

I've heard they can simply patch bootrom during the manufacturing process. No new hardware revision required. True of false?

There are a few (I believe 256) bytes of patchdata that can be included in the efuses of the Tegra SoC in the factory. Those have all been used already and even if they weren't, any Switches currently in the wild would be unaffected either way.

Mariko is apparently a slightly different SoC altogether (still a Tegra but a newer one) and has a fixed bootrom specifically for cases like this. This does of course not mean that there are no new bootrom exploits to be found.

 

[Deleted-394630]

Sounds like the whole boot0 & boot1 A9LH method on the 3DS.

 

[hippy dave]

Since the console enters in rcm when the nand module is unplugged, couldn't we use a custom chip connected to the usb internally and to the nand module keeping the nand pins open for a couple of seconds so the console has time to enter in rcm mode and then inject the payload via the usb connection?

If you're going to do something like that with a chip, connecting the joy-con pin and the vol+ might be easier than getting in the way of the nand module.

 

[Lumince]

I cant wait to brick my switch guys. This is gonna be a blast. 50% paper weight here I come

 

[WiiUBricker]

So if you want to use this method be aware of how dangerous it is. Team Xecuter may call it AutoRCM, I call it “bricking your Switch on purpose”. Because that’s what it is.

I get it, but how is that any different from arm9loaderhax-haxxed 3DS systems that won't boot without an inserted SD card?

 

[SirNapkin1334]

Following in the footsteps of Gateway. At least it’s for a good purpose.

 

[StarTrekVoyager]

Given the toxic turn this scene had taken akin to the 3DS scene, this was all but easily predictable. Welcome to Gateway-Switch team.

 

[hippy dave]

I get it, but how is that any different from arm9loaderhax-haxxed 3DS systems that won't boot without an inserted SD card?

What do you know about bricking anything, Mr WiiUBricker?

(Good point)

 

[jimmyj]

Doesn't sound that bad. Considering my paper clip has a 1/10 chance,I'd like that

 

[EclipseSin]

I agree that this is really not much different than some coldboot exploits on other systems, especially such as the 3DS. I think the difference here was the transparency of how it is done, as it raises the question of why they don't mention a backup.

True, you could make a program to repair the nand without knowing the original value of that bit/byte, but that assumes a reverse engineering of the xecute payload/system. This is going to take time, and I'm sure someone will break their dongle before this is done. If not, great, otherwise they have no backup to repair, and no idea which bit/byte to count on. This is why I mentioned in another Xecuter thread to backup before using the feature.

So, as I said, transparency is the difference here I believe. Just label it AutoRCM, but not explain the internal procedure. There are more ways than one to achieve autorcm afterall.

 

[Lacius]

I don't plan on using my Switch without CFW anyway, so I'm probably going to do this to make it autoboot RCM.

 

[mnemonicpunk]

I agree that this is really not much different than some coldboot exploits on other systems, especially such as the 3DS. I think the difference here was the transparency of how it is done, as it raises the question of why they don't mention a backup.

True, you could make a program to repair the nand without knowing the original value of that bit/byte, but that assumes a reverse engineering of the xecute payload/system. This is going to take time, and I'm sure someone will break their dongle before this is done. If not, great, otherwise they have no backup to repair, and no idea which bit/byte to count on. This is why I mentioned in another Xecuter thread to backup before using the feature.

So, as I said, transparency is the difference here I believe. Just label it AutoRCM, but not explain the internal procedure. There are more ways than one to achieve autorcm afterall.

That's my main concern with this as well. As I said before, intentionally corrupting boot0 is no new idea. What worries me somewhat is the fact that it is being advertised like some piece of software you install, not a flaw you intentionally introduce into the normal workings of the system.

 

[zeveroth]

• Q: How does the tool (jig) and dongle operate? Are they needed everytime you turn on the console?
  A: If you don't want to make any (software) modifications to your Switch Console, both the Tool (jig) and dongle are needed every boot.
  SX OS has an optional "AutoRCM" feature that can be installed to your Switch Console such that the jig tool is not needed anymore on boot.

I could have sworn that they said it was enabled but we could uninstall that feature if we wanted to after installation.

 

[tinkle]

And a9x on the 3ds originally made your 3ds unable to boot without an SD card with specific files on it. What's the difference again?

 

[Billy Acuña]

And a9x on the 3ds originally made your 3ds unable to boot without an SD card with specific files on it. What's the difference again?

With a9lh you were able to revert to stock using a NAND backup, with AutoRCM you can't.

 

[Draxzelex]

I don't plan on buying the modchip, but this type of information is very interesting! Now I don't know if TX will implement a way to reverse it, but I wonder if someone from the community will? Unlike the 3DS, we don't have control of whether we want to boot into CFW or OFW, they're forcing us to boot into CFW if you go that route.

 

[tinkle]

With a9lh you were able to revert to stock using a NAND backup, with AutoRCM you can't.

You can uninstall the change at any time.

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

I don't plan on buying the modchip, but this type of information is very interesting! Now I don't know if TX will implement a way to reverse it, but I wonder if someone from the community will? Unlike the 3DS, we don't have control of whether we want to boot into CFW or OFW, they're forcing us to boot into CFW if you go that route.

See .