Hacking Question PreventGCUpdate using hekate_fspatches_v3 or use ctcaer 4.0 and SX OS question

[thatrunks]

Hi all, sorry for the somewhat confusing thread title but I will try to clarify.
I have (or had in this case) a Switch on 3.0.1. After a lot of reading here on gbatemp.net and looking at some YouTube tutorials on how to use hekate,
I first tried to use hakete and did a rawnand dump on a 16 GB SDHC card (FAT32 formatted), but after some partial dumps I got some errors copying the files over to my computer and didn't trust it.

So I bought an 64 GB Evo Plus SDXC card. And formatted in the exFat file system. Injected the hakete payload (fspatches_v3) did a complete rawnand dump verified it and I dumped my keys with biskey and stored it in a couple of safe places.
Then I used this tutorial

to update my Switch to 5.1.0 without 'damaging the fuses'. On 3.0.1. it was on fuse count 4, using the ChoiDujourNX method to update the firmware to 5.1.0 I still have the fuse count at 4.

But I have some questions. I know that I am now on autorcm and need to inject a payload everytime (or I can just leave it at hakete's mode to charge or in the CFW (PreventGCUpdate) in the dock to charge.
I have an SX OS license that I would like to use. But I am a bit hesitant to inject the SX payload because I don't know if that is using the PreventGCUpdate which I am currently using now via hekate's so that the game card reader firmware is NOT being updated. Does anyone know if this is the case?

Also is there a difference between hekate_fspatches_v3 and the newer one from ctcaer 4.0 ? Because in the newer one it doesn't ask me about the hekate_ipl.ini. But in that ini the PreventGCUpdate is entered, but in the ctcaer 4.0 is this ini file still being used? Do I need to use ctcaer 4.0 or can I just use hekate_fspatches_v3?

 

[cherup]

As long as you are on autorcm you are save. You can inject the SX OS Payload without any problem.

It's only if you disable autorcm and boot into horizon that the fuses are burned. Not fully sure if this will happen every time if you boot into Horizon or only the first time... to be save stay on autorcm...


Gesendet von meinem SM-G950F mit Tapatalk

 

[PRAGMA]

Wait so the bug with AutoRCM that prevents charging is fixed?

 

[Garou]

As long as you are on autorcm you are save. You can inject the SX OS Payload without any problem.

It's only if you disable autorcm and boot into horizon that the fuses are burned. Not fully sure if this will happen every time if you boot into Horizon or only the first time... to be save stay on autorcm...

if I understand correctly, OS was asking if SX OS will burn the game cartridge "fuse" or not, not the switch fuse

 

[cherup]

Rright, and SX OS won't burn any fuses. So no problem for using it in that scenario.

 

[thatrunks]

if I understand correctly, OS was asking if SX OS will burn the game cartridge "fuse" or not, not the switch fuse

Thats right. Well I dont know if the game catridge reader firmware has a fuse but if I ever would like to downgrade I will need to always start the system with hekate via the PreventGCUpdate option so that the game card catridge reader controller firmware wont be updated.
But if I inject the sx payload I cannot use hekate's payload to use the PreventGCUpdate..

Guys thank you for your reply.

I mean the following;

I am using PreventGCUpdate via hekate so that the game card catridge reader controller firmware is not being updated.

See:

Q: I've never run firmware 4.0.0 or higher on my switch, so my gamecard controller firmware is still not updated. How do i make sure my gamecard controller works after i downgrade back to < 4.0.0 ?



A: When flashing the firmware image for any 4.0.0 or later firmware, ChoiDujourNX will generate a protective hekate_ipl.ini on your microsd, with a "PreventGCUpdate" launch target. You must ALWAYS boot using this launch target (or add kip1patch=nogc to any launch target you wish to use in the future) and use a Hekate that supports the kip1patch option () if you want to prevent use and updating of your GC controller firmware on firmware versions 4.0.0 and up.

But the problem is I dont know if I inject the SX os payload it will update the game card catridge reader controller firmware will be updated because I wont use hekate's PreventGCUpdate method.

Does anyone know how to load the PreventGCUpdate and inject the payload of sx os afterwards?
Or is there a way to implement the PreventGCUpdate into the sx payload?

 

[Garou]

there are conflicting reports here https://team-xecuter.com/forums/threads/154310-Does-SX-1-4-Ignore-Cartridge-Port-FW-Updates-on-Boot
also SX OS does not support custom kip so you can't use the no GC kip file on SX OS

 

[thatrunks]

Thanks for pointing me into the right direction.
So the safest to do for now is not using SX os until they come up with an solution for this of their own.
Many thanks!

Sent from my MI MIX using Tapatalk

 

[thatrunks]

Well for some reason I think I screwed something up.
I had to use hekate_ctcaer_4.0 because I could not get the homebrew app to come up via R+ Album
But I now understand that the hekate IPL ini is in the bootloader for this version.
And there it was on kip1patch=nosigchk instead of kip1patch=nogc,nosigchk so I changed that but. The game card catridge reader now work on 5.1.0.
Does this mean that the firmware of the game catridge reader has been updated?

If it has I would like to do an downgrade back to 3.0.1 and do a OFW update to lets say 4.1.0 via a game card and then do a new rawnand backup.
Does this make sense for you guys? Because if the game catridge controller firmware has been upgraded (how can I check that) I don't know if the rawnand backup from 3.0.1 is worth anything now.

Please advise?

 

[Draxzelex]

It sounds like it has been updated because we prevent it from updating by breaking the cartridge slot on firmwares 4.0 and higher. But just because the gamecart slot has been updated, the 3.0.1 backup is still useful as long as your fuses weren't burnt. The only way this could happen is if you turn on the console without a bootloader that protects the fuses such as Hekate, ReiNX, and SX OS V1.1+ (V1.2+ has the fuse bypass added).

 

[Scitzo]

Drax is, as ive seen more often than not, correct. No, your older fw dump is not useless -if your fuses have remained the same-. If they are still the same count, then you can safely restore the backup, and then remain there or upgrade again to a different fw version. Thats the beauty of upgrading without blowing the fuses.

 

[thatrunks]

Hi guys thanks for your reply. OK, so no useless raw nand backup then. Great! My fuse count is 4 (checked it after Choidujournx) via Hakete. According to the firmware table on the wiki I can downgrade back to 3.0.1 (just tested and upgraded back to 5.1.0 and still on fuse count 4).
Thank you Draxzelex for the info and the rest of the guys. Yes autorcm is enabled so I keep it on hekate's payload and on power to prevent a battery drain. Will be testing with SX Os this week now that the firmware of the game catridge reader has been updated. Too bad we wont know for sure if SX OS blocks that update.

 

[bundat]

Well I dont know if the game catridge reader firmware has a fuse

I used to think it's a GC "fuse" as well, as downgrading cart FW was implied to be impossible.

However, even though you may have accidentally updated your GC FW to cart v2, it seems there is still hope
(from CTCaer, the dev who is currently maintaining the latest Hekate fork, so this info MUST be reliable):

There is a way to actually revert the GC firmware.

Although it's not something we can expect "soon" though:

So does this mean we can finally say goodbye to nogc?

Not so easy. Because the fw can be forced updated, it doesn't mean that the whole process is already REd.
But you never know..

---

@CTCaer , can you please elaborate on reverting the GC firmware more? Or soon(TM)?

Not soon unfortunately. The data at hand is not complete

At least, it's nice to know that it MIGHT eventually be possible.