Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
Hello all. This is my first post on this great site.
I was listening to the needs of some TAS-makers in the IRC channel and suggested a tool to help. I was then suggested to post about it here in the hopes that maybe many more would find it useful.
Me
I will briefly explain my own background.
As with all people here, I have a strong passion for video games. Both my hobbies and job are filled with games.
I am the lead game programmer and lead game designer in a French game company officed in Thailand. I worked on Ghost Recon 2 Online, 187 Ride or Die, HOT PXL for Atari, a Leisure Suit Larry game for Vivendi Universal, and some others.
The Tool
One of my favorite hobbies is hacking video games, especially ROM games since most of the best games ever were on console machines. This is where my tool enters.
I made a tool to help me with hacking called MHS (previously Memory Hacking Software).
It includes a RAM searcher, real-time hex editor (both files and RAM), debugger, disassembler, and full built-in programming language to help with every type of odd job you can imagine.
Get it here -> MHS <-
The most obvious use of the tool is to perform searches to help you find data in the game to use to your advantage.
But the tool is more useful than just that. The built-in programming language is full enough that it can perform nearly any task, even tasks not related to hacking at all. For example, at my work I wrote an image converter to convert bitmaps into the formats we need for Nintendo DS. I also wrote a simple function that types file headers into the new C++/H files I write. I also wrote a function that scans a folder and deletes all files inside, just in case I need to remove some evidence (wink wink). All done with the language inside MHS.
Features
RAM Search
8-, 16-, 32-, and 64- bit integers, signed and unsigned. Floats and doubles too.
Search the RAM of your emulator to find values in both the ROM and RAM of your game. About searching.
Group Search (USD Search) find patterns of data, helpful for finding tile maps. Read about it here.
Script Search allows you to define the rules of the search in any way you please. No matter how the value is hiding or how it is encrypted, a script search can reveal its location. Read about it here.
Real-Time Hex Editor
Shows RAM in real-time, so you see the values change as they change in the game. Changed values are highlighted for easy tracking. This means, once you have found your player data in memory, you can play the game and watch the RAM to see what changes when you perform certain actions. If you fire your gun and values change, they are probably related to your weapon.
Also edits files of any size. Files measured in gigabytes load instantly with little RAM consumption.
View the data in bytes, characters, ints, floats, doubles, whatever.
Pointers, strings, and pointers to strings are decoded as you mouse over them. Pointers are highlighted in purple.
MHS comes with a built-in scripting language called L. Spiro Script. An IDE is also provided, and all API functions are fully documented. The script uses C syntax, so C programmers are ready to go without taking time to learn a new language. The code is compiled into bytecode like in Java and executed as fast. The language provides full C functionality and has an extensive API.
Scripts can be used to automate nearly any process you can imagine. API is included to send keystrokes to games to tap buttons or print the screen. Other automated tasks might include formatting and dumping parts of the game RAM for more data processing. Scripts can especially be used to automate data extraction and in-game data manipulation.
API is included to create dialogs for the scripts, so you can make dialogs for the automated tasks you create.
Scripts work mainly on hotkeys and can be executed at any time you please to perform any operation you please.
The language is made to work easily with the target process (emulators in this case). Declaring variables as “extern” means they have been declared inside the target process itself. You can read/write from them the same way as with any other variables, except the data in the target process will be modified instead. This allows extremely easy data manipulation within the game.
The API includes WinSocks functions allowing you to make conections over the web. Write a scheduler to check for new TAS videos and a downloader to get them! Examples are included showing how to create a server and how to dowloand a file.
There are many examples in the help file, all of which work with copy/paste ease. A bot that plays Minesweeper is included in the examples and shows one way clicks can be helpfully automated.
Debugger/Disassembler
This is not needed for emulation hacking but it is there. It works but it is not documented because I am still working on it.
Documentation
Documentation is included in the download package and covers all topics extensively. Topics regarding the Debugger/Disassembler have been omitted as stated above.
MHS has features allowing lots of types of game hacking, from normal data manipulation to resource extraction.
Here are some examples of actual results obtained with the help of MHS.
GoldenEye 007/Perfect Dark Maps
Using MHS, I extracted the maps from GoldenEye 007 and Perfect Dark ROMs while the games were playing in Project64. As I entered each room, the maps would be loaded to certain buffers, and my MHS script was able to scan the geometry commands, parse them, and create polygon data from them, then store that data to a file.
Here you can see the results, and if you are on Windows you can also download a second tool which will load the files and display them in 3-D.
These files were sent to the GoldenEye Source and Perfect Dark Source teams.
Final Fantasy VII Online
Using MHS, file formats are easy to decode, as we can step through the code in the game that is loading/decoding the data in files.
This project is intended to make Final Fantasy VII playable online, with a completely rebuilt game engine that uses the original files from the PC version of the game.
I hope that my tool can be of great use to the cause of this site and I would love to know it well it works.
The tool is always in production, so I am always open to requests and suggestions.
Thank you,
L. Spiro
Your program is amazing, far superior than any memory searcher out there. Bye bye tsearch.
One thing I noticed is that the message in "Lock" group next to checkbox in "Modify Address" window are chopped. I couldn't read what it said.
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
Thank you to everyone.
I am just glad it can be of use for some.
ventuz wrote:
One thing I noticed is that the message in "Lock" group next to checkbox in "Modify Address" window are chopped. I couldn't read what it said.
Windows is supposed to correctly resize dialogs based on text metrics of each computer, so it seem it does not quite work 100% at that.
This page is also in the included help file and you can use it to see what the dialogs say: Modifying ValuesRandil wrote:
So, can this program be used to watch memory addresses for a NES ROM (or ROMs in general)? Or can you only watch the RAM for executable files?
Well it watches the RAM of executable modules, including loaded modules, heap, and stacks (the Disassembler will show thread information when the debugger is attached).
Any ROM you load into an emulator will be inside that RAM, either statically inside the executable image space or dynamically on the heap.
Either way, RAM is RAM to this program and it watches it all the same.
In the Hex Editor, static addresses (data loaded as part of an EXE or DLL) are shown in blue, unreadable in red, and the rest in white.
Small emulators, such as those for NES and SNES, often have a section inside the ROM image allocated for loading the ROM file, while larger ones such as Project64 load ROMs to the heap.
Again, RAM is RAM, so you can view the RAM of the emulator, of the ROM it loaded, the emulator’s heap space, and the ROM’s RAM (which will be inside the emulator’s heap space).
If the emulator stores the ROM image dynamically, there will be a static pointer inside the emulator image that points where it loaded the ROM. You can use that pointer (or use code injection) to know where the ROM image is inside the RAM of the emulator.
Also, if the emulator declares the game’s RAM on the heap, the same rule will apply and you can find a pointer to the game’s RAM as well.
Addressing modes on consoles are different, so when you follow a pointer that is actually inside the ROM image you’ll have to do a bit of translating.
For example, Nintendo 64 uses the top 8 bits to indicate a bank of RAM, so following the pointer would mean masking off the top bits, following the emulator’s “Game RAM” pointer, and from there going to 0x00XXXXXX offset, where XXXXXX is the remaining pointer value after the top 8 bits were masked off.
Luckily, it is very simple to write a function in the scripts that does this translation for you.
Tub wrote:
Too bad it cannot easily be ported to linux :(
I am not sure what functions Linux has for opening other processes and reading/writing RAM from/to them.
Even with that functionality on Linux, a port would be near impossible, since this tool uses a kernel-mode driver to reduce detectability when hacking protected games. But that might not be a huge issue since the software is designed to run just as well if the kernel-mode driver fails to load.
L. Spiro
Wow. Just what I needed. When was it I was saying that I needed a decent RAM searcher for RCR if my run would get done? Yesterday? No, earlier today. This is great. Simon is about to meet HIS worst nightmare.
Question: Is ROM coding for NES, when translated into something resembling English written in a format like:
If "Goomba"(X,Y) == "Mario"(X,Y) AND "Mario" yspeed =>0
Then GOTO "Mariodead"
Or is it some weird thing I have no chance of figuring out?
For a given value of 'translate'.
Your code snippet there would be something like:
CMP [GoombaX], [MarioX]
RETNZ ; get out of the collision detecting function if not equal
CMP [GoombaY], [MarioY]
RETNZ ; ditto
CMP [MarioYSpeed], 0
RETL ; I forget what 'less than' would be
JMP [MarioDead]
(Not like that's NES Assembly or anything, it might not even have CMP x,y, would have to copy everything into A first etc. etc.)
If read back and treated with care, yes, the Assembly can be translated to something like BASIC. It is not always a trivial task.
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
6502 assembly is used.
As with x86 assembly, the English-translated result will be garbage to a person who has not specifically learned it.
For example:
LDA #SPCExec
STA $2142
LDA #$1CC
STA $2140
SEP #$20
Start: CMP $2140
BNE Start
Figuring it out is possible, especially since it is all documented, but understanding it will imply a fairly decent understanding of how computers work at a low level, and how if/else statements (among many others) are turned into machine languages.
My disassembler/debugger are for x86 platforms and will not translate 6502 assembly.
You can get the tools for that at http://www.zophar.net.
L. Spiro
[Edit]
Also refer to LagDotCom’s reply which I did not see until I wrote this.
[/Edit]
Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
I've tried figuring this out on my own, but can't seem to... how do I make 2d tile maps from ROMs? (maybe a little tutorial?, unless the info I need is already in a help section of the .exe?)
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
You mean you want to find it, then export it to disk for later use, as either binary or text.
Firstly, you need to find it (a natural first step).
Tile maps may be stored left-to-right or top-to-bottom (or reverse of either but that is rare). So using a USD search (help file) you can enter the pattern of the tiles you see, from left to right, or from top to bottom, until you find the big chunk of data used by the game as a tile map.
You should be able to read all about USD searches in the help file (Group Search page, or search for “USD”).
Put in the USD pattern that matches the tile pattern you see in the game. Try various ways and data sizes until you find the tile map in memory.
Once found, you need to export it to disk.
There are many ways to do this, but with various results depending on your experience.
If you can program, you can write a script to scan that memory and export the tile map in any way you please with any formatting.
As you said you can not, you have fewer options, but still good.
Open that RAM in the Hex Editor.
You should know on your own the size of the tile map.
And since you found it in RAM you know how large each element in the map is.
Let’s say the elements are 1 byte (common) and the size is 32×64.
32×64×1 = 2,048 total bytes.
Normally when you find the tile map you won’t find the very start of the map. You’ll find some part inside the whole map, and you will need to figure out on your own where the map actually begins from there. You can calculate it but I think you should understand enough about tile maps that I don’t need to do over that (tedious process but easy).
Go to the start of the tile map and select 2,048 bytes from there. Either run your cursor over them, or right-click and select Select Range.
Once you have all the bytes in the tile map selected, you can copy them as either binary values or as text (hex numbers).
Since you showed disdain for binary values, let’s go the simple route and copy as text.
With the tile map selected, go to Edit/Copy As/Copy As Hex Text.
Now the tile map will be in your clipboard.
Open notepad and paste.
Now you have a series of hex values in text format that represent the tile map in your game.
If you want to do neat things with this data, however, you will want to mess around for a while and learn a bit of coding and/or data manipulation.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
I have written a tutorial for finding and using tile-map data.
The Tutorial
Current it it only shows how to find the data, as I did not have enough time in one sitting to show how to extract/use it.
I will add that soon.
In the meantime, it should be helpful just to find the data.
L. Spiro
I maybe stupid, but I can't distinguish between tiles in SMW. I don't know what makes one different from the other..
Are you referring to USD search? Ignore the background, it's not part of tiles. When he picked first tile, first tile is empty air (U.nknown).. then the next tile is a half a bush (D.ifferent), then next tile is full bush (D.ifferent), next tile is the same full bush (S.ame).. etc.. you see?
Also, what happen to the TIME in 5th picture?.. -_-
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
MHS 4.0.0.3 is available and I included a few things to help the people of this community (aside from bug fixes).
A big problem people have been having is that when you hack away at the ROM your searches are including results from the emulator itself, not related to the game being run in it.
The solution is to set the search range to include only the area of RAM used by the ROM for the game running, but this is not easy for all to do, and I don’t feel one needs to be an expert at Windows memory management to be hacking these games.
So the good news is I added a few API functions to the script to allow people to get around this automatically. For those who do not program this does not sound like a very good solution yet, but just wait a minute.
As for those who do program, this offers a way to keep this functionality even as new emulators are released (or any other software for that matter). This is why I added this feature implementable via scripts rather than automatically inside my software.
Now, for the people who do not program, don’t worry because I had you in mind all along.
I already wrote the scripts for several emulators and all you have to do is install them, which I will explain in every detail.
#1: Download MHS 4.0.0.3. If you had an existing copy, you can save this over it. If you don’t, just put it in any folder on your hard drive (some people store it on their thumb drives).
#2: Download this file and save it on your hard drive (usually in the same folder as MHS.exe or so).
#3: Run MHS.exe and press Ctrl-T, then R. This is the shortcut to load the Script Editor.
#4: With the Script Editor open, press Ctrl-O to load a file. Browse to MHS_SetRanges.lss which you downloaded above and stored somewhere on your drive. Open it.
#5: A new tab has appeared with MHS_SetRanges.lss in it. Press Ctrl-D to add this file to MHS’s script list. When it is in this list it will be compiled when MHS is run.
#6: Restart MHS. You are ready to go.
The script file (MHS_SetRanges.lss) works on Project64 1.6, Mupen64 0.5.1, mupen64-rerecording.exe (found on this forum), ZSNES 1.36, and ZSNES 1.51.
I already expect that these will not be enough for the things people do on this site but I will leave it to everyone to request which emulators to add to the list.
So if your emulator is not yet supported just request it here and I will get it soon.
For the rest, now your searches will automatically be set to the relevant range when you load the emulator of your choice.
L. Spiro
Joined: 4/18/2007
Posts: 88
Location: Tokyo, Japan
The script file now supports FCE Ultra 0.98.16 and antids-mupen.exe.
Read above instructions for installation.
Or just copy over your existing on if you have it already (restart MHS afterwards).
L. Spiro
Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
I think that gba and snes would also greatly benefit from it... My only beef with gocha's tool, as useful as it is:
-it has a processing priority problem, it greatly reduces the FPS of VBA and snes9X when running. I have no problems ever with MHS, the emu it's watching neverlags
-It can only have a certain number of addresses before they can't appear on the window.
