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

[impeeza]

I really hop @TotalJustice give us the opinion about the new code:

https://gbatemp.net/threads/sys-patch-mod-for-18-00.652413/

and the source:
https://disk.yandex.com/d/jj1sU2_btsQ9FA

 

[urherenow]

I'm not keen on using a modified fusee either, only the one released by SciresM himself

Do you not realize the the "modified" fusee, is just modified with the official source code that was written by him, and removed by him? "git revert" is a thing...

 

[R3m0ved]

Do you not realize the the "modified" fusee, is just modified with the official source code that was written by him, and removed by him? "git revert" is a thing...

Yep i've seen his modifications

"fusee: remove ips patch parsing from sd filesystem
Parsing the SD fs is very slow. In addition, the only KIPs are either a) atmosphere modules, or b) FS.

The IPS subsystem was originally designed to make nogc/etc patches work for FS,
but these are now internal, and it appears that the literal only kip patches
that exist are for piracy.

It just doesn't make sense to slow down boot for every normal user for a feature
that has no actual usecase, and especially when fusee is already so minimal."

commit 46a4357

But nothing tells me some malicious dude or big N spy put some extra lines afterwards to brick my device, that's why we got checksums in artifactories and such
The internet is a filthy place

 

[impeeza]

Yep i've seen his modifications

"fusee: remove ips patch parsing from sd filesystem
Parsing the SD fs is very slow. In addition, the only KIPs are either a) atmosphere modules, or b) FS.

The IPS subsystem was originally designed to make nogc/etc patches work for FS,
but these are now internal, and it appears that the literal only kip patches
that exist are for piracy.

It just doesn't make sense to slow down boot for every normal user for a feature
that has no actual usecase, and especially when fusee is already so minimal."

commit 46a4357

But nothing tells me some malicious moron put some extra lines afterwards to brick my device, that's why

I got lost on this, what happened?

 

[R3m0ved]

I got lost on this, what happened?

Nothing really important, SciresM repo still show which fusee modifications he did to remove IPS patch support at boot, and you can revert those changes and build it yourself, but i don't trust unknown sources

You can insert whatever you want and tell people you just reverted SciresM changes, that's why i like checksums very much, told you i got OCD lol

And each time SciresM will update fusee, the story will repeat itself, someone will have to undo those modifications and insert back IPS patch support again and again, not quite sustainable, using both sys-patch and sigpatches for both launch flavors seems more logic for those who don't want to seek through boards and such
+ fusee does not have a versioning on its own, this can be confusing

 

[impeeza]

Nothing really important, SciresM repo still show which fusee modifications he did to remove IPS patch support at boot, and you can revert those changes and build it yourself, but i don't trust unknown sources

You can insert whatever you want and tell people you just reverted SciresM changes, that's why i like checksums very much, told you i got OCD lol

yes you are right even I published the commit, if you like to undo the commit you can, manually or using git and then build the atmosphere by yourself.

Post automatically merged: Apr 1, 2024

but I don't get why the names calling and insults, I got lost there.

 

[R3m0ved]

yes you are right even I published the commit, if you like to undo the commit you can, manually or using git and then build the atmosphere by yourself.

Post automatically merged: Apr 1, 2024

but I don't get why the names calling and insults, I got lost there.

no name drop or someone targeted, i apologize if someone took it personaly, i don't trust anyone, just an habit

 

[impeeza]

no name drop or someone targeted, i apologize if someone took it personaly, i don't trust anyone, just an habit

I think the name calling was upon you! I really get lost, sorry for making a mess.

so the summary:

Atmosphere remove something, so you can:

• Build a version including the removed code.
• Use Hekate bootloader
• And/or Use SYS-Patch.

Am I right?

 

[R3m0ved]

I think the name calling was upon you! I really get lost, sorry for making a mess.

so the summary:

Atmosphere remove something, so you can:

• Build a version including the removed code.
• Use Hekate bootloader
• And/or Use SYS-Patch.

Am I right?

Yep perfectly right

 

[RedColoredStars]

As much as I've tried to not care, it's still driving me bonkers why my ctest is green. According to the documentation that means sigpatches didn't patch ctest so sys-patch took care of it. It would be orange if the sigpatch for it was working. Which leads me to believe that if I got rid of sys-patch, ctest wouldn't be patched at all even though I have the patch. I've tried the sigpatches from the sigpatch thread and also created my own but it's stlil the same. What in the world is causing mine to be green instead of orange like in other peoples log? SOMEONE has to know the answer.

 

[kindofblue]

I really hop @TotalJustice give us the opinion about the new code:

https://gbatemp.net/threads/sys-patch-mod-for-18-00.652413/

and the source:
https://disk.yandex.com/d/jj1sU2_btsQ9FA

This modified source does not contain the (I guess) more generic pattern for ES patches (FW 14+) as mentioned here:

https://gbatemp.net/threads/sys-patch-sysmod-that-patches-on-boot.633517/post-10388784

Not that it matters if another update makes it obsolete for higher firmware versions, but just a "cleaner" implementation.

Note that you might need to adjust inst_offset and/or patch_offset for that pattern. I have not looked at the disassembled module, so I cannot comment on the relative offsets.

Cheers!

 

[unicornman]

This modified source does not contain the (I guess) more generic pattern for ES patches (FW 14+) as mentioned here:

//link remove as forum reports it as spam...

Not that it matters if another update makes it obsolete for higher firmware versions, but just a "cleaner" implementation.

Note that you might need to adjust inst_offset and/or patch_offset for that pattern. I have not looked at the disassembled module, so I cannot comment on the relative offsets.

Cheers!

It doesn't conatin that pattern for the reason that pattern is found in two places in the file, instead of just the one.

Searching for: a0.0091..0094a0..d1..ff97

Pattern found at offset: 0x0006973C (431932)
Pattern found at offset: 0x0006A044 (434244)
Pattern found: 2 times

Now to be exact and only find the pattern once - which ensures the correct place.

Searching for: .6f00...0094a0..d1..ff97

Pattern found at offset: 0x0006973C (431932)
Pattern found: 1 times

This is the reason the code was modded to that pattern. TBH it doesn't matter for now what pattern is found as the first pattern above is found at the correct offset and then I guess the search breaks out of searching for anymore offsets, but the second pattern absolute. It's easy enough to figure out a better pattern if something changes in future upadates so people shouldn't get too hung up about what patterns are used for now. Also this program can easily be modded to to read patterns from a text file or ini file without much modding should someone feel the urge to do that.

Best patch pattern for es is now this:

constinit Patterns es_patterns[] = {
    { "es1", "00...0094A0..D1..FF97.......A9", 14, 0, mov2_cond, mov0_patch, mov0_applied, true, MAKEHOSVERSION(9,1,0), MAKEHOSVERSION(18,0,0) },
};

This pattern is based on fw analysis from fw 9.1.0-18 and works for es patches on all of those fw.

 

[josete2k]

As much as I've tried to not care, it's still driving me bonkers why my ctest is green. According to the documentation that means sigpatches didn't patch ctest so sys-patch took care of it. It would be orange if the sigpatch for it was working. Which leads me to believe that if I got rid of sys-patch, ctest wouldn't be patched at all even though I have the patch. I've tried the sigpatches from the sigpatch thread and also created my own but it's stlil the same. What in the world is causing mine to be green instead of orange like in other peoples log? SOMEONE has to know the answer.

ctest in green means that it is patched by Sys-patch.

It would be in orange if it was patched by ips patches.

 

[RedColoredStars]

ctest in green means that it is patched by Sys-patch.

It would be in orange if it was patched by ips patches.

Right. Since I have the ctest sigpatch, it should be orange like other people that are using both. It's still patched so it's fine, but I like to learn the hows and whys of things. The question is more one of why are other people using both but theirs is orange because it's already being patched by sigpatches. I'm also using both and mine is green. Why is the sigpatch not patching mine before sys-patch does it like it is with other people? If using both, it should be orange. Mine is green as if my ctest sigpatch is being ignored.

 

[impeeza]

For the ones who Yandex is asking for registering a clone of the repo was created on:

https://gitflic.ru/project/impeeza/sys-patch/release

 

[kindofblue]

It doesn't conatin that pattern for the reason that pattern is found in two places in the file, instead of just the one.

Searching for: a0.0091..0094a0..d1..ff97

Pattern found at offset: 0x0006973C (431932)
Pattern found at offset: 0x0006A044 (434244)
Pattern found: 2 times

Now to be exact and only find the pattern once - which ensures the correct place.

Searching for: .6f00...0094a0..d1..ff97

Pattern found at offset: 0x0006973C (431932)
Pattern found: 1 times

This is the reason the code was modded to that pattern. TBH it doesn't matter for now what pattern is found as the first pattern above is found at the correct offset and then I guess the search breaks out of searching for anymore offsets, but the second pattern absolute. It's easy enough to figure out a better pattern if something changes in future upadates so people shouldn't get too hung up about what patterns are used for now. Also this program can easily be modded to to read patterns from a text file or ini file without much modding should someone feel the urge to do that.

Best patch pattern for es is now this:

constinit Patterns es_patterns[] = {
    { "es1", "00...0094A0..D1..FF97.......A9", 14, 0, mov2_cond, mov0_patch, mov0_applied, true, MAKEHOSVERSION(9,1,0), MAKEHOSVERSION(18,0,0) },
};

This pattern is based on fw analysis from fw 9.1.0-18 and works for es patches on all of those fw.

Sounds good!

I assumed that the pattern in the original comment had been tested.

Anyway, I see that you have been busy doing just that

Cheers!

 

[shadow256]

For the ones who Yandex is asking for registering a clone of the repo was created on:

https://gitflic.ru/project/impeeza/sys-patch/release

Thanks for the git share, more simple to follow.

Just a note, the "ES6" patch should be changed to exclude firmwares higher than firmware 17.0.1, like that:
{ "es6", "0x.6300...0094A0..D1..FF97", 16, 0, mov2_cond, mov0_patch, mov0_applied, true, MAKEHOSVERSION(14,0,0), MAKEHOSVERSION(17,0,1) },

It's not realy important but for the logic I think it's better.

 

[impeeza]

Thanks for the git share, more simple to follow.

Just a note, the "ES6" patch should be changed to exclude firmwares higher than firmware 17.0.1, like that:
{ "es6", "0x.6300...0094A0..D1..FF97", 16, 0, mov2_cond, mov0_patch, mov0_applied, true, MAKEHOSVERSION(14,0,0), MAKEHOSVERSION(17,0,1) },

It's not realy important but for the logic I think it's better.

Yes, you are right I think the same Even ask for @TotalJustice opinion, I am not the one who made the change, only posted a code handled to me.

 

[RealYoti]

It's not realy important but for the logic I think it's better.

No, it must be fixed for 18.0.0 support.

 

[R3m0ved]

No, it must be fixed for 18.0.0 support.

If you got time you can do a merge request on the new repo now