MMO Hacking Bootcamp

This is a mirror of my thread on guidedhacking

What you will end up with after following this guide:

You can find the source code to all of this here

Hello and welcome to my first real guide or tutorial on this Forum.

Since i got inspired by this talk: https://youtu.be/QOfroRgBgo0 recently I decided to give that a try myself.

I hope you find this guide useful and also enjoy reading it. Please feel free to give feedback on this guide and on the code as well. So let's get started :)

Introduction

In MMO hacking there are as always multiple approches. Our goal however is not to write a bot for the game or anything like that.

We are trying to find exploits in the protocol of the game. For that we want to do Man in the middle attacks so we can fuzz the games protocol by crafting our own packets. To be able to do that we will create our own packet editor in the first part of this guide. After that we try to understand the protocol and identify possible vulns.

For this guide i have taken the game Tera as an example but everything in this guide does also apply to any other MMO.

If you don't understand everything quite yet: Don't worry this is a step by step guide. Meaning I will take you by the hand :)

Recon

First of all you always want to do some recon on the game first before jumping right into hacking it. That includes finding out which engine/language was used to create the game, which frameworks, which anticheat gets used (if any) etc. Also search for previous work done on the game that can save a lot of debugging and re work. Im sure you all know how to do that. However here are some little tricks you might find useful to fill this section with at least some information :)

• You can use Process Hacker to view the command line arguments which where used to start the game. This can be helpful when you want to start the game without the launcher. (ProcessHacker: https://processhacker.sourceforge.io/)
• You can use Process Monitor to see all traffic a process is sending and recieving. That can give you insight and let you know whether the packets are encrypted at all. Most of the time the packets will be encrypted. (Process Monitor: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon)

Tool creation

As you have seen in our Recon phase we are lucky and dont have to deal with any anti cheat technology. And that is a common trend in MMOs. However they prevent tinkering with the game by different means. Sent and recieved packets are always encrypted and they do also encrypt data in memory pretty often to prevent the usual memory editing (with cheat engine for example).

So How do we get around that?: We will hook the packet creation process in an early stage where we can read the raw unencrypted data of the packets.

For that we have to find the internal/high level send function the game uses to send packets itself and hook there.

As Mambda has saied his guide this can be a tadious process so i will cover this step in great detail to hopefully make it less tedious for you.

Finding the Internal / High level Send function

Communication between server and client always happens either through TCP or UDP packets. In theory there can be a list of functions used for sending and recieving these packets. (Mambda has listed most of these in his packet guide) But unless your game is very exotic or old, it will most likely use the ws2_32.dll for networking and make use of either the send() function or the WSASend() function for sending packets. However if your game sends packets over udp instead of tcp it will most likely use the sendto() equivalents. For recieving Data either recv() or WSARecv() are used. I wont cover hooking/finding the recv() function in this guide.

After all that saied let's get started. So our first problem is: finding out which function used by our game. This is relatively easy to do in cheat engine or any other debugger. We just set a breakpoint at the send() function and see if its get hit.

So let's go through this step by step.

1. attach cheat engine to our game:

2. find the send function: To locate the send function we have to open the Memory View in cheat engine. In the View Menu we can enumerate all loaded dlls. From here we can search for the ws2_32.dll and its send() function. If we double click the function cheat engine will take us there.

3. set a breakpoint at the send function: To find out whether our function gets called by the game at all we need to set a breakpoint at the send() function. It should get triggered every time we do something in game. If your breakpoint gets hit and the games execution stops once we do something in game -> great. If not -> you have to repeat the last step with a different send function and see if that one gets called.

4. finding the internal send: This is one of the harder parts in this guide but i will try my best to guide you through even if your game is different. At first it's important to understand the send function our game is using. For that always search MSDN for the used send function. In my case send(): (https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-send) as we can see the 2nd parameter is a char* to our (encrypted) buffer and the 3rd is the length of our buffer. These are the most important for us.

As you can see with our breakpoint hit we can inspect the current stack. The first address on the stack (the one pushed onto the stack) will always be the return address (where the function got called from). After that we can see the srguments the function expects pushed onto the stack. I have marked the ones that are important for us. Now we have multiple options to go from here to find our internal send function. One would be to double click the return address to get to where the send() function got called from and repeat that until we can find the send function the game uses itself (before the packets get encrypted). The other way is to add the address of the encrypted buffer to cheat engines address table and then -> find out what writes to this address.

This will only work if the address of the encrypted buffer doesnt change too often. But it has the charm that we can will find the end of the encryption function most of the time straigt away. After that we just have to trace back again by placing a breakpoint at the encrypt function to see the return address on the stack there. If we double click there to see where it got called from and repeat that process maybe some layers upwards we can find our internal send function pretty quick. Most of the time its the best to use a mixture of both methods depending on what your game is doing to reach your goal "quickly". What i did to find the send function for this game was to first tracke back where the send function got called from and followed the buffer. As i saw the buffer gets passed to the function that calles send as an argument i added that buffer to the address list and had a look for what writes to it. It appears that tera uses a wrapper around the send() function thats just there to call send() really. However this procedure is different for every game and it's important that you understand basic revrsing and debugging for you find your send function successfully. There can be a lot of places that write to the buffer and you might have to do multiple hooks. However if there is a unified send function in the game it has to write to the buffer at least once for every action you take. So you can ignore the opcodes that only write to the buffer for certain actions most times. It's still a good idea to note down the addresses of these opcodes as well so you can still check them out later.

(I greatly enjoyed the workshop at https://begin.re it mostly covers static analysis. But im sure if you struggle to understand what the game is doing this workshop will help you to get to the next level :))

After you have spent some time reversing the game and tracing functions back you will most likely have found the internal send function (or given up). Here is the one i found for Tera:

As we can see on the stack this function takes a pointer to the buffer and it's length as argument. This will be helpful to know later.

Hooking the send function

we now have some options we could modify the packet with the hook itself or just log it and call the send function ourself later. Since i aimed at a packet editor like the one Mafred uses i decided to go with the 2nd option. So we just need to acess the packet buffer and it's length through our hook so we can log the packet. i wont cover how to do hooking since this was covered here: https://guidedhacking.com/threads/code-detouring-hooking-guide.14185/ but i will explain what i do in my hook. First lets have a quick look:

    void* teax;
    void* tebx;
    void* tecx;
    void* tedx;
    void* tesi;
    void* tedi;
    void* tebp;
    void* tesp;

    DWORD sentLen;
    char* sentBuffer;

    void __declspec(naked) sendHookFunc() {
    __asm {
        mov teax, eax; backup
        mov tebx, ebx
        mov tecx, ecx
        mov tedx, edx
        mov tesi, esi
        mov tedi, edi
        mov tebp, ebp
        mov tesp, esp
        mov eax, [esp + 0x8]
        mov sentBuffer, eax
        mov eax, [esp + 0xC]
        mov sentLen, eax
    }
    printSendBufferToLog();
    __asm{
        mov eax, teax
        mov ebx, tebx
        mov ecx, tecx
        mov edx, tedx
        mov esi, tesi
        mov edi, tedi
        mov ebp, tebp
        mov esp, tesp; end of r