The "New" Frontier of M2TW Modding: Memory Editing
Hi all! Recently, I started analyzing the M2TW: Kingdoms' executable in order to have a better understanding of the way the engine works for what concerns the way it parses and uses data files (how unknown options and values affect the game and how volatile data is stored into the memory) and the causes of its more common bottlenecks, bugs and misbehaviors. A mastodontic task that, little by little, is producing excellent results, especially for the knowledge of the modding community.
Then, suddenly, I realized that if I wanted to go further into this (fixing the game engine or modifying its behaviors) I would have to find a way to do it without breaking the game's license... and I found it: memory editing. Let me explain you this: in fact, as we all should know, it's strictly forbidden by CA to alter the game executable, as stated in its eula:
The same rule applies for almost every software house that produce closed source applications but it's not always easy to understand what kind of limitations it imposes. In my point of view, for example, the declarations "reverse engineer" and "create derivative works of the Game Software" should immediately ban all what concerns modding because discovering the structure of binary files (meshes and textures, for example) absolutely fall into the reverse engineering category. The same goes for the statement "create data or executable programs that mimic data or functionality in the Game Software" because edited files can be considered data that mimic existing software files and the Launcher replacements that can be found in this forum can totally be considered executable programs that mimic functionality of the original application. Right?You agree to only use the Game Software, or any part of it, in a manner that is consistent with this License and you SHALL NOT:
{...}
(f) reverse engineer, derive source code, modify, decompile, disassemble, or create derivative works of the Game Software, in whole or in part (except as the applicable law expressly permits, in which case all and any modifications, adaptations, improvements, etc. shall belong to, vest in and be the exclusive property of Sega and/or its licensors on creation, in any event);
{...}
(i) create data or executable programs that mimic data or functionality in the Game Software.
While we could waste our time discussing for the next few months about the legitimacy of binary data modifications and launcher replacements without finding a concrete and unanimous solution (it could just be considered ok, we can be sure about the fact that, by all means, releasing a modified executable could lead to very disagreable consequences (signally, a legal action from CA).
And here is where memory editing comes into play: the first thing I learned when I started working with debuggers, decompilers and disassemblers is that while it's totally forbidden to edit executables, it's 100% legit for a user to edit its own memory without any consequences. Memory editing is a grey zone in which, nowadays, there are still no real rules and this is due to the fact that all what is being put inside the virtual memory of a computer switches its ownership from the productor of a packed entity (the executable compiled by CA) to a consumer of volatile data (yourself). It's your memory, you bought it, you can do whatever you want with it.
When executables are launched, they are loaded and mapped into the computer's memory and, there, their instructions can be edited as will without breaking any law. This is the correnct and only path we must follow to circumvent the eula's restrictions and bypass any limitation. How? Using a custom launcher/patcher that creates a fully deployed game process in a suspended state, modifies some small parts of it in order to change its behavior and finally resumes its execution. This one, to be exact:
At present, the application has been created for my personal use only and has never been distributed, but it received a go ahead from the forum's administration. Here is their verdict, that has been sent to me via PM:
By all means, patching the executable can lead to infinite opportunities to improve the engine (adding new features, fixing bugs, improving existing features, removing limitations and so on) of a game that left its development stage long, long time ago and it's no more being improved and maintained by its creators, but that still has a great and very active modding community and is still being sold (blink blink). Here is what I achieved so far:Originally Posted by Gigantus
- changed the EDU units limit from 500 to 1000 (just some memory allocation adjustments and pointer shiftings remain to be done);
- changed the soldiers limit from 4/100 to 1/150 (if I'll find the multiplier being used when you set the CFG option unit_size to a value different than normal we will finally be able to have real one-man units);
- made the executable aware of large memory addresses on 64 Bit systems with at least 6 Gb of RAM;
- optimized the game engine for single core execution.
All I need is collaboration. Analyzing an executable is a very difficult and time consuming task to accomplish that requires a high knowledge of software architecture and assembly code. Anyone willing to help me is more than welcome provided he knows how to use the necessary tools (IDA Pro, OllyDBG or another similar debugger and an hexadecimal editor).
Reply With Quote
Re: The "New" Frontier of M2TW Modding: Memory Editing
Sadly I have no experience in this field. Give Zarathos a huge reputation!
Well I don't know anything about these stuff, I only know of this Large adress aware tool that supposedly makes games use up to 4gb or RAM. In the screen you posted those are just things anyone can edit in the cfg, but if you say it's possible to increase hardcoded limitations like the 500 units or the number of factions maybe, I can't wait to see such a thing with my own eyes! I wish you good luck then.
