You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 17, 2019. It is now read-only.
Perhaps a strange idea, but service patches (such as re-adding svcbackdoor) are going to be a pain in the arse if they aren't handled specially.
Basically, a service patch would have to have to specify the firmware type in subtype and somehow specify which service to set. The binary for a service patch would load to the first free area it can be called from, and the service table would be set to where it's located in memory.
Obviously svcBackdoor was removed by nintendo. While I'm close to havinf figured out the offsets necessary to fix @Wolfvak/icing, it will need a new patch1.bin every firmware, which means it's annoying to maintain even moreso than the signature patches.
This feature would also allow adding new services to unused slots, which could be interesting to developers. I'm sure there's a few use cases which would benefit from custom services.
As a final thought: svcBackdoor is gone now. We need to make sure no Nintendo applications start declaring access to it next firmware - since it's now a reliable way to detect CFW usage. Hardening svcBackdoor to be more secure than nintendo's implementation is probably a start.
The text was updated successfully, but these errors were encountered:
The binary for a service patch would load to the first free area it can be called from, and the service table would be set to where it's located in memory.
That's exactly how memory patches work. Now, I'm assuming this svcBackdoor is for arm11, in which case the current implementation for memory patches won't work yet. This is because I don't know of any place where I'm sure the patches won't be overwritten, aside from address translation.
I'll change the title to 'Allow ARM11 Memory Patches'.
IMHO, Memory patches are pretty confusing and not well documented, it took me a bit to sift through the code to realize that's how you use them and I still have no clue how to implement one.
The way Luma3DS/the experimental cake does it is by putting the code in the ARM11 exceptions page at the first free location, which won't be overwritten afaik. Requires some runtime checks for safety, though.
IMHO, Memory patches are pretty confusing and not well documented
Hm, I guess. Though it's not much more than: Memory patch is written to a free location, patcher makes sure whatever FIRM patch requires it points towards it (and I agree the code for it is shittily documented).
Perhaps a strange idea, but service patches (such as re-adding svcbackdoor) are going to be a pain in the arse if they aren't handled specially.
Basically, a service patch would have to have to specify the firmware type in subtype and somehow specify which service to set. The binary for a service patch would load to the first free area it can be called from, and the service table would be set to where it's located in memory.
Obviously svcBackdoor was removed by nintendo. While I'm close to havinf figured out the offsets necessary to fix @Wolfvak/icing, it will need a new patch1.bin every firmware, which means it's annoying to maintain even moreso than the signature patches.
This feature would also allow adding new services to unused slots, which could be interesting to developers. I'm sure there's a few use cases which would benefit from custom services.
As a final thought: svcBackdoor is gone now. We need to make sure no Nintendo applications start declaring access to it next firmware - since it's now a reliable way to detect CFW usage. Hardening svcBackdoor to be more secure than nintendo's implementation is probably a start.
The text was updated successfully, but these errors were encountered: