Posts Tagged ‘Hacking’

Hacking Grand Theft Auto IV: Part II

Tuesday, December 16th, 2008

One of the features the Games For Windows API provides is protected buffers. These buffers can be allocated by games that use the API, and data can be copied back and forth from them. GTA IV uses this for a bunch of the game memory, for example, your current cash.

The following functions (thanks, xlive.pdb!), are what provide this feature to games:

  • int XLivePBufferAllocate(int size, XLiveProtectedBuffer **pbuffer)
  • int XLivePBufferGetByte(XLiveProtectedBuffer *pbuffer, int offset, unsigned char *value)
  • int XLivePBufferGetDWORD(XLiveProtectedBuffer *pbuffer, int offset, unsigned int *value)
  • int XLivePBufferGetByteArray(XLiveProtectedBuffer *pbuffer, int offset, void *destination, int size)
  • int XLivePBufferSetByte(XLiveProtectedBuffer *pbuffer, int offset, unsigned char value)
  • int XLivePBufferSetDWORD(XLiveProtectedBuffer *pbuffer, int offset, unsigned int value)
  • int XLivePBufferSetByteArray(XLiveProtectedBuffer *pbuffer, int offset, void *source, int size)
  • int XLivePBufferFree(XLiveProtectedBuffer *pbuffer)

By creating a fake xlive.dll which wraps the real xlive.dll, we can serve ‘unprotected’ versions of these 8 functions. In doing this, we can now freely modify at runtime the data that the game wants to be protected, including your current cash.

XLive Wrapper for GTA IV 1.0.0.1

Drop this into your GTA IV game directory (where GTAIV.exe resides), start the game, viola, unprotected memory!

(The first time you run the game, the wrapper will prompt you if it is OK to copy the original xlive.dll/xlive.dll.CAT unmodified to another location with a new name)

If you encounter any issues with the wrapper aside from the UI issue, please let me know!

The only side effect that I’ve seen so far is that the in-game UI for Games For Windows no longer appears, although the game continues to function normally (including multiplayer).

Part III will talk about save validation and include version 1.1.0.0 of the wrapper with this disabled :) .

Hacking Grand Theft Auto IV

Tuesday, December 9th, 2008

A week ago Grand Theft Auto IV came out for the PC, since then I’ve been trying to poke about at things, the first thing I saw that I wanted to try was to edit the save files.

I found the save files nestled in C:\Users\Rick\AppData\Local\Rockstar Games\GTAIV\savegames. You’ll likely find several subdirectories there, following the format of user_<16 byte Live user ID>. Under one of these directories you find files following the scheme of SGTA4<index>.

Taking a look at these saves, the data is unencrypted and in a very obvious format. Unfortunately you cannot directly edit them, GTAIV makes use of some hashing features built into xlive.dll (Games for Windows – Live).

There is a 360 (coincidence?) byte footer to each GTAIV save file — this makes up two blocks. A 296 byte block, and a 64 byte block. I’m not sure about the 296 byte block, but the 64 bit block is likely a hash of the save data.

I set an obvious way to try and edit the save data: change the amount of money you have.

Looking at the structure of the save data, the amount of cash you have is in the second block of data in the save (PlayerInfo), there appear to be two values for money — one is probably total cash while the other is current cash. They are 0x1EA and 0x1F2 bytes from the start of the save file (due to the structure of the file, these offsets are unlikely to change).

Out of all the attempts I made in trying to edit a save file — the one I ended up with was pretty much a massive hack. xlive.dll has some protections enabled that make tampering with a running game a bad idea (crashing, not functioning properly, among other things). I dug deep enough to discover that I could essentially break a part of xlive.dll to make it possible to modify GTAIV code. When GTAIV calls xlive.dll to do something (in this instance, hash a save file), xlive.dll does a check on the calling process to make sure it hasn’t been modified. The offending function is called XLivepVerifyAddress (xlive.dll+0xA6354, according to xlive.pdb ;-) .

I broke this function (by making it always return 0), hooked the function that hashes save data (GTAIV.exe+0x18C180), a pointer to the save data being the first argument.

Starting the game with my changes (done at runtime, no modification to files of course, via loader + injected DLL), I load my game, something crashes (another thread, perhaps), the game continues to run fine. I save.

The end result?

A save file with its cash altered to $10,000,000, with a valid hash.

(shortly after purchasing a fancy hat with my new money in a relatively new game)

Fixing Titan Quest on Steam

Sunday, November 30th, 2008

I picked up a copy of Titan Quest + Titan Quest: Immortal Throne on the current Steam weekend deal, only to find that I couldn’t attempt to refresh the games list for internet games without getting a nice exception dialog.

Assertion failed!Program: ...ps\common\titan quest immortal throne\Tqit.exe
File: .\common\gsPlatformSocket.c
Line: 236Expression: theSocket != INVALID_SOCKET

I researched this to find that it seems to be a common issue on Vista SP1, someone had suspected that Titan Quest was creating a raw socket for some reason. That is in fact what it’s doing. Since I am not running the game in administrator mode, the socket creation fails.

Since I don’t really like the idea of running Steam and TQ:IT in administrator mode, I looked for a better fix.

It makes a call to socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) in Engine.dll. I modified Engine.dll to make it call socket(AF_INET, SOCK_DGRAM, IPPROTO_TCP) instead. I suspect this breaks the ping display in the game list now, but it appears to run just fine now without any exceptions.

It’s a two byte fix for Engine.dll, assuming the latest version of Engine.dll for TQ:IT on Steam now (md5 of cf00e85ff32629e4ad7859765722517b), you will want to change offset 0x164A0F to 0x11 (from 0x01), and offset 0x164A11 to 0x02 (from 0x03).

Left4Dead *.vpk Extraction Tools, now with UI

Friday, November 14th, 2008

A newer build of my VPK tool that now includes a UI. It also fixes handling of the ‘small data’ in the directory file that most *.vmt files were using instead of real files in one of the other package files. Please report any issues in comments, thanks. Edit: See this newer post for a newer build of tools.

The code for this is also now available on SVN.

Left4Dead *.vpk Extraction Tools Test

Thursday, November 13th, 2008

Here are some test binaries for extracting data from the *.vpk packages recently seen in the Left4Dead demo. Edit: See this newer post for a newer build of tools.

To use:

  1. Extract the *.dll and *.exe files to a directory, it doesn’t matter where.
  2. Click + dragdrop a _dir.vpk file onto Gibbed.Valve.ExtractPackage.exe.
  3. Files will be extracted to the directory the file you dragged is in, or the current directory if you invoke ExtractPackage in a console window.

I will probably get around to making a tool with a UI, but for now, this works. Source will also be provided pretty soon.

If any of you encounter any bugs please leave a comment here with information. This tool was tested with the most recent version of the Left4Dead demo, and may break with the full game files once it is out.

Fallout 3 Script Functions, Again

Friday, October 31st, 2008

The original list of functions was not 100% complete, this has been corrected.

Fallout 3 Script Functions

Thursday, October 30th, 2008

I ported some code I originally wrote for Oblivion that dumps the available functions and their arguments to work with Fallout 3. Here is the result.

Unstable FC2 tool binaries from SVN revision 4

Tuesday, October 28th, 2008

ArchiveViewer (and associated binaries). This fixes incompatability with x64 systems (an oversight on my part).

binaries-svn-rev4.zip