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

Discussion in 'Switch - Exploits, Custom Firmwares & Soft Mods' started by thatrunks, Aug 31, 2018.

  1. thatrunks
    OP

    thatrunks Newbie

    Newcomer
    1
    Dec 20, 2013
    Netherlands
    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?
     
    Last edited by thatrunks, Aug 31, 2018
  2. cherup

    cherup Member

    Newcomer
    3
    Jan 10, 2016
    Gambia, The
    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
     
    thatrunks likes this.
  3. PRAGMA

    PRAGMA GBAtemp Advanced Maniac

    Member
    11
    Dec 29, 2015
    Ireland
    127.0.0.1
    Wait so the bug with AutoRCM that prevents charging is fixed?
     
  4. Garou

    Garou GBAtemp Maniac

    Member
    6
    Jan 13, 2015
    if I understand correctly, OS was asking if SX OS will burn the game cartridge "fuse" or not, not the switch fuse
     
    thatrunks likes this.
  5. cherup

    cherup Member

    Newcomer
    3
    Jan 10, 2016
    Gambia, The
    Rright, and SX OS won't burn any fuses. So no problem for using it in that scenario.
     
    thatrunks likes this.
  6. thatrunks
    OP

    thatrunks Newbie

    Newcomer
    1
    Dec 20, 2013
    Netherlands
    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:
    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?
     
    Last edited by thatrunks, Sep 1, 2018
  7. Garou

    Garou GBAtemp Maniac

    Member
    6
    Jan 13, 2015
    thatrunks and fatterdude2000 like this.
  8. thatrunks
    OP

    thatrunks Newbie

    Newcomer
    1
    Dec 20, 2013
    Netherlands
    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
     
  9. thatrunks
    OP

    thatrunks Newbie

    Newcomer
    1
    Dec 20, 2013
    Netherlands
    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?
     
  10. Draxzelex

    Draxzelex GBAtemp Guru

    Member
    17
    Aug 6, 2017
    United States
    New York City
    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).
     
    thatrunks likes this.
  11. Scitzo

    Scitzo Member

    Newcomer
    2
    Sep 1, 2018
    United States
    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 likes this.
  12. thatrunks
    OP

    thatrunks Newbie

    Newcomer
    1
    Dec 20, 2013
    Netherlands
    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.
     
    Last edited by thatrunks, Sep 2, 2018
    Garou and Draxzelex like this.
  13. bundat

    bundat ¿

    Member
    4
    Jul 25, 2018
    Antarctica
    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):
    Although it's not something we can expect "soon" though:

    At least, it's nice to know that it MIGHT eventually be possible.
     
    Last edited by bundat, Sep 3, 2018
    klear, charlieb and thatrunks like this.
Loading...