Anything that could work like Cheat Engine or Game Guardian, etc would be very welcome. Editing actual values would be much easier than going through encrypted save files.
Yes, it could require a computer to find what you're looking for at first (instead of having it totally on the switch, at least at first) but still be able to apply the cheats you've already made just on the console itself. Kind of like what Japermen is showing right there.
But hey Japermen are you sure that's for the switch? Since it's BOTW it could be wiiu as it was also released there, anyway that's pretty much what we're thinking of.
I'm trying to figure this out, okay here's the game plan so far:
1. Use 'svcGetProcessList' to list the running processes, in the above you'd find which process id is that of BOTW.
2. Once you have that do 'svcDebugActiveProcess' which seems like it's an OpenProcess type of api as on win32
3. Then 'svcQueryDebugProcessMemory' to determine the memory regions you can read/write to and their memory protections (which you might have to change if it isn't writable for example), but this is to know what memory to read for doing your memory scan for values. Seems like win32 'VirtualQuery' equivalent.
4. After that you 'svcReadDebugProcessMemory' with what you know from the 'svcQueryDebugProcessMemory' and compare all the memory you can read against the value your scanning for, like rupees in BOTW (more advanced searches should also be doable like 'unknown initial value'). You change the value in the game and do the next scan, until you have a small enough number of results that you can easily determine which address corresponds to the value you're interested in. (Which is much simpler for exact value scans which actually are truly the value you see).
5. Finally 'svcWriteDebugProcessMemory' to the address you think is the correct one and see if it changes in game, if it does then you've found it. If not then try another one of the few remaining addresses from your scan that you've narrowed it down to. Once you've found it write the value you want, and 'freeze' it if you want it to remain always at that value. (Which just constantly writes it at some interval to keep it locked at a particular value).
Now that's good for your one play session, but the address will be different on the next no doubt, so that's where the optional next steps come in. Though I haven't figured out how to quite do it yet, this is where I need to figure out.
[Optional but desired step A.]
With the address you've found to be correct, after you've done all that work you're going to want to be able to keep reapplying your cheat easily without having to do that all over again every time. We need to know how to set a breakpoint on read/write/or access (both) so that it's possible to determine the code that's responsible for writing to or reading from your value (ex. rupees in botw).
If you find the code that writes to it, you could make it so that every time you pick up a single rupee of any kind it always sets it to the maximum amount you can carry. Or if you find the code that reads from it you could make it so it constantly is setting your rupees max even without doing anything (because as it's reading it to display it on screen it's being set to max as well).
There doesn't seem to be a 'svc' api (one will have to be written it looks like, or done manually) that lets you set a hardware breakpoint, but once you do I think 'svcGetDebugEvent' and 'svcContinueDebugEvent' will allow you to grab the addresses of the code that read/writes to your value's address and let it continue to get all the locations of code that read/write to it.
I've done some reading and it seems AARCH64 has 6 hardware debug registers. (Unlike x86/AMD64 which have 4, so that's a plus we get two extra
)
I think these are the ones of interest:
0x400 DBGBVR0_EL1 RW 64-bit Debug Breakpoint Value Register 0 [
a]
0x408 DBGBCR0_EL1 RW 32-bit
Debug Breakpoint Control Registers, EL1
0x410 DBGBVR1_EL1 RW 64-bit Debug Breakpoint Value Register 1 [
a]
0x418 DBGBCR1_EL1 RW 32-bit
Debug Breakpoint Control Registers, EL1
0x420 DBGBVR2_EL1 RW 64-bit Debug Breakpoint Value Register 2 [
a]
0x428 DBGBCR2_EL1 RW 32-bit
Debug Breakpoint Control Registers, EL1
0x430 DBGBVR3_EL1 RW 64-bit Debug Breakpoint Value Register 3 [
a]
0x438 DBGBCR3_EL1 RW 32-bit
Debug Breakpoint Control Registers, EL1
0x440 DBGBVR4_EL1 RW 64-bit Debug Breakpoint Value Register 4 [
a]
0x448 DBGBCR4_EL1 RW 32-bit
Debug Breakpoint Control Registers, EL1
0x450 DBGBVR5_EL1 RW 64-bit Debug Breakpoint Value Register 5 [
a]
0x458 DBGBCR5_EL1 RW 32-bit
Debug Breakpoint Control Registers, EL1
Maybe it's actually the watchpoint ones below that we're interested in for this purpose though, I'm not 100% sure but I think it's the above ones.
0x800 DBGWVR0_EL1 RW 64-bit Debug Watchpoint Value Register 0 [
a]
0x808 DBGWCR0_EL1 RW 32-bit
Debug Watchpoint Control Registers, EL1
0x810 DBGWVR1_EL1 RW 64-bit Debug Watchpoint Value Register 1 [
a]
0x818 DBGWCR1_EL1 RW 32-bit
Debug Watchpoint Control Registers, EL1
0x820 DBGWVR2_EL1 RW 64-bit Debug Watchpoint Value Register 2 [
a]
0x828 DBGWCR2_EL1 RW 32-bit
Debug Watchpoint Control Registers, EL1
0x830 DBGWVR3_EL1 RW 64-bit Debug Watchpoint Value Register 3 [
a]
0x838 DBGWCR3_EL1 RW 32-bit
Debug Watchpoint Control Registers, EL1
"
Table 10.3 shows the debug control registers that are accessible in AArch64 state. These registers are accessed by the MRS and MSR instructions.
Table 10.3 also shows the offset address for the AArch64 registers that are accessible from the internal memory-mapped interface or the external debug interface. See the Memory-mapped register summary for a complete list of registers accessible from the internal memory-mapped or the external debug interface."
I'm getting this from here by the way:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0488c/CEGDIEBB.html
And actually now that I look more closely it does give you an idea of how to interact with them, the MRS and MSR instructions, or the internal memory-mapped interface or external debug interface. So that should be my next thing to look into!