Reverse engineering game Hogs of War, part 1

Motivation

In connection with the holiday spoiled by local authorities, one has to occupy one’s time with something interesting. For example, to treat an old toy, the shoals of which do not allow normal play on modern operating systems, or swap a few bytes to get different extra-opportunities just for fun. The experiment will be a game from the distant 2000 called Hogs of War. If anyone does not know, then this is a turn-based strategy, where you are given a command of pigs, with the help of which you have to conquer the world. During the game, depending on the results, each pig can be modified, for example, by raising it in rank. In 2009, Atari announced the continuation of the game in the form of development of HOW2, but according to the latest data, the project was curtailed due to lack of funding. Nothing pleasant.

The purpose of this part is to fix a bug that blocks the entire desktop, if appcrash has occurred for any reason, and preparing the application to work in the on-screen mode to simplify debugging.

I want to warn everyone: you do all of the following at your own peril and risk. The author is not responsible for any kind of loss incurred as a result of reproducing the described actions. All described actions were performed by the author's cat.

Instruments

IDA, MSDN, ida_patcher, DxWnd were used for debugging. More and more details below.
')

Training

So, there is no experience of such debugging, therefore at first it is necessary to do everything on an intuitive level. To begin, open the binary file in the debugger, and this is our warhogs.exe. Possible cause of the bug: the application simply cannot start correctly in another way, or it cannot function correctly. In the debugger, we run over the imported functions in some way related to the windows of Windows, meeting there, of course, CreateWindowEx, as well as EnableWindow. If the first call is transparent, although it occurs several times, then the second one is perhaps alarming. Go to the call point of the EnableWindow function (there are 2 of them altogether) and see the following code:



We are interested in the following commands:

.text: 0044D0A0 and edx, 0FFh
.text: 0044D0A6 push edx; bEnable
.text: 0044D0A7 push ecx; hWnd
.text: 0044D0A8 call ds: EnableWindow

Which suggest that for some windows this function is called as EnableWindow (TRUE, ...) ;, and for some EnableWindow (FALSE, ...) ;. We jump up the dependencies (it is better to call the functions in the logic of which you are completely sure) and find out that the EnumFunc function is used as a callback function when calling EnumWindows, followed by a call to the SystemParametersInfo function with the code 0x61. A short googling allows you to find out that in this way the authors tried to turn off the Alt-Tab combination. This is not interesting to us, so we treat the bytes by offset .text + 0x0044D0A0, fix the instruction and edx, 0FFh to or edx, 0FFh , which will allow the EnableWindow function to always be called with the first parameter not equal to zero. The second reference to the EnableWindow function occurs when the application is closed, which indicates that the authors restore the truce after they have done a business. Here we rule nothing.

Of course, I want to immediately apply the patch and look at the result, but it was not there! First you need to generate a diff file that looks like this:

This difference file has been created by IDA Pro
warhogs.exe
0004C4A1: E2 CA

Then you need a third-party utility to apply the patch to the executable file. This is done using the compiled source code ida_patcher.c. The parameters for the resulting console application are: -i <binary_file_to_patch>, -p <.diff file>. Attention, no warnings will follow, so it is better to follow the backup in advance.

We start the application, try Alt-Tab, switches, but warhogs.exe immediately goes to appcrash. In principle, it is not surprising why they pile up so many crutches in the code. But there is a nice bonus, now after the appcrash the desktop is not locked, you can safely continue to work!

Now you need to make the application run in screen mode. After a brief examination of the information, 2 ways were found to perform the following actions: 1 - changing the application code (changing the code for working with Direct3D 7), and 2 - using a third-party application called DxWnd, which will allow forcibly run warhogs.exe in the on-screen mode.

Choose the second path, because it is more simple. DxWnd intercepts calls to Direct3D.
We try - it turns out! Switching between windows is painless, warhogs works stably in screen mode, IDA quietly debugs warhogs.exe step by step. Everything is ready for deepening into the insides of the engine, which I will do in the next part. All good officials!