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

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

Imo, the users that require it for sysMMC should need to enable it manually. But it's not really a big deal, at least not for me because I know to disable it for myself.
 
Either way,

https://switchbrew.org/wiki/SVC#GetInfo

if im reading this correctly,

invoking svcGetInfo, handle type process, and info type 18, i should get the programID.

i.e. something like this:

C++:
u64 program_id = 0;
if (R_SUCCEEDED(svcGetInfo(&program_id, 18, handle, 0))) {
    char buf[17]{};
    snprintf(buf, sizeof(buf), "%016llx", (unsigned long long)program_id);
    program_id_str = buf;
}


https://github.com/Atmosphere-NX/At...here/svc/svc_stratosphere_shims.hpp#L190-L192

unless im completely misinterpreting this, and that "ProgramId" is just an alias for "titleID", despite svcDebugEventInfo is supposed to return that.


( i probably am misinterpreting it and should instead probably just gonna have to assume svcReadDebugProcessMemory can read the header )


C++:
MemoryInfo mem_info{};
u32 page_info{};
u64 addr = 0;
bool found = false;

while (R_SUCCEEDED(svcQueryDebugProcessMemory(&mem_info, &page_info, handle, addr))) {
    addr = mem_info.addr + mem_info.size;

    if (mem_info.type == MemType_CodeStatic && (mem_info.perm & Perm_Rx) == Perm_Rx && mem_info.size > 0x60) {
        u8 module_id[32]{};
        if (R_SUCCEEDED(svcReadDebugProcessMemory(module_id, handle, mem_info.addr + 0x40, sizeof(module_id)))) {
            char buf[65]{};
            for (int i = 0; i < 32; ++i) {
                snprintf(buf + i * 2, 3, "%02x", module_id[i]);
            }
            module_id_str = buf;
            break;
        }
    }
}
 
Last edited by bth,
For those the want to try to compile this themselves:

Overlay code has been updated to fix the version skip code and to show proper skipped info in the log page and only show relevent patches for the running firmware in patches options.

Moved Linked account loop fix (fw 21+) to the options page and added a toggle to enable/disable this.
 

Attachments

For those the want to try to compile this themselves:

Overlay code has been updated to fix the version skip code and to show proper skipped info in the log page and only show relevent patches for the running firmware in patches options.

Moved Linked account loop fix (fw 21+) to the options page and added a toggle to enable/disable this.

i still heavily disagree with deploying atmosphere config files to end users systems. It is beyond the scope of what both sys-patch and the overlay is supposed to do.

I'm also disappointed you continue calling deploying the configuration file as "Linked account loop fix", despite me telling you it's not.

why not just patch olsc itself? I've provided enough information already, and you claimed you were going to investigate.

i guess your LLM/AI couldn't figure it out?



patch constant:
200080D2 (mov x0, #0x1)

cond constant:
.. .. .. 97 (BL)
.. .. .. 94 (BL)

pattern:
all firmwares:
00 .. 73 .. .. F9 68 02 40 39 .. .. 00 .. .. .. 00 (ghidra)
00.73..F968024039..00...00 (sys-patch)

6.0.0 to 14.1.2
offset: 42
15.0.0 to 18.1.0
offset: 38
19.0.0 to 21.1.0+
offset: 42




21.1.0
792DD5A46F44C0BFC017A3BAB9BB347CB51E90E7.ips
50415443480850280004200080D2454F46

085028
0004
200080D2



example implementation into sys-patch:
https://github.com/borntohonk/sys-patch/commit/a4cabed80a528326811395e3638f63842a797b49

https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py#L187-L224


olsc.jpg
 
Last edited by bth,
i still heavily disagree with deploying atmosphere config files to end users systems. It is beyond the scope of what both sys-patch and the overlay is supposed to do.

I'm also disappointed you continue calling deploying the configuration file as "Linked account loop fix", despite me telling you it's not.

why not just patch olsc itself? I've provided enough information already, and you claimed you were going to investigate.

i guess your LLM/AI couldn't figure it out?
It's a very low priority on my very long list of things to do (going to shops, do the washing, finish xmas shopping, tidy the house, etc.....) and I prefered modding other more important (in my free time and opinion) stuff that I thought needed doing first, especially as modding the ini file already works and does what is required. I'll have a look at your patch after xmas when I get some time. As for your first point about config files, we all think differently about things (which is a good thing), you have your views on this and I have mine, I only care that something works, it doesn't matter how it does it as far as I am concerned as long as it gets the job done.

You probably don't remember but I did ask you to mod this program a while ago and you basically told me to do it myself, I told you I wasn't a c++ coder and didn't know much about the switch as I've not had it for long and you then complain that I use AI to help me (which is working well for me). I generally find your posts pretty negative and unhelpful, you always seem to look for something to complain about and have a very strange way of interacting with people and come across like you think everyone should do things the same way you do. You should remember that I am not a pro coder and I don't want to be either, I am only modding this program because you wouldn't and were unwilling to listen to anyone's requests. Your last post does have some useful information in it though so thanks for that, in the meantime have a Merry Xmas and try to get away from the computer for a bit and interact with some real people.

Untitled.png


Here's a small tool (source code) I made to search firmware nca files for titleID, I also made a python version but this is pretty quick.

How to compile:
g++ -std=c++17 -o nca_searcher.exe nca_searcher.cpp -lstdc++fs
strip nca_searcher.exe


How to use:
Put hactool and keys.dat in the same folder, then run like this;
nca_searcher "Firmware.21.1.0" 010000000000003E


FYI - you put the wrong address on your IPS patch for 21.1.0 - it should be: 08 4F 2C (according to your picture & IDA)

792DD5A46F44C0BFC017A3BAB9BB347CB51E90E7.ips
50 41 54 43 48 08 4F 2C 00 04 1F 10 00 F1 45 4F 46 (Changing 0x1F0400F1 to 0x1F1000F1)

(note: Patch above doesn't fix the loop issue)

So after the offset correction for IPS patch, you should check your patch pattern because...

Pattern for 19+ "00.73..F968024039..00...00"
Pattern Found Offset: 0x084FFE + 0x2E = 08502C (crashes switch)

Probably you need to recheck for FW 21+ (I didn't check any other firmwares) & check the patch because the offset you gave in the IPS crashes the switch, and the "corrected" offset doesn't work.
 

Attachments

Last edited by bombayjack,
It's a very low priority on my very long list of things to do (going to shops, do the washing, finish xmas shopping, tidy the house, etc.....) and I prefered modding other more important (in my free time and opinion) stuff that I thought needed doing first, especially as modding the ini file already works and does what is required. I'll have a look at your patch after xmas when I get some time. As for your first point about config files, we all think differently about things (which is a good thing), you have your views on this and I have mine, I only care that something works, it doesn't matter how it does it as far as I am concerned as long as it gets the job done.

You probably don't remember but I did ask you to mod this program a while ago and you basically told me to do it myself, I told you I wasn't a c++ coder and didn't know much about the switch as I've not had it for long and you then complain that I use AI to help me (which is working well for me). I generally find your posts pretty negative and unhelpful, you always seem to look for something to complain about and have a very strange way of interacting with people and come across like you think everyone should do things the same way you do. You should remember that I am not a pro coder and I don't want to be either, I am only modding this program because you wouldn't and were unwilling to listen to anyone's requests. Your last post does have some useful information in it though so thanks for that, in the meantime have a Merry Xmas and try to get away from the computer for a bit and interact with some real people.

View attachment 547315

Here's a small tool (source code) I made to search firmware nca files for titleID, I also made a python version but this is pretty quick.

How to compile:
g++ -std=c++17 -o nca_searcher.exe nca_searcher.cpp -lstdc++fs
strip nca_searcher.exe


How to use:
Put hactool and keys.dat in the same folder, then run like this;
nca_searcher "Firmware.21.1.0" 010000000000003E


FYI - you put the wrong address on your IPS patch for 21.1.0 - it should be: 08 4F 2C (according to your picture & IDA)

792DD5A46F44C0BFC017A3BAB9BB347CB51E90E7.ips
50 41 54 43 48 08 4F 2C 00 04 1F 10 00 F1 45 4F 46 (Changing 0x1F0400F1 to 0x1F1000F1)

(note: Patch above doesn't fix the loop issue)

So after the offset correction for IPS patch, you should check your patch pattern because...

Pattern for 19+ "00.73..F968024039..00...00"
Pattern Found Offset: 0x084FFE + 0x2E = 08502C (crashes switch)

Probably you need to recheck for FW 21+ (I didn't check any other firmwares) & check the patch because the offset you gave in the IPS crashes the switch, and the "corrected" offset doesn't work.

it clearly says 08502C not 084F2C (adjustment below either way, but you're still 0x100 off)
(the reference post above was edited to reflect on the adjustments below)

(from my own collection of stuff:
.ips patch is always with the header, using the atmosphere cheat api you can target memory, which is without the header,
subtracting 0x100, but the system executables we are patching cannot use the cheat api))

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

Python:
import re
from pathlib import Path

Path('./atmosphere/exefs_patches/d2r_offline_fix').mkdir(parents=True, exist_ok=True)
Path('./atmosphere/contents/0100726014352000/cheats').mkdir(parents=True, exist_ok=True)

def get_build_id():
    with open('main', 'rb') as f:
        f.seek(0x40)
        return(f.read(0x14).hex().upper())

with open('main', 'rb') as fi:
    read_data = fi.read()
    result = re.search(b'\xd2...\xf2...\xf2...\xcb...\xeb.......\x14', read_data)
    patch = '%06X%s%s' % (result.end(), '0004', '1F2003D5')
    text_file = open('atmosphere/exefs_patches/d2r_offline_fix/' + get_build_id() + '.ips', 'wb')
    print('d2r build-id: ' + get_build_id())
    print('d2r offset and patch at: ' + patch)
    text_file.write(bytes.fromhex(str('5041544348' + patch + '454F46')))
    text_file.close()
    cheat = '%s%08X%s' % ('04000000 ', result.end() - 0x100,  ' D503201F')
    print('d2r cheat string: ' + cheat)
    text_file = open('atmosphere/contents/0100726014352000/cheats/' + get_build_id()[:16] + '.txt', 'w')
    text_file.write('{@borntohonk}\n')
    text_file.write('[D2R Bypass Online Check]\n')
    text_file.write(cheat)
    text_file.close()

again refer to:
https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py#L213-L222

whatever you're doing doesn't match the specification of what i posted above.
with the header included of the uncompressed binary (.nso0) it is 08502C. You're missing 0x100 (the size of the header)
https://switchbrew.org/wiki/NSO0



the only changes i would make would be:

(OLSC) an arm instruction with ending of 0x94 was found at the designated offset.
(OLSC) Sys-patch for OLSC string still valid for: 21.1.0
(OLSC) Sys-patch OLSC pattern found at: 085028
(OLSC) The ghidra-equivalent pattern used was: 00 .. 73 .. .. F9 68 02 40 39 .. .. 00 .. .. .. 00
(OLSC) The existing bytes at the offset are: 8AC30294
(OLSC) 21.1.0 OLSC buildid (and what .ips filename should be): {'792DD5A46F44C0BFC017A3BAB9BB347CB51E90E7'}

(OLSC) IPS patch bytes would be:
(OLSC) 50415443480850280004200080D2454F46

targeting the Branch Loader above the cmp identified, and patching it to mov x0, #0x1 will skip it entirely. (apparently failing said cmp check causes a crash function to be called of 0x9990)


08 50 28
00 04
20 00 80 D2

(compiled output of https://github.com/borntohonk/sys-patch/commit/a4cabed80a528326811395e3638f63842a797b49 attatched)
 

Attachments

Last edited by bth,
it clearly says 08502C not 084F2C (adjustment below either way, but you're still 0x100 off)
(the reference post above was edited to reflect on the adjustments below)

(from my own collection of stuff:
.ips patch is always with the header, using the atmosphere cheat api you can target memory, which is without the header, subtracting 0x100, but the system executables we are patching cannot use the cheat api))

Python:
import re
from pathlib import Path

Path('./atmosphere/exefs_patches/d2r_offline_fix').mkdir(parents=True, exist_ok=True)
Path('./atmosphere/contents/0100726014352000/cheats').mkdir(parents=True, exist_ok=True)

def get_build_id():
    with open('main', 'rb') as f:
        f.seek(0x40)
        return(f.read(0x14).hex().upper())

with open('main', 'rb') as fi:
    read_data = fi.read()
    result = re.search(b'\xd2...\xf2...\xf2...\xcb...\xeb.......\x14', read_data)
    patch = '%06X%s%s' % (result.end(), '0004', '1F2003D5')
    text_file = open('atmosphere/exefs_patches/d2r_offline_fix/' + get_build_id() + '.ips', 'wb')
    print('d2r build-id: ' + get_build_id())
    print('d2r offset and patch at: ' + patch)
    text_file.write(bytes.fromhex(str('5041544348' + patch + '454F46')))
    text_file.close()
    cheat = '%s%08X%s' % ('04000000 ', result.end() - 0x100,  ' D503201F')
    print('d2r cheat string: ' + cheat)
    text_file = open('atmosphere/contents/0100726014352000/cheats/' + get_build_id()[:16] + '.txt', 'w')
    text_file.write('{@borntohonk}\n')
    text_file.write('[D2R Bypass Online Check]\n')
    text_file.write(cheat)
    text_file.close()

again refer to:
https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py#L213-L222

whatever you're doing doesn't match the specification of what i posted above.
with the header included of the uncompressed binary (.nso0) it is 08502C. You're missing 0x100 (the size of the header)
https://switchbrew.org/wiki/NSO0



the only changes i would make would be:

(OLSC) an arm instruction with ending of 0x94 was found at the designated offset.
(OLSC) Sys-patch for OLSC string still valid for: 21.1.0
(OLSC) Sys-patch OLSC pattern found at: 085028
(OLSC) The ghidra-equivalent pattern used was: 00 .. 73 .. .. F9 68 02 40 39 .. .. 00 .. .. .. 00
(OLSC) The existing bytes at the offset are: 8AC30294
(OLSC) 21.1.0 OLSC buildid (and what .ips filename should be): {'792DD5A46F44C0BFC017A3BAB9BB347CB51E90E7'}

(OLSC) IPS patch bytes would be:
(OLSC) 50415443480850280004200080D2454F46

targeting the Branch Loader above the cmp identified, and patching it to mov x0, #0x1 will skip it entirely. (apparently failing said cmp check causes a crash function to be called of 0x9990)


08 50 28
00 04
20 00 80 D2

(compiled output of https://github.com/borntohonk/sys-patch/commit/a4cabed80a528326811395e3638f63842a797b49 attatched)
The edited offset you changed for the IPS file and edited instruction works now, so IPS patch is working, but your compiled sys-patch isn't patching. Maybe you need to recheck something for 21+ in the sys-patch code.
 
The edited offset you changed for the IPS file and edited instruction works now, so IPS patch is working, but your compiled sys-patch isn't patching. Maybe you need to recheck something for 21+ in the sys-patch code.
Makes sense

i made a typo of:
C++:
    { "olsc_19.0.0+", "0x00.73..F968024039..00...00", 32, 0, bl_cond, ret1_patch, ret1_applied, true, MAKEHOSVERSION(19,0,0), FW_VER_ANY },

when it should be:
C++:
    { "olsc_19.0.0+", "0x00.73..F968024039..00...00", 42, 0, bl_cond, ret1_patch, ret1_applied, true, MAKEHOSVERSION(19,0,0), FW_VER_ANY },


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

should be addressed now, and behave similar to the proposed .ips patches

( https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/known_patterns.py#L185-L224 )
 

Attachments

Last edited by bth,
Added olsc patch for FW21+ since it's not needed before this it won't be patched or show in the overlay unless you are on 21+ fw, updated the overlay to fix some minor graphic issues and remove ini patch from displaying, added olsc patch to the patches/log sections.

Thanks to bth for the new olsc patch :-).

@bth

Since you already have the patterns, you may as well also set: default_auto_download_global_setting to false since it's just a few bytes away at 0x085060 (and its default was changed in 20.1.0+ to true) you can use the same patch as you already have, but you may as well kill two birds with one stone since you are already setting default_auto_upload_global_setting to false and it's only a few bytes away from that.

Also @bth, I think you should add another patch to sys-patch. With DBI we can change an installed game flag "Edit Parental Controls - Linked Account Required", to force our game to require a linked account to run. We should find which module is responsible for this popup and then disable it so that there's no need for a linked account to play a game, sort of a link account bypass. That we we don't need to create a faked linked account to play some games or need to use airplane mode, or use DBI to remove the flag.

It could be this - https://switchbrew.org/wiki/Profile_Selector - isNetworkServiceAccountRequired

I'm looking here, account-sysmodule - 010000000000001E
FW 21.1
Build ID = D94C4C1969FA35BB27D2DA8E6EF2F8B06A7FA066
Possibly function to check: - sub_71000BFB60

Or it could be here:
0x0100000000001007
LibraryAppletPlayerSelect (playerSelect
 

Attachments

Last edited by bombayjack,
Added olsc patch for FW21+ since it's not needed before this it won't be patched or show in the overlay unless you are on 21+ fw, updated the overlay to fix some minor graphic issues and remove ini patch from displaying, added olsc patch to the patches/log sections.

Thanks to bth for the new olsc patch :-).

@bth

Since you already have the patterns, you may as well also set: default_auto_download_global_setting to false since it's just a few bytes away at 0x085060 (and its default was changed in 20.1.0+ to true) you can use the same patch as you already have, but you may as well kill two birds with one stone since you are already setting default_auto_upload_global_setting to false and it's only a few bytes away from that.

Also @bth, I think you should add another patch to sys-patch. With DBI we can change an installed game flag "Edit Parental Controls - Linked Account Required", to force our game to require a linked account to run. We should find which module is responsible for this popup and then disable it so that there's no need for a linked account to play a game, sort of a link account bypass. That we we don't need to create a faked linked account to play some games or need to use airplane mode, or use DBI to remove the flag.

It could be this - https://switchbrew.org/wiki/Profile_Selector - isNetworkServiceAccountRequired

I'm looking here, account-sysmodule - 010000000000001E
FW 21.1
Build ID = D94C4C1969FA35BB27D2DA8E6EF2F8B06A7FA066
Possibly function to check: - sub_71000BFB60

Or it could be here:
0x0100000000001007
LibraryAppletPlayerSelect (playerSelect
https://switchbrew.org/wiki/System_Settings#olsc

no need to, it defaults to false.


as for your other thing

0100000000001007 - playerSelect (LibraryAppletPlayerSelect)

so let me understand this correctly, what you want is to force disable the requirement for linked account, rather than force it to require a linked account...?


profile-selector.jpg

profile-selector-2.jpg


depending on that b.eq it either goes to additional select (0x409ed0), or loading the value of nsa required (0x409dc4) (code probably loops over nested list and skips if not equal

profile-selector-3.jpg




patching

710040a51c 99 70 f0 97 bl FUN_7100026780

to

710040a51c 20 00 80 52 mov w0,#0x1

will have the cmp of w0, #0x1 be equal

710040a520 1f 04 00 71 cmp w0,#0x1

causing
710040a534 60 c5 ff 54 b.eq LAB_7100409de0
to be equal, meaning it goes to LAB_7100409de0

forcefully not ever going to 0x409dc4, where 0x409dc4 is NSA required
 
Last edited by bth,
https://switchbrew.org/wiki/System_Settings#olsc

no need to, it defaults to false.


as for your other thing

0100000000001007 - playerSelect (LibraryAppletPlayerSelect)

so let me understand this correctly, what you want is to force disable the requirement for linked account, rather than force it to require a linked account...?


View attachment 547756
View attachment 547760

depending on that b.eq it either goes to additional select (0x409ed0), or loading the value of nsa required (0x409dc4) (code probably loops over nested list and skips if not equal
Hmm strange on this page it says it was false upto firmware 19.0.0, but then changed to true at firmware 20.1.0 - https://switchbrew.org/wiki/Switch_2:_System_Settings

Maybe for switch1 it's different to switch2 ?

As for the linked account thing, when a game is launched it must check the user account to see if it's a linked account, because some games will not launch if the flag for the game (probably in main.npdm) is for a linked game, There's a check " isNetworkServiceAccountRequired" which could be set to false which would make the game think it doesn't require a linked account, Either that or we can patch the account settings to report back that it's a linked account, even if it isn't.

https://switchbrew.org/wiki/Profile_Selector - isNetworkServiceAccountRequired
Untitled.png
 

Attachments

  • Untitled.png
    Untitled.png
    19 KB · Views: 23
Hmm strange on this page it says it was false upto firmware 19.0.0, but then changed to true at firmware 20.1.0 - https://switchbrew.org/wiki/Switch_2:_System_Settings

Maybe for switch1 it's different to switch2 ?

As for the linked account thing, when a game is launched it must check the user account to see if it's a linked account, because some games will not launch if the flag for the game (probably in main.npdm) is for a linked game, There's a check " isNetworkServiceAccountRequired" which could be set to false which would make the game think it doesn't require a linked account, Either that or we can patch the account settings to report back that it's a linked account, even if it isn't.

https://switchbrew.org/wiki/Profile_Selector - isNetworkServiceAccountRequiredView attachment 547763
The switch 2 is not the switch 1.

clearly the olsc system_settings from set_mitm atmosphere feature already accomplished what we wanted, which was just one entry, the upload one, which defaults to true.

so i don't see any reason to also patch download to false, which already defaults to false.
 
The switch 2 is not the switch 1.

clearly the olsc system_settings from set_mitm atmosphere feature already accomplished what we wanted, which was just one entry, the upload one, which defaults to true.

so i don't see any reason to also patch download to false, which already defaults to false.
Ok never mind that, it's not a big deal. let's figure out how to patch the account/profile to think it's a linked account so we don't need to create a faked one.
 
Ok never mind that, it's not a big deal. let's figure out how to patch the account/profile to think it's a linked account so we don't need to create a faked one.

might be a

Code:
[ns.rights]
skip_account_validation_on_rights_check = u8!0x1

situation in system_settings.ini

1. i don't know of any examples of games requiring account to be linked
2. i don't know what dbi changes
 
might be a

Code:
[ns.rights]
skip_account_validation_on_rights_check = u8!0x1

situation in system_settings.ini

1. i don't know of any examples of games requiring account to be linked
2. i don't know what dbi changes
You can make any game think it's a linked game or remove the linked flag with DBI. Just open DBI and click on "Installed Games", Scroll to a game then press the + button, Select "Edit Parental controls" from the menu and make it check "linked account required", then exit dbi and try and launch the game.
 
You can make any game think it's a linked game or remove the linked flag with DBI. Just open DBI and click on "Installed Games", Scroll to a game then press the + button, Select "Edit Parental controls" from the menu and make it check "linked account required", then exit dbi and try and launch the game.
DBI is malware, so i'm not going to use that.

your information doesn't clarify "what dbi changes"
I don't know where the flag is set.

im assuming it must be related to https://switchbrew.org/wiki/Parental_Control_services

but that would be stupid. you might just be drawing incorrect conclusion


as for account itself, a nested list of errors and call conditions (errors).

to me it sounds like an obvious situation, that something that requires a linked account, but can't find any, would log... and this would be that.

identifying what exactly is in x10 and x13, would be step 1 of many.
account-2.jpg
 
Last edited by bth,
DBI is malware, so i'm not going to use that.

your information doesn't clarify "what dbi changes"
I don't know where the flag is set.


as for account itself, a nested list of errors and call conditions (errors).

to me it sounds like an obvious situation, that something that requires a linked account, but can't find any, would log... and this would be that.

identifying what exactly is in x10 and x13, would be step 1 of many.
View attachment 547776
If you won't use DBI, I can't post you a game as that's against the rules, however you can do this instead. On your switch if your account is not linked, on the main menu just click on the Nintendo Switch Online or Nintendo Eshop icon, a popup will show asking you to link to a nintendo account. This is the same popup that shows on a linked game. If we spoof our account to a linked one we don't get that. So we can still make a patch and test it like that if you don't have a game or don't want to use dbi.

We could probably look at the source code for linkalho source code to get a hint on what we need to patch....

Or maybe this information can be of some help:
https://github.com/Kinnay/NintendoClients/wiki/BAAS-Server
 
Last edited by bombayjack,
If you won't use DBI, I can't post you a game as that's against the rules, however you can do this instead. On your switch if your account is not linked, on the main menu just click on the Nintendo Switch Online or Nintendo Eshop icon, a popup will show asking you to link to a nintendo account. This is the same popup that shows on a linked game. If we spoof our account to a linked one we don't get that. So we can still make a patch and test it like that if you don't have a game or don't want to use dbi.

We could probably look at the source code for linkalho source code to get a hint on what we need to patch....

Or maybe this information can be of some help:
https://github.com/Kinnay/NintendoClients/wiki/BAAS-Server
i'm going to admit, i have zero interest in this, as your answer doesn't make sense.

it's not against any rules to just name what game, that's just nonsense.
DBI causing said check with parental controls flag is a red herring, and unrelated. It's most definitively a rights management check, (NS.RIGHTS),, probably spawned by DLC being installed.

anyway this can be your project, good luck.



Diff:
--- a/sysmod/src/main.cpp
+++ b/sysmod/src/main.cpp
@@ -314,7 +314,7 @@ auto is_emummc() -> bool {
     return (paths.unk[0] != '\0') || (paths.nintendo[0] != '\0');
 }
 
-void patcher(Handle handle, std::span<const u8> data, u64 addr, std::span<Patterns> patterns) {
+void patcher(Handle handle, const u8* data, size_t data_size, u64 addr, std::span<Patterns> patterns) {
     for (auto& p : patterns) {
         // skip if disabled (controller by config.ini)
         if (p.result == PatchResult::DISABLED) {
@@ -336,8 +336,8 @@ void patcher(Handle handle, std::span<const u8> data, u64 addr, std::span<Patter
             continue;
         }
 
-        for (u32 i = 0; i < data.size(); i++) {
-            if (i + p.byte_pattern.size >= data.size()) {
+        for (u32 i = 0; i < data_size; i++) {
+            if (i + p.byte_pattern.size >= data_size) {
                 break;
             }
 
@@ -356,22 +356,22 @@ void patcher(Handle handle, std::span<const u8> data, u64 addr, std::span<Patter
                 // fetch the instruction
                 u32 inst{};
                 const auto inst_offset = i + p.inst_offset;
-                std::memcpy(&inst, data.data() + inst_offset, sizeof(inst));
+                std::memcpy(&inst, data + inst_offset, sizeof(inst));
 
                 // check if the instruction is the one that we want
                 if (p.cond(inst)) {
-                    const auto [patch_data, patch_size] = p.patch(inst);
+                    const auto patch_data = p.patch(inst);
                     const auto patch_offset = addr + inst_offset + p.patch_offset;
 
                     // todo: log failed writes, although this should in theory never fail
-                    if (R_FAILED(svcWriteDebugProcessMemory(handle, &patch_data, patch_offset, patch_size))) {
+                    if (R_FAILED(svcWriteDebugProcessMemory(handle, &patch_data, patch_offset, patch_data.size))) {
                         p.result = PatchResult::FAILED_WRITE;
                     } else {
                         p.result = PatchResult::PATCHED_SYSPATCH;
                     }
                     // move onto next pattern
                     break;
-                } else if (p.applied(data.data() + inst_offset + p.patch_offset, inst)) {
+                } else if (p.applied(data + inst_offset + p.patch_offset, inst)) {
                     // patch already applied by sigpatches
                     p.result = PatchResult::PATCHED_FILE;
                     break;
@@ -434,12 +434,14 @@ auto apply_patch(PatchEntry& patch) -> bool {
                     if (R_FAILED(svcReadDebugProcessMemory(buffer + overlap_size, handle, mem_info.addr + sz, actual_size))) {
                         break;
                     } else {
-                        patcher(handle, std::span{buffer, actual_size + overlap_size}, mem_info.addr + sz - overlap_size, patch.patterns);
+                        patcher(handle, buffer, actual_size + overlap_size, mem_info.addr + sz - overlap_size, patch.patterns);
                         if (actual_size >= overlap_size) {
-                            memcpy(buffer, buffer + actual_size, overlap_size);
+                            memcpy(buffer, buffer + READ_BUFFER_SIZE, overlap_size);
                             std::memset(buffer + overlap_size, 0, READ_BUFFER_SIZE);
                         } else {
-                            std::memset(buffer, 0, sizeof(buffer));
+                            const auto bytes_to_overlap = std::min<u64>(overlap_size, actual_size);
+                            memcpy(buffer, buffer + READ_BUFFER_SIZE + (actual_size - bytes_to_overlap), bytes_to_overlap);
+                            std::memset(buffer + bytes_to_overlap, 0, sizeof(buffer) - bytes_to_overlap);
                         }
                     }
                 }


meanwhile, i'm currently going over sys-patch and finalizing a 1.5.9 PR upstream
 
Last edited by bth,

it's mostly just a refactor of all patterns/conds.

but it introduces two new patches:
(NIM - for blocking firmware updates from atum when user has no cal0 blanking or dns.mitm configured)
(OLSC - for spinning icon when using fake linked account or de-synced real account from too many firmware versions ago)
attempt to address overlap boundary buffer.

and removes:
disable_ca_verification patch as users shouldn't be enabling that without real mitm (not dns.mitm)
 

Site & Scene News

Popular threads in this forum