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

[josete2k]

that also is an option

I did it in this ovl

Homebrew Homebrew app  Post in thread 'sys-patch - sysmod that patches on boot'

Nov 24, 2025

Nothing special, but maybe explain or categorise patches in the overlay. Currently they're all grouped together which users seem to think they all have equal value, which is why they ask on here why it's disabled etc.

So those patches could be moved into another subheading like "for developers" or "advanced". You can go further and group patches that are disabled due to the fw being too old/new as "deprecated" or "unsupported fw". Or add some info text under each patch that very summarises what it does, such as for ldr and fs: "allows for modified title to be launched by skipping...

• josete2k

 

[bth]

I did it in this ovl

Homebrew Homebrew app  Post in thread 'sys-patch - sysmod that patches on boot'

Nov 24, 2025

Nothing special, but maybe explain or categorise patches in the overlay. Currently they're all grouped together which users seem to think they all have equal value, which is why they ask on here why it's disabled etc.

So those patches could be moved into another subheading like "for developers" or "advanced". You can go further and group patches that are disabled due to the fw being too old/new as "deprecated" or "unsupported fw". Or add some info text under each patch that very summarises what it does, such as for ldr and fs: "allows for modified title to be launched by skipping...

• josete2k

i opted to remove ssl patches entirely, as their uses requires the end user to set up an actual physical mitm (not dns-mitm) and sign https queries with their own prodinfo/certificate and is strictly for reversing https communication with nintendo, no other usage.

so grouping as advanced or for developers strictly not necessary, the ERPT patch itself is benign, shouldn't be necessary, but also not advanced.

 

[bombayjack]

I already do that synthetically with just the firmware files on pc... and with ghidra, etc.
for the people doing maintenance on sys-patch, who already know how to reverse engineer/port-forward patches, i personally don't need that, if anyone else needs that (who is not me), they are more than free to make sys-patch do that, but it's strictly not necessary.

ex implementation:
in the sysmodule portion, write to separate new file, or append to log file.
overlay does not need it, nor does overlay know it, as the sysmodule portion exits memory before boot, unless overlay portion parses the log file with the offsets after implementing it capturing the offsets and writing them down, in the sysmodule portion.

(the overlay does not need it ever, basically)




implementation of logging the offsets, would have its offsets be taken from here: https://github.com/impeeza/sys-patch/blob/master/sysmod/src/main.cpp#L383-L418

I''ve written new code/functions yesterday to print out some advanced logs now, they still need a little work but these are the logs it prints out, if shows lots of patch information, such as what patches were used, addresses patched in memory and in the relevant modules, and addresses to to use for IDA. This is handy to make sure we are not patching new firmware with old patches as sometime these routines can inadverantly be patched. I still need to do some tweaks and is not useful for the average user, but for nerds it's quite handy information to have.

 

[bth]

I''ve written new code/functions yesterday to print out some advanced logs now, they still need a little work but these are the logs it prints out, if shows lots of patch information, such as what patches were used, addresses patched in memory and in the relevant modules, and addresses to to use for IDA. This is handy to make sure we are not patching new firmware with old patches as sometime these routines can inadverantly be patched. I still need to do some tweaks and is not useful for the average user, but for nerds it's quite handy information to have.

this is written to mirror what sys-patch does https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/check_patches.py

I'm not entirely sure what you mean by "to make sure we are not patching new firmware with old patches as sometime these routines can inadverantly be patched", as that doesn't really happen, the old patches are cut-off by min/max firmware defined in the patterns.

sometimes patterns can hit other functions with new firmwares and require adjustments (preferably just blanking bit registers in the arm instructions after comparing the two and finding a common wildcard regex pattern, and hitting the intended function in both old and new firmwares), but sometimes new pattern entries are needed for new firmwares (usually only when nintendo refactors FS/ES, or adds padding bytes to NIFM like in 21.0.0)

 

[duckbill007]

but for nerds it's quite handy information to have.

I think people who can use IDA already knows what to search there. So it is just a useless strings in the log.

 

[bth]

I think people who can use IDA already knows what to search there. So it is just a useless strings in the log.

this is why i said as much that people who aren't me can implement it if they want, as the people who can submit fixes to sys-patch if i don't exist anymore already can work ghidra/ida and know where to look (hopefully, if not they can figure out diffing previous to new firmware if N refactored and find the new function, but my experience in general is everytime FS has been refactored no one else has fixed .ips/hekate patches/sys-patch until i reverse it again :^) )

 

[bombayjack]

this is written to mirror what sys-patch does https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/check_patches.py

I'm not entirely sure what you mean by "to make sure we are not patching new firmware with old patches as sometime these routines can inadverantly be patched", as that doesn't really happen, the old patches are cut-off by min/max firmware defined in the patterns.

sometimes patterns can hit other functions with new firmwares and require adjustments (preferably just blanking bit registers in the arm instructions after comparing the two and finding a common wildcard regex pattern, and hitting the intended function in both old and new firmwares), but sometimes new pattern entries are needed for new firmwares (usually only when nintendo refactors FS/ES, or adds padding bytes to NIFM like in 21.0.0)

I've Updated that code now, it's working great - I've also modified the pattern searching code to support byte nibble patches with high byte and low byte patterns, example - 01.99.AF (old), 0...99...F (enhanced). This can make the pattern searching better, example:

Example NEW simpler ES Patterns: Add 0x12 from found to patch offset
0094..6.00........................97..............A9 (FW 9.0.1)
0094....00........................97..............A9....................0491C0035FD6 (all other FW to 21.0.1)

 

[bth]

I've Updated that code now, it's working great - I've also modified the pattern searching code to support byte nibble patches with high byte and low byte patterns, example - 01.99.AF (old), 0...99...F (enhanced). This can make the pattern searching better, example:

Example NEW simpler ES Patterns: Add 0x12 from found to patch offset
0094..6.00........................97..............A9 (FW 9.0.1)
0094....00........................97..............A9....................0491C0035FD6 (all other FW to 21.0.1)

if its a match on all firmwares, then that of course is a good change, but the longer arm byte pattern instructions you chain togheter, the more likely it is the code will change, but being able to filter bits in the arm instructions does significanly make things easier.

 

[bombayjack]

if its a match on all firmwares, then that of course is a good change, but the longer arm byte pattern instructions you chain togheter, the more likely it is the code will change, but being able to filter bits in the arm instructions does significanly make things easier.

They really just look longer, but that's only because you can see .. instead of . so it looks twice as big to what you are using. I reversed various ES down to 9.0.1 to check. I'm building a database just now with all offsets and patterns and checking for matches in patches and instructions so I can make things simpler. I still have a few more code tweaks to do to the main code. such as being able to use an ini file with patterns so if that exists when the program runs it can use that instead of hard coded values, that way I don't need to recompile the program when testing new patches on newer firmware, and I can see exactly now what addresses have been patched and what patches were used without needing to use the overlay. I've also made lots of different emu nands for each firmware sdk versions so I can check each one of them works properly. Once done I'll share my code with you and you can take what you want from it.

Also I tested all ES patch locs and patterns from sdk 9.3.0.0 to latest, here's the results:

SDKVersion: 9.3.0.0 - Probable patch offset location: 0x0002D3D4
SDKVersion:10.4.0.0 - Probable patch offset location: 0x0002DCAC
SDKVersion:11.4.0.0 - Probable patch offset location: 0x0002D0CC
SDKVersion:12.3.0.0 - Probable patch offset location: 0x0002E61C
SDKVersion:13.4.0.0 - Probable patch offset location: 0x00031A28
SDKVersion:14.3.0.0 - Probable patch offset location: 0x000663D8
SDKVersion:15.3.0.0 - Probable patch offset location: 0x00064AEC
SDKVersion:16.2.0.0 - Probable patch offset location: 0x00064B6C
SDKVersion:17.5.0.0 - Probable patch offset location: 0x0006730C
SDKVersion:18.3.0.0 - Probable patch offset location: 0x0006974C
SDKVersion:19.3.0.0 - Probable patch offset location: 0x0006A3F8
SDKVersion:20.5.4.0 - Probable patch offset location: 0x00076B18
SDKVersion:21.4.0.0 - Probable patch offset location: 0x000736B0

Search Patterns:
SDKVersion:9.3.0.0 - 0094..6.00......................F.97..............A9
SDKVersion:10.4.0.0 > 21.4.0.0 - .0....6300......................F.97..............A9................FF..0491C0035FD6

 

[Earthshine]

I see 1.5.8 v5 on impeezas git from 2 weeks ago but it looks like it was not uploaded to gbatmep. Only v4 here.

 

[bth]

I see 1.5.8 v5 on impeezas git from 2 weeks ago but it looks like it was not uploaded to gbatmep. Only v4 here.

only thing that should be different from v4 to v5 is the new optional no-erpt patch which requires users manually enabling it, was not working in v4.

the expected behaviour of sys-patch works as is, new feature no one has adopted yet, thats what v5 fixes.

 

[bombayjack]

only thing that should be different from v4 to v5 is the new optional no-erpt patch which requires users manually enabling it, was not working in v4.

the expected behaviour of sys-patch works as is, new feature no one has adopted yet, thats what v5 fixes.

You should look at the code in that again, because when I was looking at some of the patches, I can't remember if it was es or fs patches but (off the top of my head) for lower firmares from about 10>12 some of the patches were wrong. They were checking the wrong bit shifting instructions to patch. I've re-written a lot of the code now and have extra features added and updated ALL the patches and logic for checking they are correct. I can share my code if you are interested, but if not it's not a problem as I will end up putting it on github when I have completed adding some more stuff.

 

[OrGoN3]

You should look at the code in that again, because when I was looking at some of the patches, I can't remember if it was es or fs patches but (off the top of my head) for lower firmares from about 10>12 some of the patches were wrong. They were checking the wrong bit shifting instructions to patch. I've re-written a lot of the code now and have extra features added and updated ALL the patches and logic for checking they are correct. I can share my code if you are interested, but if not it's not a problem as I will end up putting it on github when I have completed adding some more stuff.

You're kind of obligated to share your code. Properly fork it on GitHub and share the link.

 

[bombayjack]

You're kind of obligated to share your code. Properly fork it on GitHub and share the link.

Hmmm, no I'm not. If I was uploading binaries and stuff then I would only need to include the licence. I'll share it with bth If he asks for it, but I'm in no way obliged to. Also the original code was written by ITotalJustice and DCMA'd by nintendo ninjas, so putting it on github is just asking for trouble. Actually if you read the licence you will see that, Here's the licence code to remind you.

MIT License

Copyright (c) 2023 ITotalJustice

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

 

[OrGoN3]

Hmmm, no I'm not. If I was uploading binaries and stuff then I would only need to include the licence. I'll share it with bth If he asks for it, but I'm in no way obliged to. Also the original code was written by ITotalJustice and DCMA'd by nintendo ninjas, so putting it on github is just asking for trouble. Actually if you read the licence you will see that, Here's the licence code to remind you.

MIT License

Copyright (c) 2023 ITotalJustice

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Yet it's on GitHub. Okay. So then keep it to yourself. Really weird flex though. Mention you fixed a now community supported program that is widely used, but don't actually share any of it with the same community. And people wonder why this scene is toxic.

Enjoy your private sys-patch! I'll stick with sigpatches.

Edit: you said you would put it on GitHub when you're done adding more things, but then you said you wouldn't put it on GitHub to not take the risk?

 

[bombayjack]

Enjoy your private sys-patch! I'll stick with sigpatches.

Or you can just use both, like I do and so do some others do. I had the sigpatches for the latest FW before sys-patch was updated (and it was wrong for es patches for a while) and before Atmosphere was updated, the previous modded fusse.bin was working with them, even though I did modify the current version when the Atmosphere code was updated.

 

[OrGoN3]

Or you can just use both, like I do and so do some others do. I had the sigpatches for the latest FW before sys-patch was updated (and it was wrong for es patches for a while) and before Atmosphere was updated, the previous modded fusse.bin was working with them, even though I did modify the current version when the Atmosphere code was updated.

Sure. And two layers of security. If there's something wrong with the patches, sys-patch will make it better. Definitely not a bad suggestion.

Good luck with the changes!

 

[bombayjack]

Sure. And two layers of security. If there's something wrong with the patches, sys-patch will make it better. Definitely not a bad suggestion.

Good luck with the changes!

Here's the latest code, so far I've updated patching routines for "nibble patterns", updated all the patches and checked them from firmware 10.0.0 to current, added advanced logging (see config folder for added ini files if this is enabled). Updated the overlay. Added better patch instruction checks. I've a few more things to add (when I get around to it), maybe I'll add a check for update function in the overlay? or add an ini patterns file to bypass hard coded patterns.

 

[NinStar]

Do newer sys-patch releases include the erpt_report toggle? I only remember seeing a single fork for firmware 19 having this feature (which is the one I'm currently using).

 

[OrGoN3]

Do newer sys-patch releases include the erpt_report toggle? I only remember seeing a single fork for firmware 19 having this feature (which is the one I'm currently using).

Impeeza's does. And the main release on his GitHub was silently updated to include this feature.

Edit: yeah it was tomvita's fork.