I'm not sure anybody would want to beta test this feature thoughnot really, a very exact "break" to trigger rcm at boot isn't really "dangerous" and should be easily reversible if/when you don't want it any more
sure if people are concerned about not having a way to boot the system while out assuming devs fix sleep mode and stuff then it would be a really neat solution, its just a matter of personal choice, and I'm sure it wont be long for someone to make a TX style standalone dongle for use when out and about
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.Does it a way to modify the boot rom on horizon? If it possible, some asm can made a goto an specific address?
- 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'm sure someone could rig up their emmc to allow direct nand restores to cover all eventualities, but afaik nand restores can be done from within rcm mode so I don't see why it would be any more dangerous than booting into rcm mode normally as long as people have a valid nand backupI'm not sure anybody would want to beta test this feature though
As long as the AutoRCM is installed on your system you can not switch back to the original firmware. It will simply refuse to boot.
Flipping one bit anywhere in the bootchain will result in failed checks and a "corrupted" state. This will not render stock FW unbootable, but you will need to use an internal modchip, an external dongle, a phone, or a PC to boot the console. Stock, CFW, or Linux doesn't matter.As long as the AutoRCM is installed on your system you can not switch back to the original firmware. It will simply refuse to boot.
The people over at ReSwitched have considered the possibility of doing this weeks ago and discarded it so far because they were worried they would fuck up someones Switch permanently. And those are the people writing AMS, the fusee gelee launcher, TegraRCMSmah, libnx and so on.
The main question is this: Did Team Xecuter implement it in an entirely safe and removable way? The honest answer is: I don't know.
Sorry to break your dream but there is some high level devs/hackers in TX, I mean more talented than reswitched members an such.As long as the AutoRCM is installed on your system you can not switch back to the original firmware. It will simply refuse to boot.
The people over at ReSwitched have considered the possibility of doing this weeks ago and discarded it so far because they were worried they would fuck up someones Switch permanently. And those are the people writing AMS, the fusee gelee launcher, TegraRCMSmah, libnx and so on.
The main question is this: Did Team Xecuter implement it in an entirely safe and removable way? The honest answer is: I don't know.
well the CFW could just automatically patch the byte change to correct it in the eyes of the system, assuming everyone gets their ducks in a row and agree on a unified brick process (assuming a few different CFWs/loaders end up being releasedThe real question is, once you've booted into Horizon with this "corruption" are you likely to be easily detectable for a ban?
That is how I hope they plan to do it. We'll see how transparent they are about their process going forward.This is actually not a terrible idea. Technically A9LH also worked by corrupting the boot partition (firm) although corrupting it in a very specific way. And that was still insanely popular with few bricks reported, fewer as time went on and the process was perfected.
The simplicity of this method (you literally only need to change a single byte) means there's also less that could go wrong and restoring the system to OFW is easier. So easy that you wouldn't even need a backup. Even if you don't know what the original byte was, worst case you would have to try editing the corrupted byte 256 times to find it. Which is kind of a pain but it could be automated by a RCM payload.
Of course you'd still need a dongle or a PC/phone and a cable/OTG adapter every time you wanted to boot, so it's a bit of a hassle and not true coldboot. But it does make the process slightly easier and you don't have to worry about misplacing/losing your jig since you won't be needing it more than once (and those things are tiny and easy to lose)
It could but how likely is TX to actually do it and how would we even find out with it being closed source :/well the CFW could just automatically patch the byte change to correct it in the eyes of the system
well you dump the nand after their patch is done and compare it, but from the TX description it sounds like they have a totally automatic solution that would be effectively dongle free......idk how they done it (assuming they aren't being a little deceptive and that's only on certain firmwares)It could but how likely is TX to actually do it and how would we even find out with it being closed source :/
TX specifically states that you will still need the dongle. What you don't need is the jig and to hold Vol+ while booting.well you dump the nand after their patch is done and compare it, but from the TX description it sounds like they have a totally automatic solution that would be effectively dongle free......idk how they done it (assuming they aren't being a little deceptive and that's only on certain firmwares)
ahhhhhh ok, that was what I was thinking initially but then misread the quote before, that makes much more senseTX specifically states that you will still need the dongle. What you don't need is the jig and to hold Vol+ while booting.
Yes, disconnecting the eMMC is another way of entering RCM.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 I read correct in another thread TX cfw won't allow online at the moment.The real question is, once you've booted into Horizon with this "corruption" are you likely to be easily detectable for a ban?