Homebrew Question Idea for a semi-permanent hack, is it doable?

[smf]

well auto rcm is perma I think, but something better than auto rcm would be good, because arcm bricks your switch to get into rcm

It doesn't brick anything. It stops the console booting up without going through RCM, which is good because it means you can never accidentally burn fuses.

Even with a "deep sleep", if the battery dies then you risk loading OFW and fuses getting burnt. This place will be full of "My kid brother charged my switch and turned it on "

I think that down the line there's gonna be NAND modification to enable permanent CFW.
It could be a "slightly" modified version of Horizon to be installed with Choixdujour (which would maybe also be slightly modified).

What makes you think that? The boot needs to be signed using keys that only Nintendo would appear to have. What do you know?

That sounds like a good way to corrupt your SD card.

It hasn't caused me any problems so far and my card is formatted with exfat. I close everything first and don't use the homebrew that seems to trigger the problems the most.

 

[ZachyCatGames]

It doesn't brick anything. It stops the console booting up without going through RCM, which is good because it means you can never accidentally burn fuses.

Even with a "deep sleep", if the battery dies then you risk loading OFW and fuses getting burnt.



What makes you think that? The boot needs to be signed using keys that only Nintendo would appear to have. What do you know?

autorcm does brick the system. It modifies BOOT0 which causes the system to boot into RCM because the signature on BOOT0 is invalid

 

[smf]

autorcm does brick the system. It modifies BOOT0 which causes the system to boot into RCM because the signature on BOOT0 is invalid

No, forcing into RCM isn't a brick. It just forces into RCM, like you want it to.

AKA Recovery mode loop.

 

[ZachyCatGames]

No, forcing into RCM isn't a brick. It just forces into RCM, like you want it to.

It forces RCM by bricking BOOT0

 

[smf]

It forces RCM by bricking BOOT0

No, that isn't what bricking means.

 

[ZachyCatGames]

No, that isn't what bricking means.

ffs. It boots into ReCovery Mode because something went wrong. It is a brick

 

[smf]

ffs. It boots into ReCovery Mode because something went wrong. It is a brick

Apparently not, RCM is working quite well.

The word brick comes from being about as useful as a brick, i.e. the device doesn't do anything. Used correctly the effect is permanent and you may as well throw it away.

It started getting thrown around here as a pejorative term for auto rcm because it was something that TX supported and everything they do is bad because of reasons.

It's not a brick, it's a recovery mode loop (that you want). If you don't want to always boot into recovery mode then don't use autorcm, just get a jig and do the key combo.

 

[Zumoly]

Apparently not, RCM is working quite well.

The word brick comes from being about as useful as a brick, i.e. the device doesn't do anything. Used correctly the effect is permanent and you may as well throw it away.

It started getting thrown around here as a pejorative term for auto rcm because it was something that TX supported and everything they do is bad because of reasons.

It's not a brick, it's a recovery mode loop (that you want). If you don't want to always boot into recovery mode then don't use autorcm, just get a jig and do the key combo.

I think you're on the same page with this one.
I assume he's referring to "brick" as being "corrupted" or "malfunctioning".

 

[ZachyCatGames]

Apparently not, RCM is working quite well.

The word brick comes from being about as useful as a brick, i.e. the device doesn't do anything. Used correctly the effect is permanent and you may as well throw it away.

It started getting thrown around here as a pejorative term for auto rcm because it was something that TX supported and everything they do is bad because of reasons.

RCM is a feature intended to allow device manufacturers to recover systems from a soft-brick. If the bootloader is corrupt/bricked in some way it’ll automatically boot into RCM, with autoRCM we’re simply taking advantages of that by intentionally partially bricking BOOT0

 

[smf]

If the bootloader is corrupt/bricked in some way it’ll automatically boot into RCM

Again. The bootloader isn't bricked, the BCT is changed so that the checks fail and it boots into RCM.

Calling it a brick is inaccurate and scares people off.

 

[ZachyCatGames]

Again. The bootloader isn't bricked, the BCT is changed so that the checks fail and it boots into RCM.

Calling it a brick is inaccurate and scares people off.

If you think its not a brick, then it would be fine to use it on a patched systems? Right?

 

[Zumoly]

not possible

For now.

Check this out: https://gbatemp.net/download/nsscreenshotmaker.33800/

 

[Zumoly]

snip

 

[Draxzelex]

For now.

Check this out: https://gbatemp.net/download/nsscreenshotmaker.33800/

This just signs pictures and it doesn't use the same key that is used for the NAND.

 

[ZachyCatGames]

For now.

Check this out: https://gbatemp.net/download/nsscreenshotmaker.33800/

to install a modified version of Horizon you’d need Nintendo’s private key, which only Nintendo has

 

[aicjofs]

If you think its not a brick, then it would be fine to use it on a patched systems? Right?

Exactly.

As if Nintendo wanted users in RCM... the average user is sending it back to Nintendo. The APX mode(RCM) has been on Tegra since the beginning. If the CPU doesnt have something to boot(boot1 unreadable in this case) it starts the 3pserver. It use to be free and clear to access the 3pserver if you could just give it a bootable payload. As security progress the added SBK(keys) to download the payload and the average user didn't get them. We are fortunate in this case(this community), but if you need APX mode you are bricked. Recovery mode is for users, APX the factory, by design. I never post here but this back in forth is hilarious.

Anyway I don't think this idea is going to save you that much more time before battery is depleted. I mean it gets you an extra half day? A full day?

 

[sj33]

I don't think the semantics really matter in this case.

 

[Deleted User]

Atmosphere Boot to Payload or RCMReboot or if SX OS and ReiNX and that, then these too

 

[The Real Jdbye]

So guys, I was wondering about something so we don't have to do a manual RCM so often and that would render the hack almost permanent without using a chip (of course that's only if it's a possible thing).

Here's my idea, would it be possible to create a .bin payload that'd be a sort of deep sleep state for the Console, in that mode we could remove the SD card and charge the device, it would also have to consume the least possible amount of power, then when we would press the power button the payload would load another payload like say ArgonNX or Hekate so we can boot normally to any payload we want?
Since there's now a way to reboot to a certain payload we'd simply have to reboot to that deep sleep payload instead of powering off our consoles and we'd never have to do a manual RCM except if the consoles batteries are totally depleted...

So yeah this is a question thread, I'm only wondering if this is a possible thing, only answer if you have a clue about what you're talking about...

That's a good idea. There seems to be some trouble with freezing when underclocking the CPU heavily (although maybe that's just an issue with HOS), so it might not actually save that much power vs. normal sleep mode, but any savings is good.

 

[smf]

If you think its not a brick, then it would be fine to use it on a patched systems? Right?

It is fine on a patched system to get you into RCM on every boot. RCM will just reject fusee gelee, but if you have another exploit or signed files then that isn't a problem.

If you don't then you can say that autorcm bricks a patched system.

 

[Diablos90]

It is fine on a patched system to get you into RCM on every boot. RCM will just reject fusee gelee, but if you have another exploit or signed files then that isn't a problem.

If you don't then you can say that autorcm bricks a patched system.

AutoRCM is a permanent (but reversible) corruption of BOOT0 that force the console to enter into RCM. Now it can be enabled from Hekate, but at the beginning this could be achieved through a payload named briccmii (the name says it all); so, AutoRCM can be considered a "soft brick".

If for every reason a patched Switch should find itself with a corrupted BOOT0 (in the same way as AutoRCM corrupts it), it can't be fixable and this can be considered a "full brick" (probably fixable only by Nintendo).