Game Hacking

Notice: This is only a draft.

1) Introduction:
Games has brought us fantasy
Not only children are easily addicted to games, we can frequently see adult indulged in games at work or at home forgetting about their jobs.
However, as a computer game player, be it beginner or hardcore, you must have been through many circumstances in which you cannot advance further in the game because of some obstacle, or you feel bored because there is nothing else to do after you have cleared the game. What you wish is something that can help you pass the obstacle (although doing that will eliminate your satisfaction of completing something difficult) or something that give you a new perspective of the game you have been playing for hundred of hours. Whether it's the first or the second case, we are involving in game hacking.

In this blog post, I'll talk about 2 aspects of game hacking, and at the same time evaluate their advantages and disadvantages.

2) "Soft" hacking:
a) Concept:
"Soft" hacking involves in changing values in the memory which the game uses to process to make the game exhibits certain desired effect(s). Since only the memory on which certain components of the game are loaded is modified, "soft" hacking will not destroy the game data.
Example of "soft" hacking software for NDS and (Wii) is EmuCheat to create ActionReplay, CodeBreaker (sharable), for PC Game is ArtMoney.
b) Extent
"Soft" hacking is only possible under certain conditions
(- The targeted memory address which decides the effect)
- The data deciding the desired effect is loaded along with the core files
OR
- The data deciding the desired effect varies from instance to instance of the game. i.e. different for every save game
AND
- The data deciding the desired effect is allocated to some fixed addresses or "lazy" addresses (the address will not change during a session of the game). It will be impossible to track down an effect if its location changes too quickly.

An example of the 1st condition (rarer) is debug mode code is some games.
Example for the 2nd condition is money, hit point (HP), lives, item, etc.
Usually, the outcome of "soft" hacking can be stored in save game, if the game supports one. Save game is in fact an incomplete copy of the memory status but sufficient for the player to resume his/her progress in the game.

c) How-to
To "soft" hack, a program for viewing and searching and possibly enforcing the value in the memory is needed. Also, some basic knowledge of data representation, intuition and luck is also required.

Firstly, think of how the data can possibly be represented. Similarly to how data is stored on hard disk, the unit of storage on memory is byte.

The targeted data in most cases is numerical, and for the sake of simplicity, the number will fully occupy several bytes instead of being trimmed half-way to conserve memory space. First case of numerical data is direct representation. Money, HP data are definitely stored in this way. The second case is "pointer" type. Games with complex mechanics will usually have an array of data, and the data refers to the position of the object in the array. If we can extract the list from the game with the correct ordering, step 2 can be carried out easier.

If the targeted data is of boolean type, the data might be compressed instead of wasting a whole byte for boolean type data if the data belongs to the same class. For example, a check list (in PMD Sky - IQ effect).

Some feel-like-boolean-type data are actually numerical data, and for certain value, it will trigger certain in-game event. Data in this kind of representation is very hard to track down because it's usually mistaken for boolean type value and the value is not shown directly in the game. A tip to detect this kind of data representation is the overriding effect (some certain things can't happen at the same time). e.g in Pokemon games, you can't be Burnt and Poisoned at the same time.

The second step involves in tracking down the address of the data and at the same time observe the behaviour of the memory when there is outside interference. (The memory slot allocated to data is usually static,) In most cases, the memory slot allocated to store particular information is static or "lazy", (so we can modify the same address every time we play without having to track the value down again. However,) so it ) We will assume the targeted data is of static or "lazy" type first (because that's how memory slot is used in most cases). With the help of the

Usually, values of the same instance (e.g. HP, stat of the character/the items in bag) are usually situate near to each other. And another tip, although usually useless because there isn't many cases, is that games with almost identical gameplay, etc. with very slight difference (Pokemon D/P) will have the addresses modifying the same data somewhere nearby. In those cases, we can use the view memory function to have a broader view of what other things that it may hold and save our time tracking down the same value again.

d) Pro and con
+ "Soft" hacking requires less time and knowledge than "hard" hacking, which we will cover later.
+ "Soft" hacking won't destroy the game file.
- The highest extent it can destroy is the save game file. (Backup is needed)
- "Soft" hacking can make the game freeze or crashes (backup is needed)
- "Soft" hacking cannot change values that are not in the memory and directly accessed from the game file.
- We have to track down the address of the data every time we start a new session of the game if the memory slot to store the targeted information is of "lazy" type.

3) "Hard" hacking
a) Concept:
"Hard" hacking involves in changing values directly in the game files. People do "hard" hacking to change values that are not loaded into the memory but read directly from the component file instead and to create a completely new game with the basic gameplay from the original game, which will be impossible and cumbersome to implement with soft hacking.

b) Extent
Depending on the level of the "hard" hack (shallow/deep), the end product can be a game that is totally different comparing to the original one. The level of the hack is dependent on the knowledge of the hacker. To do "deep" hack, one must have knowledge about assembly language to actually track down and observe how the game handles the values to create a perticular effect in reality, then manipulate the value to make the game behaves like he/she wants. "Shallow" hack only involves in discovering the position of the information and changing the values without touching too much into the core of the game (which contains intruction to coordinate other component files (how to stream music and control the graphic) or the basic game mechanics (e.g Pokemon Dungeon - rescue password system)).

c) How-to

In this blog post, I'll only discuss how to do "shallow" hacking of a game. To do "shallow" hacking, one must have some basic knowledge about data representation and file structure, and a HEX Editor to peek into the bare actual file that is store on the HDD and edit it. "Shallow" hacking is usually only possible to modify files which is not related to core information about how the game runs. The best target to do "shallow" hacking on is games with size big enough to have separate component files or is a single compressed file containing numerous smaller component files. Simple game with only one executable file will be harder to deep hack because you have to deal with both the instructions and the actual data when exploring the file.

The first step (which may not be needed at all in some cases) involves in extracting the smaller component files from any big file. The easiest example to practice is Zoo Tycoon 1 and 2. The componenent files of the game are actually a compressed file in .zip format. Those files contains smaller component files which are human-readable for text file and other files are usually of recognizable type (jpg, xml). Usuually for other games, the component files are compressed and sometimes encrypted (...[Refer to File Structure]... PK) in an obscure format which can only be interpreted by the instruction in the core component of the game. In these cases, we will need other people's help - or a program written by people who understand the decompressing process to extract the smaller component files inside the compressed file. e.g. for NDS games, we will need ndstool or LazyNDS to decompress the content inside the game.

The second step involves in searching for the component files that is likely to hold information about the target and zero in on the section with information about the target.
If the game has a large number of objects that share the same "classification" and those objects are visible when we play the game (e.g. items) then we should first find the file containing the game script and extract all the name and add numbering to it. This will help us greatly in identifying certain "pointer" value which we mentioned earlier in the "soft" hacking section. To find out which component file holds information about the target, we can identify it via file name. Game developer although doesn't want other people to hack into their game, still have to keep the file name at a discernible level.
We will then open the file and look for any pattern. File containing same size information for each entry will usually has no offset list.
[use monster.md as an example]
For files with different entry size, an offset list is usually provided at the beginning of the file.
[use mappa_s.bin as an example]
The first case will make our hack very easy because since the entry size is fixed, we have a big list of info to compare each byte to tell what kind of information the byte holds and how large the field is. We can also utilize the list with numbering we created earlier to help with the identification of the function. The second case will usually be harder since we don't know exactly how the information is represented. Either case, the best method is to tamper with the information inside the file, re-compress if necessary and play the game to see the difference (trail-and-error method).

d) Pro and con
+ "Hard" hacking can virtually change anything in the game, from value (HP, items, etc.) to behaviour (warp point destination).
- Time consuming - figure out (and in some case reverse-engineer - sound, image) the file structure from scratch while some target value can be easily changed with "soft" hacking.
- Can aslo crash or freeze the game.