I talked a lot about how you can use certain tools to research games in such a way that you can figure out how it works internally which might give interesting information or even allow to glitch the game. I mostly talk that after the emulator which is the most important tool for this, there is one called a RAM search which is so important that its uses isn’t just for reverse engineering, even TASers makes use of it because it provides quick ways to monitor important variables that the game doesn’t show you otherwise. It’s also very popular to hack stuff like Flash games or things like that.
Well, getting it to work with your program is NORMALLY painless and it’s a very documented process. There is a few exceptions and due to really specific circumstances, Dolphin emulator is unfortunately one of them. This problem has been around since forever and is not only still present today, but it got worse which was honestly inevitable to happen.
To better understand why it’s such a pain to use a decent RAM search with Dolphin, I first need to explain how a RAM search actually works.
How a RAM search works
Basically, as its name says, a RAM search allows you to……search the RAM 0_o . Now, to do this, your RAM search needs to know where to look for because you obviously don’t want to hack your Windows/Linux/MacOS’s RAM while trying to change how much HP you have in your game. For an internal RAM search in an emulator, this is of course not a problem because such RAM search can know where the emulated RAM starts, it’s inside the same program already, it has access to this easily. However, this is different for an external one because it has to look inside your RAM via its own process. This makes so that it needs to prompt you which process you want the search to be in and because of that, it will only look into the region of the RAM you want. The basic idea is that the RAM search will prevent you from touching uninteresting or unwanted RAM first.
Once it knows these information, this is where you can start scanning which is basically searching like you would through something like a phone directory, except the data will keep changing. One of the most important features of a RAM search is it works at runtime meaning it will allow you to edit and read RAM addresses while the program is running so it will also give you almost real-time updates on the value of these addresses, so this is why the data keeps changing. As for the scanning process, it’s really just you providing informations on what you know about what you are looking for, but often it’s limited and that’s fine, the RAM search is made to provide filters to make it easier to pinpoint what you want. An easy example is if you wanted the HP address of an RPG, you know the value so you just search any addresses that has THIS EXACT VALUE. After, you purposely change this in-game (take damage or heal) so then you know an exact new value that you can use to filter those who should have changed in the results list. Eventually, the result list will be small enough for you to just figure out which address you want, you could just edit the value in the RAM search and it should change in the game, you are editing its RAM after all!
Other times however, it’s much more complex, if you were trying to find your character’s coordinate in the 3D space, this gets tricky, you don’t know the value initially so you have to scan the entire RAM at first and you only can guess when it goes up or down (like Y coordinate, higher is superior number than lower). Other times it’s even more complex because you can only know where a value is changed or unchanged. The nice thing of a RAM search is it handles all of these use cases, you do however have to be smart when scanning, it can take time and patience to find the desired addresses.
Once you have the address……that’s it! You now have a bookmark to the address so you never have to redo the entire scan again, you read it directly, edit it whatever, even have a label to identify it.
It’s that simple?
Actually yeah it is. This is why RAM search are so useful among TASesrs, game reverse engineer and glitch hunter: it’s simple to grasp, you don’t even need to know about programming to use it, it helps, but you don’t need to.
The one thing you do have to make sure is that you interpret the data correctly because one disadvantage of a RAM search is just that you see the RAM, it has beautiful hexadecimal numbers that can take gigabytes of text if combined, but is completely meaningless on its own. You, the user, are supposed to be responsible for interpreting the data correctly, the RAM search cannot help there. This is different if you were using a debugger because it would show you where it write and the surrounding code tells you why it do so. For a RAM search, it’s just looking through numbers which back to my telephone directory example: if I spit out a random telephone number without anything related to it, it’s meaningless unless I tell you it is a telephone number and allows you to contact whatever. This is why although it’s simple to grasp (there is also a lot of tutorials out there), but takes a lot of experience to be efficient. I myself took months to be used to it and to be efficient. I still learn, it takes time.
A deeper perspective
So your RAM search is really just a browser of thousands of numbers in a database that is your own RAM, but one special thing with this RAM is that depending on how the program arranges its data, the formatting can be completely different.
Not only you have to be carefull on interpreting the data, but you also have to choose the right format. This is why RAM search asks you to select a type when doing any scanning or adding any addresses, they need to take the raw hexadecimal format of your RAM which is again, meaningless on its own and format it to something you want and can understand. A good example is how floating point works, a float type is 4 bytes and it uses a lot of gymnastic with the bits and scientific notation to the point where 0x3F800000 is actually 1.0 if you format it in floating point. You want to see 1.0 on your screen, and you also want the RAM to be 0x3F800000 if you edit the value on your screen to 1.0, I mean imagine if you have to enter the hex by hand for this format it’s ridiculous. The only way for the RAM search to do this formating for you is you have to specify “this is a float” or “this is text, encode it in ASCII” or even “this is just an array of bytes, don’t format anything”. At the end, it will read the same RAM whichever type you choose, it will just present it to you differently.
On a last note, RAM search can also potentially interpret pointers which are kinda special because instead of holding some data, it holds another address. This is especially important if the program you scan in uses dynamic memory because since the memory is not guaranteed to be in the same place, it has to hold a link to it somehow in a fixed memory location and work from there. A RAM search, if told could understand that this is a pointer and instead of reporting the value, it will go to the address pointed and then report the value, so it follows the link.
Getting a RAM search to work with Dolphin
And this is where we come down to using a RAM search with Dolphin. Dolphin doesn’t feature an internal one (and I don’t think there will be a very advanced one given how it could severely impact performance) so we have to get an external one, this is where the problem starts.
Dolphin is emulating a system that has a completely different architecture than the PC you would run it on. Your PC should be using an x86-64 cpu while a Gamecube or Wii actually uses a PowerPC cpu and the worse: its RAM is interpreted in big endian instead of little endian like your PC. The concept of endianness is simple to understand, it dictates which bytes in a data is the most significant one when you read or write. Here’s an example, 0x05 00 which is 1280 in decimal, but only if you say that the 05 part is more significant than the 00 one, kind of like when we write numbers normally (for 111, the leftmost 1 worth more than the rightmost one). If this was read in little endian, you have to swap the bytes which means it’s actually 0x00 05 which is 5 in decimal. This makes such a difference which shows how important it is when you read the RAM. And lastly, the emulator follows how the console would map its memory which I don’t think I need to add, is nothing like your PC.
So these are some challenges for RAM search, let’s see which one we can use.
The RAM search possibilities
Actually there’s not much. External RAM search aren’t very common and this makes it so that there’s only 2 really good RAM search for this: MHS (memory hacking software) and the overly popular Cheat Engine, which I will name CE in this post (yes, it’s not just a cheating program, it’s actually a RAM search). MHS has really nice features like being able to specify an address using an expression so it is nice, but the deal breaker is that it has NO support for big endian memory (we NEED this for Dolphin) and you can’t add such features because it’s not open source and it has no interface to add something like that. Also, it’s made for x86, definitely not going to understand the emulated addresses and its pointers making it really annoying for dynamic memory. However, it CAN work out this problem: you can use the advanced expression as an address and it could resolve the pointer correctly even though it isn’t supposed to understand Gamecube or Wii addresses. So unusable, but it’s really good for little endian memory.
As for CE, it’s similar to MHS, but is different in some ways. First, it can’t really use advanced expression like MHS does so it cannot understands Gamecube and Wii addresses so dynamic memory is a huge problem. It is also clearly designed for x86 little endian memory, but it offers possibilities to add custom type via some assembly stuff. Which is why CE can actually work with big endian memory, the conversion doesn’t seem perfect, but it works for the most part. And CE is really really simple to use I mean to make sure you know how to use it, they include a tutorial where you get to scan stuff and hack it, really nice to get into RAM search usage imo.
As a bonus, the creator also made a ceserver program that allows to scan over a network, but it can also serve to make it work under Wine and scanning Linux processes. It sounds like it’s a hack, but having used it for a long time, it works wonderfully.
Now, Cheat engine IS open source, but the problem is it’s written in a language called Delphi which I personally dealt with and……my god I wish everyone reading this won’t have to use it in their life, it’s really inefficient and just makes me not want to use it.
Putting this together, what exactly is the problem?
You might have noticed that considering these 2 choices (there is no other alternative for this), dealing with any sort of emulated dynamic memory within Dolphin is not easy. CE cannot follow pointers while MHS can, but it cannot work with Dolphin. You could maybe sort of add a lua script that MAYBE solve this problem or edit the code, but this is overly complicated and I even doubt it’s possible considering CE ONLY understands raw x86 pointers, it was designed to deal with them after all, they didn’t expect you would try to access big endian emulated memory. In fact, the only way to deal with dynamic memory is basically you find the address you want and make sure you perform all your tests without triggering a change of RAM position unless you want to test using another situation. This is the case for Super Mario Sunshine, the coordinates of Mario are in a dynamic memory area so if I was in Delfino Plaza, they would be somewhere, but if I go to Bianco Hills, it changes place, same for all stages and even it depends on what is loaded in the map so there is no way you can track all the possible places the address could be, you have to test using ONE location AT A TIME. This basically sucks and this problem has been said again and again for years and it’s still present! There’s still today NO way of dealing with this, we could if MHS supported big endian, but it doesn’t. And I guess no one including me wants to add this to their code because it’s in Delphi…..not to mention it would be very complex to implement at this point.
But wait! there’s more problems!
I mentioned at the beginning the RAM search needs to know where to look for the memory. For emulators, there’s an extra layer, you want to ONLY mess with the emulated memory which is a fraction of the entire emulator memory. CE can already hook to the Dolphin process, but cannot by itself know the address of where the emulated memory starts. luckily, up until now (more on that later), the start address was usually stable, it was hardcoded in non Windows platform and on Windows, it wasn’t guaranteed, but for whatever reasons, the address seemed to be stable and not change for most users. So you could add the address as reference and just use a range for the scan and this works, it’s also easy, you add the address and it’s done.
However, this setup is VERY fragile, the only reason this worked at ALL is because of luck, Dolphin just happened to initialize the emulated RAM in a quite stable location by accident (on Linux, it was because of an unrelated reasons it happened to be hardcoded). This means that if there’s ANY change to how Dolphin initialize the emulated RAM, this setup goes out the water…..
and the inevitable ACTUALLY happened.
The situation now
Recently (as of this post at the very least), Dolphin did changed how it maps the emulated memory because Dolphin is now PIE (position independent executable) compliant which means it can use an OS security feature that basically randomnises the layout of executables. This has been into effect since Dolphin 5.0-3981.
So you guessed it, the location of the start address is no longer stable in all platform, I confirmed it, it truly changes randomly, even staying Dolphin opened and stopping the emulation will cause a change on the next emulation start.
You can STILL use Cheat engine however, but the method is now MUCH more complicated: you have to find a pointer in the Dolphin process that points to the start of the emulated RAM. That, is already annoying to do, but the worst is the pointer changes with each versions so you have to reassign it constantly every time you update. But the worst part is the addresses, since these has to use the pointer + a certain offset they are bound to this pointer. So everytime you want to add an address permanently in your list, you have to take out a calculator, put it in hex base, and computer the difference of the address you found and the actual start address…….this sounds and IS painful. Before the easier method was known, I used to use this method and it suuuuuuuuuuuuuuucks, just adding an address is a process.
I like to reverse engineer and this is by far the most frustrating problem I ever encountered. The Dolphin team can’t really help here, it’s a bit out of the scope of the project and it’s a very specific use case.
So is this problem even solvable?
Yes, you can in theory have a RAM search that makes assumptions on how Dolphin emulated memory works, reads in big endian with good conversion and FINALLY has good dynamic memory support where the address will dynamically change depending on a Gamecube/Wii pointer. All of this is possible.
The issue is what’s needed to have this dream happen. You can’t rely on expanding Cheat engine much and it was the only good and simple RAM search that supported big endian. You could in theory have a fancy debugger setup, but this is anything but simple to use, not much would agree to use it tbh and would require you to build from source which is just very annoying for the user.
I have honestly been very unmotivated to reverse engineer a lot of Dolphin stuff because of this, it really is such a simple problem and yet, so far away from an easy solution.
Which is where I might come…
Starting a new RAM search
It’s one solution, it would work and it would solve the problem if done right…..forever. You could make it work to the new Dolphin mapping and have it work in such a way that you don’t need to even think about tour PC’s RAM, just the Gamecube or Wii RAM which is what it should have been in the first place. Since it would be for Dolphin, you can do all kinds of assumptions, it would be made for Dolphin after all.
I originally thought the idea was kinda of a dream and ridiculous, but I will be honest:
I am soooo tired of this problem
In fact, I am so much that I am even thinking about starting my own project to do just that. It would be A LOT of works and especially for me who never ever started my own project, but I just want to try it. Everyone that attempted to seriously use CE with Dolphin that I met hated the lack of dynamic memory support, several games holds their important memory in dynamic memory. These people are going to hate this even more when Dolphin 6.0 woudl come out and now they woudl be stuck with the painful pointer method….
To be clear, it’s not confirmed, but I am currently brainstorming the ideas, I really need to consider starting this and also, if I decide to do it, it would be a big challenge in my life that I would find interesting and I guess it could serve as nice blog posts 🙂
But yeah, I just want these problems to end, maybe I would be motivated to reverse engineer stuff again if I happen to solve this.