[Linux] simple injection with LD_PRELOAD

[Sednogmah]

Tonight I've played with code injection on Linux and want to share what I've learned so far. As rootguy suggested the LD_PRELOAD path, I decided to give it a try.

A nice introduction to this kind of hook can be found in this old Linux Journal article: Modifying a Dynamic Library Without Changing the Source Code. LD_PRELOAD is basically an environment variable that tells the DLL loader to load your library before any DLLs that the binary's linked to. This allows you to hook into any library function that's used by the binary, in our case WINE.

Updates:
- Added 2. glXSwapBuffers() hook.
- Added link to another thread

1. Simple glClear() hook
For my first and successful test, I've chosen the OpenGL function glClear(). It's surprisingly simple and works well enough to demonstrate LD_PRELOAD. Beware that WoW calls glClear() multiple times per frame though. I recommend to use the glXSwapBuffers() hook which is described below.

/* 
 * eve.c: Simple LD_PRELOAD injection for OpenGL applications.
 * 
 * gcc -std=c99 -Wall -Werror -m32 -O0 -fpic -shared -ldl -lGL -o eve.so eve.c
 *
 * How to use with WINE:
 *   wineserver -k
 *   export LD_PRELOAD=/path/to/eve.so
 *   wine Wow.exe
 *
 */

/* These libraries are necessary for the hook */
#include <dlfcn.h>
#include <stdlib.h>
#include <GL/gl.h>

/* "Injected" stuff */
#include <stdio.h>
#include <stdint.h>
#include <string.h>
void doevil();

/* Hook function */
void glClear(GLbitfield mask) {
	static void (*lib_glClear)(GLbitfield mask) = NULL;
	void* handle;
	char* errorstr;

	if(!lib_glClear) {
		/* Load real libGL */
		handle = dlopen("/usr/lib32/libGL.so", RTLD_LAZY);
		if(!handle) {
			fputs(dlerror(), stderr);
			exit(1);
		}

		/* Fetch pointer of real glClear() func */
		lib_glClear = dlsym(handle, "glClear");
		if( (errorstr = dlerror()) != NULL ) {
			fprintf(stderr, "dlsym fail: %s\n", errorstr);
			exit(1);
		}
	}

	/* Woot */
	doevil();

	/* Call real glClear() */
	lib_glClear(mask);
}

/* Here be dragons */
void doevil() {
	static int framecnt = 0;
	framecnt++;

	uint32_t read_uint( uint32_t addr ) { return *((uint32_t*) addr); }
	float read_float( uint32_t addr ) { return *((float*) addr); }

	// calling game functions works too! (WoW 3.3.0a)
	static int (*ClntObjMgrGetActivePlayer)() = (void*) 0x0047A2B0;

	printf("doevil(), frame %d... ", framecnt);
	if( ClntObjMgrGetActivePlayer() == 0 ) {
		printf("not logged in.\n");
	} else {
		char p_name[16];
		uint32_t p_base;
		float p_x, p_y;
		
		strncpy( p_name, (char*) 0x00C923F8, 16 );
		if( read_uint(0x00CF7C00) ) {
			p_base = read_uint(read_uint( read_uint( 0x00CF7C00 ) + 0x34 ) + 0x24);
			p_x    = read_float( p_base + 0x798 );
			p_y    = read_float( p_base + 0x79C );
		}

		printf("p_name: %s, x/y: %.2f/%.2f\n", p_name, p_x, p_y);
	}
}

Example output:

...
doevil(), frame 1037... not logged in.
doevil(), frame 1038... not logged in.
doevil(), frame 1039... p_name: Somedude, x/y: -14444.90/464.05
doevil(), frame 1040... p_name: Somedude, x/y: -14444.90/464.05
doevil(), frame 1041... p_name: Somedude, x/y: -14444.90/464.05
...

Enjoy.

2. glXSwapBuffers() hook
void glXSwapBuffers(Display *dpy, GLXDrawable drawable) is probably the best OpenGL method to hook because it gets called exactly once per frame and WoW's engine is in a consistent state at that point. However there is one downside: You need to patch WINE in order to hook it with LD_PRELOAD. Credits to RoKFenris for supplying that patch.

Patch:

diff -Nru wine-1.1.39.orig/dlls/winex11.drv/opengl.c wine-1.1.39/dlls/winex11.drv/opengl.c
--- wine-1.1.39.orig/dlls/winex11.drv/opengl.c	2010-02-27 02:21:02.973526893 +0100
+++ wine-1.1.39/dlls/winex11.drv/opengl.c	2010-02-27 02:27:11.231401387 +0100
@@ -412,7 +412,7 @@
         return FALSE;
     }
 
-    pglXGetProcAddressARB = wine_dlsym(opengl_handle, "glXGetProcAddressARB", NULL, 0);
+    pglXGetProcAddressARB = wine_dlsym(RTLD_DEFAULT, "glXGetProcAddressARB", NULL, 0);
     if (pglXGetProcAddressARB == NULL) {
         ERR("Could not find glXGetProcAddressARB in libGL, disabling OpenGL.\n");
         goto failed;

If you're not familiar with the OpenGL extension mechanism: applications that wish to use an extension function call void* glXGetProcAddressARB(const GLubyte *procName) with the name of the desired extension as a parameter and get a pointer to the function in return. In order to hook glXSwapBuffers, you actually hook glXGetProcAddressARB, and return the pointer to your function as soon as procName equals "glXSwapBuffers".

hook-glx.c:

#include "hook-glx.h"

#define _GNU_SOURCE
#include <dlfcn.h>

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#include <GL/gl.h>
#include <GL/glx.h>

void hookfunc();

/* glXSwapBuffers() is very appropriate as an "end scene" hook because
 * WoW calls it exactly once, at the end of each frame.
 *
 * Unfortunately WINE needs to be patched to allow hooking this via
 * LD_PRELOAD.
 *
 * 1) Instead of using the default RTLD loader, WINE retrieves the address
 *    for glXGetProcAddressARB directly from the OpenGL library.
 *    This is done to enable binary compatibility to systems with or without
 *    OpenGL.
 *
 *    Solution: patch WINE to use the default loader
 *
 * 2) WINE gets the pointers to glx functions via glXGetProcAddressARB
 *    
 *    => I'm hooking glXGetProcAddressARB and return my own
 *       pointer to glXSwapBuffers.
 *
 */

typedef __GLXextFuncPtr (*fp_glXGetProcAddressARB) (const GLubyte*);
typedef __GLXextFuncPtr (*fp_glXSwapBuffers)(Display* dpy, GLXDrawable drawable);

// glXSwapBuffers
fp_glXSwapBuffers real_glXSwapBuffers;

void my_glXSwapBuffers(Display* dpy, GLXDrawable drawable) {
	real_glXSwapBuffers(dpy, drawable);
	hookfunc();
}

// glXGetProcAddressARB
__GLXextFuncPtr glXGetProcAddressARB (const GLubyte* procName)
{
	__GLXextFuncPtr result;
	printf("* hook-glx.c: glXGetProcAddressARB(\"%s\")\n", procName);

	// Fetch pointer of actual glXGetProcAddressARB() function
	static fp_glXGetProcAddressARB lib_getprocaddr = NULL;
	if(!lib_getprocaddr)
	{
		char* errorstr;
		lib_getprocaddr = (fp_glXGetProcAddressARB) 
			dlsym(RTLD_NEXT, "glXGetProcAddressARB");
		if( (errorstr = dlerror()) != NULL )
		{
			fprintf(stderr, "dlsym fail: %s\n", errorstr);
			exit(1);
		}
	}
	result = lib_getprocaddr(procName);

	// Return our own function pointers
	if( strcmp( (const char*) procName, "glXSwapBuffers" ) == 0 )
	{
		real_glXSwapBuffers = (fp_glXSwapBuffers) result;
		return (__GLXextFuncPtr) my_glXSwapBuffers;
	}
	
	// Return default function pointer
	return lib_getprocaddr(procName);
}

hook-glx.h:

#pragma once
// http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html

/* In your C++ source:
 *
 *	void hookfunc() { ... }
 *
 */

#ifdef __cplusplus

extern "C" void hookfunc();

#else

void hookfunc();

#endif

=> Link hook-glx.c with the rest of your code and define void hookfunc() in another .c or .cpp file.


SEE ALSO:
http://www.ownedcore.com/forums/worl...hing-wine.html ([Linux] LD_PRELOAD injection without patching Wine)

[flo8464]

+rep for using Linux!

[audible83]

mega +rep for doing linux

I'm actually just installing all bits and parts myself now.

[corderoy]

A little while ago I was experimenting with detouring dll calls with custom WINE source build but this method is far superior, +rep from me as well

[Sednogmah]

Thanks Obviously this is just a minimal "proof of concept". My next step would be to create an interface that allows you to comfortably modify your code without restarting WoW. Off the top of my head, I'd make a small stub ("Eve") that gets preloaded when WoW starts. Eve would have:

* D-Bus inter-process communication
* Dynamic library loader to update the injected code

As a long-term goal I'd like to have all the actual logic outside of WoW, talking to the "Eve" stub via D-Bus and maybe a 2nd more efficient IPC system like shared memory or just a simple named pipe.

[RoKFenris]

If you want to hook glx functions (i.e., the ones used for almost all texture and 3d data manipulation and drawing), you will need this:

diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c
index 4e4a3a0..0ad8f42 100644
--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -375,7 +375,7 @@ static BOOL has_opengl(void)
         return FALSE;
     }

-    pglXGetProcAddressARB = wine_dlsym(opengl_handle, "glXGetProcAddressARB", NULL, 0);
+    pglXGetProcAddressARB = wine_dlsym(RTLD_DEFAULT, "glXGetProcAddressARB", NULL, 0);
     if (pglXGetProcAddressARB == NULL) {
         ERR("Could not find glXGetProcAddressARB in libGL, disabling OpenGL.\n");
         goto failed;

(For those that don't know, this is the content of a diff file for the Wine source code, you apply from the wine source base directory with )
patch -p1 <glx_dlsym.diff )

The explanation being, you have to hook glXGetProcAddressARB in order to return the address to your own functions, but Wine usually loads it directly from the opengl library itself, disregarding loading order.

[Sednogmah]

Thanks a lot for the hint & patch, RoKFenris! Even though I don't plan to interact with OpenGL yet, it might become useful soon.

[Unkn0wn0x]

If it works thats actually what i was looking for. Well lets try to convert my projects to Linux so i can switch finally. Thanks =)

+ big fat rep

[amadmonk]

How well does Wine support .Net?

I know about Mono, but what I mean is that at least in theory, Wine should be able to load and run mscoree.dll (the main .Net bin). If that works, then in theory my code should be immediately portable.

Of course it should be noted, that this code isn't inherently superior to doing dll injection on Windows, nor is it inherently safer (since it still "injects" a dll which I'm presuming would show up in the loaded module list). In reality, though, very few people (as a percent) run WoW on linux, so I doubt you'd pose a big threat target for Warden (which is a good thing).

[Sednogmah]

How well does Wine support .Net?

I know about Mono, but what I mean is that at least in theory, Wine should be able to load and run mscoree.dll (the main .Net bin). If that works, then in theory my code should be immediately portable.

WINE's support for the MS .Net distribution is mediocre. I've never used .NET as a developer but have installed the MS .NET framework in WINE for some applications that need it, like the CurseClient. Olders versions such as .NET 2.0 have worked reasonably well for me as a user. To find out more about the current state of MS .NET in WINE, you can check out the official application compatibility database: WineHQ - .NET Framework
Nevertheless you can always inject a native Mono, Python, Ruby or whatever interpreter into WINE. Maybe even PHP if you're either adventurous or a masochist!

Of course it should be noted, that this code isn't inherently superior to doing dll injection on Windows, nor is it inherently safer (since it still "injects" a dll which I'm presuming would show up in the loaded module list). In reality, though, very few people (as a percent) run WoW on linux, so I doubt you'd pose a big threat target for Warden (which is a good thing).

Yes, I am fully aware that this solution is not inherently safer. However the injected (linux) library does not show up from the Win32 EXE's point of view. This module is not a Win32 DLL loaded into Wow.exe but an "ELF shared object" injected into WINE's preloader. The basic idea of WINE is presenting a fake windows environment to a Win32 program, including all the system DLLs, and translating the program's calls to native shared objects. WINE doesn't present its own s.o. dependencies to the guest application. Think of it like this: Native library <--X--> WINE <-> Win32 EXE, where X is the aforementioned injection.

$ wine pv -m Wow.exe
  Module information for  'Wow.exe'(8)
  MODULE          BASE     SIZE     PATH
Wow.exe           400000 14471168 C:\Testing-WoW\Wow.exe
ntdll.dll       7bc10000   667648 C:\windows\system32\ntdll.dll
KERNEL32.dll    7b820000  1372160 C:\windows\system32\KERNEL32.dll
opengl32.dll    7ec20000   557056 C:\windows\system32\opengl32.dll
user32.dll      7eac0000  1142784 C:\windows\system32\user32.dll
gdi32.dll       7ea20000   520192 C:\windows\system32\gdi32.dll
advapi32.dll    7e9d0000   286720 C:\windows\system32\advapi32.dll
rpcrt4.dll      7e960000   389120 C:\windows\system32\rpcrt4.dll
version.dll     7ec00000    49152 C:\windows\system32\version.dll
lz32.dll        7e940000    65536 C:\windows\system32\lz32.dll
imm32.dll       7e920000   118784 C:\windows\system32\imm32.dll
wininet.dll     7e8d0000   315392 C:\windows\system32\wininet.dll
mpr.dll         7e880000    86016 C:\windows\system32\mpr.dll
shlwapi.dll     70bd0000   413696 C:\windows\system32\shlwapi.dll
msvcrt.dll      7e810000   380928 C:\windows\system32\msvcrt.dll
shell32.dll     7e680000  1576960 C:\windows\system32\shell32.dll
comctl32.dll    7e5b0000   770048 C:\windows\system32\comctl32.dll
ws2_32.dll      7e580000   131072 C:\windows\system32\ws2_32.dll
dinput8.dll     7e560000    94208 C:\windows\system32\dinput8.dll
dinput.dll      7e530000   188416 C:\windows\system32\dinput.dll
ole32.dll       7e450000   876544 C:\windows\system32\ole32.dll
DivxDecoder.dll 10000000   430080 C:\Testing-WoW\DivxDecoder.dll
winmm.dll       7e3b0000   483328 C:\windows\system32\winmm.dll
msacm32.dll     7e380000   106496 C:\windows\system32\msacm32.dll
setupapi.dll    7e330000   282624 C:\windows\system32\setupapi.dll
winspool.drv    7e2f0000   188416 C:\windows\system32\winspool.drv
hid.dll         7e2e0000    36864 C:\windows\system32\hid.dll
system.drv16    7e2d0000    20480 C:\windows\system32\system.drv16
gdi.exe16       7e2a0000   135168 C:\windows\system32\gdi.exe16
winex11.drv     7e0e0000   598016 C:\windows\system32\winex11.drv
uxtheme.dll     7e010000   196608 C:\windows\system32\uxtheme.dll
winealsa.drv    7df90000   159744 C:\windows\system32\winealsa.drv
msacm32.drv     7df60000    90112 C:\windows\system32\msacm32.drv
midimap.dll     7da10000    57344 C:\windows\system32\midimap.dll
localspl.dll    7d9f0000   102400 C:\windows\system32\localspl.dll
spoolss.dll     7d9e0000    40960 C:\windows\system32\spoolss.dll
dsound.dll      7d6d0000   241664 C:\windows\system32\dsound.dll

No "eve.so" in sight. Native Linux processes are invisible to the Win32 guest application as well.

Of course the hack is definitely detectable, as its running in the same process space as Wow.exe. As you said though, few people play WoW on Linux and there's not even a single public bot for Linux. Warden Guy has more important issues to deal with.

[amadmonk]

No "eve.so" in sight. Native Linux processes are invisible to the Win32 guest application as well.

Of course the hack is definitely detectable, as its running in the same process space as Wow.exe. As you said though, few people play WoW on Linux and there's not even a single public bot for Linux. Warden Guy has more important issues to deal with.

Hah, true that. Of the couple thousand people (out of how many million?) who run WoW on Linux, how many are botters? And how many of THOSE are commercial botters (the real target)?

I didn't realize that using the LD_PRELOAD method actually allows you to inject code at a Wine-only level (which is what I think you're indicating). That's pretty cool, since it's built-in module list spoofing. Of course... a windows DLL != an ELF portable bin, so I'd have to relearn everything I know to go down this road, but it's still pretty cool

[RoKFenris]

Just saw it, the OP is manually loading the OpenGL library and using it's handle to find the glClear function pointer; you shouldn't need to do this. By the time your preloaded fake glClear function is called the program should have already loaded the OpenGL library; you can just use RTLD_NEXT as dlsym's handle. In short, you should be able to change:

	if(!lib_glClear) {
		/* Load real libGL */
		handle = dlopen("/usr/lib32/libGL.so", RTLD_LAZY);
		if(!handle) {
			fputs(dlerror(), stderr);
			exit(1);
		}

		/* Fetch pointer of real glClear() func */
		lib_glClear = dlsym(handle, "glClear");
		if( (errorstr = dlerror()) != NULL ) {
			fprintf(stderr, "dlsym fail: %s\n", errorstr);
			exit(1);
		}
	}

into

	if(!lib_glClear) {
		/* Fetch pointer of real glClear() func */
		lib_glClear = dlsym(RTLD_NEXT, "glClear");
		if( (errorstr = dlerror()) != NULL ) {
			fprintf(stderr, "dlsym fail: %s\n", errorstr);
			exit(1);
		}
	}

You also don't need to link against the OpenGL library; you can drop that -lGL from your compile command.
Which means you don't even need to know from which library the function is loaded, just it's name, parameters, and the header that defines it

I didn't realize that using the LD_PRELOAD method actually allows you to inject code at a Wine-only level (which is what I think you're indicating). That's pretty cool, since it's built-in module list spoofing. Of course... a windows DLL != an ELF portable bin, so I'd have to relearn everything I know to go down this road, but it's still pretty cool

LD_PRELOAD is roughly equivalent to putting a fake DLL into the program's directory. Most of the time it works quite well, although there are limitations - you must load the library when starting the program, and you can only preload functions that are loaded from external libraries (and those libraries must be Linux ones in the case of LD_PRELOAD). Of course you can combine preloaded libraries with conventional hooking if you need to hook a function that is not from a Linux library, but by doing that you are basically giving up most of the advantages of using LD_PRELOAD.

BTW, detecting the existence of the preloaded library from inside a process running under Wine should be quite easy (AFAIK wine doesn't block the running app from issuing Linux system calls, which can be readily used to gleam information about the Linux system itself). The real question is, will Warden ever bother doing it? They have way easier and more numerous targets among the Windows using crowd. Besides, legitimate uses for preloading are aplenty, so detecting a preloaded library is just a first step for them.

As for having to re-learn everything, LD_PRELOAD do have the advantage of being absurdly simple to use; mostly you just call dlsym to obtain the function pointer (and cache it if you don't want to do a library function lookup every call), do whatever you want to do and then call the original function. I learned how to do it by looking at the source code of "libkeepalive", a small preloaded library that modifies some networking behavior, whose source code is about 2KB in size.

[amadmonk]

I'll definitely have to play with this. I don't have a box to sacrifice to the Ubuntu gods at the moment, but I can set up a Virtualbox em on one of my beefier Windows machines; I think they've got pretty good OGL support in VBox nowadays to run WoW...

[pendra]

You can also use ptrace() in linux to do memory inspection on the Wow.exe process from outside of windows. This way you can SIGSTOP the entire wine environment, including warden, read whatever you want from memory, then resume the process. No way warden is going to detect that, as there is no API for them to even inquire about what is happening outside of wine.

[audible83]

One question that pops up to my mind.

Why is blizz checking wether we are running wow under linux? API_IsLinuxClient