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

[bombayjack]

Can someone please explain what these sys-patch related changes on these forks of ovl-sysmodules and Tesla-Menu would do?

https://github.com/zdm65477730/ovl-sysmodules/commit/be88ee641df246bba4af78ddc28949788dd074ed
https://github.com/zdm65477730/Tesla-Menu/commit/d56c681b5b639e620598f7751f417064c4abfa8a

First link: seems to do this: don't allow Tesla to be killed if it finds a module running with one of theses ID:
420000000007E51 or 420000000000000

Second Link: Find these overlays in .overays folder
ovlmenu.ovl or sys-patch.ovl or sys-patch-overlay.ovl
If an overlay is found with one of those names, patch the overlay with a language json translation file.
Example - patch overlay with: sdmc:/switch/.overlays/lang/sys-patch/de.json

Post automatically merged: Dec 30, 2025

You who cant name a real life example, of a game that exhibits this behaviour?

I don't think you qualify for the type of feedback required, as your homebrew/parentail control whatever dbi nonsense isn't the same function that is supposed to "fix"

Huh, there's plenty things that require a linked account but since you don't know any here's one. Official Nintendo 64/Nintendo classics emulator.

 

[bth]

First link: seems to do this: don't allow Tesla to be killed if it finds a module running with one of theses ID:
420000000007E51 or 420000000000000

Second Link: Find these overlays in .overays folder
ovlmenu.ovl or sys-patch.ovl or sys-patch-overlay.ovl
If an overlay is found with one of those names, patch the overlay with a language json translation file.
Example - patch overlay with: sdmc:/switch/.overlays/lang/sys-patch/de.json

Post automatically merged: Dec 30, 2025

Huh, there's plenty things that require a linked account but since you don't know any here's one. Official Nintendo 64/Nintendo classics emulator.

the emulators that are part of the nintendo switch online subscribtion use a different call.

come up with an actual example (a REAL game)

 

[josete2k]

Second Link: Find these overlays in .overays folder
ovlmenu.ovl or sys-patch.ovl or sys-patch-overlay.ovl
If an overlay is found with one of those names, patch the overlay with a language json translation file.
Example - patch overlay with: sdmc:/switch/.overlays/lang/sys-patch/de.json

Are you sure? I thought that it was only for hidding the sys-patch overlay in the tesla menu.

 

[bombayjack]

Are you sure? I thought that it was only for hidding the sys-patch overlay in the tesla menu.

I just had a quick look so you could be right, why not just ask the dev since it's on github.

 

[00diabolic]

Ive got a major syspatch conflict.. I've got the latest syspatch 1.5.9 installed and I'm still having issues with with 2 games that wont load. Metroid prime 4 and xenoblade x. I'm running firmware 19.0.1 and AMS 1.9.5. I also cant get tinfoil self installer to run or NSP ver. Both fail to run or even install. I end up with a black box with a spinning icon on them. I'm thinking I probably am going to need to run firmware 20 but I kinda was hoping I could use these games on ver 19. Any ideas? Ive had sigpatches in the past and deleted the patches that I knew would cause conflicts with syspatches, but last time I did an update I have since forgot some of these tricks and might have conflicts again.

Hope someone can help. my sd is fat32 and what's really weird is DBI installer 8.25 installs these games with no errors and no corruption and then when I go to run them I get the checker and it says both installs are corrupted. Again its very odd, so makes me think it's a conflict between syspatches/sigpatches, if that's possible again just a guess.

 

[PRTechNova]

Ive got a major syspatch conflict.. I've got the latest syspatch 1.5.9 installed and I'm still having issues with with 2 games that wont load. Metroid prime 4 and xenoblade x. I'm running firmware 19.0.1 and AMS 1.9.5. I also cant get tinfoil self installer to run or NSP ver. Both fail to run or even install. I end up with a black box with a spinning icon on them. I'm thinking I probably am going to need to run firmware 20 but I kinda was hoping I could use these games on ver 19. Any ideas? Ive had sigpatches in the past and deleted the patches that I knew would cause conflicts with syspatches, but last time I did an update I have since forgot some of these tricks and might have conflicts again.

Hope someone can help. my sd is fat32 and what's really weird is DBI installer 8.25 installs these games with no errors and no corruption and then when I go to run them I get the checker and it says both installs are corrupted. Again its very odd, so makes me think it's a conflict between syspatches/sigpatches, if that's possible again just a guess.

Why are you updating to the newest sys-patches if youre still on an older firmware and using sigpatches? Do you know what youre doing? What sigpatches folders did you deleted? If youre going to use sys-patch you must remove all related folders to sigpatches, sigpatches at this point are useless because sys-patch is superior. I suggest you delete all folders related to Atmosphere on your SD and add everything again for your firmware version, or just update to the newest firmware and sys-patch as its working with no issues except for some homebrew apps.

 

[00diabolic]

Why are you updating to the newest sys-patches if youre still on an older firmware and using sigpatches? Do you know what youre doing? What sigpatches folders did you deleted? If youre going to use sys-patch you must remove all related folders to sigpatches, sigpatches at this point are useless because sys-patch is superior. I suggest you delete all folders related to Atmosphere on your SD and add everything again for your firmware version, or just update to the newest firmware and sys-patch as its working with no issues except for some homebrew apps.

well I've actually gone between 1.5.6 and 1.5.9 with same results. Your response does confirm what I did not know and that is that syspatches do need to match atmosphere version. So I think I should be using 1.5.6 right? Also which sigpatches should I delete? all of them? I remember that folder includes more then just the sigpatches but also some other stuff, so I did not want to wipe it out, I just don't know which are the specific folders I should keep.

 

[bth]

well I've actually gone between 1.5.6 and 1.5.9 with same results. Your response does confirm what I did not know and that is that syspatches do need to match atmosphere version. So I think I should be using 1.5.6 right? Also which sigpatches should I delete? all of them? I remember that folder includes more then just the sigpatches but also some other stuff, so I did not want to wipe it out, I just don't know which are the specific folders I should keep.

This only applies to atmosphere 1.9.5, that specific version and below should use sys-patch 1.5.6

atmosphere versions above 1.9.5 (such as, 1.10.1) needs a more recent release, such as sys-patch 1.5.9

(firmware version is completely out of equation - this is an atmosphere thing)

 

[00diabolic]

This only applies to atmosphere 1.9.5, that specific version and below should use sys-patch 1.5.6

atmosphere versions above 1.9.5 (such as, 1.10.1) needs a more recent release, such as sys-patch 1.5.9

(firmware version is completely out of equation - this is an atmosphere thing)

ok 1.5.6 and I'm still having the issue, so it must be a conflict with sigpatches then?

 

[bth]

ok 1.5.6 and I'm still having the issue, so it must be a conflict with sigpatches then?

I'm running firmware 19.0.1 and AMS 1.9.5

required sdk version for metroid 4 is 20.5.17.0 (which is actually 21.0.0, as 20.5.4.0 is 20.1.1)
required sdk version for xenoblade x is 19.3.2.0 (19.0.1)

metroid 4 not starting isn't a surprise.

xenoblade x not running is probably wherever you got it from providing you a bad file.

both are keygen revision 18 (0x12) (18.0.0) - that is why they both install for you, if they do install for you.

sys-patch 1.5.6 will conflict with sigpatches, sys-patch 1.5.9 has patterns refactored to not conflict.

your problems are unrelated to sys-patch, or potentially, they are related, and you are just unable to properly add sys-patch to sd card. Probably? consult with /config/sys-patch/log.ini for definitive answer. - that will tell you (or us) what patches you have, or don't have active.

if no such file exists, then you don't have sys-patch, if the date of the log doesn't align with when you just booted, then you don't have sys-patch.

 

[00diabolic]

required sdk version for metroid 4 is 20.5.17.0 (which is actually 21.0.0, as 20.5.4.0 is 20.1.1)
required sdk version for xenoblade x is 19.3.2.0 (19.0.1)

metroid 4 not starting isn't a surprise.

xenoblade x not running is probably wherever you got it from providing you a bad file.

both are keygen revision 18 (0x12) (18.0.0) - that is why they both install for you, if they do install for you.

sys-patch 1.5.6 will conflict with sigpatches, sys-patch 1.5.9 has patterns refactored to not conflict.

your problems are unrelated to sys-patch, or potentially, they are related, and you are just unable to properly add sys-patch to sd card. Probably? consult with /config/sys-patch/log.ini for definitive answer. - that will tell you (or us) what patches you have, or don't have active.

if no such file exists, then you don't have sys-patch, if the date of the log doesn't align with when you just booted, then you don't have sys-patch.

Ok you wont believe it but I got it fixed and it was a bad kip patch that was the culprit. When I could not get the syspatches to work I did some stupid stuff then other day and started installing sigpatches hoping to make it work, I used the HATS pack to do that, big mistake. It included a kip patch I never heard of but did not think it would cause an issue. So now deleting that, deleting all the exfs patches and now every game is back working including Metroid 4, under AMS 1.9.5 with OS 19. I did not update as I read Metroid would work on 19 and just wanted to figure out how. Anyway now I have only 2 small games that wont run with the error "the software closed because of an error occured". As I recall that's kinda easy to fix..

UPDATE: yep simple reboot fixed it.

SO THE TLDR: Match your AMS and firmware version to syspatches, don't install any exefs patches at all. Watch your kip patches unless you know exactly what they do, lastly reboot.

 

[bombayjack]

@bth

Since logic and nibble patches are now fixed in the sys-module, why not make the patch patterns get stored in an ini file now so you don't need to keep updating the app on every firmware update. You only need to update the ini file instead of the program. Benefits are no need to compile the program on each pattern update, ini file can be updated easier, you can make the overlay download and updated ini file when required, so it's easier to update and a smaller download.

You can keep embedded patches, but if the ini file exists if can use that instead to read patterns from. That way you can have the same benefits of IPS patches (no need to compile when testing), and never need to use IPS patches again when testing.

Pro's:
No recompilation needed for pattern updates
Users can add custom patterns without touching source
Debugging easier - just edit INI file
Share patterns without sharing compiled binaries
Update/download ini file easily from overlay

Con's:
INI parsing adds ~5-10ms startup time (negligible)
~4KB extra for pattern storage

Backward Compatibility:
Keep compiled patterns as fallback
Users without INI file get original behavior

 

[bth]

@bth

Since logic and nibble patches are now fixed in the sys-module, why not make the patch patterns get stored in an ini file now so you don't need to keep updating the app on every firmware update. You only need to update the ini file instead of the program. Benefits are no need to compile the program on each pattern update, ini file can be updated easier, you can make the overlay download and updated ini file when required, so it's easier to update and a smaller download.

You can keep embedded patches, but if the ini file exists if can use that instead to read patterns from. That way you can have the same benefits of IPS patches (no need to compile when testing), and never need to use IPS patches again when testing.

Pro's:
No recompilation needed for pattern updates
Users can add custom patterns without touching source
Debugging easier - just edit INI file
Share patterns without sharing compiled binaries
Update/download ini file easily from overlay

Con's:
INI parsing adds ~5-10ms startup time (negligible)
~4KB extra for pattern storage

Backward Compatibility:
Keep compiled patterns as fallback
Users without INI file get original behavior

If you're referring to this: https://github.com/impeeza/sys-patch/compare/master...borntohonk:sys-patch:master

i'll just reiterate once again, since it doesn't seem to stick.

https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/find_patterns.py

that thing there, in combination of the latest firmware files, will test the pattern, synthetically, with the same logic sys-patch does, on your pc, with no requirement of ever booting your console.

https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/find_patterns.py#L238-L287
you can even batch run every single firmware version possible and instantly spam tweak patterns until only correct result is found / no multiple results are found.

those patterns in that array are basically as optimized as they possibly can, never booted into the physical console to test even once. No need for that.




as for "side-loading" patterns from an .ini file, that would require an abstracted template to be included, of course;
and for the overlay to also be capable of reading the exact same "sideloaded" pattern file

ex:
[FS: patch_name]
pattern:"0xPattern_Example"
offset:"6"
head_offset:0"

(patch_name = "nocntchk_25.0.0")
(Pattern_example = 0x40F9............40B9091C)

which would ideally, append it under:
https://github.com/borntohonk/sys-patch/blob/master/sysmod/src/main.cpp#L366
https://github.com/borntohonk/sys-patch/blob/master/sysmod/src/main.cpp#L318-L326

 

[bombayjack]

If you're referring to this: https://github.com/impeeza/sys-patch/compare/master...borntohonk:sys-patch:master

i'll just reiterate once again, since it doesn't seem to stick.

https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/find_patterns.py

that thing there, in combination of the latest firmware files, will test the pattern, synthetically, with the same logic sys-patch does, on your pc, with no requirement of ever booting your console.

https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/find_patterns.py#L238-L287
you can even batch run every single firmware version possible and instantly spam tweak patterns until only correct result is found / no multiple results are found.

those patterns in that array are basically as optimized as they possibly can, never booted into the physical console to test even once. No need for that.

I guess you didn't understand my post at all, even though it was very simple to read and understand. I already have working code for what I want to do. Maybe you should re-read what I wrote so you can grasp what I posted.

 

[bth]

I guess you didn't understand my post at all, even though it was very simple to read and understand. I already have working code for what I want to do. Maybe you should re-read what I wrote so you can grasp what I posted.

you must be hallucinating, as the conversations you have in mock with whatever LLM/chatbot you normally converse with doesn't really apply to me.

if your intent was to convey a summary of what you have done, then that has no bearing on me at all. You present it as hypothetical, so I respond appropriately. Keep that in mind for future, that your LLM/AI-chatbots are programmed to glaze you heavily.

 

[AllOver]

What is the benefit of an ini file approach? Smaller download size is irrelevant because syspatch is already a few kb. You will run into users installing just the ini and not syspatch and vice versa. Then you will have users manually editing the ini file and breaking patches in the process.

Always assume the user is dumb, you'd want to make the process as simple as possible. Single file approach is better for everyone. The ini is only useful for if you want to try and circumvent a dmca by making syspatch just a fancy patch engine, not containing any patches (which wouldn't work btw).

Post automatically merged: Jan 6, 2026

If you're going the way of ini patches, then how do you suggest handling the cond checks that syspatch has? They don't translate so easily to a ini.

You'd either have to have a preset amount of conds in syspatch and then have a switch() over which cond to use (set inside the ini) along with the offset to check. Or you have a basic pattern to match to check stuff, but that's far more limited compared to what syspatch can currently do.

You also kinda (for the most part) lose the ability to check if a pattern has already been applied. Not that it's a huge loss as imo ips patches shouldn't be used anymore, and the pattern check hasn't exactly been accurate. But yeah it's far harder to express this stuff inside ini files. Unless you're doing some bytecode shit with an interpreter inside syspatch, might as well go full lua at that point.

 

[bth]

What is the benefit of an ini file approach? Smaller download size is irrelevant because syspatch is already a few kb. You will run into users installing just the ini and not syspatch and vice versa. Then you will have users manually editing the ini file and breaking patches in the process.

Always assume the user is dumb, you'd want to make the process as simple as possible. Single file approach is better for everyone. The ini is only useful for if you want to try and circumvent a dmca by making syspatch just a fancy patch engine, not containing any patches (which wouldn't work btw).

Post automatically merged: Jan 6, 2026

If you're going the way of ini patches, then how do you suggest handling the cond checks that syspatch has? They don't translate so easily to a ini.

You'd either have to have a preset amount of conds in syspatch and then have a switch() over which cond to use (set inside the ini) along with the offset to check. Or you have a basic pattern to match to check stuff, but that's far more limited compared to what syspatch can currently do.

You also kinda (for the most part) lose the ability to check if a pattern has already been applied. Not that it's a huge loss as imo ips patches shouldn't be used anymore, and the pattern check hasn't exactly been accurate. But yeah it's far harder to express this stuff inside ini files. Unless you're doing some bytecode shit with an interpreter inside syspatch, might as well go full lua at that point.

like, if he wants to show what he has done, he should do it as git diffs in the future.

as to sideloading patterns, it can be implemented as a completely optional side feature, but it's uneeded, even for testing, due to the reasons i already have pointed out.

for hot-dropping fixes without requiring recompilation, sure. It needs to be designed before implementation, and a standarization decided upon, in a manner that doesn't conflict with the existing pattern arrays. etc etc

and yes, you would have to pretty much chuck in a whole bunch of conds, if one assumes they are ever unchanging and only ever BL/TBZ

and i did redo the patterns to be able to find the offsets even if .ips patches (or patches.ini) has been deployed before sys-patch in the boot process, so it should be able to find the exact offset even if it was patched now.

 

[bombayjack]

If you're going the way of ini patches, then how do you suggest handling the cond checks that syspatch has? They don't translate so easily to a ini.

You'd either have to have a preset amount of conds in syspatch and then have a switch() over which cond to use (set inside the ini) along with the offset to check. Or you have a basic pattern to match to check stuff, but that's far more limited compared to what syspatch can currently do.

You also kinda (for the most part) lose the ability to check if a pattern has already been applied. Not that it's a huge loss as imo ips patches shouldn't be used anymore, and the pattern check hasn't exactly been accurate. But yeah it's far harder to express this stuff inside ini files. Unless you're doing some bytecode shit with an interpreter inside syspatch, might as well go full lua at that point.

I already did the code and it's working just fine, as for handling the cond checks and ini stuff.

Ini part looks like this:

[fs.noncasigchk_1000-1610]
pattern = "0036 ........ ......71 ....0054 ....4839"
inst_offset = -2
patch_offset = 0
cond_func = "tbz_cond"
patch_func = "noncasigchk_patch"
enabled = true
min_fw = 167772160  # MAKEHOSVERSION(10,0,0)
max_fw = 268566528   # MAKEHOSVERSION(16,1,0)

Struct looks like this:

// Function name → function pointer mapping
static const struct {
    const char* name;
    bool (*cond_func)(u32);
} cond_map[] = {
    {"bl_cond", bl_cond},
    {"ctest_cond", ctest_cond},
    {"mov_cond", mov_cond},
    {"nim_cond", nim_cond},
    {"ret_cond", ret_cond},
    {"stp_cond", stp_cond},
    {"subs_cond", subs_cond},
    {"tbz_cond", tbz_cond},
    {"olsc_cond", olsc_cond},
    {"test_cond", test_cond},
};

static const struct {
    const char* name;
    PatchData(*patch_func)(u32);
} patch_map[] = {
    {"ctest_patch", ctest_patch},
    {"erpt_patch", erpt_patch},
    {"es_patch", es_patch},
    {"ldr_patch", ldr_patch},
    {"nim_patch", nim_patch},
    {"nocntchk_patch", nocntchk_patch},
    {"noncasigchk_patch", noncasigchk_patch},
    {"updateblock_patch", updateblock_patch},
    {"olsc_patch", olsc_patch},
};

I won't bother posting ini loading code or pattern loading function for now as you don't need to know about that. For me it's working fine though, I just need to do some slight tweaks to the overlay for internet connection error checking and I'm done.

As you say though, for a normal user I have to assume they are dumb, so probably I should add some code to the overlay so they can update the sys-module if that needs updated instead of just the ini file.

 

[bth]

I already did the code and it's working just fine, as for handling the cond checks and ini stuff.

Ini part looks like this:

[fs.noncasigchk_1000-1610]
pattern = "0036 ........ ......71 ....0054 ....4839"
inst_offset = -2
patch_offset = 0
cond_func = "tbz_cond"
patch_func = "noncasigchk_patch"
enabled = true
min_fw = 167772160  # MAKEHOSVERSION(10,0,0)
max_fw = 268566528   # MAKEHOSVERSION(16,1,0)

Struct looks like this:

// Function name → function pointer mapping
static const struct {
    const char* name;
    bool (*cond_func)(u32);
} cond_map[] = {
    {"bl_cond", bl_cond},
    {"ctest_cond", ctest_cond},
    {"mov_cond", mov_cond},
    {"nim_cond", nim_cond},
    {"ret_cond", ret_cond},
    {"stp_cond", stp_cond},
    {"subs_cond", subs_cond},
    {"tbz_cond", tbz_cond},
    {"olsc_cond", olsc_cond},
    {"test_cond", test_cond},
};

static const struct {
    const char* name;
    PatchData(*patch_func)(u32);
} patch_map[] = {
    {"ctest_patch", ctest_patch},
    {"erpt_patch", erpt_patch},
    {"es_patch", es_patch},
    {"ldr_patch", ldr_patch},
    {"nim_patch", nim_patch},
    {"nocntchk_patch", nocntchk_patch},
    {"noncasigchk_patch", noncasigchk_patch},
    {"updateblock_patch", updateblock_patch},
    {"olsc_patch", olsc_patch},
};

I won't bother posting ini loading code or pattern loading function for now as you don't need to know about that. For me it's working fine though, I just need to do some slight tweaks to the overlay for internet connection error checking and I'm done.

As you say though, for a normal user I have to assume they are dumb, so probably I should add some code to the overlay so they can update the sys-module if that needs updated instead of just the ini file.

without proper git diff ( https://git-scm.com/docs/git-diff ) its not much value in reading what you're typing out, "we don't need to know about that" applies to everything you're talking about, as there isn't any actual code to read, you keep posting statements that read as hypotheticals.

if you want feedback on something, post actual code diff.

 

[hippy dave]

For the sake of having text here, I'll agree that keeping everything in one file will make it easier on the people here trying to help troubleshoot for noobs.