Obtaining The Memory (RAM VRAM etc.) state off an emulator in real time ?

Started by zhade, July 24, 2016, 08:46:20 AM

Previous topic - Next topic

zhade

Hi,
I've been working on some snes debugging tools lately that need to obtain the RAM from an emulator,
the way I obtain the current RAM values (in geiger's snes9x debugger) is by using an AutoHotKey script that, on the press of "CAPSLOCK + Q" quickly clicks on the "show Hex" button , sets the range from 7E0000 to 7FFFFF and press Dump which creates a dump of the whole ram that I then can access from programs that I write..
but thats very slow.. there must be a way to directly read the RAM off of the emulator's memory so that a whole RAM dump is not needed.. right ? I've seen some programs (for example the megamanX editor) which seems to have no problem doing this so heres some questions I have about it all:

- Should it be possible to obtain this kind of data from any emulator, using the same general "technique" ?
- Do some emulators have some built-in mechanisms to "share" their RAM/VRAM etc. values with outside programs, and if so does geiger's snes9x happen to have such a feature  :happy: ?
- Are there other threads about this subject or documents related to "accessing other program's memory" that I could learn from ? I feel as tho there is a common name for this that I am not aware of


Heres why Im asking:
I've made a tool that uses what I call "script sheets" that works with geiger's snes9x debugger.
Its like a notepad with two states, edit and view, that makes it easy (at least if you can cope with the awkward script syntax..) to see everything you need when debuging..
Basically when switching to "view" mode, every text between "[" "]" is interpreted/executed and the result is shown.

For a basic example, in secret of mana, each CPU controlled character have a "AI script current instruction" value,
the value corresponds to the address where the next AI instruction is located starting from D04F15 (meaning a value of 0000 = D04F15 and a value of 0010 = D04F25, 1000 = D05F15).
This can get bothersome because you don't get the full address right away and need to add D04F15 each time,
Lets say you are messing with AI script and often need to know each character's current AI instruction location.. you could use a"script sheet" like this:

Edit / View


the above is just a very basic example tho..between "[" "]" brackets it is possible to call "functions" that can make conditional operations and return a value as well as define "decoders" that deals with "coded data" (stuff that like ASM has instructions with variable byte count depending on the opcode) all of which are defined in the '3rd mode' (that 'A' book button) which looks like:

yea..  I don't assume you can make out what any of this does since it has this... hum.. Unique ! *cough* cough* awkward and unpractical *cough* *cough* syntax and all.. but it gets the job done and I came to like it somehow :P

And heres a more complex sheet I made (for secret of mana) to see randi's sprite/animation information:



FAST6191

I have not looked at the SNES stuff but the Lua supporting emulators (poke around tool assisted speedrun sites) do much like what you want.
http://www.fceux.com/web/help/fceux.html?LuaFunctionsList.html is for the NES emulator fceux but it is the standard that things tend to work towards if they are doing it.
A nice example of a more complex script
http://www.romhacking.net/forum/index.php?topic=18717.0

Equally you can hook into other programs in a variety of ways. Some security setups will not like it but it should just be a matter of forcing it through. I am not sure if any emulators will be compiled to use ASLR or equivalents (ASLR = address space layout randomisation, a way for programs to avoid some of the problems with buffer overflow exploits). Anyway many hex editors should be able to attach to a process (several free ones do, can't remember which off the top of my head though) and plenty of debuggers will offer similar functionality.

Also plenty of cheat programs are external to the emulators. Emuhaste is my chosen tool here ( http://i486.mods.jp/ichild/?page_id=38 ), though some prefer artmoney and there are many more. You may need to a find a specific version of the emulator to work with it or reprogram the emuhaste program to find the new memory storage location within the emulator memory (just a text ini file really).
Their scripting levels are not so great

The hex editor/debugger and cheat program may well have some limited scripting functionality but it will probably not be more than cheats themselves (if value =, if value =/=, if value <, if value >....) whereas lua is a full programming language in and of itself.

STARWIN

I might try something like https://msdn.microsoft.com/en-us/library/windows/desktop/ms680553(v=vs.85).aspx for this problem. First check if you can get it to work, then view process memory with some tool or dump as much as you can and observe where the RAM is. If it is always mapped to the same location, good, otherwise I assume you'd have to search for it once.

But even if you can read RAM easily, does it solve this problem? By realtime do you mean you are going to keep checking the RAM all the time? How often?

zhade

Quote from: STARWIN on July 24, 2016, 11:54:34 AM
But even if you can read RAM easily, does it solve this problem? By realtime do you mean you are going to keep checking the RAM all the time? How often?

I would only check the needed RAM addresses (Don't know if that was clear), and I dont need it to update say 60 times per second, something like 10x per second would be perfect, I think with the way I do it right now I can't get more than 1update every 4 seconds or so..oh and actually I forgot to mention but one major problem with the method im currently using is that it also pauses the game each time the RAM is dumped.

still haven't tried ReadProcessMemory() but thx, it looks promising

EDIT:

Try as I might I can't seem to be able to read any byte of data using ReadProcessMemory().. I have been able to find the (snes) RAM using a program called 'Cheat Engine' which means it should be possible.. oh and the address does change each time the emulator is restarted, altho finding it is easy enough anyway.. I am able to 'hook' on snes9x, but then every call to ReadProcessMemory() returns false, with bytesRead = 0 and calling getLastError() returns error code 299 which is "Only part of a ReadProcessMemory or WriteProcessMemory request was completed"... I don't know why it talks about anything having been completed since the bytesReadCount returned is 0 lol but I guess I should be glad something went ok at some point before complete failure  :laugh: I get the same result when trying to read notepad's RAM so I probably messed something up.. with some perseverance I should be able to pull this off but if you happen to know some common issues I am running out of ideas :P

henke37

If you want to access data from another process then you need information of where said data is located in memory. And as luck has is, the compiler combined with the linker knows exactly where things are, it's their jobs. So ask them! Use an emulator build with an DWARF or PDB file.

zhade

old thread but I thought someone willing to do as I did might find this useful:
most applications (if not all of them) require the program reading memory from them to be executed with admin privileges..
I didnt see this anywhere, tried stuff for days then asked a friend who's into non-rom hacking and he told me to try this... I think I would never have thought of running my app as an admin lol, I guess there might be a way to only gain the required privileges from code somehow but didnt bother looking.

My debugging tool works great, I found the RAM, ROM, rom file path and many other things using Cheat engine, it was at a different address every time I ran the app, but then I found the pointer table with addreses to RAM,ROM and it is always at the same address (geiger's snes9X debugger). My script sheets now can update like 100x per second.. I didnt even bother only getting the values as needed, just took RAM as a whole block, same for VRAM and its lightning-fast.. So now it updates about 500-600 times faster :laugh:

henke37

On Windows you don't need administrative rights to debug another process. The user owning the process can always debug the process. The debugging user right is for forcing access checks to pass, no matter what (except for DRM).

zhade

IIRC it worked without it for some apps like notepad , but it didnt for geiger's snes9x debugger, every read failed. Maybe a regular version of snes9x would have worked.. but anyway.. thought it could be helpful...

Cheat Engine got me interested into hacking the emulator itself lol, so I learned some basic x86 asm and managed to change the maximum save state count from 10 to 100, then made a save state manager window that lists all saves with a description :)

I also made my breakpoint manager write directly to memory instead of using some autoHotKey trickery which means my debugging tools are now completely independant of external scripts.

I thought it would be nice to mix the breakpoint manager with my script engine, so that breakpoints only get triggered if some conditions are met. But im not so sure about how I should do it.. Is there a way to get noticed when some offset is read/written ? Otherwise I guess I could, when a breakpoint is triggered, check the condition and if it isnt met, quickly make the game continue.. but Im guessing this could end up screwing with the game controls like if you press a button during the short time the game doesnt have focus it could end up not being registered by the emulator.. I guess I could just make some x86 asm code that checks some conditions like the value of A, X, Y PC DP etc.. but I'd very much like to use my script engine instead


henke37

What you are asking for is called a conditional breakpoint. They are implemented by the debugger just automatically continuing for you if the condition doesn't match.

As for getting a "notice" when an address is read or written, there is a breakpoint type for that. Go read up on the x86 debugging registers.