Hacking Discussion Bricking your Switch on purpose or: How AutoRCM works
- Thread starter mnemonicpunk
- Start date
- Views 65,666
- Replies 178
- Likes 51
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.
D
Deleted-394630
Guest
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.
I get it, but how is that any different from arm9loaderhax-haxxed 3DS systems that won't boot without an inserted SD card?
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.
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.
With a9lh you were able to revert to stock using a NAND backup, with AutoRCM you can't.
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.
You can uninstall the change at any time.
--------------------- MERGED ---------------------------
See .
Attachments
Similar threads
-
-
-
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
32GBs is the baseline for 4K video editing these days and lots of recommendations for 64GBs but for games 16,GBs is honestly plenty for a long time. -
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
Some sort of police thing going on near me lol "Get out of the car with your hands up and walk backwards towards us" over a loud speaker thing
-
-
-
