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!
This is completely bogus and wrong in nearly every way. People aren't "selling" hacks online (well, except for TX, but I digress) There isn't any economic pressure, that may go on for other consoles (probably not, however) but this has never occured in any recent history of nintendo consoles that I can think of and certainly isn't going on now. The main reason why hax like this are kept under closed doors is due to the fact that the software isn't finished, and they don't want people getting banned or damaging their systems. Despite how it looks, ram hacking is fairly dangerous. Not just the online hacking, but the sheer fact that you could write to places where ninty could detect you. Thus, the devs keep it under closed doors until it's ready for release, and all bugs are patched out. This "selling cheats" thing is not true at all, but i'm open to proving me wrong. Can you link the article?From what I read in a recent public article about the switch hacking scene, there is a certain "economic pressure" not let them be public anyhow..
Ram hacking is simply editing values of games in ram, while they are executing. If you've ever used a cheat engine, or one of the "cheat modules" on older consoles in the past, you know exactly - what it its. (8x1993840 99382893 type cheat codes..
Apparently there is a market of selling those cheats to "rich kids" that want to impress their friends and be on a god trip in ego shooter gaming. Not sure how big that would be on the Switch, but it exists.
Those kids apparently are willing to pay big bucks fpr invisibility, wallhacks, always first... Stuff like that.
Also - the worry that this will become widespread is - not necessarily huge, as Nintendo should always be able to detect modified system partitions an ban anyone doing it.
An idea I had was port CEServer over to the Nintendo Switch. The Switch uses an ARM processor which CEserver supports ARM instructions. What CEServer does is run in the background (Can be a Switch system module) that lets you remotely connect to it from a PC using Cheat Engine to browse and modify memory.
https://github.com/cheat-engine/cheat-engine/tree/master/Cheat Engine/ceserver
https://github.com/cheat-engine/cheat-engine/tree/master/Cheat Engine/ceserver
Pretty sure there's a free version that doesn't have backup loading, but still everything else.
Yea I'm probably just gonna pay for the license though hell it's not like I don't have the money but I want to load my xci back ups as well instead of having to convert them to nsp
Hello!
This is the first time I came here, maybe you know how to download ram for your computer, I have successfully downloaded 4gb ram on the chrome app store on google for free and my computer is used very smoothly but!
This is the first time I came here, maybe you know how to download ram for your computer, I have successfully downloaded 4gb ram on the chrome app store on google for free and my computer is used very smoothly but!
Similar threads
-
- Portal
