Hacking Discussion Bricking your Switch on purpose or: How AutoRCM works
- Thread starter mnemonicpunk
- Start date
- Views 65,678
- Replies 178
- Likes 51
My bad. Still in the midst of trying to catch up with everything that was released. Thanks for all your hard work and contributionsYes, press VOL+ instead of VOL- when it asks you
(Check the readme or even the repository title next time, please)
And now that the open source auto rcm was released, peace is restored in the land, tx are still evil, but open source "bricks" are better than the evil closed source "bricks" lol
All the information from the initial post obviously also applies to the newly released public implementations. The two major advantages available to us now are:
- We can test it in isolation, free from any DRM entanglements
- We can read the source, which I will do for rajkostos release. In my experience he does quality work but I still WANT TO KNOW WHAT IT DOES. And so should you before you, intentionally brick your Switch. Which is what it does and what it is called.
Happy bricking. Or briccing, if you're so inclined.
- We can test it in isolation, free from any DRM entanglements
- We can read the source, which I will do for rajkostos release. In my experience he does quality work but I still WANT TO KNOW WHAT IT DOES. And so should you before you, intentionally brick your Switch. Which is what it does and what it is called.
Happy bricking. Or briccing, if you're so inclined.
Here’s a deeper look at how rajkosto’s briccmii works. We’re gonna be looking at main.c because that’s where most of the interesting stuff happens. If you want to follow along at home, code checked out was https://github.com/rajkosto/briccmii/blob/master/src/main.c from the commit faea0fc, most recent at the time of writing.
From line 22 - the beginning of main function - to line 65 we take care of initializing the hardware and setting up the capability to interact with the eMMC. This is fairly standard stuff and looks a lot like what we find in Hekate.
From lines 67-74 we read in the BCT, the part that configures the boot procedure of the Switch. This is already important since that is what we’re going to corrupt in order to force the Switch to boot into RCM. No corrupting has happened yet, though.
From 76-88 we map out the BCT entries that are currently in use. This is done somewhat needlessly fancy but from a coders perspective it looks kinda cool. I wouldn’t expect anything else from rajkosto to be honest. ^^ This is gonna make things a little easier later on.
Now for the real meat:
From lines 90-119 we first read the correct SHA256 hash from the Tegra fuses so we know what correct output has to look like, then compare it to the current values’ hashes and display which ones are correct at this time and which ones are not.
Time to get bricking! Since this is a somewhat user-friendly program, it displays a menu in line 122. After that we enter an infinite loop. This isn’t as infinite as it sounds, quitting the program will end it. For our purposes that means the program will always return to this point after doing something.
After reading the buttons (line 124) we determine our course of action:
Pressing Power will safely exit the program (125+126) by skipping out of the infinite loop towards the end of the program.
If we press Vol+ (line 128) we begin the unbricking process:
If there are no valid BCT entries - we determined these earlier, remember? - we grab a known good public key from the BCT signature data. (lines 129 147) Otherwise we go through each key and, if we find a corrupt one, repair it under the assumption that it was corrupted using the very same method we will use later down the line in the bricking part of the code. (lines 150-177)
Now that we should have a known good key - we verify this in lines 180-187, quitting the program if we still don’t have one - let’s unbrick. We cycle through the BCT entries, skipping any entries that are already correct. The write of the correct data occurs in line 205, informing the user whether it worked or something went wrong.
Phew, that’s a load. There are quite a few checks and safety measures in place here to make sure we only do what we need.
After this, we have the code that most of you came here to see, starting in line 212: If the user presses Vol-, the bricking process is intiated.
We cycle through our BCT entries, checking if they are already “bricc’d” as rajkosto calls it, since we only ever want to apply the bricking procedure to valid data. It is reversible but we can only use the code above to unbrick it if it was bricked in a very specific way so this is a very sane check to perform. (220-225)
If we reached this point in the code we know we are good to brick. So let’s do that! In a loop that refuses to end until we have successfully bricked the Switch, we generate a pseudo-random number, AND it with 0xff and then write it to the position 0x10 of our BCT data. Having done that, we calculate the sha256 hash of our data. If we get a mismatch, our data is correctly wrong (meaning corrupted) and we can exit the loop. (230-234)
Now that we have the data we want to write, all that is left is to write our changed data to the eMMC, which we do in line 236. If it succeeded, we also display a cheeky message to the user to let them know they just “GOT BRICC’D!”.
The rest of the code after the infinite loop is just fairly standard cleanup code, it will only ever be reached if the program or user decide to quit.
The good thing about the method used is that it both uses pseudo-random numbers to corrupt - making it indistinguishable from accidental corruption on a grander scale if someone were to try to find such a thing - and corrupts only data that is easy to reconstruct at any time, because the Switch always has a spare copy available in its fuses.
I like what I see here. If I wanted to brick my Switch on purpose, this would be a candidate for me.
Correction: After talking with rajkosto I saw why I misread the code that restores the data thinking it would only restore one (I mistakenly thought a break; statement broke more than it actually does.) This has since been fixed to accurately reflect the actual code.
From line 22 - the beginning of main function - to line 65 we take care of initializing the hardware and setting up the capability to interact with the eMMC. This is fairly standard stuff and looks a lot like what we find in Hekate.
From lines 67-74 we read in the BCT, the part that configures the boot procedure of the Switch. This is already important since that is what we’re going to corrupt in order to force the Switch to boot into RCM. No corrupting has happened yet, though.
From 76-88 we map out the BCT entries that are currently in use. This is done somewhat needlessly fancy but from a coders perspective it looks kinda cool. I wouldn’t expect anything else from rajkosto to be honest. ^^ This is gonna make things a little easier later on.
Now for the real meat:
From lines 90-119 we first read the correct SHA256 hash from the Tegra fuses so we know what correct output has to look like, then compare it to the current values’ hashes and display which ones are correct at this time and which ones are not.
Time to get bricking! Since this is a somewhat user-friendly program, it displays a menu in line 122. After that we enter an infinite loop. This isn’t as infinite as it sounds, quitting the program will end it. For our purposes that means the program will always return to this point after doing something.
After reading the buttons (line 124) we determine our course of action:
Pressing Power will safely exit the program (125+126) by skipping out of the infinite loop towards the end of the program.
If we press Vol+ (line 128) we begin the unbricking process:
If there are no valid BCT entries - we determined these earlier, remember? - we grab a known good public key from the BCT signature data. (lines 129 147) Otherwise we go through each key and, if we find a corrupt one, repair it under the assumption that it was corrupted using the very same method we will use later down the line in the bricking part of the code. (lines 150-177)
Now that we should have a known good key - we verify this in lines 180-187, quitting the program if we still don’t have one - let’s unbrick. We cycle through the BCT entries, skipping any entries that are already correct. The write of the correct data occurs in line 205, informing the user whether it worked or something went wrong.
Phew, that’s a load. There are quite a few checks and safety measures in place here to make sure we only do what we need.
After this, we have the code that most of you came here to see, starting in line 212: If the user presses Vol-, the bricking process is intiated.
We cycle through our BCT entries, checking if they are already “bricc’d” as rajkosto calls it, since we only ever want to apply the bricking procedure to valid data. It is reversible but we can only use the code above to unbrick it if it was bricked in a very specific way so this is a very sane check to perform. (220-225)
If we reached this point in the code we know we are good to brick. So let’s do that! In a loop that refuses to end until we have successfully bricked the Switch, we generate a pseudo-random number, AND it with 0xff and then write it to the position 0x10 of our BCT data. Having done that, we calculate the sha256 hash of our data. If we get a mismatch, our data is correctly wrong (meaning corrupted) and we can exit the loop. (230-234)
Now that we have the data we want to write, all that is left is to write our changed data to the eMMC, which we do in line 236. If it succeeded, we also display a cheeky message to the user to let them know they just “GOT BRICC’D!”.
The rest of the code after the infinite loop is just fairly standard cleanup code, it will only ever be reached if the program or user decide to quit.
The good thing about the method used is that it both uses pseudo-random numbers to corrupt - making it indistinguishable from accidental corruption on a grander scale if someone were to try to find such a thing - and corrupts only data that is easy to reconstruct at any time, because the Switch always has a spare copy available in its fuses.
I like what I see here. If I wanted to brick my Switch on purpose, this would be a candidate for me.
Correction: After talking with rajkosto I saw why I misread the code that restores the data thinking it would only restore one (I mistakenly thought a break; statement broke more than it actually does.) This has since been fixed to accurately reflect the actual code.
Last edited by mnemonicpunk,
Like I said the good and blessed open source brick and the evil and wretched tx way that you must be away because of reasons? Jajaja it's so funny to see that people just because is free and made from the community, even though the most problems come to people testing than the drm ones
I really don't know what to say about comments like this anymore, as the reason why they are simply not true have been reiterated many times over the course of this thread and other, similar threads and you willingly choose to ignore them to make this all about some kind of war or competition in your mind. It is not, I'll gladly take a similar look at TXs version of this if they release source and there is an interest for it.
the reason is the purpose of this thread as a whole, to show that they are drm and they are bricking!!! they are evil, but when the open source community does it, its good and nothing bad happens, that is why the gateway vs open source cfw was always awful, gateway got ahead for 2 years but the open source is the jesus of all our problems, thats how gbatemp is
Of course they are bricking. That's how this works. Without bricking AutoRCM would not function.
I never mentioned bricking, is about the evil drm vs the good open source, they could say that their method implies that you must do a twirl before doing it, and someone will have to say!!! ohhh god!! they are evil, they tell to do a twirl, I could fall
, and the open source says do 2 twirls, and the same people would be dude!!! I will do 3 twirls just in case, this thread is a fear inducing and hate inducing thread by how it was created, but well we will see things like this on the long run
This whole thread about a feature in the Tegra platform. the AutoRCM is quite simple since it loads something that is broken and panics to RCM mode. It's nothing more fancy than that.
https://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html - It's even explained here... This isn't a "OH NOES MY SWITCH IS BROKEN!" it's just an abuse of a bug.
Also AutoRCM doesn't corrupt your boot. It's just making a hash-mismatch.
https://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html - It's even explained here... This isn't a "OH NOES MY SWITCH IS BROKEN!" it's just an abuse of a bug.
Also AutoRCM doesn't corrupt your boot. It's just making a hash-mismatch.
Last edited by linuxares,
Right, but clueless people were bitching that AutoRCM was the final straw and that TX were definitely hitler (I'm paraphrasing).
Shoving paper clips into the side rails is dangerous, AutoRCM is relatively benign. You need to be wary about bricking your console no matter what you do, make sure you take a working backup of your switch mmc before you make any changes to it.
Last edited by smf,
Rickardo over at ReSwitched made this great graphical representation of the topic at hand. I particularly like the part where it says "Shit" before moving on to RCM.
Last edited by mnemonicpunk,
My favorite part is where it says it boots into Recovery Mode ModeRickardo over at ReSwitched made this great graphical representation of the topic at hand. I particularly like the part where it says "Shit".
Rickardo over at ReSwitched made this great graphical representation of the topic at hand. I particularly like the part where it says "Shit".
Yeah, it's funny how people choose words to push their opinions. It's doing what it's supposed to do, it's not anything to worry about. If you want you can always restore your emmc backup. If you mess around with your emmc without a backup, then you better start praying.
Ironically the SX jig is safer than a lot of methods people are using to get into RCM.
Last edited by smf,
Similar threads
-
-
-
@
Xdqwerty:
Is it safe to update a modded ps3?
Can I play online in pirated games? (with ps3hen either enabled or not) -
-
-
-
-
-
@
Xdqwerty:
@salazarcosplay, I used apollo save tool to activate my ps3 offline so i could play a game that wasnt working
-
S @ salazarcosplay:from what I understood. you load up the piratged game. you the clear the syscalls, then you play
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
