Reversing GTA:SA Code - Revision history

Qaisjp: add category

2016-07-22T03:48:37Z

add category

← Older revision		Revision as of 03:48, 22 July 2016
Line 84:		Line 84:
	* bring up questions once in a while, even if they seem trivial		* bring up questions once in a while, even if they seem trivial
	* do not be afraid to be wrong, because the developer community as a whole is right		* do not be afraid to be wrong, because the developer community as a whole is right

			[[Category: Development]]

The GTA: /* Usage Explanation */

2013-12-03T23:33:42Z

Usage Explanation

← Older revision		Revision as of 23:33, 3 December 2013
Line 26:		Line 26:

	===Usage Explanation===		===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.		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 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==		==Localized C++ Implementations==

The GTA at 13:11, 1 December 2013

2013-12-01T13:11:21Z

@@ Line 42: / Line 42: @@
 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.
+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. New functionality can be added or existing functionality optimized by '''common development theories''' (multi-threading, fibers, complexity questions, fixing bottlenecks, ...).
-'''(WIP...)'''
+===Localized implementations of MTA:Eir===

The GTA at 13:04, 29 November 2013

2013-11-29T13:04:24Z

← Older revision		Revision as of 13:04, 29 November 2013
Line 17:		Line 17:
	* Research is not shared with other developers		* Research is not shared with other developers
	* Hackish agenda on an open source project		* Hackish agenda on an open source project
	* Progress on GTA:SA research is slowed down
	* Only experts of their research can modify their hacks (elitist thinking)		* Only experts of their research can modify their hacks (elitist thinking)
	* Logic may not be compatible across multiple GTA:SA versions		* Logic may not be compatible across multiple GTA:SA versions
Line 25:		Line 24:
	\|}		\|}
	''(The arguments are interpretations by The_GTA.)		''(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==		==Localized C++ Implementations==
Line 36:		Line 38:
	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.		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.		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...)'''		'''(WIP...)'''

The GTA: Created page with "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. Resu..."

2013-11-28T10:08:11Z

Created page with "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. Resu..."

New page

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===
{|class="wikitable"
|-
!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
* Progress on GTA:SA research is slowed down
* 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.)

==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.

'''(WIP...)'''