Feature request: flexible patch settings for rxMode

[dukesrg]

It will be good if all optional patches can be switched on/off. Maybe it will be even more comfortable to have a separate settings for sysNAND and emuNAND.
For example:

• a special patches configuration is required to do a system transfer from the exploitable version of sysNAND
• update preferably should be switched off for sysNAND but must be able to access from emuNAND
  It also will be useful to test a side-effects of patches.

[Hartie95]

I'm working on including more arm11 patches in rxtools, but at the moment its not flexible and the labeling in syssettings is not working, but you can check it out:
https://github.com/hartmannaf/rxTools/tree/fmpPatches

I didnt include the auto update patch, because I heard it could make the home menu unstable. I will create a pull request, after I fixed the labeling.

[AlbertoSONIC]

@dukesrg The problem is that patches are injected in the firm (sd/rxtools/data) at the first boot, during the Installation Data Suite. This means that we can't choose the patches to apply if not during the first boot...

[Syphurith]

@AlbertoSONIC @dukesrg See how the region-free is done. It could be patched everytime.

[AlbertoSONIC]

?

[Syphurith]

Eh.. The region-free from MyThread.c (in rxMode) is done when boot. If modified to read a specific file, you could load your patch patterns and search for that, instead of just region-free.
If i've made mistake again, sorry for that. Still the 16 bytes is present in the FIRM.

[AlbertoSONIC]

Yeah this is true

[dukesrg]

IMO there are virtually may be two kind of patches: that can be applied on after firmware file loaded just before actual firmlaunch executed and that must be applied on already running firmware (like MyThread)
Also patches may have fixed address or signature-based.

It's not a big deal to make a unified format that will support all those king of patches (including firmware version differences) and make the rxMode engine work with separate patch files.

[Hartie95]

That's something I thought about to add it to my my free multi patcher, but I haven't thought about a format yet.

[Syphurith]

@hartmannaf Glad to see you. is your patcher only for ARM11 or also for ARM9?
I think those ARM9 should be kept here, and most ARM11 could go into your patcher.

typedef struct {
  u32 offset; //Where the original code should be.
  u32 original_length;
  u8* original_bytes;
  u32 patched_length;
  u8* patched_bytes;
  u32 flag; //Contains some flags such as ModeApply, Override, and so on.
} PatchRecord;

And be followed by those original bytes and patched ones directly after it.
You may even make a RAM dumper or auto-searcher to make it even easier - if you would like.

[Hartie95]

@Syphurith my patcher is an arm11 application for arm11 patching. I think I will start implementing a patch format there first and port it over here to rxtools after I finished it. But first I will finish implementing my current patches in rxtools(Its only fixing the system version labeling for rxmode before it's finished).

[Syphurith]

@hartmannaf Thanks for contributions. If you want to discuss the format, don't forget to tag someone.

[ghost]

Soo... Any progress on this? Would be neat to be able to completely disable all mods in emuNAND, so it's like "Classic Mode" where emuNAND is completely clean (such as the old rxTools).

[AlbertoSONIC]

Ehmmmm old rxTools emunand wasn't clean at all. It had MyThread and reboot patches. The only missing thing was the sigcheck patch. Anyway, this a planned feature. As i said on gbatemp, I want to remove Native_Firm patches from initial configuration and apply them at every boot, so that we can choose which one to apply ;)

[ghost]

Cool :)

[173210]

@AlbertoSONIC Patching in booting time has accomplished with 2c38588 and other fixes.
But I don't think we need more options for patching. Now it has options for emuNAND and key X 0x25. They should be enough.