do not udpate Rocket League
he he heHacking Sigpatches for Atmosphere (Hekate, fss0, fusee & package3)
- Thread starter ShadowOne333
- Start date
- Views 2,174,481
- Replies 3,351
- Likes 245
he he he
hello do you think you could help me with the error in nxdump tool error findkeyinprocessmemory: unable to locate key'headere_key_source in process memory thanksdo not udpate Rocket League
Yes I did all of that I generated the product keys and everything and no matter what I do I get that error that I showed you That says it couldn't find the process header key
Post automatically merged:
Just so you know it works fine on the cfW emunand but not on the system nand that I accidently updated to the 17.0 fw
Post automatically merged:
Yes notice that you said pick lock 1.9.11 where do I get that from I have pick lock 1.9.10
hey i found the picklock rcm 1.9.11 on a french website and an update to tegra explorer installed these ran picklock 1.9.11 the nxdump tool i was originally using no longer works but i found an updated version called nxdt_poc.nro which is 2.0 of nx dump tool and it works just fine thank you for all your help i am up and running for the most part now the only issues are when i need to use the cfw sysnand i need to put it in flight mode because the internet is crashing my system the program causing it is a system program called nim the id is 0100000000000025 but for now the work around is flight mode and i also need to uninstall my themes before going into cfw sysnand as there is no theme support right now hopefully these things will be fixed but at least i have functioning work arounds again thank you so much i will definiatly be more careful in the future and not just push buttons
you didn't need to french sites
here on gbatemp there is the official link to PickLock 1.9.11
Post automatically merged:
And latest release of NxDumpTool ( https://github.com/DarkMatterCore/nxdumptool/releases ) is FW 17 compatible.
Last edited by impeeza,
Judging by the to-do list of Atmosphere, I’d say it added plenty….more on the under the hood stuff rather than anything useful. Enough to give SciresM a huge headache as well as other devs.
Post automatically merged:
I think that was the intention. It WAS a big update despite speculation to the contrary. The big updates were to under the hood kinda things rather than anything an end user would notice. From my understanding, they changed quite a bit how the Switch works.Relax, I was merely asking how long it takes on average for new sigpatches to be releases after an update. I wasn't asking with the intention of having these people hurry up or anything like that.
Good to know. I guess there are issues this time then. Wasn't aware this was such a big update. Goes to show that not everyone reads changelogs, I guess...
Post automatically merged:
That’s what I do. Use EmuNAND for CFW and daily driver, stock nand to download updates, and SysNAND CFW simply to dump them. I never install anything onto SysNAND because at least if something messes up on EmuNAND, I can just make a new one. Can’t exactly do that with SysNAND. It’s a more involved process. Gives me peace of mind. Been doing that since the Wii days.
Last edited by skydancer93,
oh i didnt know that when i googled it the french one was the only one that came up and the nxdumptool link you posted that is the one i updated to thank you again so much for your helpyou didn't need to french sites
Post automatically merged:
And latest release of NxDumpTool ( https://github.com/DarkMatterCore/nxdumptool/releases ) is FW 17 compatible.
If I don't tell bullshit fs patch is now ready to do.
https://github.com/mrdude2478/IPS_Patch_Creator
https://github.com/mrdude2478/IPS_Patch_Creator
The update of the soft was yesterday on GitHub, the post you mention was Wednesday.
Still the package isn't done. The ldr partition isn't patched yet. Even the dev (mrdude) say so.
Haven't turned on any of my Switch systems since Pikmin 4. Looks firmware 17.0 is causing a bit of an issue for of mod Gods.
goodmorning at all,
i have found this: https://github.com/exelix11/dvr-patches/releases
but i don't know if it right...
i have found this: https://github.com/exelix11/dvr-patches/releases
but i don't know if it right...
No they are not the sigpatches that belong in this thread, they are patches for something totally unrelated so don't bother with these unless you know what they are for.
This is a exefs patche use for contents sysdvr.It doesn't use for install or run game.
Can someone elaborate on what the difference is between these sigpatches. Why do different parts of the system need a different sigpatch?
In my understanding signed software uses a asymmetric cryptography validate the binaries.
So that would mean that different parts are signed with different private keys? And therefor we have to patch these different parts?
In my understanding signed software uses a asymmetric cryptography validate the binaries.
So that would mean that different parts are signed with different private keys? And therefor we have to patch these different parts?
Firmware is made up from hundreds of compressed different files. The sigpatches look at the sha256 value of the unpacked file that we want patch, and then jump to the address (shown in the ips patch) in the decompressed file and then patch it with a new arm64 instruction.
For example say we have an address in the decompressed file that contains a boolean (true or false) we want to patch. if it's true do this - or false do that, to force the code to do what we want we can set the value with a patch and the instruction will always do what we want.
I suggest you make some small computer programs so you know how they work, then decompile them and load them into ida or ghidra so see how they look dissasembled, then make a small change to the source, recompile and then do the same again to see what's changed in the dissasembled file - you'll see instructions that have changed, to prevent you needing to upload a new binary with the changes - you just upload an IPS patch to make the changes to those instructions you modded. Now if your files were massive and you only changed 1 byte, it's easier/faster to upload a patch than a whole new massive file.
Now here's an example, for atmosphere loader sigpatch:
We can set this value to "false", that way we can skip needing an ips patch for the loader and can then run nro formwarders, however obviously people want to get the original file from source, so we can just make a patch to do the same thing and distribute that - hence the need for ips patches. Other things in these patches are for switch fimware to skip checks these are es/fs patches but we don't have the source for these and it's illegal to mod the original files and share the copyrighted code, hence the need for patches.
Last edited by mrdude,
Similar threads
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
NinStar:
I bought a pair of joy cons for really cheap, but the right side wasn't being detected by the console when attached to it, it was charging though -
@
NinStar:
I took a look at the rail and noticed that the two last pins were soldered for some reason, luckly I still had the rail of my broken joycon so after I swapped them I was able to use it attached to the console
-
@
NinStar:
I'm pretty sure I know the reason it was soldered, but I don't know why someone would do that directly on the joycon
-
-
-
-
-
-
-
-
