Wine // Linux - WoWClassic 2.5.1

[Wontuse]

How many here are reversing on Linux while running WoW under Wine?

Everything seems to be Windows specific and I've only come across a couple of (decade old) Linux//Wine threads across the internet. I'm struggling to find the base process//address to go from. With C++ I can rip through

/proc/<PID>/maps

and find what I need... except what I want isn't there. At least nothing obvious. Only shared libs, graphics//sound libs, Lutris//Wine modules, and a lot of unnamed stuff.

Code:

#include  <fstream>
#include  <cstring>
#include  <iostream>
#include  <proc/readproc.h>
 
struct moduleinfo_t
{
    std::string sName = "NOT LOADED";
    unsigned long ulBase = 0;
    unsigned long ulSize = 0;
};

int GetProcessID(const char *chProcessName)
{
    PROCTAB* proc = openproc(PROC_FILLMEM | PROC_FILLSTAT | PROC_FILLSTATUS);
    proc_t proc_info;
    memset(&proc_info, 0, sizeof(proc_info));
    while (readproc(proc, &proc_info) != NULL) {
        if (strcmp(proc_info.cmd, chProcessName) != 0) {
            continue;
        } else {
            closeproc(proc);
            return proc_info.tid;
        }
    }
    return 0;
}
 
moduleinfo_t GetLoadedModule(unsigned int uiProcessID, const std::string sModuleName)
{   
    std::ifstream infile( "/proc/" + std::to_string(uiProcessID) + "/maps" );
    std::string sLineIn = "";
    
    moduleinfo_t moduleInfo;
    
    while(std::getline(infile, sLineIn)) {
        if( sLineIn.find(sModuleName) != std::string::npos ) {
            moduleInfo.ulBase = std::stoi( sLineIn.substr(0, 8), nullptr, 16 );
            moduleInfo.ulSize = std::stoi( sLineIn.substr(9, 8), nullptr, 16 ) - moduleInfo.ulBase;
            moduleInfo.sName = sModuleName;
            break;
        }
    }
    return moduleInfo;
}
 
int main()
{
    const char *chProcessName = "WoWClassic.exe";
    unsigned int uiPID = GetProcessID(chProcessName);
    // moduleinfo_t moduleClient = GetLoadedModule(uiPID, "kernel32.dll");
    moduleinfo_t moduleClient = GetLoadedModule(uiPID, "libc-2.31.so");
    std::cout << "ProcessName: " << chProcessName << std::endl;
    std::cout << "PID:         " << uiPID << std::endl;
    std::cout << "ModuleName:  " << moduleClient.sName.c_str() << std::endl;
    std::cout << "ModuleBase:  " << std::hex << moduleClient.ulBase << std::endl;
    std::cout << "ModuleSize:  " << std::hex << moduleClient.ulSize << std::endl;
    return 0;
}

I run a

scanmem <PID>

and find something easy.. HP for example and narrow it down to 3 addresses. All 3 addresses fall in-between the address space of some unnamed module from

/proc/<PID>/maps

and it's usually between the 400-410 module in the list but no info on it; e.g.

326b0000-39840000 rw-p 00000000 00:00 0

That's all the info I have and as far as I've been able to get. On Windows it seems pretty easy to pop open Cheat Engine find what you want, find an offset, find pointers and run with that but Linux is proving to be much more difficult. And when I try to debug through GDB the game freezes 99% after I detach making it more difficult.

I'm looking for any tips//pointers on where to go from here to find offsets, a good base address to go from, am I even on the right path?

[scimmy]

Disclaimer: I don't know too much about how wine works. But it is a translation and runtime layer that is mapping a PE file into a linux process which is going to have to do translation for syscalls, calling conventions, etc. It's going to be more difficult for you to get stuff working as you're probably going to have to hook into the way wine executes code and that translation layer.

Now for the question regarding the HP address. This data is probably living on the heap, not in any program section, hence the anonymous region of memory that /proc/PID/maps shows.

[Wontuse]

Disclaimer: I don't know too much about how wine works. But it is a translation and runtime layer that is mapping a PE file into a linux process which is going to have to do translation for syscalls, calling conventions, etc. It's going to be more difficult for you to get stuff working as you're probably going to have to hook into the way wine executes code and that translation layer.

Now for the question regarding the HP address. This data is probably living on the heap, not in any program section, hence the anonymous region of memory that /proc/PID/maps shows.

Makes sense. Does it sound like I'm at least on the right track? I too lack understanding of how WINE is loading everything and translating everything and am seeking to understand it better.

-----------------------

Thinking out loud.. I attach to the process with GDB and run a search for UNIT_HEALTH and get this back:

[+] Searching 'UNIT_HEALTH' in memory
[+] In (0x30780000-0x32f00000), permission=rw-
  0x31a76210 - 0x31a7621b  →   "UNIT_HEALTH" 
[+] In (0x3ab70000-0x45a90000), permission=rw-
  0x3e8ccd40 - 0x3e8ccd54  →   "UNIT_HEALTH_FREQUENT" 
[+] In (0x477b0000-0x4a450000), permission=rw-
  0x48bf9fff - 0x48bfa011  →   "UNIT_HEALTH player" 
[+] In (0x4a4f0000-0x4b910000), permission=rw-
  0x4a59f930 - 0x4a59f960  →   "UNIT_HEALTH UNIT_HEALTH_FREQUENT UNIT_CONNECTION" 
  0x4a59f93c - 0x4a59f960  →   "UNIT_HEALTH_FREQUENT UNIT_CONNECTION" 
  0x4a59f9b0 - 0x4a59f9e7  →   "UNIT_HEALTH UNIT_HEALTH_FREQUENT UNIT_MAXHEALTH UN[...]" 
  0x4a59f9bc - 0x4a59f9f3  →   "UNIT_HEALTH_FREQUENT UNIT_MAXHEALTH UNIT_CONNECTIO[...]" 
  0x4a59fbd0 - 0x4a59fbf0  →   "UNIT_HEALTH UNIT_HEALTH_FREQUENT" 
  0x4a59fbdc - 0x4a59fbf0  →   "UNIT_HEALTH_FREQUENT" 
  0x4a59fcb0 - 0x4a59fce7  →   "UNIT_HEALTH UNIT_HEALTH_FREQUENT PLAYER_UPDATE_RES[...]" 
  0x4a59fcbc - 0x4a59fcf3  →   "UNIT_HEALTH_FREQUENT PLAYER_UPDATE_RESTING UNIT_CO[...]" 
  0x4a5a8490 - 0x4a5a84c7  →   "UNIT_HEALTH UNIT_HEALTH_FREQUENT UNIT_MAXHEALTH UN[...]" 
  0x4a5a849c - 0x4a5a84d3  →   "UNIT_HEALTH_FREQUENT UNIT_MAXHEALTH UNIT_CONNECTIO[...]" 
  0x4a5a84ec - 0x4a5a8523  →   "UNIT_HEALTH UNIT_HEALTH_FREQUENT UNIT_MAXHEALTH UN[...]" 
  0x4a5a84f8 - 0x4a5a8503  →   "UNIT_HEALTH[...]" 
  0x4a5ad106 - 0x4a5ad111  →   "UNIT_HEALTH[...]" 
  0x4a5ad112 - 0x4a5ad11d  →   "UNIT_HEALTH[...]" 
[+] In (0x4b990000-0x4f1d0000), permission=rw-
  0x4d5a7d9f - 0x4d5a7db1  →   "UNIT_HEALTH target" 
[+] In (0x4f3c0000-0x505e0000), permission=rw-
  0x4fc3c870 - 0x4fc3c89f  →   "UNIT_HEALTH UNIT_HEALTH_FREQUENT UNIT_MAXHEALTH" 
  0x4fc3c87c - 0x4fc3c89f  →   "UNIT_HEALTH_FREQUENT UNIT_MAXHEALTH" 
  0x4fc3cc30 - 0x4fc3cc50  →   "UNIT_HEALTH UNIT_HEALTH_FREQUENT" 
  0x4fc3cc3c - 0x4fc3cc50  →   "UNIT_HEALTH_FREQUENT" 
[+] In '/tmp/.wine-1000/server-802-19e35fe/anonmap.k0d46p (deleted)'(0x140000000-0x142910000), permission=r-x
  0x142559ec8 - 0x142559ed3  →   "UNIT_HEALTH" 
  0x142559ed8 - 0x142559eec  →   "UNIT_HEALTH_FREQUENT"

Particularly interesting is the last two lines; I think anonmap is something to do with virtual memory mapping and/or aslr?? I need to look into that

[+] In '/tmp/.wine-1000/server-802-19e35fe/anonmap.k0d46p (deleted)'(0x140000000-0x142910000), permission=r-x
  0x142559ec8 - 0x142559ed3  →   "UNIT_HEALTH" 
  0x142559ed8 - 0x142559eec  →   "UNIT_HEALTH_FREQUENT"

using scanmem to find health; I always find 3 addresses; probably one for current health, max health, and ???

[ 0]     35dbe948, 171 +      166e948,  misc, 9507, [I64 I32 I16 ]
[ 1]     35dd887c, 171 +      168887c,  misc, 9507, [I64 I32 I16 ]
[ 2]     35dd889c, 171 +      168889c,  misc, 9507, [I64 I32 I16 ]

The addresses I find interesting can be traced back to 3 separate modules or blocks of memory I see in /proc/PID/maps.

The 2 from GDB:
[+] In (0x30780000-0x32f00000), permission=rw-
0x31a76210 - 0x31a7621b → "UNIT_HEALTH"

[+] In '/tmp/.wine-1000/server-802-19e35fe/anonmap.k0d46p (deleted)'(0x140000000-0x142910000), permission=r-x
0x142559ec8 - 0x142559ed3 → "UNIT_HEALTH"

and the three addreses I get from scanmem are traced back to a single block of memory




I've had no luck finding pointers to any of these addresses and am unable to make breakpoints work because of the ant-debug which pauses the game. Thus far I'm stuck. I'm thinking of writing a quick tool to run a pointer scan in those 3 particular blocks of memory I think look interesting to maybe come up with something to go off but am unsure if that's even worth my time? Does WoW obscure pointers? I.e. packing data into them, compute pointers rather than store?

[Wontuse]

I was able to get injected, but still need to figure out to get execution inside the process.

I found this great guide on guided hacking; seriously anyone doing this on Linux go read it: https://guidedhacking.com/threads/li...l-guide.16411/

A couple key points:

1. This doesn't use the LD_PRELOAD "it is very easy to detect LD_PRELOAD. If you look at the file /proc/<pid>/environ, you can see LD_PRELOAD defined there with your library path parameter."
2. It uses ptrace to attach and hook the C standard library, libc
3. With ptrace I should be able to stop the entire process, including Warden, read/write what I want then resume

ptrace:
The ptrace() system call provides a means by which one process (the "tracer") may observe and control the execution of another process (the "tracee"), and examine and change the tracee's memory and registers. It is primarily used to implement breakpoint debugging and system call tracing.

***edit
It was a timing issue when doing my injection. Needed to be done during the login process whereas I was doing it at character screen. Looks like I'm in!

***edit edit
Question for those doing this under Windows:
I still need to find the equivalent of WoWClassic.exe base - from the threads I have read am I correct that those on Windows are using the base address for the "WoW.exe" process?
And if I understand correctly - the process is as follows: WoW.exe base + some offset -> get a reference to a pointer -> de-reference pointer and read value?

I ask because nothing of the sorts shows up under Linux.

[thateuler]

I was able to get injected, but still need to figure out to get execution inside the process.

You can hook endscene or present just like in windows. You can also build your own wine lib and just put your code directly in the lib, or put hook into your dll (.so) using dlsym(). You can also create your own pthread but be aware that creating a pthread from LD_PRELOAD or a library initializer won't work because the wine loader will just overwrite the entire process. You'll need to create your thread after that happens. I'm doing it from a present hook.

The ptrace() system call provides a means by which one process (the "tracer") may observe and control the execution of another process (the "tracee"), and examine and change the tracee's memory and registers. It is primarily used to implement breakpoint debugging and system call tracing.

/proc/<pid>/status will show the pid of the tracer when using ptrace. Both ptrace and LD_PRELOAD can be detected. IMO, the best way to avoid detection is to fly under the radar. Also, wow runs a thread with max suspend count. so any code to freeze all threads needs to take special care to maintain that counter.

I still need to find the equivalent of WoWClassic.exe base - from the threads I have read am I correct that those on Windows are using the base address for the "WoW.exe" process?
And if I understand correctly - the process is as follows: WoW.exe base + some offset -> get a reference to a pointer -> de-reference pointer and read value?

Wine doesn't do aslr. 64 bit binaries are always loaded at 0x140000000

[Wontuse]

You can hook endscene or present just like in windows. You can also build your own wine lib and just put your code directly in the lib, or put hook into your dll (.so) using dlsym(). You can also create your own pthread but be aware that creating a pthread from LD_PRELOAD or a library initializer won't work because the wine loader will just overwrite the entire process. You'll need to create your thread after that happens. I'm doing it from a present hook.

I am creating my own pthred from the SO I'm injecting by hooking libc. And I'm getting execution but the timing is important; i.e. I have to inject during the login process. Too soon and login process hangs, too late and my injected SO doesn't execute. There's still a big enough window that I can manually trigger my injection and get it to inject successfully.

/proc/<pid>/status will show the pid of the tracer when using ptrace. Both ptrace and LD_PRELOAD can be detected. IMO, the best way to avoid detection is to fly under the radar.

I looked into this after your comment and I'm guessing you are referring to TracerPid? The injection is bloody fast and then I detach it shows 0. To test, I put a sleep in before I detach and I can see TracerPid.

In which case... I think I could attach with a SIGSTOP wait for the process (including Warden I would imagine?) to completely stop, do my reads//writes and then detach again. The process would never have a chance to even know I was attached?

Also, wow runs a thread with max suspend count. so any code to freeze all threads needs to take special care to maintain that counter.

Good to know. I did notice I can attach GDB for about 10 seconds and detach without issue. A minute or two and the game never resumes after I detach.

Wine doesn't do aslr. 64 bit binaries are always loaded at 0x140000000

Again, thank you, good to know and should be extremely helpful when I get a chance to keep digging into things

[Wontuse]

*** disclaimer: I'm new to C++ and picked up RE a day before this post began. However, not new to SE but very new to low level stuff.

I'm tapping and asking for help.. I thought I had a basic understanding of offsets & pointers but they're kicking my ass. In exchange for working Linux injector I'm asking for help reading WoW objects on 39475 with C++ I feel like I'm having difficulty because I have no CE to go back and verify what I'm doing so everything is a shot in the dark.

Code I have tried:

uintptr_t BaseAddress   = 0x140000000;
uintptr_t ObjectManager = BaseAddress + 0x2D657B8;
long ObjectManagerPtr   = *reinterpret_cast<long *>(ObjectManager);]

long FirstObjectPtr = 0;
if (ObjectManagerPtr != 0)
{
    FirstObjectPtr = *reinterpret_cast<long *>(ObjectManagerPtr + 0x18);
}

long FirstObjectType = -1;
if (FirstObjectPtr != 0)
{
    FirstObjectType = *reinterpret_cast<long *>(FirstObjectPtr + 0x20);
}

Output I am seeing (long // hex):

ObjectManager:    5416310712  0x142d657b8
ObjectManagerPtr: 744050992   0x2c595130
FirstObjectPtr:   868024592   0x33bd0110
FirstObjectType:  12884902145 0x300000101

I've tried 100 different variations of it and can never get what I think is an expected WoW Object "Type".
I've tried a few other WoW Object offsets, like X//Y and can watch the value change... but the values I see are something in the range of 1-3.xxxxxxxxe^x

Anyways... on to the promised Linux injector, compile instructions are commented at the bottom.

This injector hijacks the libc dlopen and does the following:

1. Allocate memory in WoW process through mmap
2. Inject a single instruction to make syscall
3. Load the external lib on the process w/ dlopen
4. Restore the hijacked instruction pointer

injector.cpp
*** DELETED; PM if interested


mylib.cpp
*** DELETED; PM if interested

**Bonus if you want to point me in a direction to finding these offsets on my own through IDA, Ghidra, or something else.

[ChrisIsMe]

Why even bother, you deal with all the annoyance of windows binary obfuscation and anti-manipulation tactics; while running the game in a easily recognizable way, and probably are easily detectable. The code you posted is not even attempting to hide the arbitrary code inside of the wow binary, DLOPEN exposes your dylib in multiple places, really you can see from `lsof`

It's fun in theory, but this is really not a great idea at all, like people think it is.

Feel free to do it to learn yourself, but expecting to release anything around this will just result in bans like normal.

[Wontuse]

Why even bother

to learn...

you deal with all the annoyance of windows binary obfuscation and anti-manipulation tactics; while running the game in a easily recognizable way, and probably are easily detectable. The code you posted is not even attempting to hide the arbitrary code inside of the wow binary, DLOPEN exposes your dylib in multiple places, really you can see from `lsof`

Do not plenty of applications do injection for perfectly valid reasons? So long as I just do reads I'd imagine I'd be fine.

Feel free to do it to learn yourself

Thank you.. that's what I'm doing

but expecting to release anything around this will just result in bans like normal.

No intentions of releasing anything. Only trying to share knowledge and learn.

[ChrisIsMe]

to learn...


Do not plenty of applications do injection for perfectly valid reasons? So long as I just do reads I'd imagine I'd be fine.

How many 'perfectly valid applications' hijack a processes thread and invoke dlopen? Probably none?

The game loads the intended libraries itself, from paths that it knows. Applications have the option to use DYLD_INSERT_LIBRARIES and LD_PRELOAD, not needing to hijack the games threads.

It's unlikely, however, that the wow developers are paying any attention to dlopen or wine syscalls, but the point still stands.

[_chase]

@Wontuse

Re: your question about figuring out the object manager search for the string "gmvision" or really any of the strings shown in the picture and locate the function I added as a picture.
I've annotated some of the simple parts of the function for you, and will leave it as an exercise for you to figure out how to implement it code wise. Also, everywhere you used a long in your original snippet is wrong

Hint: when trying to read the object's type pay close attention to

v12 = dword_14257E160[*(unsigned __int8 *)(currentObject + 0x20)];

... if you were building a game and only had 12 different object types, would you store the type as a long or perhaps something more compact...

Additionally, please use google to search for your questions prior to making a thread/post about them. Lots of questions (like about the object manager) have been answered a bazillion times so you're not going to win any popularity contests asking easily searchable things. You can use google/duckduckgo and do a search like "site: ownedcore.com object manager" to find helpful threads.

[Wontuse]

Still going at it. I've been able to dump the game from memory and load it into IDA. Currently trying to figure out how to find patterns and offsets on my own. I've been reading Secrets of Reverse Engineering, learning IDA, and C++

I still suck at C++

webp_net_resizeimage.jpg

[ChrisIsMe]

Still going at it. I've been able to dump the game from memory and load it into IDA. Currently trying to figure out how to find patterns and offsets on my own. I've been reading Secrets of Reverse Engineering, learning IDA, and C++

I still suck at C++

webp_net_resizeimage.jpg

Easiest one to get you really started is `gmvision` to find the object manager and how to iterate it.

Or start messing with the `Script_` methods (LuaC methods) if you want to get a better understanding of how a lot of the game works.

[Hareturtle]

I feel like I'm having difficulty because I have no CE to go back and verify what I'm doing so everything is a shot in the dark.

For what it's worth, you can run CheatEngine (assuming that's what you mean by CE) on Linux. It works using Wine and can hook into other Wine processes as long as it's running in the same wineprefix. If you want to use it to hook into native Linux processes you have to use ceserver.

Beyond CE there are of course native debuggers. Personally I use edb (Evan's Debugger) which is a lot like OllyDBG, because I never bothered to learn the TUI of gdb (edb is just a front-end for it anyway I think). Ghidra also has debugging capabilities these days with gdb-server I believe.