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

[lsp199308]

The patterns go + 0x2 from start, so the BL cond at 07A880 and the other is a TBZ at 023C88

use https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/check_patches.py as means to verify, i added condition checkers into my pattern searcher



EX: output:

# Firmware version number generated keys for is: 20.0.1

# key revision generated keys for ends with _13

# mariko_master_kek_source_13       = *******************************

# Keygen completed and output to C:\Users\shadowjacker/.switch/prod.keys


Sys-patch for ES string still valid for: 20.0.1

Sys-patch ES pattern found at: 076A38

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.0.1 ES build-id: CF84DE5278AE823734DE630A098C6B1AEEF12894


Sys-patch for NIFM string still valid for: 20.0.1

Sys-patch NIFM pattern found at: 0879C0

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.0.1 NIFM build-id: 2C3E24F46D131685B361FEE1F0570B985095E034


Sys-patch for NIM string still valid for: 20.0.1

Sys-patch NIM pattern found at: 1909A8

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.0.1 NIM build-id: 9A576C1A8BE653CD24C88A8C239DADA3E1EF73F8


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

20.0.1 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 patch, it is found within the pattern.

20.0.1 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 patch, it is found within the pattern.

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

20.0.1 FS-FAT32 SHA256 hash: 6354969E60A7977B5A3C0E25EF39DEC1D84AC43E4F2BE16B3521A4FB4D6D0548


FS-exFAT was skipped for: 20.0.1, due to missing NCA file for exfat in the provided firmware files.

{ "noncasigchk_new", "0x.94..0036.258052", 2, 0, tbz_cond, nop_patch, nop_applied, true, MAKEHOSVERSION(17,0,0), FW_VER_ANY }, // 17.0.0 - 19.0.0+


.. 94 .. .. 00 36 .. 25 80 52 | 2 | 0
= | 2
.. .. 00 36
+ | 0
= patch from same offset as test offset


View attachment 503094

Post automatically merged: May 5, 2025

only 1.5.5 should have been problematic for 20.0.0+, but explicitly only nifm, as it was 0x4 too far ahead. 1.5.6 addresses that part, as the other patches already are confirmed to work.

I've heard of problems with DBI and tinfoil on 20.0.0, but i suspect that's an atmosphere thing that will be addressed by full release of atmosphere 1.9.0 // updates pushed out for at least tinfoil if needed.

existing installs work fine, installing new things does work, but the homebrew themselves have error.

Oh, my God, my ghidra shows an error.

 

[bth]

Oh, my God, my ghidra shows an error.

Just right drag a portion below and before and hit "D"

or ctrl + A -> D (not recommended with file this big)

it's just ghidra switch loader skipping a segment it thinks you don't care about.

 

[hetop]

Most Recent version 1.5.6 with FW 20+ on the downloads section

https://gbatemp.net/download/sys-patch-sysmodule.39124/

I notice it says "Now full supporting Firmware 20+ avoiding crash when PRODINFO is blanked.", is this fix for not crashing when PRODINFO is blanked backwards compatible with FW 19 and earlier? For now, I've been using nim-prodinfo-blank-fix to fix that, but the less software I have to run the better.

 

[Blythe93]

is this fix for not crashing when PRODINFO is blanked backwards compatible with FW 19 and earlier?

It should be backwards compatible.

 

[bth]

I notice it says "Now full supporting Firmware 20+ avoiding crash when PRODINFO is blanked.", is this fix for not crashing when PRODINFO is blanked backwards compatible with FW 19 and earlier? For now, I've been using nim-prodinfo-blank-fix to fix that, but the less software I have to run the better.

The sys-patch string for that (nim) is backwards compatible down to 17.0.0 when it started.

im guessing he thought the crash was NIM related, when 20.0.0 had a NIFM (force network connectivity patch "CTEST") (not NIM) crash related to incorrect pattern hit.

 

[enomaru]

Hi this may be a stupid question, but where am i putting the contents of the syspatches zip? is it in the same place as sigpatches? Thank you

 

[UsernamesAreWeird]

Hi this may be a stupid question, but where am i putting the contents of the syspatches zip? is it in the same place as sigpatches? Thank you

Drag and drop the contents of the zip onto your SD card

 

[impeeza]

Hi this may be a stupid question, but where am i putting the contents of the syspatches zip? is it in the same place as sigpatches? Thank you

extract to the root of your SD Card AS STATED ON THE OP!

 

[Blythe93]

Hi this may be a stupid question, but where am i putting the contents of the syspatches zip? is it in the same place as sigpatches? Thank you

Pretty much, provided that you extract the sigpatches archive and drag and drop it to the root of the SD card.
As it's the case with all homebrew apps (for any console really), if unsure, check the folder structure of the archive and you'll probably know where to paste those files.

 

[aprat_cl]

Hi, i bough a new SD for this, and i was installing my backups, but i get an "NCA Magic Invalid" on DBI and TinFoil. What other installer are you guy using? they work fine?

 

[duckbill007]

but i get an "NCA Magic Invalid"

Issue not in installer. You have corrupted files.

 

[aprat_cl]

Issue not in installer. You have corrupted files.

but, in 18.0.1 they installed fine, i've had them for a while, and they are not new games, also all my backup thows this error... i think something is wrong with the sys-patch or HATS update...

 

[bth]

but, in 18.0.1 they installed fine, i've had them for a while, and they are not new games, also all my backup thows this error... i think something is wrong with the sys-patch or HATS update...

Filesystems can corrupt despite "they've installed fine before".

 

[Blythe93]

but, in 18.0.1 they installed fine, i've had them for a while, and they are not new games, also all my backup thows this error... i think something is wrong with the sys-patch or HATS update...

Can you check your files with NxFileViewer and see if there are any errors?

 

[Blythe93]

Does sys-patch work on the latest firmware (20.1.0)? I'm yet to update so just checking if someone already tried it.

 

[josete2k]

Does sys-patch work on the latest firmware (20.1.0)? I'm yet to update so just checking if someone already tried it.

Yes

 

[alcab]

Hello!

A few weeks ago I finally did a complete migration from sigpatches to sys-patch by deleting all sigpatches in my system, and I am in need of some help, as I do not know if what I see in the log of sys-patch is a problem or not.

I am attaching two images, and I'd be very grateful if someone could tell me if I have to worry about this, although everything seems to be working fine in my Switch.

Sorry for bothering, and thanks a lot for your help.

Best regards.

 

[bth]

Hello!

A few weeks ago I finally migrated from sigpatches to sys-patch, and I am in need of some help, as I do not know if what I see in the log of sys-patch is a problem or not.

I am attaching two images, and I'd be very grateful if someone could tell me if I have to worry about this, although everything seems to be working fine in my Switch.

Sorry for bothering, and thanks a lot for your help.

Best regards.

View attachment 508133View attachment 508134

the only thing abnormal i see is both ctest 1 and ctest2 being patched at the same time, but it doesn't matter that much as ctest2 corrects what ctest1 does incorrectly

the rest should be unpatched


ctest 1 should only apply up to 18.1.0, and ctest2 should only apply to 19.0.0 and above, yet you have both active...?

constinit Patterns nifm_patterns[] = {
    { "ctest", "....................F40300AA....F30314AAE00314AA9F0201397F8E04F8", 16, -16, ctest_cond, ctest_patch, ctest_applied, true, FW_VER_ANY, MAKEHOSVERSION(18,1,0) }, // 1.0.0 - 18.1.0
    { "ctest2", "14...........91...........97...............14", 37, 4, b_cond, ctest_patch, ctest_applied, true, MAKEHOSVERSION(19,0,0), FW_VER_ANY }, //19.0.0 - 20.0.1+
};

 

[alcab]

I will toggle ctest1 patch OFF, then.

Thanks a lot for your help!

 

[Deleted member 413168]

the only thing abnormal i see is both ctest 1 and ctest2 being patched at the same time, but it doesn't matter that much as ctest2 corrects what ctest1 does incorrectly

the rest should be unpatched


ctest 1 should only apply up to 18.1.0, and ctest2 should only apply to 19.0.0 and above, yet you have both active...?

constinit Patterns nifm_patterns[] = {
    { "ctest", "....................F40300AA....F30314AAE00314AA9F0201397F8E04F8", 16, -16, ctest_cond, ctest_patch, ctest_applied, true, FW_VER_ANY, MAKEHOSVERSION(18,1,0) }, // 1.0.0 - 18.1.0
    { "ctest2", "14...........91...........97...............14", 37, 4, b_cond, ctest_patch, ctest_applied, true, MAKEHOSVERSION(19,0,0), FW_VER_ANY }, //19.0.0 - 20.0.1+
};

They have the option to skip fw version, hence why the old fs patches say unpached.