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

[OrGoN3]

I purge the release/tag and stealth update whenever i make changes, but yes,

https://github.com/borntohonk/sys-patch/tree/dev
https://github.com/borntohonk/sys-patch/commit/e88e7e42c2c6bd8dfca7f33f7bb8c616eb1bc68b
https://github.com/borntohonk/sys-patch/releases/tag/v1.5.9

(as reference)
https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py
(for validation)
https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/find_patterns.py

(v3 because i forgot a cond in ctest_cond)

Sneaky sneaky, hehe. Thank you!

 

[Taffer]

In my overlay, sys-modules says sys-patch is turned off. When I turn it on, it turns off in few seconds. How can I make it work?

 

[Nephiel]

In my overlay, sys-modules says sys-patch is turned off. When I turn it on, it turns off in few seconds. How can I make it work?

This has been asked and answered so many times. It's not supposed to stay on, sys-patch does the patching when the console boots, and then quits until next boot.

 

[Taffer]

This has been asked and answered so many times. It's not supposed to stay on, sys-patch does the patching when the console boots, and then quits until next boot.

Thank you for clarification. I thought I did something wrong.

 

[bth]

Thank you for clarification. I thought I did something wrong.

the overlay is a cosmetic addon which does none of the core functions.
it's a conditonally optional thing which only reads a text-file/config-file for its output and edits the text-file/config-file if the user makes that action.

it's only loaded if the user has sys-ovlloader running on the console.

it's the sysmodule part of sys-patch that actually does anything.

 

[Taffer]

the overlay is a cosmetic addon which does none of the core functions.
it's a conditonally optional thing which only reads a text-file/config-file for its output and edits the text-file/config-file if the user makes that action.

it's only loaded if the user has sys-ovlloader running on the console.

it's the sysmodule part of sys-patch that actually does anything.

Thank you for explanation

 

[bombayjack]

For those that want this, I've added nintendo host blocking to the options in the overlay + added a few changes to the main program. Attached is the souce for those that want to compile themselves.

 

[bth]

For those that want this, I've added nintendo host blocking to the options in the overlay + added a few changes to the main program. Attached is the souce for those that want to compile themselves.

see

example, most of current patterns include the very cond_check in it, which is bad design (my personal opinion), as it also prevents searching for a pre-patched binary for the pattern (should i fix this? Yes. have i yet? no. why? im lazy)

example:

{ "nocntchk_19.0.0+", "0x40f9...94..40b9..0012", 2, 0, bl_cond, ret0_patch, ret0_applied, true, MAKEHOSVERSION(19,0,0), FW_VER_ANY },
where bl_cond is testing the 4th byte from offset 0x2 of the pattern, which becomes..."...94" (21.0.0+ = "6AB80394")
and bl_cond is valid at both 0x25 and 0x94 (!) and we are patching this with "E0031F2A"
the pattern cannot find "40f9e0031f2a..40b9..0012" as the pattern itself prevents that.

what we found initially before patching was "40f96ab80394..40b9..0012""
changing this, it wouldn't matter if the bl instruction we were patching was 0x25 in the 4th byte or 0x94 in the 4th byte, as that's what the bl_cond check exists for, it doesn't require ...94 or ...25 to be in the pattern, that's redundant.

the bytes being tested, and the bytes being patched, should be wildcarded inside the pattern, if it was, both results would be valid, and essentially is how sys-patch verifies if something is patched by file or not, it cannot verify if it cannot find the pattern, and it cannot find the pattern if the patterns include the "_cond" (which is the 4th byte of an arm instruction)

i have already addressed all of the problems relating to this, but your code still has this problem.


also:
https://github.com/borntohonk/sys-patch/blob/master/sysmod/src/main.cpp#L260-L263

(your first patch in this code does ret_cond, with offset of 0, 0, when it should be 0, 4, but testing for ret and patching unrelated bytes is stupid.

see https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py#L91-L166
(also )
for correct alignment.


(incase alignment of nocasigchk is questioned, N refactored that function in 17.0.0)

 

[bombayjack]

see



i have already addressed all of the problems relating to this, but your code still has this problem.


also:
https://github.com/borntohonk/sys-patch/blob/master/sysmod/src/main.cpp#L260-L263

(your first patch in this code does ret_cond, with offset of 0, 0, when it should be 0, 4, but testing for ret and patching unrelated bytes is stupid.

see https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py#L91-L166
(also )
for correct alignment.


(incase alignment of nocasigchk is questioned, N refactored that function in 17.0.0)

View attachment 546939

I know how the code works in reference to the update blocking patch and the ret_cond, and the code I posted is correct. I've tested on every firmware from 10-21+ and it's working just fine. I also have debugging code (not posted) which confirms the checks are correct. I'll take a look at your code later, but currently I already tested all of the patterns I have for each patch on each firmware from 10.x-21.1.0 and don't have any issues. Everything is being patched properly and the checks work fine and return the correct boolean value.

 

[bth]

I know how the code works in reference to the update blocking patch and the ret_cond, and the code I posted is correct. I've tested on every firmware from 10-21+ and it's working just fine. I also have debugging code (not posted) which confirms the checks are correct. I'll take a look at your code later, but currently I already tested all of the patterns I have for each patch on each firmware from 10.x-21.1.0 and don't have any issues. Everything is being patched properly and the checks work fine and return the correct boolean value.

you are applying your patch in territory in padded bytes of "00 00 00 00 00 00 00 00 00 00 00 00" by targeting ret as your validation condition, in most of the firmwares. see: https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py#L91-L139

using your eyes, and not LLM/AI, you can instantly see a visual pattern, of what im talking about.

that and the way sys-patch functions, requires for the pattern to hit a unique address, without the bytes of the entire length of a patch being applied to be within the pattern itself, otherwise it cannot find a match if someone has patched it by .ips patch or hekate applied patch. (* unless one of the bytes of the patch aligns with the address being patched, if it does, wildcard the ones that doesn't)


example of problematic pattern:
on 21.0.0 + nocntchk is fine with "00..0240F9....E8.....00...00...00"
but on 19.0.0 to 20.5.0 that same pattern produces a whole lot of duplicates. ("00..0240F9....08.....00...00...00")
tuning out the duplicates makes the pattern longer, like this "00..0240F9....08.....00...00...0054", theres now zero duplicates produced.

see this for that example:
( using https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/find_patterns.py )





on unrelated note:
this needs testing, if anyone is willing.
https://github.com/borntohonk/sys-patch/commit/136d156851b064844ee118f9566ca784529acfc6



do the following:
delete /atmosphere/exefs_patches/
reboot with this version of sys-patch active
check /atmosphere/exefs_patches/


if folders are made, visit /atmosphere/exefs_patches/es_patches/
if an .ips file has been made


provide the filename, and make a .zip of /atmosphere/exefs_patches/ and the ,zip archive and provide the filename of the .ips file that was made

 

[bombayjack]

you are applying your patch in territory in padded bytes of "00 00 00 00 00 00 00 00 00 00 00 00" by targeting ret as your validation condition, in most of the firmwares. see: https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py#L91-L139

using your eyes, and not LLM/AI, you can instantly see a visual pattern, of what im talking about.

that and the way sys-patch functions, requires for the pattern to hit a unique address, without the bytes of the entire length of a patch being applied to be within the pattern itself, otherwise it cannot find a match if someone has patched it by .ips patch or hekate applied patch. (* unless one of the bytes of the patch aligns with the address being patched, if it does, wildcard the ones that doesn't)


example of problematic pattern:
on 21.0.0 + nocntchk is fine with "00..0240F9....E8.....00...00...00"
but on 19.0.0 to 20.5.0 that same pattern produces a whole lot of duplicates. ("00..0240F9....08.....00...00...00")
tuning out the duplicates makes the pattern longer, like this "00..0240F9....08.....00...00...0054", theres now zero duplicates produced.

see this for that example:
( using https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/find_patterns.py )





on unrelated note:
this needs testing, if anyone is willing.
https://github.com/borntohonk/sys-patch/commit/15c84264a6138708cfc84019d3d48b47db5ab118


do the following:
delete /atmosphere/exefs_patches/


reboot
check to see if there's any new files in:
/atmosphere/exefs_patches/es_patches/

make a .zip of /atmosphere/exefs_patches/ and upload it, kindly.

Your code doesn't produce any files or even the folders, you need to mount the sd card for it to create these,( I didn't check your code to see if you are doing this properly) ini files are created without mounting because the ini library deals with that. But for anything else like writing logs/ips files or reading/writing files on the sd card you need to mount it. Did you even test your code on a real switch? You mentioned on 21.0.0 + nocntchk is fine with "00..0240F9....E8.....00...00...00" but on lower firmware it's not, this is not an issue as the patterns are controlled by mix & max HOS Version, so patch patterns will not be used on any other firmware it's not made for.

 

[bth]

Your code doesn't produce any files or even the folders, you need to mount the sd card for it to create these, ini files are created without mounting because the ini library deals with that. But for anything else like writing logs/ips files or reading/writing files on the sd card you need to mount it. Did you even test your code on a real switch? You mentioned on 21.0.0 + nocntchk is fine with "00..0240F9....E8.....00...00...00" but on lower firmware it's not, this is not an issue as the patterns are controlled by mix & max HOS Version, so patch patterns will not be used on any other firmware it's not made for.

the ini library doesn't invoke fsdevMountSdmc, sys-patch in all contexts uses 'fsOpenSdCardFileSystem' to mount the sd card. ( a libnx concept, https://github.com/switchbrew/libnx/blob/master/nx/source/services/fs.c#L257 )

https://github.com/borntohonk/sys-patch/blob/dev/sysmod/src/main.cpp#L580

are you using LLM/AI to generate your replies here...?

 

[bombayjack]

the ini library doesn't invoke fsdevMountSdmc, sys-patch in all contexts uses 'fsOpenSdCardFileSystem' to mount the sd card. ( a libnx concept, https://github.com/switchbrew/libnx/blob/master/nx/source/services/fs.c#L257 )

https://github.com/borntohonk/sys-patch/blob/dev/sysmod/src/main.cpp#L623

are you using LLM/AI to generate your replies here...?

Your witty reply still doesn't make your code generate any ips patches or folders, maybe concentrate on fixing that and testing your code (on a real switch) before you post it rather than semantics.

As for worrying about my patterns, don't - I can see exactly what's being patched - example:

[NetworkInteface.updateblock-1500+]
IDA_offset_address=0x114600
Actual_offset_address=0x114500
Memory_address=0x5B42F14500
Original_instruction first 4 bytes=0xFD7BBCA9
Patched_instruction=E0031FAA C0035FD6
Result=Patched (sys-patch)

 

[bth]

Your witty reply still doesn't make your code generate any ips patches or folders, maybe concentrate on fixing that and testing your code before you post it rather than semantics.

no for real, are you using LLM/AI to generate your replies here?

the implementation is very straight forward, even cited in the libraries you're referencing.

you may think im being "witty", but i'm geniuinly curious.

static bool ini_open(const char* filename, struct NxFile* nxfile, u32 mode) {
    Result rc = {0};
    char filename_buf[FS_MAX_PATH] = {0};

    if (R_FAILED(rc = fsOpenSdCardFileSystem(&nxfile->system))) {
        return false;
    }

    strcpy(filename_buf, filename);

    if (R_FAILED(rc = fsFsOpenFile(&nxfile->system, filename_buf, mode, &nxfile->file))) {
        if (mode & FsOpenMode_Write) {
            if (R_FAILED(rc = fsFsCreateFile(&nxfile->system, filename_buf, 0, 0))) {
                fsFsClose(&nxfile->system);
                return false;
            } else {
                if (R_FAILED(rc = fsFsOpenFile(&nxfile->system, filename_buf, mode, &nxfile->file))) {
                    fsFsClose(&nxfile->system);
                    return false;
                }
            }
        } else {
            fsFsClose(&nxfile->system);
            return false;
        }
    }

    nxfile->offset = 0;
    return true;
}

 

[bombayjack]

no for real, are you using LLM/AI to generate your replies here?

the implementation is very straight forward, even cited in the libraries you're referencing.

you may think im being "witty", but i'm geniuinly curious.

static bool ini_open(const char* filename, struct NxFile* nxfile, u32 mode) {
    Result rc = {0};
    char filename_buf[FS_MAX_PATH] = {0};

    if (R_FAILED(rc = fsOpenSdCardFileSystem(&nxfile->system))) {
        return false;
    }

    strcpy(filename_buf, filename);

    if (R_FAILED(rc = fsFsOpenFile(&nxfile->system, filename_buf, mode, &nxfile->file))) {
        if (mode & FsOpenMode_Write) {
            if (R_FAILED(rc = fsFsCreateFile(&nxfile->system, filename_buf, 0, 0))) {
                fsFsClose(&nxfile->system);
                return false;
            } else {
                if (R_FAILED(rc = fsFsOpenFile(&nxfile->system, filename_buf, mode, &nxfile->file))) {
                    fsFsClose(&nxfile->system);
                    return false;
                }
            }
        } else {
            fsFsClose(&nxfile->system);
            return false;
        }
    }

    nxfile->offset = 0;
    return true;
}

As I said, worry more about fixing your untested code. FYI I created a bin launcher overlay, it scans sdmc:/bootloader/payloads folder for bin files and lets you launch them, I was thinking about making a sub menu for sys-patch-plus overlay and adding the code from this so you can reboot to whatever payload you want. Do you think I should bother or just keep it as a seperate overlay.

 

[garbagehuman123]

why is this bombayclow even allowed to keep shitspoting in here

 

[Zoria]

I don't understand the point of the discussion either. Bombayjack clearly isn't trying to listen to the advice he's being given and prefers to do absolutely everything with AI, which may be helpful, but I seriously doubt that AI is capable of this type of code on Switch...

 

[Earthshine]

I purge the release/tag and stealth update whenever i make changes, but yes,

https://github.com/borntohonk/sys-patch/tree/master
https://github.com/borntohonk/sys-patch/commit/e27cc1ad29578a229bda13f000d0ac3d7039b563
https://github.com/borntohonk/sys-patch/releases/tag/v1.5.9

(as reference)
https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py
(for validation)
https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/find_patterns.py

(it now is aligned correctly: https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py#L96-L137 )


this is the final version of 1.5.9 - ready for PR'ing upstream


changelog:
refactors conds, patterns
removes ssl patches
attempts to address two memory bugs.

Should we be using this instead of 1.5.8 from impeezas git? I noticed the ""Disable CA Verification" options are gone in your 1.5.9. Was that to prevent people from messing with them when they don't know what they do? Also, for a long time I have thought that patching sysMMC should be turned OFF by default, instead of enabled.

 

[bth]

Should we be using this instead of 1.5.8 from impeezas git? I noticed the ""Disable CA Verification" options are gone in your 1.5.9. Was that to prevent people from messing with them when they don't know what they do? Also, for a long time I have thought that patching sysMMC should be turned OFF by default, instead of enabled.

There isn't a rush to PR it upstream just yet, 1.5.8 is fine for now, i have just pushed a 1.5.9 myself which refactors almost every pattern and conds, and addresses the overlap memory buffer stuff. (i.e. this commit: https://github.com/borntohonk/sys-patch/commit/e27cc1ad29578a229bda13f000d0ac3d7039b563 )

ideally the ips-beta is tested and validated before i send an official PR upstream,
basically, im unsure if the kernel debug svc atmosphere has implemented provides the header of the module being loaded or not (which is what sys-patch uses!)

if the header isn't loaded then the buildID for the .ips filename also cannot be acquired, if it can't, then 1.5.9 is ready to be PR'd already today. (i haven't yet, as there is no rush to push a refactor, at the current moment, a new feature can be included then it'd be better for it to be 1.5.9 rather than 1.6.0)

https://github.com/borntohonk/sys-patch/releases/tag/v1.5.9-ips-beta

https://github.com/Atmosphere-NX/At...bmesosphere/source/svc/kern_svc_debug.cpp#L96
https://github.com/Atmosphere-NX/At.../include/mesosphere/kern_k_debug_base.hpp#L59
https://github.com/Atmosphere-NX/At...here/svc/svc_stratosphere_shims.hpp#L422-L424
https://github.com/switchbrew/libnx/blob/master/nx/include/switch/kernel/svc.h#L1354
https://github.com/Atmosphere-NX/At...phere/source/svc/kern_svc_debug.cpp#L274-L291
https://github.com/Atmosphere-NX/At...phere/source/svc/kern_svc_debug.cpp#L533-L535
https://github.com/Atmosphere-NX/At...phere/source/svc/kern_svc_debug.cpp#L479-L481

Disable CA Verification was removed because people shouldn't be enabling it, and people who have the actual mitm setups required can use https://github.com/misson20000/exef...osphere/exefs_patches/disable_ca_verification the .ips patches for it.

as for sysmmc, patching there should ideally be off by default, but if it is patching there by default, then well, yeah... the git blame would say that it was iTotalJustice that did that.

https://github.com/impeeza/sys-patc...276c9c4ae95053830d7f1d3deaf009a4625409ad2R369


i personally disagree with that behaviour, but at same time, it's been that way for a long time and changing the behaviour now might inconvenience certain set of users.


(i have PR / merge permissions in impeeza's github, but i feel no desire to force merge a refactor which isn't strictly necessary, as sys-patch 1.5.8 functions just fine, but i will send a PR soon)

 

[AllOver]

There isn't a rush to PR it upstream just yet, 1.5.8 is fine for now, i have just pushed a 1.5.9 myself which refactors almost every pattern and conds, and addresses the overlap memory buffer stuff. (i.e. this commit: https://github.com/borntohonk/sys-patch/commit/e27cc1ad29578a229bda13f000d0ac3d7039b563 )

ideally the ips-beta is tested and validated before i send an official PR upstream,
basically, im unsure if the kernel debug svc atmosphere has implemented provides the header of the module being loaded or not (which is what sys-patch uses!)

if the header isn't loaded then the buildID for the .ips filename also cannot be acquired, if it can't, then 1.5.9 is ready to be PR'd already today. (i haven't yet, as there is no rush to push a refactor, at the current moment, a new feature can be included then it'd be better for it to be 1.5.9 rather than 1.6.0)

https://github.com/borntohonk/sys-patch/releases/tag/v1.5.9-ips-beta

https://github.com/Atmosphere-NX/At...bmesosphere/source/svc/kern_svc_debug.cpp#L96
https://github.com/Atmosphere-NX/At.../include/mesosphere/kern_k_debug_base.hpp#L59

Disable CA Verification was removed because people shouldn't be enabling it, and people who have the actual mitm setups required can use https://github.com/misson20000/exef...osphere/exefs_patches/disable_ca_verification the .ips patches for it.

as for sysmmc, patching there should ideally be off by default, but if it is patching there by default, then well, yeah... the git blame would say that it was iTotalJustice that did that.

https://github.com/impeeza/sys-patc...276c9c4ae95053830d7f1d3deaf009a4625409ad2R369


i personally disagree with that behaviour, but at same time, it's been that way for a long time and changing the behaviour now might inconvenience certain set of users.


(i have PR / merge permissions in impeeza's github, but i feel no desire to force merge a refactor which isn't strictly necessary, as sys-patch 1.5.8 functions just fine, but i will send a PR soon)

The issue with having sysMMC patching disabled by default is that it means syspatch is no longer drag and drop. The user will either have the overlay installed and enable the settings and reboot again (too confusing for most AIO users, and most temp users from what I've read), or manually edit the config.

I don't think syspatch has been problematic enough to where enabling it by default causes issues. I can foresee that changing this behaviour would cause much confusion for many users, and I agree with you that it will break some user setups, including me (I only use sysMMC).