Universal Video Game Hacking Framework

[misfire]

[...]
1. We must finally develop a working system of donation, incentive-based task accomplishment, and paid requests for hacking system functionality, for which we will require a highly-interested user base, willing to make such investments and confident that the developers will produce a product worthy of their contributions.
2. We must aggressively build awareness in the general public of the fascinating, entertaining, and enlightening arena of video game hacking, including the need for more developers and better incentive systems to attract, motivate, and retain them.
3. We must actively recruit developers to the cause, both as the unpaid trailblazers we see today, and the compensated ones we envision tomorrow.
4. We must concentrate on relevant platforms, including both the obvious - current generation video game consoles - and other, more pervasive platforms, such as mobile devices (those running Apple's IOS, Google's AndroidOS, HP's WebOS, etc).
[...]

Apart from the monetary aspect, I think what we really need are standard tools. We need a generic, platform-independent framework to do all the game hacking tasks for us. We need a standard trainer toolkit to compare RAM dumps and find cheat codes. We need a standard protocol for debugger-debuggee communication. We need a standard library to parse and write cheat codes in text format. We need a standard framework to handle code encryption. We need standard user interfaces (both command-line and graphical) to access these tools. We need standard file formats. We need proper documentation. We need automated tests.

Let's face it, most hacking tools are crap. They work more or less for the specific task they were built for, but when you look at the source code (if available), you can easily tell that it will most likely never be used again. I mean how many peek/poke tools, game trainers, and code converters/compilers are there?

With a standard framework in place, we can jointly concentrate on the most important thing - game hacking - without reinventing the wheel for each new system.

[misfire]

And btw, the funding platform http://www.kickstarter.com/ is worth a look.

I know that bushing of team fail0verflow used it to finance OpenVizsla.

[Helder]

A universal device and tools would be awesome and make cross platform hacking a simple transition without learning a whole new tool or software. Maybe try to get some of these hardware developers like the guys from Team Twiizers to see if they might be interested in helping to develop such a device.

[Lazy Bastard]

misfire: Yes! We should band together to get the ball rolling on the Scalable Remote Debugger Protocol...perhaps even dropping the Remote, and making it encompass both local and remote debuggers , and perhaps other hacking tools as well...

And that does look like an awesome place to get useful projects going. Perhaps we should make real attempts to kick-start both SRDP and individual hacking projects there.

[misfire]

misfire: Yes! We should band together to get the ball rolling on the Scalable Remote Debugger Protocol...perhaps even dropping the Remote, and making it encompass both local and remote debuggers , and perhaps other hacking tools as well...

And that does look like an awesome place to get useful projects going. Perhaps we should make real attempts to kick-start both SRDP and individual hacking projects there.

Yes, SRDP would indeed solve the "We need a standard protocol for debugger-debuggee communication" problem. Although the protocol has very high goals, not limited to video game hacking, and I estimate that its completion would take several man-years of effort.

As for the "standard trainer toolkit", I think that Viper's RenegadeEx has some good ideas. The tool supports multiple systems and understands what a basic game trainer is about. Unfortunately, its source code has some design problems (e.g. the search code is tightly bound to the GUI). Nevertheless, it's a start.

Pyriel's MAXConvert is - if you neglect the GUI - the best we have when it comes to a "standard framework to handle code encryption". But it's for PS2 only and more a device-dependent crypto tool than a generic framework. I don't think that we really need it at the moment anyway.

Though not really generic (yet), libcheats has become my "standard library to parse and write cheat codes in text format". With it, I was able to come up with a CodeBreaker "cheats" compiler only minutes after figuring out the file compression. This project looks promising and I've plenty of ideas for it.

[Lazy Bastard]

Yes, SRDP would indeed solve the "We need a standard protocol for debugger-debuggee communication" problem. Although the protocol has very high goals, not limited to video game hacking, and I estimate that its completion would take several man-years of effort.

True. We could always use a video game hacking tool framework as a baseline/test for building SRDP into a real protocol, molding it along the way. That way, both goals are furthered.

As for the "standard trainer toolkit", I think that Viper's RenegadeEx has some good ideas. The tool supports multiple systems and understands what a basic game trainer is about. Unfortunately, its source code has some design problems (e.g. the search code is tightly bound to the GUI). Nevertheless, it's a start.

Yes, Viper187's RenegadeEX is awesome. I think if it didn't rely on MFC, it would be perfect, or could fairly easily be made perfect. Not that I'm one to talk; the only GUI I ever made (aside from the patchwork GUIs I made for Artemis) was in VB.NET, heh.

Pyriel's MAXConvert is - if you neglect the GUI - the best we have when it comes to a "standard framework to handle code encryption". But it's for PS2 only and more a device-dependent crypto tool than a generic framework. I don't think that we really need it at the moment anyway.

Yeah, but any complete hacking system should include an encryption/decryption utility, so it's worth mentioning.

Though not really generic (yet), libcheats has become my "standard library to parse and write cheat codes in text format". With it, I was able to come up with a CodeBreaker "cheats" compiler only minutes after figuring out the file compression. This project looks promising and I've plenty of ideas for it.

Yes, libcheats should be adopted in full. It's essentially the only library of its kind, and it's fairly straight-forward and clean.


So what should be the first step? Should we get with Viper and see if we can rewrite RenegadeEX to be more portable?

[Helder]

So what should be the first step? Should we get with Viper and see if we can rewrite RenegadeEX to be more portable?

Sounds like a good first step in the right direction.

[misfire]

[...] So what should be the first step? Should we get with Viper and see if we can rewrite RenegadeEX to be more portable?

I don't know. I'm only good at criticising other people's work and fail when it comes to doing it better.

But seriously, before rushing into coding we should first think about what we really want (requirements) and then how we can achieve it (implementation). I'm not talking about writing a detailed specification upfront, I'd rather start with some brainstorming and optionally creating a mind map.

[misfire]

Just to make it clear, with "game hacking system" I do not mean a physical device you can attach to any console and that works by magic. I'm talking about a software framework for Windows/Linux/Mac/etc. that provides all the tools a game hacker needs (see previous posts) and that is written in such a way (standard interfaces, modularization, etc.) that it can be used for almost any target system (e.g. PS2) with little to no effort. I think the term "game hacking framework" is more appropriate here.

Of course, some of the framework's components need to or can be implemented on the target system too. For example, a SRDP stub if you want to use that protocol for communication, or a cross-compiled version of libcheats if you like to load your cheats.txt on the target platform (like PS2rd does). But I'm concerned with hacking tools on the PC side in the first place.

[Lazy Bastard]

Note: I've moved these posts from a thread under Announcements concerning the state of GSHI and the scene, per request by and agreement with misfire.

I agree, we're not talking a physical device. We already have a standard framework of physical devices - computers.

So what we should do is define what specifically a hacking system should entail. Also, we should mention right now that a hacking system will inherently include a cheat system, so we can simply refer to the entire system as a hacking system, not as a cheat/hacking system, etc.

Anyway...to begin, I think it should include the following capabilities:

0. Cheat system (constant-write, and various code types)
1. Memory dump
2. Memory dump comparison
3. Memory viewer, with editor
4. Breakpoint/watchpoint
5. Disassembler

Perhaps some of these are too lofty for a baseline. Perhaps I've been too concise, and none of that needs to be said. I guess input from other people is required. How shall we start?

[misfire]

While your points are all valid, I suggest to first concentrate on the very basics - reading from and writing to memory of some target system. I think those are the fundamental operations for game hacking.

I've said some fuzzy things about standard tools and generic interfaces. Let me give you an illustrative example: http://pastie.org/1624650

What you can see is some (disfunctional) Python code that implements a standard interface to read and write memory using either the NTBP or SRDP protocol. The point is that the function dump_memory() at the end doesn't care about how the underlying protocol actually reads memory; it just happily calls it. You can then write some nice tools (e.g. game trainer) relying on dump_memory(), and the cool thing is that the same tools can be used for all systems you implemented a protocol for.

What I'm proposing here is similar to how a operating system handles files. If you copy a file from A to B, it generally doesn't matter if B will be on a different file system than A. You just type "copy A B" and the OS does all the magic behind the scenes. In fact, B could be stored thousands of miles away if its a network file system.

This design would actually allow us to easily write virtual file systems mapping memory to local files... But I'm getting ahead of myself.

[Lazy Bastard]

Yes, that's exactly the kind of framework we're talking about...but what should be the next step in our brainstorming? More refined pseudo-code?

I'm not sure what else can be accomplished, or even planned for, without first taking Viper187's RenegadeEX, and getting it re-written to be portable (at least, the universal pieces of it).

[misfire]

I'm doing some more prototyping.

I find Parasyte's idea of using URI schemes to specify debugger protocols very appealing, and consequently changed the Python prototype to determine the protocol by URL, e.g.

$ python protocol.py srdp://192.168.0.100
Protocol = srdp
Host = 192.168.0.100
Port = None
Data = SRDP says hello

$ python protocol.py srdp://192.168.0.100:1234
Protocol = srdp
Host = 192.168.0.100
Port = 1234
Data = SRDP says hello

$ python protocol.py ntpb://192.168.0.100:1234
Protocol = ntpb
Host = 192.168.0.100
Port = 1234
Data = NTPB says hello

$ python protocol.py ntpb://localhost
Protocol = ntpb
Host = localhost
Port = None
Data = NTPB says hello

In this way, all a memory dumper would need is the URL, offset, and data length.


Other devs could work on (planning) a generic library to compare RAM dumps or a portable game trainer GUI. Do not expect much input from me though, I'm still concerned with the low-level parts.

[Viper187]

Well, I recently survived cancer (so far), and I've been trying to max my rank on Halo Reach the past 4 months. You've got my attention with this project though. I just don't know how I'm going to find time to get this going.

Actually, RenegadeEX is full of Win32API stuff, not MFC. Same difference though. As I told LMZ, you're welcome to it.

When I started working on RenegadeEX 2.0 (and later PS2CC), it was my intention to weed out as much Win32 stuff as much as I could and seperate GUI from other functions. I was making progress before I left it sit for like 2 years. I would need to compare the difference in that source from what I put in PS2CC now once I figure out where I left off. The next step was to setup something SDRP-like to use. I was gonig to set it up with the open source Mupen for Windows that I modified befoee, since I know I can screw with that and it actually compiles. I even figured out how to do breakpoints on it at one point, I think. First thing I have to do is figure out how the hell to get MinGW32 on Ubuntu to compile Renegade from the makefile I used on MinGW in XP.

The protocol obviously isn't my thing. Only time I even messed with commuications like this was implimenting the winsock stuff for PS2CC that you guys put together. That worked out pretty well, once I got used to it. I wouldn't know where to begin to get something custom and platform independent to work though. I assume there's a way to write a library that'll work on multiple OSes, consoles, etc. I just wouldn't have the first clue how to set it up.

Anyway, I guess we'll see how it works out.

[Lazy Bastard]

A generic library to compare RAM dumps is soooo enticing. But the question becomes: do we write it in something like plain C, then modify it to compile on various platforms...or in something that's designed to be portable, like Java?

The next step would be to make a mentally palatable layout of block size options for comparison (bit [by boolean operation], nibble [same], 8-bit, 16-bit, 32-bit, 64-bit, etc), functions for detecting total dump size and comparing dumps of different sizes based on offset, etc, then the obvious (and not-so-obvious) code search functions. I figure the latter can be as giant and extensive as we like, so long as the naming convention is highly unique, and doesn't crowd potential variable names for other uses, etc.