Hacking Sigpatches for Atmosphere (Hekate, fss0, fusee & package3)

  • Thread starter Thread starter ShadowOne333
  • Start date Start date
  • Views Views 5,305,289
  • Replies Replies 7,368
  • Likes Likes 266
When doing "payload=whatever" every other command you input is ignored.

you're effectively doing:


[Semi Stock (SYSNAND)]
payload=atmosphere/reboot_payload.bin

and as mentioned above, you've set hekate replace reboot_payload.bin with itself.
this is news for me!!!
Post automatically merged:

When doing "payload=whatever" every other command you input is ignored.

you're effectively doing:


[Semi Stock (SYSNAND)]
payload=atmosphere/reboot_payload.bin

and as mentioned above, you've set hekate replace reboot_payload.bin with itself.
Ok, I got this, on the Hekate readme is:

1748018530854.png


«Any key above when used with that, doesn't get into account.» and the above Keys are:
  • warmboot={FILE path}
  • secmon={FILE path}
  • kernel={FILE path}
  • kip1={FILE path}
  • kip1={FOLDER path}/*
  • pkg3={FILE path}
  • fss0={FILE path}
  • pkg3ex=1
  • pkg3kip1skip={KIP name}
  • exofatal={FILE path}
  • ----------------------
  • kip1patch=patchname
  • emupath={FOLDER path}
  • emummcforce=1
  • emummc_force_disable=1
  • stock=1
  • fullsvcperm=1
  • debugmode=1
  • kernelprocid=1

As I understand the text, that keys are ignored when you use Payload, but the others keys are indeed processed. the other keys are:
  • l4t=1
  • boot_prefixes={FOLDER path}
  • ram_oc=0
  • ram_oc_vdd2=1100
  • ram_oc_vddq=600
  • uart_port=0
  • sld_type=0x31444C53
  • Additional keys
  • ----------------------
  • bootwait=3
  • id=IDNAME
  • logopath={FILE path}
  • icon={FILE path}


Am I wrong?
 
Last edited by impeeza,
this is news for me!!!
Post automatically merged:


Ok, I got this, on the Hekate readme is:

View attachment 506352

«Any key above when used with that, doesn't get into account.» and the above Keys are:
  • warmboot={FILE path}
  • secmon={FILE path}
  • kernel={FILE path}
  • kip1={FILE path}
  • kip1={FOLDER path}/*
  • pkg3={FILE path}
  • fss0={FILE path}
  • pkg3ex=1
  • pkg3kip1skip={KIP name}
  • exofatal={FILE path}
  • ----------------------
  • kip1patch=patchname
  • emupath={FOLDER path}
  • emummcforce=1
  • emummc_force_disable=1
  • stock=1
  • fullsvcperm=1
  • debugmode=1
  • kernelprocid=1

As I understand the text, that keys are ignored when you use Payload, but the others keys are indeed processed. the other keys are:
  • l4t=1
  • boot_prefixes={FOLDER path}
  • ram_oc=0
  • ram_oc_vdd2=1100
  • ram_oc_vddq=600
  • uart_port=0
  • sld_type=0x31444C53
  • Additional keys
  • ----------------------
  • bootwait=3
  • id=IDNAME
  • logopath={FILE path}
  • icon={FILE path}


Am I wrong?
The other keys "below" doesn't really do anything when booting fusee, aside from icons and logos, it's cosmetic/vanity only,

the payload chainloading functionality cannot be used with all the other functions, purely placebo to keep it there.
 
Hey guys. Hmm.. i updated to 19.0.1 with atmosphere 18, but only 70 % of games working, updated sigpatches from oktober and also syspatch, what could be the problem?
Post automatically merged:

Hey guys. Hmm.. i updated to 19.0.1 with atmosphere 18, but only 70 % of games working, updated sigpatches from oktober and also syspatch, what could be the problem?
logs say noncasigchk_new and nocntchk2 unpatched
Post automatically merged:

Hey guys. Hmm.. i updated to 19.0.1 with atmosphere 18, but only 70 % of games working, updated sigpatches from oktober and also syspatch, what could be the problem?
Post automatically merged:


logs say noncasigchk_new and nocntchk2 unpatched
i just figured it out kip1patch=nosigchk - i deleted this, now syspatch is working...
 
Last edited by Danny1980,
  • Like
Reactions: bth
Hello! I've been trying to install NSP, that I dumped from my legally-owned digital titles in Stock, to my emuMMC using sphaira. I dumped them using these settings shown in the image below using nxdumptool. I was able to install it with sphaira when I dump the game with those settings, but the problem is that I know have an issue where I can't open the game. I get the "Checking software information..." message, and then I received Error 2155-8007. Does this issue stems from my sigpatches and syspatch? I downloaded the latest edition for Firmware 20.0.1. Or do I need to use sys-tweak instead?
 

Attachments

  • 20250525_115905.jpg
    20250525_115905.jpg
    660.9 KB · Views: 37
Hello! I've been trying to install NSP, that I dumped from my legally-owned digital titles in Stock, to my emuMMC using sphaira. I dumped them using these settings shown in the image below using nxdumptool. I was able to install it with sphaira when I dump the game with those settings, but the problem is that I know have an issue where I can't open the game. I get the "Checking software information..." message, and then I received Error 2155-8007. Does this issue stems from my sigpatches and syspatch? I downloaded the latest edition for Firmware 20.0.1. Or do I need to use sys-tweak instead?
I assume that you're using emummc and you dumped the game from sysmmc?

If that's the case, then you probably don't have the same account for both, hence why its trying to check if you own the game. The settings there indicate that you kept console specific data in check, meaning that the ticket is personalised (so its linked to your switch and account). With those tickets, it may be a temporary ticket, where it becomes invalid after some time or on a reboot.

As you're already patching es, you're better off re-dumping the game and removing the personalised data, then re-install. Do note that you will be banned when you install that title. But i assume you accept that as you're using patches.
 
I assume that you're using emummc and you dumped the game from sysmmc?

If that's the case, then you probably don't have the same account for both, hence why its trying to check if you own the game. The settings there indicate that you kept console specific data in check, meaning that the ticket is personalised (so its linked to your switch and account). With those tickets, it may be a temporary ticket, where it becomes invalid after some time or on a reboot.

As you're already patching es, you're better off re-dumping the game and removing the personalised data, then re-install. Do note that you will be banned when you install that title. But i assume you accept that as you're using patches.
Now it works! I must have missed up with the settings in which I remove console-specific data AND title-key encryption which made the installation failed back then. Thanks for the help!
 
Does "profile" means the "player account" in emuNAND atmopshere OS?
yes it does.
Post automatically merged:

Damn you Nintendo FW 20.1.0 RELEASED!!


Do not update yet! Wait for a next CFW release or confirmation from our chats.

Ver.20.1.0(Released May27,2025)
- Visual updates have been made to the Parental Control settings.
- The sound that plays when Nintendo Switch Online is launched from the HOME Menu has been changed.
- General system stability improvements to enhance the user's experience.
 
Last edited by impeeza,
yes it does.
Post automatically merged:

Damn you Nintendo FW 20.1.0 RELEASED!!


Do not update yet! Wait for a next CFW release or confirmation from our chats.

Ver.20.1.0(Released May27,2025)
- Visual updates have been made to the Parental Control settings.
- The sound that plays when Nintendo Switch Online is launched from the HOME Menu has been changed.
- General system stability improvements to enhance the user's experience.


seems fine to me


Code:
# Firmware version number is: 20.1.0

# key revision generated keys for ends with _13

a "MOV" arm instruction with ending of 0x2A was found within the pattern

Sys-patch for ES string still valid for: 20.1.0

Sys-patch ES pattern found at: 076A18

The ghidra-equivalent pattern used was: .. .. 00 .. .. .. 00 94 a0 .. .. d1 .. .. ff 97 .. .. .. .. .. .. .. a9

An arm "MOV" condition is what is supposed to be patched at this offset

20.1.0 ES build-id: 8B2E677DE5991C87B35E84F7DDB8056F62D4582E


an "STP" arm instruction with ending of 0xA9 was found proceding the pattern

Sys-patch for NIFM string still valid for: 20.1.0

Sys-patch NIFM pattern found at: 087AC0

The ghidra-equivalent pattern used was: 14 .. .. .. .. .. .. .. .. .. .. .. 91 .. .. .. .. .. .. .. .. .. .. .. 97 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 14

An arm "STP" condition is what is supposed to be patched at the offset right after the branch arm condition tested ("B")

20.1.0 NIFM build-id: 523D2C6E08D9BE4B512AD20AA5628B7BB06D73C2


a "ADR" arm instruction with ending of 0x10 was found within the pattern

Sys-patch for NIM string still valid for: 20.1.0

Sys-patch NIM pattern found at: 190DF8

The ghidra-equivalent pattern used was: .. 0F 00 35 1F 20 03 D5 .. .. .. ..

An arm "ADR" condition is what is supposed to be patched at the offset right after the "CBNZ and "NOP" conditions the pattern finds

20.1.0 NIM build-id: CC269DEA7E3AE16FAA39215F5A1CEF5C82FA1C00


a "TBZ" arm instruction with ending of 0x36 was found within the pattern, first pattern verified

a "BL" arm instruction with ending of 0x94 was found within the pattern, second pattern verified

both sys-patch strings are valid for FS-FAT32 for: 20.1.0

20.1.0 First Sys-patch FS-FAT32 pattern found at: 023C88

The ghidra-equivalent pattern used was (11.0.0+) : .. 94 .. .. 00 36 .. 25 80 52

An arm "TBZ" condition is what is supposed to be patched, it is found within the pattern.

20.1.0 Second Sys-patch FS-FAT32 pattern found at: 07A880

The ghidra-equivalent pattern used was (19.0.0+) : 40 f9 .. .. .. 94 .. .. 40 b9 .. .. 00 12

An arm "BL" condition is what is supposed to be patched, it is found within the pattern.

20.1.0 Second Sys-patch FS-FAT32 pattern found at: 07A880

20.1.0 FS-FAT32 SHA256 hash: ED34B450584A5B43150CFF94D6A7C49F6B7F4C649B7CC6A0D8A0BB316EB52B76


FS-exFAT was skipped for: 20.1.0, due to missing NCA file for exfat in the provided firmware files.
 
  • Love
  • Like
Reactions: Tyvar1 and impeeza
seems fine to me


Code:
# Firmware version number is: 20.1.0

# key revision generated keys for ends with _13

a "MOV" arm instruction with ending of 0x2A was found within the pattern

Sys-patch for ES string still valid for: 20.1.0

Sys-patch ES pattern found at: 076A18

The ghidra-equivalent pattern used was: .. .. 00 .. .. .. 00 94 a0 .. .. d1 .. .. ff 97 .. .. .. .. .. .. .. a9

An arm "MOV" condition is what is supposed to be patched at this offset

20.1.0 ES build-id: 8B2E677DE5991C87B35E84F7DDB8056F62D4582E


an "STP" arm instruction with ending of 0xA9 was found proceding the pattern

Sys-patch for NIFM string still valid for: 20.1.0

Sys-patch NIFM pattern found at: 087AC0

The ghidra-equivalent pattern used was: 14 .. .. .. .. .. .. .. .. .. .. .. 91 .. .. .. .. .. .. .. .. .. .. .. 97 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 14

An arm "STP" condition is what is supposed to be patched at the offset right after the branch arm condition tested ("B")

20.1.0 NIFM build-id: 523D2C6E08D9BE4B512AD20AA5628B7BB06D73C2


a "ADR" arm instruction with ending of 0x10 was found within the pattern

Sys-patch for NIM string still valid for: 20.1.0

Sys-patch NIM pattern found at: 190DF8

The ghidra-equivalent pattern used was: .. 0F 00 35 1F 20 03 D5 .. .. .. ..

An arm "ADR" condition is what is supposed to be patched at the offset right after the "CBNZ and "NOP" conditions the pattern finds

20.1.0 NIM build-id: CC269DEA7E3AE16FAA39215F5A1CEF5C82FA1C00


a "TBZ" arm instruction with ending of 0x36 was found within the pattern, first pattern verified

a "BL" arm instruction with ending of 0x94 was found within the pattern, second pattern verified

both sys-patch strings are valid for FS-FAT32 for: 20.1.0

20.1.0 First Sys-patch FS-FAT32 pattern found at: 023C88

The ghidra-equivalent pattern used was (11.0.0+) : .. 94 .. .. 00 36 .. 25 80 52

An arm "TBZ" condition is what is supposed to be patched, it is found within the pattern.

20.1.0 Second Sys-patch FS-FAT32 pattern found at: 07A880

The ghidra-equivalent pattern used was (19.0.0+) : 40 f9 .. .. .. 94 .. .. 40 b9 .. .. 00 12

An arm "BL" condition is what is supposed to be patched, it is found within the pattern.

20.1.0 Second Sys-patch FS-FAT32 pattern found at: 07A880

20.1.0 FS-FAT32 SHA256 hash: ED34B450584A5B43150CFF94D6A7C49F6B7F4C649B7CC6A0D8A0BB316EB52B76


FS-exFAT was skipped for: 20.1.0, due to missing NCA file for exfat in the provided firmware files.
Excellent, then just wait for SciresM and a new Atmosphère, Thanks a lot mate.
Post automatically merged:

seems fine to me


Code:
# Firmware version number is: 20.1.0

# key revision generated keys for ends with _13

a "MOV" arm instruction with ending of 0x2A was found within the pattern

Sys-patch for ES string still valid for: 20.1.0

Sys-patch ES pattern found at: 076A18

The ghidra-equivalent pattern used was: .. .. 00 .. .. .. 00 94 a0 .. .. d1 .. .. ff 97 .. .. .. .. .. .. .. a9

An arm "MOV" condition is what is supposed to be patched at this offset

20.1.0 ES build-id: 8B2E677DE5991C87B35E84F7DDB8056F62D4582E


an "STP" arm instruction with ending of 0xA9 was found proceding the pattern

Sys-patch for NIFM string still valid for: 20.1.0

Sys-patch NIFM pattern found at: 087AC0

The ghidra-equivalent pattern used was: 14 .. .. .. .. .. .. .. .. .. .. .. 91 .. .. .. .. .. .. .. .. .. .. .. 97 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 14

An arm "STP" condition is what is supposed to be patched at the offset right after the branch arm condition tested ("B")

20.1.0 NIFM build-id: 523D2C6E08D9BE4B512AD20AA5628B7BB06D73C2


a "ADR" arm instruction with ending of 0x10 was found within the pattern

Sys-patch for NIM string still valid for: 20.1.0

Sys-patch NIM pattern found at: 190DF8

The ghidra-equivalent pattern used was: .. 0F 00 35 1F 20 03 D5 .. .. .. ..

An arm "ADR" condition is what is supposed to be patched at the offset right after the "CBNZ and "NOP" conditions the pattern finds

20.1.0 NIM build-id: CC269DEA7E3AE16FAA39215F5A1CEF5C82FA1C00


a "TBZ" arm instruction with ending of 0x36 was found within the pattern, first pattern verified

a "BL" arm instruction with ending of 0x94 was found within the pattern, second pattern verified

both sys-patch strings are valid for FS-FAT32 for: 20.1.0

20.1.0 First Sys-patch FS-FAT32 pattern found at: 023C88

The ghidra-equivalent pattern used was (11.0.0+) : .. 94 .. .. 00 36 .. 25 80 52

An arm "TBZ" condition is what is supposed to be patched, it is found within the pattern.

20.1.0 Second Sys-patch FS-FAT32 pattern found at: 07A880

The ghidra-equivalent pattern used was (19.0.0+) : 40 f9 .. .. .. 94 .. .. 40 b9 .. .. 00 12

An arm "BL" condition is what is supposed to be patched, it is found within the pattern.

20.1.0 Second Sys-patch FS-FAT32 pattern found at: 07A880

20.1.0 FS-FAT32 SHA256 hash: ED34B450584A5B43150CFF94D6A7C49F6B7F4C649B7CC6A0D8A0BB316EB52B76


FS-exFAT was skipped for: 20.1.0, due to missing NCA file for exfat in the provided firmware files.
Mate, so the new firmware will not need new set of keys?
 
Last edited by impeeza,
Can't play dumped games.. I keep getting an error after updating to the latest hekate and atmosphere version and I also tried updating sigpatches but the software just closes and gives an error.

I think we need new sig patches.. so yep..
 

Site & Scene News

Popular threads in this forum