Reversing GTA:SA Code

From Multi Theft Auto: Wiki
Revision as of 13:04, 29 November 2013 by The GTA (talk | contribs)
Jump to navigation Jump to search

Reversing GTA:SA code is the process of turning the x86 assembler instructions back into readable C++ code. It is made to fully understand logic inside of the GTA:SA engine. Results of code reversal can be put down as assembler hooks and/or localized C++ implementations.

Assembler Hooking

This is the method MTA:BLUE developers use to provide features to the MTA runtime. When logic patterns have been analysed inside of the GTA:SA engine by careful study of the assembler instructions, manipulations to the assembler instructions can be made. This way the logical flow of engine code is tampered with. Changes are local to the game executable.

Pros and Cons

Pro Contra Neutral
  • Exploits of the engine stay hidden
  • Rockstar code is not shown to public
  • Research is not shared with other developers
  • Hackish agenda on an open source project
  • Only experts of their research can modify their hacks (elitist thinking)
  • Logic may not be compatible across multiple GTA:SA versions
  • Cooperation of multiple GTA:SA mods

(The arguments are interpretations by The_GTA.)

Usage Explanation

While assembly hooks are not the optimal way to output research about the GTA:SA engine, they are very quick means to solve imminent problems of low complexity. For example, while it takes long to research the linked list container for the streaming garbage collection entity management, it takes less time to simply increase the amount of available nodes to be allocated. Hence assembly hooking is essential to prematurely provide features to the MTA runtime, while they may be be reversed in the longrun. In that sense, it is not true that code that works should be left alone: assembly hooks are not proper coding and allow no optimizations to the logic they are targeting.

Localized C++ Implementations

This is the way MTA:Eir developers use to provide features to the MTA runtime. First, the logic inside of the engine is analyzed. The researcher attempts to give meaning to said logic, by giving names to functions and variables that make sense. Once he thinks he fully understands the researched section of code, he rewrites the x86 assembler instructions into C++. Every researched function has to be given a comment header with a function description. The more a function is split into subroutines or the more patterns found have been put into shared functions, the better is the result of the research. Since the whole engine logic ties together, code research has to be revisited from time to time to make sure it is up to date in the context of the whole engine.

Changes to the original GTA:SA logic have to be marked with a comment that describes what has changed and where exactly. Additions which benefit the MTA runtime are often marked as "MTA extension". Bugfixes to the engine have to be explained in a comment.

Since the rewritten version of code has to perfectly match the original GTA:SA logic, it is a very tiring and time-consuming process. But once the code has been completely reversed and localized, it is open for every developer to try his hands on it.

What is Localization?

Localization is the process of extracting GTA:SA logic from its engine so that MTA can execute it stand-alone. It is required so that changes to the structures of GTA:SA can be made without breaking things. When code has been first rewritten the researcher is free to use the original GTA:SA binary offsets to reference structures and classes that he has found. This changes with Localization.

A binary offset is complex. It can be tied to many locations inside of the binary. Worst case scenario is if there are obfuscated references to the binary offset that cannot be spotted at development time but cause crashes during testing. It is mandatory to track all of the locations a memory address is referenced from, most notably using hardware breakpoints.

All routines that are tied to binary offsets have to be rewritten. Then groundbreaking changes can be made to the logic. If the logic is using a static pointer array natively, an improvement would be to introduce a linked list without limits. Target of such improvement is the GTA:SA rendering system, that lists to-be-rendered entities on a static pointer array and saves its count. A static array implies that rendering is limited to a certain count; this contradicts with a patch that introduces theoretically infinite entities into rendering. In this way, localization exposes contradicting or deprecated functionality.

When a system is completely reversed, it opens doors for meta-programming. Globals/macros that have been exposed can be modified to do performance tests of GTA:SA logic. Code can be split up into subroutines or turned into templates.

(WIP...)