Hjalfnar
19.05.14, 15:23
Aus der TWC:
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?
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:
https://dl.dropboxusercontent.com/u/97127394/KingdomsPatcher/KingdomsPatcher.png
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:
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).
Was heißt das für Modder? Effektiv ist es ihm gelungen, einen Launcher zu entwerfen, der quasi die Exe NACH ihrer Ausführung im Arbeitsspeicher sozusagen "einfriert" und dort modifiziert. Dadurch ist es möglich, den Prozess der Kingdoms-Exe zu modifizieren, ohne Hand an die Exe-Datei selber zu legen, was ja durch AGB und EULA strengstens verboten ist. Da aber ohne Exe-Änderungen Modding recht eingeschränkt ist, würde das "Memory Modding" quasi einen Quantensprung für die Modding-Community darstellen, da so eine Menge Begrenzungen wegfallen.
Z.B. sind bei Kingdoms so 1-Mann-Einheiten möglich (man denke an Third Age: Total War...Sauron anyone?!), was sonst durch die Exe verhindert wird, ebenso wäre die Implementierung neuer Einheitentypen wie z.B.fliegende Einheiten möglich, oder Panzer (man denke an The Great War für E:TW). Regionsbeschränkungen würden wegfallen etc.pp. Könnte tatsächlich auch das Modding von den heutzutage ja häufig gegen Modding stark abgeschotteten Spielen wie halt Rome 2 möglich machen. Ist halt nur deutlich komlizierter als normales Modding.
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?
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:
https://dl.dropboxusercontent.com/u/97127394/KingdomsPatcher/KingdomsPatcher.png
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:
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).
Was heißt das für Modder? Effektiv ist es ihm gelungen, einen Launcher zu entwerfen, der quasi die Exe NACH ihrer Ausführung im Arbeitsspeicher sozusagen "einfriert" und dort modifiziert. Dadurch ist es möglich, den Prozess der Kingdoms-Exe zu modifizieren, ohne Hand an die Exe-Datei selber zu legen, was ja durch AGB und EULA strengstens verboten ist. Da aber ohne Exe-Änderungen Modding recht eingeschränkt ist, würde das "Memory Modding" quasi einen Quantensprung für die Modding-Community darstellen, da so eine Menge Begrenzungen wegfallen.
Z.B. sind bei Kingdoms so 1-Mann-Einheiten möglich (man denke an Third Age: Total War...Sauron anyone?!), was sonst durch die Exe verhindert wird, ebenso wäre die Implementierung neuer Einheitentypen wie z.B.fliegende Einheiten möglich, oder Panzer (man denke an The Great War für E:TW). Regionsbeschränkungen würden wegfallen etc.pp. Könnte tatsächlich auch das Modding von den heutzutage ja häufig gegen Modding stark abgeschotteten Spielen wie halt Rome 2 möglich machen. Ist halt nur deutlich komlizierter als normales Modding.