Hacking [RCM Payload] Hekate - CTCaer mod

  • Thread starter Thread starter CTCaer
  • Start date Start date
  • Views Views 1,186,190
  • Replies Replies 3,330
  • Likes Likes 128
@CTCaer So EMMC password perma-disabling coming soon? Hopefully the rise of being able to do such a thing so easily doesn't cause a certain company to get any more ideas of better ways to make a console not work. ;)
 
Not yet. But you can compile it
or use the other payload that fixes this. It does the same thing.
payload seems to be working my games now still running at 39% so im happy it seemed to work but wats this thing about clock resetting? does it affect anything do u know
 
@CTCaer So EMMC password perma-disabling coming soon? Hopefully the rise of being able to do such a thing so easily doesn't cause a certain company to get any more ideas of better ways to make a console not work. ;)
Yep. But they can still wipe the emmc. Or other malware-style things. Like fuse burning, big voltages that can fry, SoC, eMMC, SD cards, etc..

payload seems to be working my games now still running at 39% so im happy it seemed to work but wats this thing about clock resetting? does it affect anything do u know
Because the battery is disconnected internally from the main system, the RTC clock loses power and may reset the time/date.
As far as I know, switch does not have any capacitor to keep powering this when no power from battery exists.

It's nothing weird though. Just manually update it from settings.
If you have the auto update time/date from network, it will fix itself.
 
A real release will take some time.
Maybe I'll manage tomorrow, but I don't know really.

I need to finalize the restore feature.
The battery info feature.
The backup/restore verification algorithm.
And recheck for a 10th time the autoboot/configuration feature.
 
Just to confirm,
-there isn't a release yet with 100% reliable backup verification?
-but it's planned for the next release?

If so I'll gladly wait. Cheers.
That's correct.

The current releases are actually 0% reliable on the verification matter.
Basically the verification is mostly skipped.

Next release will have 2 ways to verify.
* A full 100% reliable and slow (12MB/s).
* A fast one that checks only for block corruptions (57MB/s).
 
Last edited by CTCaer,
Eek, so is there another backup method/payload with working verification in the meantime? Not linux please I don't wanna have to disconnect the battery again.
 
hi guys just trying to backup my nand using this tool before i do any messing around with the switch,but when i go to dump my nand i get the error message:failed to init sd card make sure it is inserted.i have tried a sandisk ultra 64gb micro sdxc card and samsung evo 32gb micro sdhc card both with same results.i have formatted both cards to fat32 and still no luck.i am using the latest hekate payload and am on firmware 5.1.0.
 
hi guys just trying to backup my nand using this tool before i do any messing around with the switch,but when i go to dump my nand i get the error message:failed to init sd card make sure it is inserted.i have tried a sandisk ultra 64gb micro sdxc card and samsung evo 32gb micro sdhc card both with same results.i have formatted both cards to fat32 and still no luck.i am using the latest hekate payload and am on firmware 5.1.0.
Happen to me too ,i just change the cluster size from 32 to 16 and it worked.
So try changing it
 
  • Like
Reactions: steplay29
Cheers, and thanks to you for updating this tool.
I want to let you know there may be a timing bug.

I dumped my rawnand onto a 256 GB Sandisk Ultra SDXC, and it took almost 210 minutes (3.5hours)
I captured the confirmation screen, which i've attached, and it displays 3086 seconds, which is about 51 minutes.

So to be clear, the potential bug is that there's a timer running somewhere, which recorded 3086 seconds, but the actual time to dump/verify was over 4x that amount.

I also thought 4 hours was a little long, so there could be something else going on. I may have done something wrong.
I was checking it every few minutes throughout, as I was concerned with the battery dying during the process.

*EDIT* I'm just realizing that perhaps the dump was indeed 51 minutes, but the verify took an additional 2.5 hours beyond that and wasn't tracked. So maybe it's not a bug after all.
I have no way to check at what time the verification started without repeating the process.
 

Attachments

  • IMG_8799.jpg
    IMG_8799.jpg
    317.3 KB · Views: 228
Last edited by 1LastRide,
  • Like
Reactions: CTCaer
Cheers, and thanks to you for updating this tool.
I want to let you know there may be a timing bug.

I dumped my rawnand onto a 256 GB Sandisk Ultra SDXC, and it took almost 210 minutes (3.5hours)
I captured the confirmation screen, which i've attached, and it displays 3086 seconds, which is about 51 minutes.

So to be clear, the potential bug is that there's a timer running somewhere, which recorded 3086 seconds, but the actual time to dump/verify was over 4x that amount.

I also thought 4 hours was a little long, so there could be something else going on. I may have done something wrong.
I was checking it every few minutes throughout, as I was concerned with the battery dying during the process.
You are actually the first one to notice that actually :P
Yeah there's a bug where a 32bit microseconds timer was used (max is 71minutes before resetting).
It's already fixed in upstream by implementing a seconds timer.
https://github.com/CTCaer/hekate/co...39#diff-799c7cc4c061751437d68637b5d9ae27R1177

It took so much time because there's also another bug with the verification, which is not working correctly actually.
But I assume your eMMC was mostly empty, so it had a lot of 00s and the verification somewhat continued to verify.
This bug is also fixed in upstream and the algorithm was also changed to use hw accelerated sha256 or a sparse checking.
So the new version can finish the verification in 8 minutes (sparse) or 44 minutes (full - sha256). These times are without reading from eMMC/SD. It's only the compare time.
The old algorithm was using memcmp for all of this. And when it somewhat worked, it could take up to 4.5hours
 
Last edited by CTCaer,

Site & Scene News

Popular threads in this forum