Dolphin ASLR

[Henrik0x7F]

Hey, I'm working on a similar project and I have some questions about dolphin's ASLR. Is only the begin of the emulated memory at a random location in dolphin's process memory or is the emulated ram itself randomized? When I found the start, is it valid until the emulation is stopped? I did a bit of research but found inconsistent information, so I would appreciate the help of someone who has a program dealing with exactly that.

[aldelaro5]

Hi.

I haven't tested too much, but there's one thing I know for sure: 5.0-3981 is the first version of Dolphin where no matter the platoform, you CANNOT guess the base address of the RAM and also, this base is only good for the duration of the emulation, pressiong stop and play immediately after has a great chance to have the base address change. It can happen that it would be the same as the previous run, but it's unlikely.

This version's PR text says: "Allow (but don't force) ASLR" https://dolphin-emu.org/download/dev/3443454ba279811a6e10a840d8c21af3e24dd614/

Most importantly, this version completely changes the way the base address is determined. Before this version, you could actaully either be 100% sure of the base every single time or be fairly sure depending on the platoform. On Windows, the emulator tries to find a large conriguous space of free virtual memory of I think it's 4GB which is very large, but it's still the OS that decides here. Well for unknown reasons, it seemed very likely that the base address ended up being 0x7FFF0000, even today I have no idea why it tends to be this, most user could actually use Cheat Engine assuming this as the base, Some users however, couldn't the base could change between emulations, or be consistent, but different. As for non Windows platoform (such as Linux), the base is hardcoded to be 0x2580000000, they did this because of other circumstantial reasons, but they kept the end of the address at 0x80000000 as it makes it very easy to convert Dolphin address to console address 75% of the time (you just remove the 25 at the beginning).

This PR however, no matter the platofrm, it's random, I got multiple base address on my Linux system and none of them seemed to make much sense as far as pattern goes, the only thing it seems to guarantee is the address will end with 4 zeros, my guess is it has to do with alignement or base allocation size, but I can't really tell here. Maybe other stuff are randomnised as far as the RAM layout goes, but this is the only one I really care and am aware of. Keep in mind however that it's only the LOCATION of the emulated RAM that is random, the RAM itself isn't, for example, say you have a base, the location of MEM2 (the region of memory only used by the Wii as usable RAM) is still the base + 0x10000000, this will never change so once you have the base address, you can pretty much get to any addresses in RAM for the duration of this emulation only.

There is a way for each emulation start to be aware of the start address which might be usefull for debugging (keep in mind though, this is a revision that is further than stable 5.0 which had a ton of log changes by me). To see it, open Dolphin with the -d argument which enables debugging features. Make sure the log and log configuration panel are visible by checking in the view menu. Go to the log configuration panel, put the verbosity level to info and as for the log types, uncheck all except MI & memmap. Go to the log panel and boot a game, it will tell you that the RAM initialised sucessfully with an address, this address is your base address. You can test to stop and play the emulator and see that it indeed seems to change at random.

Now, when people was using Cheat Engine, multiple solutions were proposed such as using scans with the ID of the game (because it seems the RAM starts with that ID), but that method is wrong as many games do not have an ID (such as virtual console titles). There's also the pointer method which involves finding an internal pointer of the RAM inside Dolphin's process and add any addresses in relation to that pointer. This works, but has many caveats such as only working on the current version of Dolphin and nothing else, the annoyance of having to do hex math just to add an address permanently and finally, if you desire to change the version of Dolphin, you need to recalculate the entire table and some of these can go hundreds of entries.....not nice.

The solution I do in this project is not 100% sure to get the right address, but the chances of failling are VERY low (as if, so far, in the lattest version, no one had any problems with it). Basically, I checked the source code of Dolphin to figure out how does it map the memory such as its size and flags (like MEM_MAPPED under Windows or a filename under Linux). I use as much heuristics as I can about the mapping and I basically go through all the virtual mapping of the process and I attempt to find one with the same heuristics. This has been pretty reliable so far and it is very possible to adapt this in case there's changes in the way Dolphin maps its memory, but the heuristics I use tends to be very essential for an emulator such as Dolphin, the only change I had to do so far was to accept 2 different filenames for the mapping under Linux as one version changed it.

For more details, check the DolphinProcess folder, this is where I manage all the low level communication with Dolphin and also the "hook" process.

I kept this answer as exhaustive as possible as this is not something I told for the first time, but if you still found conflicting informations, it would mean that you haven't found a place where I was saying the whole story so I am keeping exhaustive here in case others have the same question.

[Henrik0x7F]

Thanks for the detailed answer! Since I just care about 1 game, scanning the process memory for the game id (and maybe some other bytes to avoid false positives) should be fine. However factoring in the region size could reduce the size of the scanned memory and improve speed. The thing I wasn't sure about was if the ram itself is randomized but since your editor displays the memory correctly I think that's not the case.

[Henrik0x7F]

Ok, seems like the person who said the ram is random was using cheat engine. He was probably looking at completely different memory.

[aldelaro5]

For CE, after the ASLR update, you HAVE to use the pointer method to make it work reliably, which sucks, but I mean, it is why this project exists :)