Hacking Discussion Bricking your Switch on purpose or: How AutoRCM works
- Thread starter mnemonicpunk
- Start date
- Views 66,003
- Replies 178
- Likes 51
Stop right there. If you're posting that it's the wrong thread, it's probably the wrong thread. Please go elsewhere.
Just to disple some misunderstandings ...
So there are three ways atm. to enter the Tegra RCM.
1. by a combination of key presses (Volume+ & right JoyCon rail pin 10)
2. removing the eMMC/sysNAND module
3. manipulating the sysNAND (the BCT or the bootloader itself) so that nintendo's bootloader can't be loaded succesfully
The switch has two Recovery Modes.
1. The Tegra Boot ROM RCM that ist part of the SoC
2. A Recovery Mode / Maintanance Mode / Safe Mode that was written by Nintendo and is loaded from the eMMC (boot partitions 1 & 2)
The Tegra Boot ROM RCM ist the one that is targeted by fusee gelee to inject some payload to be then able to load and execute unsigned code.
So far, I hope everything is correct.
Now, I am asking myself, if there is a possibility that nintendo could find out that I ever booted into the Tegra RCM? Does the system store this kind of informations that could be read by Horizon?
So there are three ways atm. to enter the Tegra RCM.
1. by a combination of key presses (Volume+ & right JoyCon rail pin 10)
2. removing the eMMC/sysNAND module
3. manipulating the sysNAND (the BCT or the bootloader itself) so that nintendo's bootloader can't be loaded succesfully
The switch has two Recovery Modes.
1. The Tegra Boot ROM RCM that ist part of the SoC
2. A Recovery Mode / Maintanance Mode / Safe Mode that was written by Nintendo and is loaded from the eMMC (boot partitions 1 & 2)
The Tegra Boot ROM RCM ist the one that is targeted by fusee gelee to inject some payload to be then able to load and execute unsigned code.
So far, I hope everything is correct.
Now, I am asking myself, if there is a possibility that nintendo could find out that I ever booted into the Tegra RCM? Does the system store this kind of informations that could be read by Horizon?
Last edited by tecfreak,
But they kinda did.. Switch is more likely to see a downgrade, IMO. Much like the Wii revisions that removed GameCube compatibility and eventually online capabilities & SD slot.
Last edited by PuNKeMoN,
The quoted information looks correct to me.
To address your question: Since the RCM even works with the NAND disconnected, it can't rely on the presence of any data storage. This makes it very likely that it does not store information about entering RCM. Since I haven't looked into the code of the RCM though I can not guarantee that.
Thread is bad.. OP seems to have it out for TX. Threads like these are bias.
TX (a good development team, just like reswitched), obviously knows more than you do. They know what they're doing. You don't even have access to their dongle yet and you're saying they can brick your devices..
AutoRCM is stated to be reversible (and optional).. What's even less reversible is people soldering the pins in their joycon.. yet you don't hear anyone complaining or warning how dangerous it is.. just "at your own risk".. TX comes up with a software & 3rd party hardware solution and a thread about bricking comes along.
They're smart enough to create and distribute a hardware solution and a full OS. If there's a 1% failure rate, that's still less of a failure rate than soldering (optional) and fucking up your joycon pins. There's people bending their pins and the right joycon is no longer recognized by the system.. but yet, no warning threads like this one.
You install anything on your switch other than the official Nintendo firmware, and you know the risks pretty damn well. After all, you came here in search of how to do it. If you can't handle the risks, you shouldn't touch home-brew. You're buying a third-party dongle and "trusting" them to get things right. It's the same as installing atmosphere when it comes out.
Either trust the code or don't. They're not here to brick your console. They're here to make money by selling software and hardware.
TX (a good development team, just like reswitched), obviously knows more than you do. They know what they're doing. You don't even have access to their dongle yet and you're saying they can brick your devices..
AutoRCM is stated to be reversible (and optional).. What's even less reversible is people soldering the pins in their joycon.. yet you don't hear anyone complaining or warning how dangerous it is.. just "at your own risk".. TX comes up with a software & 3rd party hardware solution and a thread about bricking comes along.
They're smart enough to create and distribute a hardware solution and a full OS. If there's a 1% failure rate, that's still less of a failure rate than soldering (optional) and fucking up your joycon pins. There's people bending their pins and the right joycon is no longer recognized by the system.. but yet, no warning threads like this one.
You install anything on your switch other than the official Nintendo firmware, and you know the risks pretty damn well. After all, you came here in search of how to do it. If you can't handle the risks, you shouldn't touch home-brew. You're buying a third-party dongle and "trusting" them to get things right. It's the same as installing atmosphere when it comes out.
Either trust the code or don't. They're not here to brick your console. They're here to make money by selling software and hardware.
Last edited by JustBrandonT,
The code inside the boot ROM is executed by the BPMP which has some IRAM in that the BCT is copied from the boot storage device (don't know if the bootloader is also copied into the IRAM or into SDRAM). Is the data stored in this IRAM somehow accessible by the CCPLEX / the main processor?
And there are also the "straps" which atm. I don't know what these exactly are:
Is the Tegra RCM code pulling these straps so that Horizon would know if we were booting after entering the Tegra RCM?
Oh, and there should be also a way to enter Tegra RCM on every reboot (not cold boot) if you are already booted into and running a CFW by setting a specific PMC register bit.
Last edited by tecfreak,
I and a couple of others have been brandying about ideas for building a home-made dongle. I have ordered a(nother) test candidate, and should get it .. sometime. (Damned aliexpress and overseas shipping!) (This after being reminded by my shaky assed carpal tunnel afflicted limbs that I am no good at soldering teeny tiny things, when I screwed up the zsun I had ordered. Too small for me to solder. If somebody else wants to try though, check my thread. I will go with the solderless, full software flash method on the cheap Chinese "3g /4g router 150m" hardware candidate. Also doubles as a battery pack.)
One of the topics that came up was integrating a device to perform the injection as a hardware modchip. In addition to the usual suspects in the embedded microcontroller lineup, there are some SoM/SoC offerings that look particularly choice.
ACME's Arietta, and the VoCore2 look like good candidates for the more adventurous. Both have full USB port implementations and a bevy of GPIOs that can be used to disrupt the boot process prior to payload injection, while being small and thin. (the vocore2 is thinner, so may be more desirable, but still carries more than is needed to do the job-- but that wireless interface might be useful for updating the "modchip" later without opening the case on the switch.) The issue would be getting the SoM/SoC to boot fast enough for picky users. Microcontroller would have them beat there, but would be harder to update with different payloads later. Using a custom binary instead of a linux kernel on the SoC would suffice I think. One of the advantages to using this more capable hardware is that if you overstock on them, or they become obsolete, you can always repurpose them. Less so with a custom micro.
Integrating a highspeed usb switch on a tiny breakout would solve the "how to disconnect from the port" problem cleanly. The zsun I initially planned to use includes a was7227q, which is about the size of a large grain of rice. You would control it with a simple GPIO pin, and just disable the pin after injecting the payload. The OLD hardware revision of this device was practically perfect here. (Small, about the size of a nickel. Can run OpenWRT/some other linux, once you cut off the SDCard daughter board, you have a fully usable D+ and D- attached to the SoC's usb host controller, with a nice software off gpio already wired up.) However, the new version that hit around 2016 moved the 5v regulator to the daughter board, making that unpleasant. However, this particular component is a bulk commodity item, and ordering a custom breakout designed around one should not be difficult.
A hardware modchip of this type along with autoRCM would basically make the unit your bitch.
While TX has a leg up on the community at this point in the game, they have yet to ship any units that I am aware of, and the community at large is already hard at work devising alternatives. Those alternatives will work with *ANY* IPL that can be injected, not just TX''s. I fully expect an end-user friendly "flash and go" solution to appear in the comming weeks, as I myself and several others are working on that exact thing.
One of the topics that came up was integrating a device to perform the injection as a hardware modchip. In addition to the usual suspects in the embedded microcontroller lineup, there are some SoM/SoC offerings that look particularly choice.
ACME's Arietta, and the VoCore2 look like good candidates for the more adventurous. Both have full USB port implementations and a bevy of GPIOs that can be used to disrupt the boot process prior to payload injection, while being small and thin. (the vocore2 is thinner, so may be more desirable, but still carries more than is needed to do the job-- but that wireless interface might be useful for updating the "modchip" later without opening the case on the switch.) The issue would be getting the SoM/SoC to boot fast enough for picky users. Microcontroller would have them beat there, but would be harder to update with different payloads later. Using a custom binary instead of a linux kernel on the SoC would suffice I think. One of the advantages to using this more capable hardware is that if you overstock on them, or they become obsolete, you can always repurpose them. Less so with a custom micro.
Integrating a highspeed usb switch on a tiny breakout would solve the "how to disconnect from the port" problem cleanly. The zsun I initially planned to use includes a was7227q, which is about the size of a large grain of rice. You would control it with a simple GPIO pin, and just disable the pin after injecting the payload. The OLD hardware revision of this device was practically perfect here. (Small, about the size of a nickel. Can run OpenWRT/some other linux, once you cut off the SDCard daughter board, you have a fully usable D+ and D- attached to the SoC's usb host controller, with a nice software off gpio already wired up.) However, the new version that hit around 2016 moved the 5v regulator to the daughter board, making that unpleasant. However, this particular component is a bulk commodity item, and ordering a custom breakout designed around one should not be difficult.
A hardware modchip of this type along with autoRCM would basically make the unit your bitch.
While TX has a leg up on the community at this point in the game, they have yet to ship any units that I am aware of, and the community at large is already hard at work devising alternatives. Those alternatives will work with *ANY* IPL that can be injected, not just TX''s. I fully expect an end-user friendly "flash and go" solution to appear in the comming weeks, as I myself and several others are working on that exact thing.
You may have inside knowledge about the code they use to be able to make statements about the quality. I don't, so I don't. That also prevents me from estimating failures rates. Feel free to share that code you seem to have access to, so we can come to our own conclusions.
I am, however, not saying that they might bright your Switch. I'm saying that they will brick your Switch, because that is literally how "AutoRCM" works. Again, I haven't seen code for that either, I'm inferring that from their product description and the smartest and easiest way that I and many others know of to achieve this feature. (Please see the additional explanation in the first post about semi-bricks/softbricks and full bricks, you seem to have missed it because it was added only a few hours ago.)
For what it's worth: I routinely warn people about the dangers of soldering, sticking things into their joycon rail - for the love of god, stop using tinfoil! - and bending pins.
When Atmosphere comes out, by the way, I will know exactly what it is doing, because I am reading and playing with the code on a daily basis. Admittedly, the Assembler bits take me quite some time to understand each time something changes, but I take the time because I find it really interesting. Admittedly, that is probably not true for everyone around here. But for me it is. I don't have to trust. I know.
Whether the data of the BPMP is accessible or not depends on the execution level code runs in. In normal operation the BPMP is completely shut down - for firmwares >1.0.0 at least - so there is nothing to access there. At boot that is of course not the case.
There used to be a PMC register you could use to boot into RCM from software. The register obviously still exists - so CFWs are likely to have a "boot to RCM" feature in the future - but for OFWs it was disabled in 2.3
Interesting thoughts! But they are not really on topic here. I would suggest you head over to ReSwitched though if you want to discuss with like-minded people, there is a whole channel about this topic!
Hmm, this could cause problems if you turn on your console while it is sitting inside the dock, because then you have two devices on the same rail at the same time - the usb switch and the dock's usb hub. For this case you would need some extra circuit that detects wether the console is sitting inside the dock or not and if it is the case than prevent the usb switch from beeing activated.
The referenced switch would be wired similarly to this:
The "input" of the switch chip is the Nintendo's USB D+/D-. (From the switch motherboard.)
SelectOutput1 is the USB-C port's D+/D- (active when GPIO is low)
SelectOutput2 is the microcontroller's D+/D-. (Active when the GPIO is high.)
Thus, when the GPIO is low, the port on the switch will function normally, as the microcontroller will be disconnected.
When the GPIO is high, the port on the bottom is physically D/C, and the micro controller has the lane exclusively.
the was7227q is fully bidirectional, and would work just fine in this configuration.
When the switch is in the dock, it will receive power through the port; You will need to include some voltage control circuitry to prevent the modchip being fried by nintendo's nonstandard wattage. Otherwise, the data pins are connected by default (dock would try to turn on), until the micro controller asserts control, and raises its GPIO pin. When it is done doing the injection, it lowers the pin, and normal function resumes.
Ok, but you would have to cut the traces on the switch's main pcb to which the usb port is soldered to, to disconnect it from the SoC, or am I getting something wrong?
Yes, you would have to intercept the port's wiring before it terminates at the USB-C port. Thankfully it is just two traces.
Are they even on one of the visible pcb layers? USB type C has also two seperate d+ and two d- rails. Can't see any visible traces coming from the usb port's pins, neither on the top nor on the bottom side of the pcb.
Last edited by tecfreak,
Brick means irrecoverably damaged. ie, only useful as a brick building material from here on out. Use the right terms, stop fearmongering.
I am using the right terms. The different types of brick have been further clarified in the opening post to avoid confusion like yours, you likely missed that addition because it only happened a few hours ago.
Oh, you're confused, it doesn't matter how you define it. Let me wiki it for you, doll!
The word "brick", when used in reference to consumer electronics, describes an electronic device such as a smartphone, game console, router, or tablet computer that, due to severe physical damage, a serious misconfiguration, corrupted firmware, or a hardware problem, can no longer function, hence, is as technologically useful as a brick.[1]
The term derives from the vaguely rectangular shape of many electronic devices (and their detachable power supplies) and the suggestion that the device can function only as a lifeless, square object, paperweight or doorstop.
This term is commonly used as a verb. For example, "I bricked my MP3 player when I tried to modify its firmware." It can also be used as a noun, for example, "If it's corrupted and you apply using fastboot, your device is a brick."
In the common usage of the term, "bricking" suggests that the damage is so serious as to have rendered the device permanently unusable
That is why we refer to it as a soft-brick to separate it from a full brick. Thank your for posting that here for anyone interested.
yeah but even the term "soft-brick" isn't really apt as once this process is performed properly its actually just a exploit of a feature that would normally be caused by what might be a brick
the term brick/soft brick implies unintended non functionality, not intended differing of functionality
while I do understand where your coming from it isn't really what I would call a brick if it was purposefully performed to serve a purpose, I guess maybe the term "crippled" might be a little more appropriate as it does stifle normal operation but doesn't render the device unuable
Last edited by gamesquest1,
SUCH A LUST FOR BRICKS
well now it's as easy as 1,2,3: get briccmii from https://switchtools.sshnuke.net (source code at https://github.com/rajkosto/briccmii)
well now it's as easy as 1,2,3: get briccmii from https://switchtools.sshnuke.net (source code at https://github.com/rajkosto/briccmii)
Last edited by rajkosto,
Similar threads
- No one is chatting at the moment.
-
@
SylverReZ:
@Jayro, I don't see whats so special about the DS ML, its just a DS lite in a phat shell. At least the phat model had louder speakers, whereas the lite has a much better screen.+1 -
@
SylverReZ:
They probably said "Hey, why not we combine the two together and make a 'new' DS to sell".
-
-
-
@
Veho:
Nothing special about it other than it's more comfortable than the Lite+1
for people with beefy hands. -
-
-
-
-
-
-
@
The Real Jdbye:
@SylverReZ if you could find a v5 DS ML you would have the best of both worlds since the v5 units had the same backlight brightness levels as the DS Lite unlockable with flashme -
-
-
@
BigOnYa:
A woman with no arms and no legs was sitting on a beach. A man comes along and the woman says, "I've never been hugged before." So the man feels bad and hugs her. She says "Well i've also never been kissed before." So he gives her a kiss on the cheek. She says "Well I've also never been fucked before." So the man picks her up, and throws her in the ocean and says "Now you're fucked."+2 -
-
-
@
BakerMan:
anyways, we need to re-normalize physical media+1
if i didn't want my games to be permanent, then i'd rent them -
@
BigOnYa:
Agreed, that why I try to buy all my games on disc, Xbox anyways. Switch games (which I pirate tbh) don't matter much, I stay offline 24/7 anyways.
-
-
@
cearp:
@BakerMan - you can still "own" digital media, arguably easier and better than physical since you can make copies and backups, as much as you like.
The issue is DRM -
@
cearp:
You can buy drm free games / music / ebooks, and if you keep backups of your data (like documents and family photos etc), then you shouldn't lose the game. but with a disk, your toddler could put it in the toaster and there goes your $60
-
-
@
rqkaiju2:
i like physical media because it actually feels like you own it. thats why i plan on burning music to cds -
