Universal Video Game Hacking Framework

[misfire]

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.

Let me give you a concrete example:

In Renegade's lib_search.c there's a function called CodeSearch() which is tightly bound to the Window handle hProgressBar:

int CodeSearch(CODE_SEARCH_VARS Search, HWND hProgressBar)
{
    u32 address;
    u64 NewValue;
    u64 OldValue;
//    RamInfo.NewResultsInfo.ResCount = 0;
    if (Search.TypeEx & EXCS_SIGNED) {
        int i;
        for (i = 0; i < 10; i++) { Search.Values[i] = SignExtend64(Search.Values[i], Search.Size); }
    }
    for (address = 0; address < RamInfo.NewResultsInfo.DumpSize; address += Search.Size) {
        if(!(address % 0x100000)) { SendMessage(hProgressBar, PBM_STEPIT, 0, 0); }
...

To remove the dependency, let CodeSearch() accept a callback (or hook) function it invokes once after each memory block processed. The callback will be passed three arguments: a count of blocks processed so far, a block size in bytes, and the total size. You then define the progress bar magic inside the callback and everything is fine - no more WinAPI stuff in lib_search.c.

Also, you don't have to worry about the protocol thing, that's a different layer. You'd just call another library's dump_memory() function like I proposed the other day.

[Viper187]

Yeah, I'll have to change that progress bar stuff. I finally solved the compiling issue on Ubuntu, so I started to at least look at the source. FYI -The lib_search in PS2CC is the most up to date. It has a couple PS2-specific, but easy to remedy, aspects though. The call(s) to GetSearchValues() were locked to little endian instead of using the var, and the GetSearchValues() only has the code for little endian. That function needs retooled anyway if we're comparing dumps of different sizes etc because it was made to grab values from the same location of both dumps anyway. Easiest thing will probably be to cut it down so it grabs 1 value and call it twice. Less vars, and less complexity.

[misfire]

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.

IMHO, Java is a pain when it comes to dealing with bits and bytes. It doesn't even have unsigned data types... I'm all in favor of portable C code here. In addition I'll be using Python for prototyping (which can be extended with C code, by the way).

[Lazy Bastard]

A library could be written to treat numbers as unsigned in certain circumstances...in fact, there probably already is one...but yes, Java sucks in several ways, though it is quite good for portability.

C it is.

[kh2k4]

I'm not the only one who hates java then, I was feelng kinda lonely in that department.
I have some experience with C++, 10 programs made college 7 years ago lol, I prefer program in pascal and delphi though, i'm trying to learn vb simply because simlair programs compile smaller than delphi.

[Viper187]

I'm not the only one who hates java then, I was feelng kinda lonely in that department.
I have some experience with C++, 10 programs made college 7 years ago lol, I prefer program in pascal and delphi though, i'm trying to learn vb simply because simlair programs compile smaller than delphi.

You should really consider learning old school C over VB6/.net. VB6 was incredibly slow at processing things. Can't speak for VB.net, but I wouldn't learn it. C itself is easy to get started with. The GUI end of it was a pain to find a proper tutorial of the way I do it, but once you get used to how the message loop works and learn to use a proper compiler (MinGW), it's all good.

[kh2k4]

How much different is it C++?, I still have a copy of Borland Turbo knocking on floppy somewhere.
One thing i'd like to do first is add CDVD support to radshell atm it'll only load the script file from it's current working dictionary using uLE as it loads the modules beforehand to access the device, they stay resident on the next launched elf too.

rom0:ROMDRV
rom0:ROMDIR
rom0:FILEIO
rom0:IOMAN
rom0:CDVDFSV
rom0:CDVDMAN

[Viper187]

Looking back on Renegades past and PS2CC, what would people like to see different in terms of GUI/functionality? I know I need to get searching to work with files of different sizes. That'll be interesting. I'm curious as to what purpose people have for that feature besides something like PS2 where dumping the whole RAM actually takes time. Obviously, that's reason enough, but I'm still curious since the issue came up in the past too.

How much different is it C++?, I still have a copy of Borland Turbo knocking on floppy somewhere.
One thing i'd like to do first is add CDVD support to radshell atm it'll only load the script file from it's current working dictionary using uLE as it loads the modules beforehand to access the device, they stay resident on the next launched elf too.

rom0:ROMDRV
rom0:ROMDIR
rom0:FILEIO
rom0:IOMAN
rom0:CDVDFSV
rom0:CDVDMAN

Well, to me C++ is really ugly, but it seems to do some things a little easier and a lot of people prefer it.

[kh2k4]

A value monitor, 12 address seems enough so you can see it changing addresses on the fly.
Do I have the go ahead to reuse PS2CC code for a server for PS2 Remote Joker?
I need to find the source to Argon and padtest though :-(
I want a dev enviroment under windows where I don't need to use VM or use Linux instead to compile elf's, I tried ps2dev sdk before with devkitpro / programmers notepad setting the makefile and make.exe but no joy :-( I've even considered tracking down a copy of codewarrior for the ps2.

[Viper187]

A value monitor, 12 address seems enough so you can see it changing addresses on the fly.
Do I have the go ahead to reuse PS2CC code for a server for PS2 Remote Joker?
I need to find the source to Argon and padtest though :-(

That sounds easy enough. Figuring out where to fit it in the interface will probably be the hard part. lol
Yeah, that's what the source is there for. Have at it. What do you mean by remote joker?

[misfire]

Though I don't want this to be about programming languages in general, this is quite interesting:
http://www.tiobe.com/index.php/conte...pci/index.html

[kh2k4]

That sounds easy enough. Figuring out where to fit it in the interface will probably be the hard part. lol
Yeah, that's what the source is there for. Have at it. What do you mean by remote joker?

Taking the controller joker values from one ps2 and passing / overriding it to another using ps2cc as a server between the two ps2 clients.

[misfire]

To keep the thread on topic, what about this effort to build a ps2cc variant with the cross-platform Qt framework: http://gshi.org/vb/threads/3817-A-ps...riant-with-QT4

It also comes with a bit of documentation.

[bungholio]

Looking back on Renegades past and PS2CC, what would people like to see different in terms of GUI/functionality?

- Being able to search for an array of bits instead of only bytes would be useful at times. I could imagine that taking quite some time though compared to an array of bytes.

- For address ranges, the ability to select "pointer" and then to supply where to get the address range to search in.

- Able to select and do multiple searches at the same time. I might be looking for 2 very unrelated things that I could find in the same area of the game. It's just for multitasking if anybody feels they can find more than one thing at the same time.

- Some way of specifying specific gaps in things searched for. Example:
I'm looking for something like this:
3f800000
????????
40000000
Those question marks are ignored because it doesn't matter what they are, so you would end up with these kinds of results:
3f800000
00000000
40000000
or
3f800000
3cdccccc
40000000

It wouldn't care about certain things like the middle 4 bytes. It would be nice to have it for the array of bits too.

- Similar to the above, but you can use multiple different searches at the same time. Many games usually have some HP setup of 4 bytes being your current HP, and the next 4 bytes being your max HP capacity. Here's an example:

Start game with full health.
Search 01:
4 bytes, equal: 42c80000 (assuming this is current HP)
Next 4 bytes, equal: 42c80000 (assuming this is max HP)
Then take damage.
Search 02:
4 bytes, decreased value and NOT zero (you took a hit, so your HP should go down)
Next 4 bytes, equal: 42c80000 (your max HP shouldn't have changed.

And that's how that would be useful.

I'll probably think of more later at some point.

[Lazy Bastard]

Another cool, fairly innovative feature would be to search for a series of values. For example, search for an 8-bit value of FF, followed by an 8-bit value of 00 exactly 128 bits later, followed by a 16-bit value of 09FA exactly 128 bits later. This would help when you know the value of several things, and the offset between them, but not the address.