Homebrew Homebrew app sys-patch - sysmod that patches on boot

[Bigdrago]

1.60 doesnt work with turtles shredders revenge "An error has occured". Will reverting back to 1.59, hoping that will fix the issue.

Post automatically merged: Mar 8, 2026

1.60 doesnt work with turtles shredders revenge "An error has occured". Will reverting back to 1.59, hoping that will fix the issue.

 

[bth]

1.60 doesnt work with turtles shredders revenge "An error has occured". Will reverting back to 1.59, hoping that will fix the issue.

Post automatically merged: Mar 8, 2026

1.60 doesnt work with turtles shredders revenge "An error has occured". Will reverting back to 1.59, hoping that will fix the issue.

use 1.6.0, provide the /config/sys-patch/log.ini (so that i can see if you are actually using 1.6.0-a9d04af)
and from /atmosphere/crash_reports/ which title you claim is having the issue. (.log file)

(0100FE701475A000 / 0100FE701475A800 - teenage mutant ninja turtles. shredders revenge)
or alternatively, if an error report was produced, from the moment you had the error, obviously, not from weeks ago,

0100000000000033 - ES
010000000000003E - OLSC
010000000000000F - NIFM
0100000000000025 - NIM

this game also has functionality that might interfer with you pirating it...

EOS being EpicOnlineServices


edit: this game also has references to JIT, but calls to RO, but if it uses JIT, then this game wont work on 21.0.0+, similar to the n64 title failing to launch, https://github.com/Atmosphere-NX/Atmosphere/issues/2729

 

[Bigdrago]

No error when playing handheld mode.
Error only occurs when playing docked.
I guess it isnt syspatch error then (?).

 

[bth]

No error when playing handheld mode.
Error only occurs when playing docked.
I guess it isnt syspatch error then (?).

nothing is anything unless you provide what i asked for.

 

[Bigdrago]

Update: Error occur when docking station is connected with ethernet cable, if I disconnect cable error does not occur. Switch have airplane mode.

From log:
version=1.6.0-a9d04af
build_date=03.03.2026 19:45:53
fw_version=21.0.0
ams_version=1.10.2

No logs from today regarding crash error log.

 

[bth]

Update: Error occur when docking station is connected with ethernet cable, if I disconnect cable error does not occur. Switch have airplane mode.

From log:
version=1.6.0-a9d04af
build_date=03.03.2026 19:45:53
fw_version=21.0.0
ams_version=1.10.2

No logs from today regarding crash error log.

i investigated the shredders revenge title, it has a whole bunch of network related code in it

your sys-patch log output is incomplete.
docking console overrides airplane mode.


fact:
the network adapter ordinarily does not activate (ethernet or wifi), unless it can hit in consecutive order:
1. ctest domain (to "open" the network adapter) (HTTP) (dns mitm 127.0.0 *nintendo* -> network dont work -> we patch -> network now work)
2. time test domain (HTTPS) (prodinfo blanker / incognito applied -> console crash -> we patch to not crash)

We patch out 1 and 2 with NIFM (1) and NIM (2)

now you are force enabling network connectivity, even if those conditions don't fulfill naturally, as dns.mitm and/or blanking your prodinfo is what those patches are for, to force enable the network adapter, gaining network functionality for homebrew, without being blocked from using network functionality to failing the two conditions.


the game you are trying to play has so much network enabled bloat, i found even discord hooks in the game binary; and since the console is being forced to have network functionality, with both the http and https flag supposedly passed, there is zero reason for communication to their servers to fail -> "an error has occured"

as both http and https have completed, both nifm and nim are saying to game, "we have full network working, go ahead, do all server communication", and it cannot do that as you obviously are a pirate with at least a dns.mitm configuration and/or exosphere/cal0blanker/incognito active (alternatively if your console is banned from ninty, the result is the same as having exosphere/cal0blanker/incognito active)




tl:dr your problem has nothing to do with sys-patch 1.6.0 specifically, and sys-patch 1.5.9 will not somehow change how that works

your problem stems from the game itself

 

[josete2k]

Update: Error occur when docking station is connected with ethernet cable, if I disconnect cable error does not occur. Switch have airplane mode.

From log:
version=1.6.0-a9d04af
build_date=03.03.2026 19:45:53
fw_version=21.0.0
ams_version=1.10.2

No logs from today regarding crash error log.

You can avoid network connection with salty and these asm patches.

Hacking Homebrew  Post in thread 'Is it feasible to MITM the internet connection/module?'

Jun 1, 2022

I'm using the patches when network is available but if you don't have a network available in those games you either have "could not connect" nag without airplane mode or "turn off airplane mode" nag with airplane mode so I was just asking if it's possible to have a patch to eliminate the nag. It would also be nice for users that need or want to stay in airplane mode for whatever reason.

Ok, seems legit .
So I'm trying random things, but seems to works, at least for DOOM (1993), I didn't tried something else.
But I had no nag at launch while in airplane mode

If you can confirm...

• bestpig

• 
• 

 

[bth]

ES pattern from 1.5.9 not valid for 22.0.0, have pushed a correction, and also merged into upstream, so that it is at https://github.com/impeeza/sys-patch/releases/tag/v1.6.0


(nintendo refactored the function doing signature checks for ES)

 

[Bigdrago]

1.6.0 on github any different on what you posted here earlier?

 

[bth]

1.6.0 on github any different on what you posted here earlier?

the one pushed (and merged) to upstream has 22.0.0 ES fix, so yes, i had not yet merged it as there was no need for it yet, but since the ES pattern for 22.0.0 was incorrect, it was a fitting time to merge and have it be released upstream

 

[Axoza]

Thanks @bth for the new upload on March 3rd.
The previous build was crashing with Ultrahand.
I can confirm that this version works perfectly on my side with Ultrahand 2.2.9, ATM 1.10.2, and FW 21.2.0.

Hey, I'm also at ATM 1.10.2, and FW 21.2.0 with Ultrahand 2.3.0 but I never be able to turn the sys-patch on via ediZonSE.
How did you manage to turn it on?
Every time I turn it on, the status always goes back to off.
I can't use my FPS Locker since I always got "SaltyNX is not running" due to no sys-patch is present in the CFW.
Any suggestions?
Thank you!

EDIT:
I think somehow I missed some of the required setup. Now it's working like charm!
Thank you guys, you rock!

 

[Blythe93]

I never be able to turn the sys-patch on via ediZonSE.
How did you manage to turn it on?
Every time I turn it on, the status always goes back to off.

That's normal. sys-patch does its thing on startup and then turns off, no need to re-enable it.

 

[bth]

if anyone's interested in trying something different;

Atmosphere with embedded patches, and a trimmed down, non-configurable version of sys-patch built into atmosphere, which sole purpose is to add FS patches so that both hekate and fusee.bin booters can use it.

this version of sys-patch does not have an overlay, or logs.

it also forces dns mitm of 127.0.0 for all *nintendo* domains (in addition to whatever configuration any other user may provide)

essentially, atmosphere with all patches built in.

https://github.com/borntohonk/Atmosphere/commit/ba7284945f70cb8c7cc03f855ac36b18bdcad774

https://github.com/borntohonk/Atmosphere/releases/tag/1.10.2+

https://github.com/borntohonk/Atmosphere/releases/tag/1.9.5+


what needs testing is really just that your regular games work (those should work, as embedded ES patches already been tested to work before), and if possible, someone who has forwarders compatible with latest atmosphere (1.10+) (what needs testing basically is the embedded sys-patch for the FS patches)

before testing, kindly rename atmosphere folder to atmosphere-backup and only use this version with nothing extra while testing.

boot with hekate pkg3 method, or fusee.bin, doesn't matter which, but if hekate, don't have patches.ini or kip1patch=nosigchk line

(not compatible with 22.0.0 just yet - will wait for homebrew fix before rebasing for that)



pros:
version of atmosphere, if maintained, will always have the correct patches for a firmware version


edit:
i added a "1.9.5" atmosphere version, which is 1.10.2 bundled with tls 0x108 hbl, hbmenu and atmosphere itself is compiled with tls 0x108 libnx, and reverting the tls 0x108 restriction commit
(to faster be able to have someone test if tinfoil starts on any firmware, to verify the FS patches are loaded or not)

 

[Vin_Thod]

if anyone's interested in trying something different;

Atmosphere with embedded patches, and a trimmed down, non-configurable version of sys-patch built into atmosphere, which sole purpose is to add FS patches so that both hekate and fusee.bin booters can use it.

this version of sys-patch does not have an overlay, or logs.

it also forces dns mitm of 127.0.0 for all *nintendo* domains (in addition to whatever configuration any other user may provide)

essentially, atmosphere with all patches built in.

https://github.com/borntohonk/Atmosphere/commit/ba7284945f70cb8c7cc03f855ac36b18bdcad774

https://github.com/borntohonk/Atmosphere/releases/tag/1.10.2+

https://github.com/borntohonk/Atmosphere/releases/tag/1.9.5+


what needs testing is really just that your regular games work (those should work, as embedded ES patches already been tested to work before), and if possible, someone who has forwarders compatible with latest atmosphere (1.10+) (what needs testing basically is the embedded sys-patch for the FS patches)

before testing, kindly rename atmosphere folder to atmosphere-backup and only use this version with nothing extra while testing.

boot with hekate pkg3 method, or fusee.bin, doesn't matter which, but if hekate, don't have patches.ini or kip1patch=nosigchk line

(not compatible with 22.0.0 just yet - will wait for homebrew fix before rebasing for that)



pros:
version of atmosphere, if maintained, will always have the correct patches for a firmware version


edit:
i added a "1.9.5" atmosphere version, which is 1.10.2 bundled with tls 0x108 hbl, hbmenu and atmosphere itself is compiled with tls 0x108 libnx, and reverting the tls 0x108 restriction commit
(to faster be able to have someone test if tinfoil starts on any firmware, to verify the FS patches are loaded or not)

pls make a different thread for this!!!

 

[duckbill007]

@bth, short question - why embed syspatch for FS and direct patches for ES/NIM and so on? Why not the same way for all patches? And I do understand your position about always have correct patches. Also I see a lot of error reports after resuming from sleep that I can explain only by HOS restarting sysmodules for example FS or ES. In case of syspatch these modules becames unpatched and do not work. In case of patches embedded to loader they always will be patched.

 

[bth]

@bth, short question - why embed syspatch for FS and direct patches for ES/NIM and so on? Why not the same way for all patches? And I do understand your position about always have correct patches. Also I see a lot of error reports after resuming from sleep that I can explain only by HOS restarting sysmodules for example FS or ES. In case of syspatch these modules becames unpatched and do not work. In case of patches embedded to loader they always will be patched.

Agnostic for both hekate and fusee

hekate doesn't benefit, or is able to use the FS patches atmosphere has embedded in fusee

as for loader, which also is a kip patch, both fusee (cant anymore) and hekate (patches.ini) require new patch for every version of atmosphere, sys-patch makes both not need external patches.

since this is an atmosphere fork, loader is not needed to be patched, which leaves only FS.

as for embedding all EXEFS patches, that is agnostic to both methods of booting, so that part makes sense.

tl:dr while i can add the patches to atmosphere directly, hekate PKG3/FSS0 method cannot use those, as they are in fusee, not pkg3/loader

basically, if i am to embed patches into fusee, i have to also embed into hekate and distribute both, so the easier route is just embedding a stripped down version of sys-patch to only patch FS - which is now in stratosphere.romfs (no risk of end user deleting if being asked to delete /contents folder, and overwritten by future atmosphere (fork) updates)


alternative: embed patches into fusee (i can do that, easily) + distribute bootloader folder + patches.ini in the archive, which assumes end user has kip1patch=nosigchk

it's just more efficient to embedd the one kippatch fork cannot undo, as sys-patch, so that people who boot with hekate benefits from it


problem is fusee is responsible for patching FS
https://github.com/Atmosphere-NX/At...ogram/source/fusee_stratosphere.cpp#L900-L902

Post automatically merged: Mar 24, 2026

@duckbill007 basically...

there's several types of patches to FS that atmosphere does
FUSEE NOGC (hekate equivelant patches.ini)

https://github.com/Atmosphere-NX/At...ogram/source/fusee_stratosphere.cpp#L708-L710
https://github.com/CTCaer/hekate/blob/master/bootloader/hos/pkg2_patches.inl#L861-L863

the problem with this is they use different apis to patch "kip" modules.


the second api that atmosphere patches FS with is:
https://github.com/Atmosphere-NX/Atmosphere/tree/master/emummc

the emummc patches, which seem agnostic to both hekate and atmosphere, kind of? So squeezing in FS patches there might be viable. -> problem: only for emummc users

convoluted solution:
https://github.com/Atmosphere-NX/Atmosphere/blob/master/emummc/source/main.c#L421

add function to patch fs into emummc module, load before load_emummc_ctx(); or inside of load_emummc_ctx(); function

 

[duckbill007]

Thank you for detailed explanation

 

[bth]

Thank you for detailed explanation

example implemented into the emummc module (inside of pkg3)
i havent fully checked if atmosphere always loads the code from emummc module, but this would patch it for emummc users lmao

basically, the idea is there, just figure out how to make it call for both non-emummc (and emummc), done.
going this route, embedding sys-patch not necessary


https://github.com/Atmosphere-NX/At...ogram/source/fusee_stratosphere.cpp#L941-L951

problem: fusee/hekate loads emummc.kip differently. back to same problem.
can make FS patches agnostic for emummc users only, have to use sys-patch to make it agnostic for both emmc and emummc

obviously, making a separate function for storing the offsets is ideal, instead of editing the emummc offset .h's



could embedd the fs pathes into fusee, with condition of emummc not active (to not double-apply patch)
and have emummc do fs_patch(); for when fusee is not used, making both hekate emummc users, fusee emummc users, and fusee sysnand users get fs patches.

hekate sysnand users however does not get FS patches like that (which is why i opted to embed sys-patch)

Post automatically merged: Mar 24, 2026

i will consider extending on the loader patcher api to patch FS, instead of having the patcher code be inside of sys-patch which is ultimately loaded by loader, it doesn't make much sense for it not to be able to patch FS, if sys-patch is loaded by loader

loader is capable of loading other things capable of patching FS. loader itself does not launch FS, so it cannot patch FS.

mesosphere alternative angle



https://github.com/borntohonk/Atmosphere/commit/305c5a4214ebebfec9ad5e981a75f90f69c1ae28

this commit has FS patches applied by the same patcher api that emummc uses, although, it only applies to to emummc users.

 

[duckbill007]

One more question: are you sure that hos never restart modules like fs or es?

 

[bth]

One more question: are you sure that hos never restart modules like fs or es?

the answer in the context is, even if it does, we cant do anything about it, the reason loader "stays patched" if you fork atmosphere and alter loader, is because loader is part of atmosphere, and open source.

if the patches we apply by loader (exefs_patches), or to FS through patches.ini (example for hekate)

as for sys-patch, i guess in realms of theory since sys-patch patches memory, a "restart of modules", example, loader, would have to re-load sys-patch and then re-initialize FS/ES and so on, i guess in that scope, sys-patch that uses svc's to debug edit memory of running processes wont be able to patch it a second time.

as for using the patcher api of emummc.kip, it shouldn't be able to fall off, as the emummc code does the same
with that logic, patches applied by patches.ini shouldn't fall off either. (this implementation should work, but it'll only apply patches to FS, and only for emummc) and patches, if embedded into fusee shouldn't have problems either



My current idea to accomplish agnostic patches embedded, and not rely on sys-patch, is to introduce the patching of FS into mesosphere (agnostic to both fusee and hekate), basically using the same data fusee uses to patch nogc

combine the approaches, implement a narrow sys-patch-like approach directly into mesosphere, capable of editing only FS.
edit:
second variant embedding only 17.0.0 and above patches, without sys-patch-like approach:

both variants introduced in this commit:
https://github.com/borntohonk/Atmosphere/commit/8bef4cdc48f512679c6d2cfbaf8ab147475f9f14