Emulation Project - GameGuard'd Client

[Lokked]

Hello,

I'm not new to MMO Server Emulation, but I am new to working with a protected Client, and have very basic RCE skills. I would appreciate some direction, and maybe this won't be possible, given the requirements.

The target is Uncharted Waters Online, now published by Papaya Play, utilizing GameGuard (instead of X-Trap, as the previous publisher).

Two Priorities:
1. Can I prevent the Client from loading or attempting to refer to GameGuard?

2. I need to understand the client-server communication through Packet Analysis. Obviously impossible with Encrypted Packets.

My Questions:
1. How entrenched is GameGuard? Will simply bypassing the loading routines be enough?? Or must I allow it to load, but Bypass all the functions that it alters? Obviously, I would like the Client to not have to load GameGuard when accessing the Emulated Server.

2. Almost guaranteed is the encryption of packets. A major task will be to see the unencrypted packets while connected to Live Servers. Does anyone have experience with this? My thoughts are to find and detour the encryption and decryption functions, to output the raw packet information somewhere else. Is this a viable approach? Is this practical, or is there an easier way for me to understand the network communication?

Thanks all. All I'm looking for is an approach. I can research on my own how to achieve that, but at this point, I don't know enough about GameGuard and Reversing Packet Encryption to know where to start.

Lokked

[Shadow992]

Originally Posted by Lokked

Hello,
2. Almost guaranteed is the encryption of packets. A major task will be to see the unencrypted packets while connected to Live Servers. Does anyone have experience with this? My thoughts are to find and detour the encryption and decryption functions, to output the raw packet information somewhere else. Is this a viable approach? Is this practical, or is there an easier way for me to understand the network communication?

I am not very deep into Game Guard, so I will skip this question.

But the packet encryption is easy to solve - given you managed to disable Game Guard. Basically the easiest solution I always used was to set breakpoints on send/recv winapi functions and step backwards until I found the encryption/decryption routine. As soon as you found the routine it depends on what you are going to do with it.

Reversing the encryption/decryption is a possible way to go, but not neccessary for your purpose, because you only want to analyze packets. So hooking/detouring the encryption/decryption function is the easiest and fastest way to go in my opinion.

[atom0s]

Priorities 1 - Depends on how in depth the GG implementation is. If they use the heartbeat packet, you can't just simply remove GG and expect it to work. You will either need to emulate the heartbeat or bypass the anti-cheat in general.

Priorities 2 - This isn't impossible. This is just a means of having to determine the encryption being used and undo it.

Questions 1 - Depends on the version and what features are in use. In some cases if they do not use major features you can just prevent it from loading.Other cases you have to either full bypass it or emulate parts of it (ie. the heartbeat).

For private servers, you can just fully remove the anti-cheat from the client when you are at that point and be able to do what you need as normal. But while on the retail version of the game, you will have to allow the client to behave in a manner the server expects it to.

Questions 2 - Depends on the approach you want to take. You could proxy the connection and decrypt the packets yourself within your own proxy after figuring out the needed information. Or, as you mentioned, hooking the functions handling this and just logging data before the encryption is implied, and after it removed based on packet direction. Either method is viable and works fine, just up to you which you are more comfortable with.

With GameGuard active, you will need to bypass the various layers of protection that are in-use (if enabled) such as:
- Anti-injection
- Anti-thread creation
- Anti-memory editing
- Anti-module loading / alterations
- Anti-API hooks

And so on. GG is not that hard to bypass but information on anti-cheats publicly available is slim to none as people do not want their methods being patched.

If you are new to things kind of stuff then its probably not your best idea to be jumping into something with an anti-cheat as a first-time project based on how you are explaining it.

[Lokked]

UPDATE:
I realized my error below in disassembling GVOnline.exe. It is just a game launcher. Not a login system or anything like that. No net code. Just a "Start Game", "Settings" and "Quit" style app. Once you Start Game, it launches Gameguard/nProtect and when that succeeds, GVOnline.bin is loaded as a Process, and then promptly hidden, along with gameguard.des and one other that I'm not quick enough to see.

When I disassemble GVOnline.bin, IDA is unable to find an Entry Point and asks me to select a function that seems reasonable. I have no idea, so I pick the first Subroutine. It comes up with a lot of errors during analysis, and has no entries for the Import and Names Tables. Ollydbg, on the other hand, can open GVOnline.bin and does have a long list of Names, including WSASend and WSARecv, but isn't the easiest to statically analyse.

Any hints on how I can get this disassembled in IDA without issues, similar to how Ollydbg is able to do so?


Previous Information (It's wrong, but keeping it here for learning purposes)
I've had some time to work on this. I obtained and read a book called Attacking Network Protocols, as it was recommended. It seems a bit rudimentary, and the section I was interested in, Reverse Engineering a Network Application, was nothing I didn't already know.

I obtained the free, 5.0 version, of IDA, and disassembled GVOnline.exe (the Uncharted Waters Launch exe). I cannot find anything that looks like socket calls in the Imports table. No Send, Recv or any of the other analogs.

I've created a Pastebin of the Imports:


And here is a Pastebin for Names:



I apologize ahead of time for my lack of understanding.

Could it be that Gameguard itself is responsible for communicating with the Sockets? If that's the case, then I'd suspect Gameguard would also be responsible for encrypting the packet payload, but I should be able to get the raw information from the software itself, as it must construct it somehow before passing it to whatever sends or encrypts it.

Thank you,

Lokked


UPDATE: On a Better Track
The GVOnline.bin File is just an EXE disguised as another binary. I renamed it to .exe and launched it, and it did exactly what normally happens after pressing "Start Game" from GVOnline.exe.

I've disassembled it in IDA and have found calls related to the net code. Send imports are Send, SendFrom and WSASend. Recv imports are only RecvFrom.

Starting with RecvFrom, I didn't get very far. Instead, I looked at what could be Encryption-related calls. GVOnline uses ADVAPI32 and the Crypt set of Calls. I found only 2 references to CryptEncrypt, so I'm hoping I'm on the right track.

CryptEncrypt is called twice in a short frame. First, it called it with the following params:
Signature:

CryptEncrypt(
HCRYPTKEY  hKey,
HCRYPTHASH hHash,
BOOL       Final,
DWORD      dwFlags,
BYTE       *pbData,
DWORD      *pdwDataLen,
DWORD      dwBufLen
)

CryptEncrypt(
hKey (from parent function param),
0,
1,
0,
0,
eax (from parent function param),
0
)

I couldn't find documentation on why you would want to send the encryption key and the pointer to actual data, but put 0s in the for length fields. Won't that fail?

Anyways, the instruction after this call is test eax,eax and then a jz succeed to what looks like error handling (a bunch of writefiles), and a jz fail to a second CryptEncrypt function. This time with what seems like actual data (there were a LOT of Calls and various jumps before returning back to this function. I didn't bother to follow at this point):

CryptEncrypt(
hKey (from parent function param),
0,
1,
0,
eax (from parent function param),
esi (mov'd from eax, which is likely set in the mess that I gave up on),
ebx (pushed to stack prior to the large set of subroutines)
)

So I think I'm making progress. It will be hard to tell if the entire packet payload is made up of the result of this encryption, but with some analysis of the packets themselves it shouldn't be too bad to determine.


My biggest challenge is now rerouting this function to output esi, considering Gameguard won't even let me OpenProcess or CreateRemoteThread. I'm reading about kernelmode drivers and maybe another route is to hook CryptEncrypt and output the contents of that param before anything is manipulated.

My other realization is now that simply removing Gameguard from loading won't stop the packet encryption, and I'll have to figure out exactly how that works, as I'll need to do that same on the server (the client expects the packets encrypted).

NOW, having said all that.... maybe the easiest path is to not even detour anything in the application. They just use MS's Crypt calls, so if I can figure out at runtime what the Encryption Key is, I can just write an app to decrypt all the packets that I can collect using any number of ways.

So, I have 2 questions:
1. IDA-Pro: How can I have it generate a "map" or Process Flow between 2 functions? Namely, I want to know how the CryptEncrypt section can reach the Send/SendFrom/WSASend call(s). I'm sure it would look like a nightmare, but it could help.
2. Gameguard... . I'm sure it's not going to be public information, but I'd like some guidance on the best path to be able to monitor the memory space where the Encryption Key is created, at a minimum. The closest I'd gotten was Cheat Engine's DBVM Mode, where I could open the process, but I couldn't run any of the memory scan functions. It told me that there was no readable memory.

Thanks all. I'll keep updating the thread with my journey. I won't give away too much unless people would like to know in a PM.

Lokked

[krotkin]

reading your post, i think u have no idea what are u doin.. to land on CS Auth, u need unpack and check gamemon.des not client. If i understand u right, just bored read all..

here how looks GG auth routline in olly


PS. i dont understand, u wanna remove GG from client or do GG heartbeat (CS Auth) emulator?
be cause, remove GG from client is piece of cake, but u wont get far with it, be cuz of heartbeat and server will disconnect u in 5- 10.mins from server

[Lokked]

I’ll refactor this response later, as I’m doing this quickly from my phone.

The goal is to develop an emulated server for a game (Uncharted Waters Online). I need to capture packet information to develop server-client communications. UWO packets are encrypted within the client (Crypt* routines from ADVAPI32). I need to be able to see the packet information while connected to live servers to understand how the communication is supposed to work.

Basically, the only challenge is bypassing GameGuard’s annoying hooks so I can OpenProcess, inject a custom DLL or just use Detours on the CryptEncrypt and CryptDecrypt routines to capture the raw packet information. And from there I do what I do with the emulation server.

Yes I’ll have to provide a mod for the client to skip loading Gameguard, but that’s the easy part (easy unless there is trickery).

Lokked

[pornpinoy]

are there any documentation about this heartbeat and what procedures to take? i'm also creating a trainor... but i'm kinda rusty... any guide will do thanks...

by the way very informative post... i have almost spend my time reading this post

[Lokked]

Hello!

I'd given up on this for a while, but in he last couple weeks focused on becoming familiar with ASM, anti-debugging techniques, GameGuard's annoying scan and it launching process.

I was able to prevent GameGuard from completing its launch sequence and have a modified client that runs without GameMon.des. I can now run the client in a debugger and what I'm working on is discovering the handshake process and the encryption process.

All that crap above about CryptEncrypt was wrong. I'm a noob. GameGuard implements CryptEncrypt to create its error logs and all that crap they want you to send them when their app crashes.

I know nothing about encryption, but when you provide your log on information, the client sends a packet with the World options and the server sends back a packet that contains some opcodes that indicate how long each section is, and then the sections. Each section is 256 bytes and there are 2 sections. Both are a combination of numbers and letters, however, the first block has all lowercase letters and the second block has all uppercase letters. I tried googling such a key and couldn't find anything.

At any rate, I should be in the clear to find the plain-text portion of the packet and then I can carry on with this.

Just thought I'd update my thread at ElitePvpers.

Originally Posted by Shadow992

Basically the easiest solution I always used was to set breakpoints on send/recv winapi functions and step backwards until I found the encryption/decryption routine.

And this is my current task, now that I've disabled GameGuard. I am either really bad at reversing ASM (yep) or the engine has written a confusing process to decrypt the packets. I started looking at Send and working backwards, but I just don't have the knowledge on how to do that. Following the assembly backwards line by line in IDA is a nightmare. i have a feeling it would be easier said than done, because when I write a UDP server, it's always on another thread than the logic that submits the packet to be sent, and I have a feeling this is the case. This means simply following in static analysis is not going to work. I've been working with breakpoints on what accesses the buffer from the recvfrom call, and I know I'll get their eventually, but this strategy won't help working backwards from Send very well.

[florian0]

Originally Posted by Lokked

And this is my current task, now that I've disabled GameGuard. I am either really bad at reversing ASM (yep) or the engine has written a confusing process to decrypt the packets. I started looking at Send and working backwards, but I just don't have the knowledge on how to do that. Following the assembly backwards line by line in IDA is a nightmare. i have a feeling it would be easier said than done, because when I write a UDP server, it's always on another thread than the logic that submits the packet to be sent, and I have a feeling this is the case. This means simply following in static analysis is not going to work. I've been working with breakpoints on what accesses the buffer from the recvfrom call, and I know I'll get their eventually, but this strategy won't help working backwards from Send very well.

Going backwards in pure static analysis is not an easy task at all. Especially if things get threaded/async, it's quite a nightmare :P. Yep, motivating people has never been a strength of mine xD.

The idea of tracing memory access at runtime is quite smart. The memory being used might be deterministic aka: The send buffer might be reused. So your access breakpoints might also trigger when the buffer is filled.
Another thing might also come handy: How a binary is actually compiled. Each Source file becomes an object file and is then merged together by the linker. That means that all functions of a Source file are stored together and there is a good chance that the encrypt and decrypt methods are close together as well. If you find one, you might find the other. Just by scrolling up and down in the assembly. And even if they are not close together, they might share a common memory for substitution/permutation data.

Afair there are scripts for IDA that recognize different encryption algorithms. Maybe give these a try.

What I like to do when going backwards in code is
0. Label the function where I am at (e.g. "NetworkRelated")
1. Set a breakpoint on the beginning of the function
2. When the breakpoint is hit, look at the stack where the program came from
3. Go there, label the function (e.g. "NetworkRelated_outer")
(3b. Make a quick assumption if that function has other uses. You'll learn to make guesses like that)
4. Continue at 1.
Now, whenever you pass any of these functions again, you know that these (may) lead to networking code.

Just keep in mind: Every label is a win. Whenever you recognize a label, it's like recognizing a place you have been before.

[Lokked]

Thank you for the advice, florian0.

I wanted to share a hilarious story (to me), that I would bring up if I had to teach someone what I learned.

I was doing as you mentioned, set a Read HWBP on the recvfrom() buffer, continued execution so the function would write to it. It was hit, and I started following. I was in a memory region I'd never been in before, really high offsets. I was single stepping through and noting the values I was interested in and getting nowhere. I search the offsets in IDA and nothing. I saw the module in the Debugger listed as "CryptEnc". I tried to figure out if IDA could be fooled and not recognized this module being loaded. I Googled "CryptEnc" and got absolutely nothing. I was frustrated.

Then, in stepping through, I saw some strings in the Dump that looked REALLY familiar.... a lot like what my hook on recvfrom and other functions outputs....

Sure enough, I was debugging the hook function and the hook itself from my injected DLL, lol! For almost 2 hours!

Man. Fascinating how you can surprise yourself when you don't really know what you're doing! Hah!


An Update:
I found the blowfish routines (the engine they used also has AES, but they don't use it). I noticed it right away because the ASM was rolled out into 1 long set of MOVs, XORs, SHRs, etc, using 2 registers and the 8 bit portion of those registers. I need to work on following this back to the point before the payload is separated and padded into 8 byte blocks. I stopped at the CALL to the function but couldn't find anything apparent in the registers or stack around the ESP.


I have a question:
When a CALL is done like this (forgive my bad asm, I'm doing this from memory):
CALL dword ptr:[eax+someoffset]
instead of the usual CALL someoffset

How could this have been written in C, to be compiled this way? Is that what a function pointer boils down to? From what I could understand, this engine allowed them to select a cipher to use with their implementation, so is [eax+someoffset] just what they'd created as a #define (ie. #define BlowfishCipher)?

If that's the case, I'd write my whole program with function pointers, because then no one would ever be able to statically analyze it.

[florian0]

Originally Posted by Lokked

I have a question:
When a CALL is done like this (forgive my bad asm, I'm doing this from memory):
CALL dword ptr:[eax+someoffset]
instead of the usual CALL someoffset

How could this have been written in C, to be compiled this way? Is that what a function pointer boils down to? From what I could understand, this engine allowed them to select a cipher to use with their implementation, so is [eax+someoffset] just what they'd created as a #define (ie. #define BlowfishCipher)?

If that's the case, I'd write my whole program with function pointers, because then no one would ever be able to statically analyze it.

Nice progress!

A call with an offset can have different origins. It's also depended on the compiler. For MSVC, I think the most likely one is a virtual function call. Virtual functions are organized in a table called virtual function table. A pointer to it is located in the very first (4) bytes of the object you are dealing with. You can pretty much tell if that's the case by looking at the previous instructions.

So if you got something like this:

MOV EAX, [object] ; get virtual function table
MOV ECX, object ; this pointer
CALL [EAX+8] ; call third entry of vftable, sometimes gets expanded into two instructions for add and call

It's rougly translated to this:

class MyClass {
public:
    virtual void MyFunc_0(); // Offset 0, offsets are separated by 4 because sizeof(pointer_type) == 4
    virtual void MyFunc_1(); // Offset 4
    virtual void MyFunc_2(); // Offset 8
};

int main()
{
    MyClass m;
    m.MyFunc_2();
}

If it doesn't follow this pattern, it could be a simple function pointer or even a list of functions in an array (which would be the same like a vft, but not compiler generated).

[Lokked]

Update:
I've found a way to prevent GameMon.des from loading, but only if I run the app is a debugger and do some shifty work each time I launch the app. It's fine for now. I will need to figure out how to completely remove it eventually, but for now it's ok because...

I reversed the Encryption/Decryption routines and am spitting out non-encrypted packets from send() and recvfrom() functions. I can get some real work done now with creating a catalogue of Packets and their OpCode datatypes and values.

It's been a fun time with real-time and static assembly analysis, but finally I can get going on the rest of this.

I have a few long term goals:
1. Game Server (massively oversimplified with 2 words)
1.5 Implement Scripting Language Bindings (I don't know what yet) to make custom content easier.
2. Web Crawler to scour the unofficial UWODB. The owner hasn't responded to emails I've been sending for 2 years to access his DB. He has pretty much every piece of content nicely organized in a database, aligned with the game's IDs. It would make content generation in the Server MUCH easier. I figure a web scrubber or whatever can get what I need.
3. Create Patch Server (I don't know why. Just in case?)
4. Create Logon Server in case I feel like releasing this emulator to the community and they want to spin up theor own servers.
5. Patch some annoying things out of the client.
6. Not get sued (this should probably be #1)

[JUSTARAMDOMDUDE]

Any more progress on this? I recently found this post and I am quite eager for progress now that I've found it. This game is one of my all time favorites and after the last wipe, I'd like to make my own server to play on.

[Lokked]

Hello! I'd given up after categorizing a limited set of packets (Chat, Movement, Land Zone Change, Actor Instantiation (I hadn't figured out the Actor types), a few more.

I switched my talents to something more profitable: Business Software. This was a fun journey, but I got bored after I experienced the "New Learning" side of things. Packet Analysis is so boring and gives me a headache. Content, I realized, also gives me a headache and can't really be done by 1 person, especially someone who has no help collecting packets from others. The game literally takes 100s of hours to progress to see all the different parts, and I just don't have the time.

I haven't loaded up my game nor my packet logger, so who knows if they've expanded the GG set of features. Maybe my approach is broken at this point.

[Lokked]

Because I'm getting a couple questions on this, I'll post my latest response to "I want to do that for this game. How?" here:


GG may use the Heartbeat function. If it does, you WILL NOT be able to solve this. You will only know it uses this if you manage to disable GG, and yet you are still kicked from the server.

The first thing you must do is attempt to disable GG. You will do this by performing dynamic analysis on the running assembly using a Debugger, like OllyDBG. If GG detects OllyDBG (....It will), you will need to use Immunity Debugger or X64DBG and you will need to have the correct settings to prevent GG from detecting it. You will run the game from the debugger and search for the LoadLibrary() function call, breakpointing each call to LoadLibrary(). All games use LoadLibrary to load GG. Once you find the correct call, step through it to understand what branches are taken (if none of this makes sense, you are in WAY over your head, and you need to study ASM as well as Static and Dynamic Analysis) and what actually causes the GG splash screen to display.

You will need to NOP the LoadLibrary() call to load GG, and then play with the Branches downstream to see what allows the game to launch. Basically, you fiddle around with things till it works.

If you need to Decrypt the packets, begin Static Analysis using IDA (this is the only tool you can use, really. It's expensive). You have to figure out where the encryption routines are. For this, you need to understand what Encryption does, how it works and how it's generally programmed in higher level languages, then translate that into what the ASM for that might look like. You also need to know how Net Code is generally written, to some degree. Knowing this, you will need to trace Recv() in memory and figure out what accesses the payload, because Net Code will always be threaded in a game, and following Recv() will just lead you in a loop. Recv() will put the payload into a variable accessed by multiple threads, so you will need to set breakpoints and follow it in your debugger. You should be looking for the Decryption routine, so follow Recv().

Once you have the entry address to these functions, you still have a lot of work to do. You need to hijack the Send and Recv calls. These days, you can find a library to do this. Other terms to help you search are Detour and Code Cave. You'll hijack the Send() and Recv() calls and call the Decryption routine using the Address you found in IDA. You would then log the result of the encryption function call.

Don't get your hopes up to make this happen in time. Collecting Packets is also a non-trivial thing. You can't just run a packet logger and go play the game. You would get millions of packets and you'd have no context as to what each of them does. You have to take things VERY systematically and you have to be VERY organized to catalogue everything properly. For example, you would be standing still, where there are no NPCs or players, start the packet logger, then move once, then stop it. Then you would take that file and catalog it as "movement". You would isolate EVERY tiny action and catalogue it with what input you provided and what action you were taking (ie. click mouse to move). This is a very time-consuming process.

Good luck!