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

[josete2k]

If that were true, there wouldn't be an overlay.

It isn't needed at all

 

[AllOver]

It isn't needed at all

Nor are the patches that 99% of users don't need, yet both are distributed with syspatch so it's worth discussing.

 

[bombayjack]

If that were true, there wouldn't be an overlay.

The overlay just reads/writes new values to the config.ini file when you change something. The main program reads that ini file when it launches and applies the relevant patches based on it. If that file doesn't exist then default values are used instead and a new ini file gets created.

 

[AllOver]

The overlay just reads/writes new values to the config.ini file when you change something. The main program reads that ini file when it launches and applies the relevant patches based on it. If that file doesn't exist then default values are used instead and a new ini file gets created.

I was just explaining that if the intention of syspatch was to be truly hidden for a user, then it wouldn't have an overlay where the user can view and modify the patches enabled and the log.

I didn't really understand the counterargument to begin with because I was suggesting if anything should be done, it could be to add some info inside the overlay to dissuade then from enabling something they don't need.

 

[bombayjack]

I was just explaining that if the intention of syspatch was to be truly hidden for a user, then it wouldn't have an overlay where the user can view and modify the patches enabled and the log.

I didn't really understand the counterargument to begin with because I was suggesting if anything should be done, it could be to add some info inside the overlay to dissuade then from enabling something they don't need.

You're probably correct, what did you have in mind?

 

[AllOver]

You're probably correct, what did you have in mind?

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 verification checks, recommend to keep this enabled (default)".

Idk just a suggestion. It doesn't fix any bugs and people will continue to ask and get confused about the patches, so it's probably not worth the effort to change stuff. But I also think educating users goes a long way.

 

[bombayjack]

Nothing special, but maybe explain or categories 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 verification checks, recommend to keep this enabled (default)".

Idk just a suggestion. It doesn't fix any bugs and people will continue to ask and get confused about the patches, so it's probably not worth the effort to change stuff. But I also think educating users goes a long way.

I like the way you think, it's people like you that come up with ideas that makes homebrew better. Sometimes the ideas might be a bit meh! but it's still better to have an idea and even if ony 50% of them are good then those good ones can be of great help.

 

[josete2k]

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 verification checks, recommend to keep this enabled (default)".

Idk just a suggestion. It doesn't fix any bugs and people will continue to ask and get confused about the patches, so it's probably not worth the effort to change stuff. But I also think educating users goes a long way.

Check it:

 

[impeeza]

I has been thinking for long time to rename the patches on the config and the overlay, do not have too many sense patch1 patch2 and patch3.

Will be better Patchfw1to5 patchfw5to17 and patch fw18to21. etc. or give the real name to the paches

 

[b17bomber]

Does this still work on the new 21.0.1?

 

[bth]

I has been thinking for long time to rename the patches on the config and the overlay, do not have too many sense patch1 patch2 and patch3.

Will be better Patchfw1to5 patchfw5to17 and patch fw18to21. etc. or give the real name to the paches

example:

given that users are in other languages than english as well, simplifying it to just the patch name + firmware numbers applicable is easy to do.


example of renaming of patches, as well as removal of disable_ca_verification SSL patches from sys-patch.
https://github.com/borntohonk/sys-patch/commit/fdd5f78f0e6ff206e840defabe797c0e57545b2d

ctest_1.0.0-18.1.0
ctest_21.0.0+

instead of:

force_enable_network_1.0.0-18.1.0
force_enable_network_21.0.0+

Does this still work on the new 21.0.1?

nothing relevant was changed in 21.0.1 that would affect sys-patch

https://switchbrew.org/wiki/21.0.1

 

[froggy55]

example:

given that users are in other languages than english as well, simplifying it to just the patch name + firmware numbers applicable is easy to do.


example of renaming of patches, as well as removal of disable_ca_verification SSL patches from sys-patch.
https://github.com/borntohonk/sys-patch/commit/ccc5d9ec9d1c66007242f2313f6bce53e0f4e954

ctest_1.0.0-18.1.0
ctest_21.0.0+

instead of:

force_enable_network_1.0.0-18.1.0
force_enable_network_21.0.0+


nothing relevant was changed in 21.0.1 that would affect sys-patch

https://switchbrew.org/wiki/21.0.1

i can confirm that syspatch v5 is working fine with fw21.01

 

[RealYoti]

example of renaming of patches

Why did you keep numbers for es patch?

 

[bth]

Why did you keep numbers for es patch?

not finalized for PR/integration, pending feedback as if what is wanted. i've updated the message/commit/archive uploaded with the correction.


example:
es_certificate_signature_verification_disable_21.0.0+
es_21.0.0+

ctest_21.0.0+
force_enable_network_21.0.0+

while i'm not opposed naming the patches after what they do, i also think just keeping them as-is, is fine too. (* with the inclusion of firmware numbers the patch is applicable for)

 

[AllOver]

Why did you keep numbers for es patch?

There isn't a fitting name for them. You could do es_old and es_new like with fs, but then you'd have es_new_new. I think patch scripts also name them 1,2,3 etc but I could be wrong. Changing the name to include the fw min/max is a good idea however.

 

[bth]

There isn't a fitting name for them. You could do es_old and es_new like with fs, but then you'd have es_new_new. I think patch scripts also name them 1,2,3 etc but I could be wrong. Changing the name to include the fw min/max is a good idea however.

was more of typo in the commit for the es1, es2, es3, es4

the idea was to accomodate @impeeza desire to rename them from the current format
es1, es2, es3

es_1.0.0
es_2.0.0-8.1.1
es_9.0.0-20.5.0
es_21.0.0+

nim_old, nim_new

nim_17.0.0-20.5.0
nim_21.0.0+

https://github.com/borntohonk/sys-patch/commit/fdd5f78f0e6ff206e840defabe797c0e57545b2d


(should be noted that the overlay strings that says es1, es2 doesn't really matter, what matters are the strings shown in the overlay)

example:
list->addItem(config_es1.create_list_item("es_1.0.0"));
ConfigEntry config_es1{"es", "es_1.0.0", true};

i.e. the config_es1 is just overlay code not seen by end user. - and end users doesn't see that unless they have sys-ovlloader, or the tesla menu homebrew(?)

 

[bombayjack]

was more of typo in the commit for the es1, es2, es3, es4

the idea was to accomodate @impeeza desire to rename them from the current format
es1, es2, es3

es_1.0.0
es_2.0.0-8.1.1
es_9.0.0-20.5.0
es_21.0.0+

nim_old, nim_new

nim_17.0.0-20.5.0
nim_21.0.0+

https://github.com/borntohonk/sys-patch/commit/fdd5f78f0e6ff206e840defabe797c0e57545b2d


(should be noted that the overlay strings that says es1, es2 doesn't really matter, what matters are the strings shown in the overlay)

example:
list->addItem(config_es1.create_list_item("es_1.0.0"));
ConfigEntry config_es1{"es", "es_1.0.0", true};

i.e. the config_es1 is just overlay code not seen by end user. - and end users doesn't see that unless they have sys-ovlloader, or the tesla menu homebrew(?)

You should also add a debug file to print to text file where the offset was found for what patches were applied - this will be helpful for debugging if the pattern you checked was found at the correct offset.

 

[bth]

You should also add a debug file to print to text file where the offset was found for what patches were applied - this will be helpful for debugging if the pattern you checked was found at the correct offset.

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

 

[josete2k]

was more of typo in the commit for the es1, es2, es3, es4

the idea was to accomodate @impeeza desire to rename them from the current format
es1, es2, es3

es_1.0.0
es_2.0.0-8.1.1
es_9.0.0-20.5.0
es_21.0.0+

nim_old, nim_new

nim_17.0.0-20.5.0
nim_21.0.0+

https://github.com/borntohonk/sys-patch/commit/fdd5f78f0e6ff206e840defabe797c0e57545b2d


(should be noted that the overlay strings that says es1, es2 doesn't really matter, what matters are the strings shown in the overlay)

example:
list->addItem(config_es1.create_list_item("es_1.0.0"));
ConfigEntry config_es1{"es", "es_1.0.0", true};

i.e. the config_es1 is just overlay code not seen by end user. - and end users doesn't see that unless they have sys-ovlloader, or the tesla menu homebrew(?)

You couls also change the header's name


Something like this

list->addItem(new tsl::elm::CategoryHeader("ERPT - 010000000000002B")

to

list->addItem(new tsl::elm::CategoryHeader("NO SD REPORTS")

 

[bth]

You couls also change the header's name


Something like this

list->addItem(new tsl::elm::CategoryHeader("ERPT - 010000000000002B")

to

list->addItem(new tsl::elm::CategoryHeader("NO SD REPORTS")

that also is an option