Hacking Sigpatches for Atmosphere (Hekate, fss0, fusee & package3)

[duckbill007]

@bth , about nocntchk patch. For 19.0.0 exfat now it is patched at 745a0, but there are 2 other checks for the same flag, that produces the same error code: at 75498 and 7551c. Why 1st one so special, so it need to be patched and 2nd and 3rd ones should not?

 

[bth]

@bth , about nocntchk patch. For 19.0.0 exfat now it is patched at 745a0, but there are 2 other checks for the same flag, that produces the same error code: at 75498 and 7551c. Why 1st one so special, so it need to be patched and 2nd and 3rd ones should not?

tl:dr 745a0 BL -> mov x0, xzr to cause zero to be passed down into this chain:

brown colored function is the header signature check, which performs the check if a non-zero result is passed to the function.

(mov x0,xzr sets x0 to 0 and x0 is what is passed down into that functon call/branch loader/ "BL")

nintendo has done this code this way, because this function is called repeadetly, and if a prior call of function has returned zero, it is passed down and skips the check.


patching to mov x0, xzr at that bl/function call/branch loader forces the "skip" condition.

Post automatically merged: Nov 9, 2024

In other words, 745a0 is sacrificed to force zero to be passed for when BL 76ac0 is called, as 76ac0 is what actually checks the signature, or skips if zero is passed through x0.

 

[duckbill007]

Why patched 745a0 is obvious. I asked not about this place, but why two other places are not patched.

 

[bth]

Why patched 745a0 is obvious. I asked not about this place, but why two other places are not patched.

Perhaps language barrier for you, i explained why. big image, explaining why in detail too


here is more big image

 

[Oliver180401]

I have a problem playing games i installed from Tinfoil and DBI.

Console is on FW 19.0.0
Atmosphere v1.8.0 Pre-release
Newest Sigpatches from their website.

I have updated everything through USB tools in hekate.

I have tried NSP and XCI roms launched in Tinfoil, DBI and Awoo.

I launch in Atmosphere FSS0 emuMMC

I'll add pictures of everything. Let me know if you need more.

I have spend a good amount of time myself try to fix this, but i don't know what to do anymore.

Does anyone have an idea what the problem is? I'll try anything.

Pictures below:

Post automatically merged: Nov 9, 2024

Omg never mind i am just an idiot. I have it working now with dbi.

I updated the files on my sd card on the pc, not via usb tools and put fusee.bin in payloads. But atleast i am glad its working now

 

[duckbill007]

@bth , I do understand code flow of this function. I am asking about 2 other places: 75498 and 7551c. Both of them are absent in your pictures and are part of another function, called in some other case. My question - why that places shouldn't be patched?

 

[MoonDog]

Hey so I stupidly updated to 19.0.0 without thinking and now even with hekate and atmosphere updated with the sig patches and running an Archive Bit Fix, I still get a fatal error 0xffe when attempting to load atmosphere from package3. Running from fusee seems to work but does not let me choose to boot semi-stock. inexplicably, running package3 to emummc works just fine. I -would- just stick with running using fusee, but several of my games won't let me play unless i install an update, and since it's blocked from updating i'm stuck doing nothing.

I'd very much appreciate some help unless this isn't the place to ask for it.

 

[duckbill007]

@bth, already figured out myself.

 

[bth]

@bth , I do understand code flow of this function. I am asking about 2 other places: 75498 and 7551c. Both of them are absent in your pictures and are part of another function, called in some other case. My question - why that places shouldn't be patched?

tl:dr as highlighted with images above, the actual function loading the signature modulus for verification is called there with x0 as a parameter.

the other offsets/functions you reference do something else.

we care about the return value of this function, and it should be ret 0.

other functions example: 75498; bl FUN_71001517c
which is just ldrb w0, x0, ret, doesn't have much to do with anything really

just as example the "75498; bl FUN_71001517c" is called from within function 75410, and eventually leads to 743f0 which is where 745a0 is.

now why would you patch up there, or down here, or why not all places?

we patch 745a0 to control outcome of where problem is, no reason to go out of way 5 functions deep ahead when we can just ensure zero at the specific arm instruction we need.


while you can end the call chain and ret 0 already in function 75410 that is bad behavior, as this is FS- File System, it loads nca into memory and such, obvious stuff, interrupting with how that works bad.

Post automatically merged: Nov 10, 2024

very obvious upon inspecting pseudocode why not to mess with before functions. and logically, a function checking header signature obviously does not do anything but verify signature.

similarily, the function which calls for result from 743f0 (fun 722a0) returns the value of 743f0 to 76634.

we could also just do this, as uvar5 is the return of 743f0 (which we change the outcome of by patching mov, x0, xzr

changing 7235c to mov, w0, wzr from mov, w0, w21 should have same effect.

in 722a0 which is the function that works with the result of 743f0 this is exactly what uses the value.

15174c / 151768 / 662f0 becomes ran if 743f0 returns zero, does not if return 1, which is why to patch function 743f0 and not 722a0 (patching 722a0 in addition would eliminate other fail conditions, but eh)

15174c is an external service call to what im guessing is spl or ncm

151768 is just instruction mover

662f0 is essentially just a check for zero

all of this information boils down to that 745a0 must be patched to return zero so that the function itself returns zero for the codepath below in 722a0, otherwise that function call to external function isn't made.

 

[duckbill007]

I was talking not about header signature check but about different check. Nonetheless I already fugured out what I want.

 

[bth]

I was talking not about header signature check but about different check. Nonetheless I already fugured out what I want.

Are you sure you're finding anything? Becuase the function call which is related to function 743f0 (745a0) is 7550c, not
75498 or 7551c (this one is 0x10 wrong, but close enough)

75498 doesn't have much to do with anything of interest.
7551c also doesn't have much to do with anything of interest

both are just x0 to w0 loaders


if you are confused, 745a0 is patched not because it's loading x0 to w0 loader, it's patched to force zero to x with mov x0, xzr (zero to x0) so that the check is bypassed, and the function call itself is worthless, so nice place to sacrefice the call to force zero

for 7551c specifically, zero comes out there down where the value that is being compared is derived from (ultimately function 743f0)

like sure you could patch 1517c4 to be mov, w0, wzr instead of placing mov x0, xzr at 745a0, and instead of patching 3 BL's since this function is what is called, and all it does is load x0 into w0 for then to be called into a zero check


the reason i didn't implement a pattern for 1517c4 is because exfat/fat32 different in that region, and it's surrounded by other various loader functions, which while not impossible to just instruction pattern search, is more of hassle than 745a0

1518C4 0004 E0031F2A
15D0F4 0004 E0031F2A

#FS 19.0.0-fat32
[FS:D94C6815F8F50A20]
.nosigchk=0:0x021478:0x4:60090036,1F2003D5
.nosigchk=0:0x1517C4:0x4:00004039,E0031F2A

#FS 19.0.0-exfat
[FS:EDA87868A4490750]
.nosigchk=0:0x021478:0x4:60090036,1F2003D5
.nosigchk=0:0x15CFF4:0x4:00004039,E0031F2A

for 17.0.0+ would be
byte search
\xe1\x03\x00\xaa\xe0\x03\x08\xaa\x02\x25\x80\x52..\x01\x14

sys-patch
constexpr auto ldrb_cond(u32 inst) -> bool {
return (inst >> 39) == 0x10; // ldrb w0, [x0]
}



{ "nocntchk2", "0xe10300aae00308aa02258052..0114", 16, 0, ldrb_cond, ret0_patch, ret0_applied, true, MAKEHOSVERSION(17,0,0), FW_VER_ANY },

ghidra search
e1 03 00 aa e0 03 08 aa 02 25 80 52 .. .. 01 14

 

[shadow256]

@bth: Thanks for all these explainations, it's far from my comprehension but it's intresting to have some informations on how things work so thanks again to share your knolages with us.

 

[PxPates]

Hi, I still have the error when i try to connect to internet. I have done an complete reinstallation from 0 of my hacked switch with the HATS 1.8.0 prerelease v1.2 pack and i still have this problem. Can someone look into it ?

 

[Blythe93]

Hi, I still have the error when i try to connect to internet. I have done an complete reinstallation from 0 of my hacked switch with the HATS 1.8.0 prerelease v1.2 pack and i still have this problem. Can someone look into it ?

Latest sys-patch 1.5.4 has nim prodinfo fix included so it should fix that error you're having. Make sure to reboot after you copy the files over to your SD card.

 

[PxPates]

Latest sys-patch 1.5.4 has nim prodinfo fix included so it should fix that error you're having. Make sure to reboot after you copy the files over to your SD card.

installed it + rebooting and i still have the error code

 

[Blythe93]

installed it + rebooting and i still have the error code

From what I can see here, the program ID matches the one for NPNS services, used for Push Notifications. Not really sure what else you can do about that.
Do you have DNS MITM set up? If not, try that as well.

If that doesn't work, make a backup of your atmosphere and bootloader folders just in case something goes wrong and remove them afterwards from your SD card. After that, download the latest fresh Atmosphere and Hekate from their official repositories. While you're at it, you'll need a new hekate_ipl.ini which you can grab from the sigpatches thread, as well as latest sys-patch. After that, put the SD card back into your PC, launch RCM mode and send the latest fusee.bin payload and, hopefully, it'll work this time around.

Ultimately, I'd check if the SD card is faulty or not with h2testw and see if that's the issue. If you can boot into stock firmware, I'd start from scratch by following the NH Switch guide and install the latest firmware, sys-patch and set up DNS MITM.

 

[JamesDeans]

cann someone help i still have the Standby issue and i cant start any forwardes on 19.0.1 is really frustrating since a few weeks it dont work anymore

 

[bth]

cann someone help i still have the Standby issue and i cant start any forwardes on 19.0.1 is really frustrating since a few weeks it dont work anymore

The forwarder part of your problem is related to a kernel change in 19.0.0+, you have to obtain new forwarders complying with debug flag change in kernel.

the other half is you have sysmodules that exist in /atmosphere/contents/ that are outdated and need to be removed completely (all of them), and reobtain newer versions (if they exist)

 

[PxPates]

From what I can see here, the program ID matches the one for NPNS services, used for Push Notifications. Not really sure what else you can do about that.
Do you have DNS MITM set up? If not, try that as well.

If that doesn't work, make a backup of your atmosphere and bootloader folders just in case something goes wrong and remove them afterwards from your SD card. After that, download the latest fresh Atmosphere and Hekate from their official repositories. While you're at it, you'll need a new hekate_ipl.ini which you can grab from the sigpatches thread, as well as latest sys-patch. After that, put the SD card back into your PC, launch RCM mode and send the latest fusee.bin payload and, hopefully, it'll work this time around.

Ultimately, I'd check if the SD card is faulty or not with h2testw and see if that's the issue. If you can boot into stock firmware, I'd start from scratch by following the NH Switch guide and install the latest firmware, sys-patch and set up DNS MITM.

Like i said, i have done a clean install from 0 of my sd card with the latest HATS pack. DNS MITM is set up, I have latest sigpatches and sys patch. My switch was working flawlessly until i update my switch from 19.0.0 to 19.0.1 and now I can't connec to internet without it crashing...

Post automatically merged: Nov 11, 2024

Like i said, i have done a clean install from 0 of my sd card with the latest HATS pack. DNS MITM is set up, I have latest sigpatches and sys patch. My switch was working flawlessly until i update my switch from 19.0.0 to 19.0.1 and now I can't connec to internet without it crashing...

Ok so i found what the problem was. My emummc and sysmmc software versions were not the same. I found a 19.0.1 firmware version to update to and now the problem is solved.
Im sorry for losing everyone's time

 

[Blythe93]

Ok so i found what the problem was. My emummc and sysmmc software versions were not the same. I found a 19.0.1 firmware version to update to and now the problem is solved.
Im sorry for losing everyone's time

I'm glad that you managed to fix it. ^^ While my emuMMC is usually the latest available, my sysMMC is still on 16.1.0 or something like that (that's the firmware it had on it when I bought it). No worries, I'm no expert so I try to help however I can, even if it is a moral support only. ^^ Have fun.