Hacking [RCM Payload] Hekate - CTCaer mod

  • Thread starter Thread starter CTCaer
  • Start date Start date
  • Views Views 1,195,841
  • Replies Replies 3,331
  • Likes Likes 128
@CTCaer Sorry to bother you again, but I've got another mind-numbing and possibly redundant question. Does Hekate wipe all of the traces of booting outside of the normal bootloader therefore making all bootups into CFW or OFW look as normal as possible? If yes, I have a follow-up question that you do not have to respond to if you do not wish to. I'll even edit the second question out if you do not provide a response to it as an answer to the first question is sufficient.

Does the SX OS Loader perform the same wiping that Hekate does?

In case you or anyone else is curious, I'm asking because I'm trying to rationalize why people are being banned for using SX OS completely offline as opposed to Hekate/Atmosphere (so far).
 
@CTCaer Sorry to bother you again, but I've got another mind-numbing and possibly redundant question. Does Hekate wipe all of the traces of booting outside of the normal bootloader therefore making all bootups into CFW or OFW look as normal as possible? If yes, I have a follow-up question that you do not have to respond to if you do not wish to. I'll even edit the second question out if you do not provide a response to it as an answer to the first question is sufficient.

Does the SX OS Loader perform the same wiping that Hekate does?

In case you or anyone else is curious, I'm asking because I'm trying to rationalize why people are being banned for using SX OS completely offline as opposed to Hekate/Atmosphere (so far).
Yes and no. Here's why/how:

Boot reason is cleared. HW config is the same with nx bootloader. Package2 could be identified though (*). It's where all these kips, kernel, etc go.
*But it cannot actually be identified (currently) anyway. The reason is that the secure monitor which is the only thing that has the permissions to check them, is patched before boot.
There are other things that get cleared also and make the boot look like a normal boot, but I can't remember them (even though I was cross-checking some things 2 days before for my linux chainloading).


The sx os loader does some things differently though.
What I know and remember are these:
For example, they didn't even have the basics on launch. A day-one hekate feature; Disable fuse programming.
Also the initialization of DRAM and LP0 (for sleep mode), is actually the coreboot's routines and binaries, copy pasted.
Some configuration from this differs with hekate/nxbootloader.
And also some other configuration.
 
Yes and no. Here's why/how:

Boot reason is cleared. HW config is the same with nx bootloader. Package2 could be identified though (*). It's where all these kips, kernel, etc go.
*But it cannot actually be identified (currently) anyway. The reason is that the secure monitor which is the only thing that has the permissions to check them, is patched before boot.
There are other things that get cleared also and make the boot look like a normal boot, but I can't remember them (even though I was cross-checking some things 2 days before for my linux chainloading).


The sx os loader does some things differently though.
What I know and remember are these:
For example, they didn't even have the basics on launch. A day-one hekate feature; Disable fuse programming.
Also the initialization of DRAM and LP0 (for sleep mode), is actually the coreboot's routines and binaries, copy pasted.
Some configuration from this differs with hekate/nxbootloader.
And also some other configuration.
Alright, this does indeed confirm my suspicious based on the data that I have been collecting (although to say I was surprised would be an understatement). I also hope you don't mind me asking these questions in your thread (I can switch to PM) as I want to share the info I receive from your answers with everyone (that Wi-Fi one surprised a lot of people). All I have left to explain is why potentially some users were banned for using TX's AutoRCM as opposed to Hekate's but, once again, you don't have to answer that if you don't want to (I am being genuinely serious and this is not reverse psychology but if you got some insider info, my ears are always open ;))
 
Last edited by Draxzelex,
Alright, this does indeed confirm my suspicious based on the data that I have been collecting (although to say I was surprised would be an understatement). I also hope you don't mind me asking these questions in your thread (I can switch to PM) as I want to share the info I receive from your answers with everyone (that Wi-Fi one surprised a lot of people). All I have left to explain is why potentially some users were banned for using TX's AutoRCM as opposed to Hekate's but, once again, you don't have to answer that if you don't want to (I am being genuinely serious and this is not reverse psychology but if you got some insider info, my ears are always open ;))
If someone can be banned for a corrupted BCT, he can be banned for any flavor of it. So either all or none can be banned for AutoRCM.
 
  • Like
Reactions: Draxzelex
I am unable to restore a backup. Error (4) while opening backup
error 4 : happen to me too , in my case the files were not where are suposed to be.
for raw gpp :
backup/restore/rawnand.bin
for emms boot0/1 :
backup/restore/boot0 ,also boot1
for gpp partitions :
backup/restore/partitions/bcpkg2..... ,safe , system, ect ect
 
Last edited by mitcha,
Is it at all be possible to boot SXOS thru Hekate's "Launch Firmware" menu? Is this what the warmboot path options in the .ini would be used for (like creating an entry in the .ini with the path to sx_os_payload.bin on the SD card)? Apologies if this is explained elsewhere, I'm a little unfamiliar with the terminology and I'm probably way off with that assumption.

Thanks in advance for any answers. I know I can do this in reverse using SXOS's "External Payload" option to boot into Hekate, but I'd like to do it the other order.
 
Hi! I'm a TX OS user but I wanted to load Hekate CTCaer's NSwitchDebugger. But everytime I does that, whether it's through the TX OS's external payload loader or directly on my PC through TegramRCMsmash, I always get a "failed to launch firmware" message that prevents me from loading the CTCaer payload. Any idea why? Appreciate all help!
 
How to know you are with AutoRCM ON or OFF?

I cant boot to test and risk burning fuses

When I go to tool -> autoRCM it only askes if I want to toggle it and if I choose it always says toggled.
 
Is it at all be possible to boot SXOS thru Hekate's "Launch Firmware" menu? Is this what the warmboot path options in the .ini would be used for (like creating an entry in the .ini with the path to sx_os_payload.bin on the SD card)? Apologies if this is explained elsewhere, I'm a little unfamiliar with the terminology and I'm probably way off with that assumption.

Thanks in advance for any answers. I know I can do this in reverse using SXOS's "External Payload" option to boot into Hekate, but I'd like to do it the other order.
Possible? Yes. Will CTCaer do it? Eh...
 
Download briccmii and check
Too late.... I was expecting that since AutoRCM was always saying "AutoRCM Toogled!" that it was always on then.

Tried to boot without the my magnet and boom... Nintendo logo right away... fuses went from 2 to 6...

Sad losing a 2.0.0 console (was waiting for a coldboot) like that but oh well... at least now I dont need to worry about that anymore ¯\_(ツ)_/¯
 
Too late.... I was expecting that since AutoRCM was always saying "AutoRCM Toogled!" that it was always on then.

Tried to boot without the my magnet and boom... Nintendo logo right away... fuses went from 2 to 6...

Sad losing a 2.0.0 console (was waiting for a coldboot) like that but oh well... at least now I dont need to worry about that anymore ¯\_(ツ)_/¯

How to check how many fuses i've burnt?
 
does this Payload require any files on microSD? or we only need to load the payload via RCM?
i currently running SX OS 1.3 with 64GB and almost no free space

i'd like to insert new microSD/exFAT, directly load Hekate payload and dump NAND/RAW partition
is that sounds right? or do i need to prepare something first?

Thanks!
 
Ok, i'm using AutoRCM with CTCaer 3.2
What do i have to do to untoggle this feature? I've got both BOOT0/1 and rawnand.bin backup if needed.
Thank you.

(No i didn't brick or anything, everything is fine, just curious about this.)
 
Hi ctcaer, are you planing to support partial nand restoration for those of us with fat32 in the future or is it just not possible?
 

Site & Scene News

Popular threads in this forum