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

[bombayjack]

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).

I just delete that folder and create a blank file called "erpt_report", that way nothing can ever get written as you can't write a file into a folder or create a folder with the same name as the file, you can do the same for other folders that log stuff.

 

[AllOver]

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.

Privately, syspatch does support ini patches. It's not worth it really as the program is better off as a self contained single file exe, rather than a bunch of loose files. Not to mention that ini files make the run time slower. The ini files could be used as a way to dance around a dmca by not actually including patches, but instead syspatch becomes a patch engine.

Another benefit of the ini patches is that it would in a single repo for syspatch and likely other repos for community patches. This however would be awful user experience as they'd have to source the patches themselves, which would likely result in more awful aio packs and terrible experience for those offering support. Also, syspatch has remained as a single fork anyway, and trouble shooting has been reasonable painless, just update and reboot and usually that's all a user needs to do. So I don't think the ini stuff is a good idea for devs or users.

 

[bombayjack]

Privately, syspatch does support ini patches. It's not worth it really as the program is better off as a self contained single file exe, rather than a bunch of loose files. Not to mention that ini files make the run time slower. The ini files could be used as a way to dance around a dmca by not actually including patches, but instead syspatch becomes a patch engine.

Another benefit of the ini patches is that it would in a single repo for syspatch and likely other repos for community patches. This however would be awful user experience as they'd have to source the patches themselves, which would likely result in more awful aio packs and terrible experience for those offering support. Also, syspatch has remained as a single fork anyway, and trouble shooting has been reasonable painless, just update and reboot and usually that's all a user needs to do. So I don't think the ini stuff is a good idea for devs or users.

You're probably correct, It was more for devs and advanced users for testing patterns, I was thinking that it could be both hard coded and ini support, so if the ini file existsed and contained the patches it would use that, if it didn't exist it would use hard coded values. To be honest I don't really need this as I have other private software to do the same thing, thanks for you reply though I will take that point of view on board.

 

[ber71]

I just delete that folder and create a blank file called "erpt_report", that way nothing can ever get written as you can't write a file into a folder or create a folder with the same name as the file, you can do the same for other folders that log stuff.

That works for everyday usage but causes issues in some games iirc.

 

[bth]

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.

i personally do not diff lower than 17.0.0 as that's when nintendo completely refactored their rights management modules ("DRM"). and that was reflected on their changes for FS (also in 17.0.0).

They don't really make that much of radical changes anymore in the underlying logic, aside from adding more to the chain before the functions we patch, but we deliberately let the functions play out and just change the outcome of the that ultimately is called.

technically we are failing every single check we patch, and just returning success within the scope of the check, and that is passed recursively up to the original calling function.

while sys-patch at that point was inspired mostly by some of my private notes and scripts at the time (i had zero involvement in the actual creation of sys-patch), their pre-16.0.0 everything was mostly some volunteer who i spoke to a few times while trying to gaslight people into learning how to reverse engineer and port-forward patches themselves, who was the one who figured out why not just patch one offset for ES instead of 3, after coaxing said volunteer into doing it himself.

Also the original code was written by ITotalJustice and DCMA'd by nintendo ninjas,

my memory of this differs, another project of his was DMCA'd, the repository simply named "patches", which contained hekate and .ips patches, with no scripts or code in the repository, just the releases.

he voluntarily took down his other repositories for unrelated reasons, and later (recently) deleted all his accounts everywhere, because nintendos archbox lawsuit resulting in default has some "chilling effects" , as one of the key components of the lawsuit is the fact he operated sigmapatches (the website hosting lockpick rcm, prod.keys and sigpatches).

 

[AllOver]

i personally do not diff lower than 17.0.0 as that's when nintendo completely refactored their rights management modules ("DRM"). and that was reflected on their changes for FS (also in 17.0.0).

They don't really make that much of radical changes anymore in the underlying logic, aside from adding more to the chain before the functions we patch, but we deliberately let the functions play out and just change the outcome of the that ultimately is called.

technically we are failing every single check we patch, and just returning success within the scope of the check, and that is passed recursively up to the original calling function.

while sys-patch at that point was inspired mostly by some of my private notes and scripts at the time (i had zero involvement in the actual creation of sys-patch), their pre-16.0.0 everything was mostly some volunteer who i spoke to a few times while trying to gaslight people into learning how to reverse engineer and port-forward patches themselves, who was the one who figured out why not just patch one offset for ES instead of 3, after coaxing said volunteer into doing it himself.


my memory of this differs, another project of his was DMCA'd, the repository simply named "patches", which contained hekate and .ips patches, with no scripts or code in the repository, just the releases.

he voluntarily took down his other repositories for unrelated reasons, and later (recently) deleted all his accounts everywhere, because nintendos archbox lawsuit resulting in default has some "chilling effects" , as one of the key components of the lawsuit is the fact he operated sigmapatches (the website hosting lockpick rcm, prod.keys and sigpatches).

The last part isn't completely true. Maybe it was in the beginning, but arch was not operating the site for the majority of the time. One of fitgirl releasers hosted the site whilst another user ran scripts to update stuff. Arch had involvement with most things, but usually only so far as talking to people and bringing different people together to get stuff done, so basically networking.

 

[bth]

The last part isn't completely true. Maybe it was in the beginning, but arch was not operating the site for the majority of the time. One of fitgirl releasers hosted the site whilst another user ran scripts to update stuff. Arch had involvement with most things, but usually only so far as talking to people and bringing different people together to get stuff done, so basically networking.

While archbox was mostly just a scapegoat for other people, he was the exclusive guy who ran that (sigmapatches)

it was done on his private google enterprise workspace, his cloud compute instances, and so on.

he tried to pass it on to other people after being issued a Cease & Desist, and nintendo saw that as violation of the terms of the C&D he was supposed to comply with. (not to mention the people he handed things over to were incompetent, making him have to continue maintaining all the projects, which was the other violation of the C&D)

archbox ran pretty much everything, but it was spazzlo and mz who was the origin of the project(s) i.e. jits, then they found a neurodivergent volunteer, terminally online redditor (archbox) to be their scapegoat/fallguy, and all of the people involved basically ditched moment N set their eyes on him.

 

[UnT7oh]

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.

Sorry to say this since you clearly put a lot of effort into it but this isn't fit for purpose, you managed to 10x the size of the sysmodule which was designed to be ultra lightweight and fast. Totaljustice will be turning in his grave.

 

[bombayjack]

Sorry to say this since you clearly put a lot of effort into it but this isn't fit for purpose, you managed to 10x the size of the sysmodule which was designed to be ultra lightweight and fast. Totaljustice will be turning in his grave.

It patches in about 0.05 seconds, That about a 20th of a second. My micro sd card is 256GB, so I can afford the few kilobytes it uses on the sd card, as for heap size, it's tiny the amount it uses. It's probably good you haven't seen the new code I've added to the overlay yet, you'd be going mad.

 

[browntigerz]

Check it:

Are you able to recompile this with libultrahand for the overlay? So it can have the sounds and wallpaper

 

[AllOver]

Sorry to say this since you clearly put a lot of effort into it but this isn't fit for purpose, you managed to 10x the size of the sysmodule which was designed to be ultra lightweight and fast. Totaljustice will be turning in his grave.

It's because they included stdio functions for some reason. It looks like AI code completion was used, and AI is awful at writing optimised and memory efficient code, so it just uses standard functions without taking into account the context of existing functions. The extra stuff added was just to make the logs more readable. So a 10x size to have a nicer looking log, which is pointless when most users use the overlay to read the log and devs can already read the log. There's some commented out code for string stream which is odd, dynamic memory should not be needed as there's nothing dynamic to be done at runtime.

It patches in about 0.05 seconds, That about a 20th of a second. My micro sd card is 256GB, so I can afford the few kilobytes it uses on the sd card, as for heap size, it's tiny the amount it uses. It's probably good you haven't seen the new code I've added to the overlay yet, you'd be going mad.

Imo it's worth fixing the bugs in syspatch. The pattern boundary has been broken since the first release and the fix that was authored doesn't actually fix the bug, and instead introduces two further bugs. One of them is extremely dangerous as it can (although unlikely) patch the completey wrong area as the secondary buffer is always used and never cleared. So, after the first run, whatever was left in the buffer will be used on the second pass, which could trigger a pattern to be detected.

 

[bth]

It's because they included stdio functions for some reason. It looks like AI code completion was used, and AI is awful at writing optimised and memory efficient code, so it just uses standard functions without taking into account the context of existing functions. The extra stuff added was just to make the logs more readable. So a 10x size to have a nicer looking log, which is pointless when most users use the overlay to read the log and devs can already read the log. There's some commented out code for string stream which is odd, dynamic memory should not be needed as there's nothing dynamic to be done at runtime.


Imo it's worth fixing the bugs in syspatch. The pattern boundary has been broken since the first release and the fix that was authored doesn't actually fix the bug, and instead introduces two further bugs. One of them is extremely dangerous as it can (although unlikely) patch the completey wrong area as the secondary buffer is always used and never cleared. So, after the first run, whatever was left in the buffer will be used on the second pass, which could trigger a pattern to be detected.

vibecoded aislop? also most of the extra logging is pointless and should only be compiled into a debug version of sys-patch // only compiled if a debug flag is set in enviroment variables / makefile when compiling sys-patch.

normal people don't need it, developers for most part don't need it either

 

[AllOver]

vibecoded aislop? also most of the extra logging is pointless and should only be compiled into a debug version of sys-patch // only compiled if a debug flag is set in enviroment variables / makefile when compiling sys-patch.

normal people don't need it, developers for most part don't need it either

I could be wrong on the AI claim. I'm basing it on the comments and the code looking very AI-like (which I unfortunately have to see every day).

This comment: "// In main function, after variable declarations, add:"

There's commented out code for deleting a log file, then creating it and then opening the file to see if it really was created? Even though ini_remove is already there? Just screams AI. It could be some copy paste code from a previous project and then the author realised it wasn't needed. But the left in code, along with the comments, along with the baffling std::string usage to format a string when sprintf is used elsewhere which was written by the author, I'm pretty sure it's AI enshittification.

I agree that if a detailed log was to be added, it should be a compile time flag. Further more, it should probably dump the full memory of the sysmod to file, along with the offset it managed to find (if any). As the offset on its own it's useless as it doesn't line up with the code in main.

 

[bombayjack]

I could be wrong on the AI claim. I'm basing it on the comments and the code looking very AI-like (which I unfortunately have to see every day).

This comment: "// In main function, after variable declarations, add:"

There's commented out code for deleting a log file, then creating it and then opening the file to see if it really was created? Even though ini_remove is already there? Just screams AI. It could be some copy paste code from a previous project and then the author realised it wasn't needed. But the left in code, along with the comments, along with the baffling std::string usage to format a string when sprintf is used elsewhere which was written by the author, I'm pretty sure it's AI enshittification.

I agree that if a detailed log was to be added, it should be a compile time flag. Further more, it should probably dump the full memory of the sysmod to file, along with the offset it managed to find (if any). As the offset on its own it's useless as it doesn't line up with the code in main.

That commented out code was just left in temporarily as I was using it when first testing stuff. Honestly I never looked at the sys-patch code before about a week or two weeks ago. I only got a switch about a month ago from my friend for free so have zero experience about it (apart from what I read about ips patches and sys-patch). As for AI, I don't know why some people don't like it. It's in everything nowadays. I just updated to visual studio 2026 last week and that has copilot built in now and pretty much everything is going that way so it's best to embrace the technology as we aren't going backwards. AI is a great tool, especially if you don't want to read loads of documentation and just want to test an idea out quickly.

Honestly I also didn't want to even look at sys-patch code, I was asking BTH to do maybe do something last week but was met with an "elitist" attitude and some tripe about me wanting to corrupt tickets, god only knows how he came to that conclusion?

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

Nov 24, 2025

A simple line in the overlay to Reset - could just remove the ini file and reboot the switch, then when it reboots the default ini would be recreated and the correct patches applied, I think you are overthinking this or what is required/requested.

and that is bad behaviour for the minority of users who forcibly enable patches on sysnand, now you are corrupting all their installed tickets.

wipe clean = no



adjust the sysmodule part of code instead, make cosmetic alterations to overlay only.

sysmodule part already permits rewriting keys and persisting key values end user has made...

• bth

Then he accused me of something on github, I've no idea what he was talking about nor do I care, I got the gist that he wasn't interested in helping in any way though and was just about comparing his superior knowledge against my non switch homebrew knowledge, so was forced to look at the code myself. So where does someone that knows nothing about the switch workings go? Libnx documetation as all homebrew seems to be based on that as far as I know, or do you use AI to help you, which in my opinion vastly decreases the time reading up on things that you don't even know about or where to look, or even what to ask about?

In the last week, I've learned and immense amount about creating overlays and what some of the limitations are when using them. For example, today I was trying to use one to get account information, I can get the user ID list of names and information about icons and some other stuff - but trying to find out if an acocunt is linked or not, well I totaly failed on that as I don't even know what to look for in the libnx documentation to find that out. I had a look here, but couldn't see anything - https://switchbrew.github.io/libnx/acc_8h_source.html

Anyway I digress, if you want to help make syspatch better, please do as it seems BTH who seems to be the only once currently adding stuff, in not receptive to any other ideas apart from his own so that's why I have been forced to take matters into myown hands for now, and to be honest I've now added all the things I wanted into it which I thought were lacking or broken. I've fixed all the patches from 10.0.0 firmware right up to 21+, (some were broken in lower firmware), I've added code to fix linked account looping in fw21+, I've added a reboot button to the overlay and I have debug logs for testing. Now I just need to start cleaning up the code a bit to optimise it. If you want to help with that, then I would be grateful, if not then no problem as I can do it myself, but you seem to have far more experience that me in that department as I just recently started learning about c++ about 2 weeks ago and have a lot to learn.

 

[AllOver]

That commented out code was just left in temporarily as I was using it when first testing stuff. Honestly I never looked at the sys-patch code before about a week or two weeks ago. I only got a switch about a month ago from my friend for free so have zero experience about it (apart from what I read about ips patches and sys-patch). As for AI, I don't know why some people don't like it. It's in everything nowadays. I just updated to visual studio 2026 last week and that has copilot built in now and pretty much everything is going that way so it's best to embrace the technology as we aren't going backwards. AI is a great tool, especially if you don't want to read loads of documentation and just want to test an idea out quickly.

Honestly I also didn't want to even look at sys-patch code, I was asking BTH to do maybe do something last week but was met with an "elitist" attitude and some tripe about me wanting to corrupt tickets, god only knows how he came to that conclusion?

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

Nov 24, 2025

A simple line in the overlay to Reset - could just remove the ini file and reboot the switch, then when it reboots the default ini would be recreated and the correct patches applied, I think you are overthinking this or what is required/requested.

and that is bad behaviour for the minority of users who forcibly enable patches on sysnand, now you are corrupting all their installed tickets.

wipe clean = no



adjust the sysmodule part of code instead, make cosmetic alterations to overlay only.

sysmodule part already permits rewriting keys and persisting key values end user has made...

• bth

Then he accused me of something on github, I've no idea what he was talking about nor do I care, I got the gist that he wasn't interested in helping in any way though and was just about comparing his superior knowledge against my non switch homebrew knowledge, so was forced to look at the code myself. So where does someone that knows nothing about the switch workings go? Libnx documetation as all homebrew seems to be based on that as far as I know, or do you use AI to help you, which in my opinion vastly decreases the time reading up on things that you don't even know about or where to look, or even what to ask about?

In the last week, I've learned and immense amount about creating overlays and what some of the limitations are when using them. For example, today I was trying to use one to get account information, I can get the user ID list of names and information about icons and some other stuff - but trying to find out if an acocunt is linked or not, well I totaly failed on that as I don't even know what to look for in the libnx documentation to find that out. I had a look here, but couldn't see anything - https://switchbrew.github.io/libnx/acc_8h_source.html

Anyway I digress, if you want to help make syspatch better, please do as it seems BTH who seems to be the only once currently adding stuff, in not receptive to any other ideas apart from his own so that's why I have been forced to take matters into myown hands for now, and to be honest I've now added all the things I wanted into it which I thought were lacking or broken. I've fixed all the patches from 10.0.0 firmware right up to 21+, (some were broken in lower firmware), I've added code to fix linked account looping in fw21+, I've added a reboot button to the overlay and I have debug logs for testing. Now I just need to start cleaning up the code a bit to optimise it. If you want to help with that, then I would be grateful, if not then no problem as I can do it myself, but you seem to have far more experience that me in that department as I just recently started learning about c++ about 2 weeks ago and have a lot to learn.

I apologise for being being a bit hard about using AI. I agree that it is useful tool. However my expensive with it is soured due to the extremely poor code quality that it often produces. As well as leading young developers astray by leaning into AI too much.

Sysmod dev for the switch should be treated the same as working in embedded development. You need to use as little amount of memory as possible, which also includes the binary size. Syspatch is likely installed on 70-80% of hacked switches. Any changes that increase the memory footprint can have a huge knock-on effect to users that are currently redlining the memory usage due to the sysmod bloatware they already have installed.

If the last thing the user updates is syspatch, which then causes ams to fatal due to OOM, then syspatch gets the blame. Even then, you have to justify if the changes made are worth the code complexity added, and the increased memory usage.

That's just my take though. If this were a normal NRO, then go wild. We have so much free memory there and 3 dedicated cores to work with. But sysmod land is like working on a C64. 1 core shared with the OS, fatals is anything goes wrong, very limited memory.

Post automatically merged: Dec 7, 2025

If you are unsure on anything code related, you can ask on here. I'll happily help out where I can. Not sure if there is an existing thread for developers to post code or ask questions (like a stack overflow thread but for switch stuff), but if not, I'd say it's worth creating.

It is difficult to source information on switch stuff as your best bet is to read existing code from libnx, ams and other projects. That's a bit overwhelming if you're just getting started and want to do something beyond what the very basic switch examples repo shows.

 

[UnderTakeBoi]

im on the latest firm ware I have sys patch v5 and when I boot the system if I do anything like delete bf an app or opening a game it crashes and this error code appears:
Error Code: 2168-0003 (0x6a8)


Program: 0100000000000024


Firmware: 21.0.1 (Atmosphère 1.10.0-master-28a378ca0)

 

[bombayjack]

I apologise for being being a bit hard about using AI. I agree that it is useful tool. However more expensive with it is soured due to the extremely poor code quality that it often produces. As well as leading young developers astray by leaning into AI too much.

Sysmod dev for the switch should be treated the same as working in embedded development. You need to use as little amount of memory as possible, which also includes the binary size. Syspatch is likely installed on 70-80% of hacked switches. Any changes that increase the memory footprint can have a huge knock-on effect to users that are currently redlining the memory usage due to the sysmod bloatware they already have installed.

If the last thing the user updates is syspatch, which then causes ams to fatal due to OOM, then syspatch gets the blame. Even then, you have to justify if the changes made are worth the code complexity added, and the increased memory usage.

That's just my take though. If this were a normal NRO, then go wild. We have so much free memory there and 3 dedicated cores to work with. But sysmod land is like working on a C64. 1 core shared with the OS, fatals is anything goes wrong, very limited memory.

Post automatically merged: Dec 7, 2025

If you are unsure on anything code related, you can ask on here. I'll happily help out where I can. Not sure if there is an existing thread for developers to post code or ask questions (like a stack overflow thread but for switch stuff), but if not, I'd say it's worth creating.

It is difficult to source information on switch stuff as your best bet is to read existing code from libnx, ams and other projects. That's a bit overwhelming if you're just getting started and want to do something beyond what the very basic switch examples repo shows.

Firstly thanks for replying, I accept your apology and an greateful you acknowledged that I am a noob in switch homebrew so haven't been hard on me.

Fair enough, I get your point. I have made stuff using Arduino IDE and written code for ESP32 based chips before so know what you mean about being coy with the code as you are limited, more than once have I had issues where memory has been overwritten by running code and caused a crash with no obvious reason. I have no idea about Swtich development though so I thought sys-patch is loaded by atmosphere and patches the system/firmware files, then gets discarded at that point and doesn't use anymore memory or resources? I've got a homebrew called Hekate Toolbox and Sys-patch is turned off as a background service and yet it's working just fine so I assumed it's not using any memory at all when the system is fully booted. Maybe I am wrong?

I am more interested in homebrew on a running switch now, overlays at the moment, I spent hours yesterday just trying to write a file to the sd card, not realising an overlay first needs to mount the sd card, WTF how is someone expected to know that, It's not like google is any help and where do you even look for that information or know that you even need to? It's not like you get spat out from the womb into the world with a full encylopedic knowledge on switch homebrew coding. So you come on here, ask someone and then get met with "I know more than you do" type of replies by the very people you hope will help, so that's why I am grateful you have been of more help than others I won't mention. So

 

[AllOver]

Firstly thanks for replying, I accept your apology and an greateful you acknowledged that I am a noob in switch homebrew so haven't been hard on me.

Fair enough, I get your point. I have made stuff using Arduino IDE and written code for ESP32 based chips before so know what you mean about being coy with the code as you are limited, more than once have I had issues where memory has been overwritten by running code and caused a crash with no obvious reason. I have no idea about Swtich development though so I thought sys-patch is loaded by atmosphere and patches the system/firmware files, then gets discarded at that point and doesn't use anymore memory or resources? I've got a homebrew called Hekate Toolbox and Sys-patch is turned off as a background service and yet it's working just fine so I assumed it's not using any memory at all when the system is fully booted. Maybe I am wrong?

I am more interested in homebrew on a running switch now, overlays at the moment, I spent hours yesterday just trying to write a file to the sd card, not realising an overlay first needs to mount the sd card, WTF how is someone expected to know that, It's not like google is any help and where do you even look for that information or know that you even need to? It's not like you get spat out from the womb into the world with a full encylopedic knowledge on switch homebrew coding. So you come on here, ask someone and then get met with "I know more than you do" type of replies by the very people you hope will help, so that's why I am grateful you have been of more help than others I won't mention. So

I'm not sure if the memory is actually relinquished when syspatch exits. I vaguely remember SciresM saying that a closed sysmod doesn't free the memory, although I am not sure if that's true or (more likely) I misunderstood. Even so, it's possible that syspatch is the last sysmod to load, which would cause it to crash if memory is tight.

For normal NRO development, you can use standard C/C++ code without having to touch switch specific code. AI can be useful there. For sysmod, you have to manually setup a lot of things. Libnx has a function (which can found at the bottom of syspatch) which normally sets up the heap and inits a few services, including the SD card. This function is marked as "weak", meaning that it can be overridden. Basically if a function exists with the same name, the linker will use that instead. Normally this would be a linker error, but as it's labelled weak, it just discards the old version. Remember that C++ performs name mangaling, so you need to wrap those functions in extern C, which syspatch does.

In a sysmod, you want to override this function to manually set how much heap you want to use, as well as only init services that you need, as some services are very limited, such as the time service.

AI cannot help you in this case because it has very limited data on libnx. And the data it has trained on is a very old version of libnx and a lot of bad homebrew from back in the day. It will often hallucinate libnx API functions and headers that don't exist etc.

 

[bombayjack]

@AllOver

Since you seem to know quite a bit about this firmware hacking malarky, I want to ask you a question about FW spoofing.

Say I want to add a patch to block fw updates I imagine I just need to spoof the reported firmware version to 9.9.9 or something like that. (because even with fw checking turned off in 20.50 update files are still downloaded)

I find in the firmware this: - example 11.0.0/20.5.0/21.00 firmwares:

594c90bcdbcccad6b062eadba0cd0e7e.nca
Title ID: 0100000000000809 (FW HASH + FW Version)
0x14E68 - 34197eba8810e2edd5e9dfcfbde7b340882e856d
0x14EA8 - 11.0.0
0x14EC0 - NintendoSDK Firmware for NX 11.0.0-5.0

23ce01f1fc55e55a783162d456e5ca58.nca
Title ID: 0100000000000809 (FW HASH + FW Version)
0x14E68 - c7f472f9b64b7b0cba46a25e6a610f70613a4792 (hash)
0x14EA8 - 20.5.0
0x14EC0 - NintendoSDK Firmware for NX 20.5.0-1.0

e7273dd5b560d0ba282fc64206fecb56.nca
Title ID: 0100000000000809 (FW HASH + FW Version)
0x14E68 - 066a75e6fab7316de34b88b60d229a0b2729e421
0x14EA8 - 21.0.1
0x14EC0 - NintendoSDK Firmware for NX 21.0.1-1.0


It seems the module for reporting the firmware hash and version is in Title ID: 0100000000000809.

Offsets are the same in all decrypted nca fimware file versions I checked, so we probably just need to search for hex string "NintendoSDK" then go back 0x18 bytes to spoof patch the reported FW version.

What do you think, can this be patched because it must be loaded before sys-patch otherwise how do we get the firmare version? If it's loaded first, then maybe it's locked? I tried patching but couldn't get it to work.

 

[bth]

@AllOver

Say I want to add a patch to block fw updates I imagine I just need to spoof the reported firmware version to 9.9.9 or something like that. (because even with fw checking turned off in 20.50 update files are still downloaded)

What do you think, can this be patched because it must be loaded before sys-patch otherwise how do we get the firmare version? If it's loaded first, then maybe it's locked? I tried patching but couldn't get it to work.

the hint you're looking for is what communication the console sends as telemetry to nintendo, what it receives as a response in form from nintendo.

the console ultimately receives the update from atum after your console tells nintendo your firmware and it responding that it has one of greater value and then issues a command to start loading it into NCM preparing it for install.


if you truly want to "patch it out", you'd find and snuff out what triggers either the telemetry, or the response to your consoles telemetry from nintendo which triggers the console firmware update. (spoofing firmware version ill advised)




https://github.com/Atmosphere-NX/Atmosphere/tree/master/troposphere/daybreak
Daybreak is a firmware updating tool, reading through it (and atmosphere as a whole), will give you the answer as to where you want to look through

( incase not obvious; https://switchbrew.org/wiki/NS_services#ns:su and https://switchbrew.org/wiki/NS_services#ISystemUpdateControl ,which ultimately is called from https://switchbrew.org/wiki/NIM_services)
https://switchbrew.org/wiki/Network#atum/atumn
very specifically 0100000000000816 / SystemUpdate
010000000000001F - NS
0100000000000025 - NIM