Linux/FreeBSD memory editing

[igorzarew]

Hi,

being a bit late to the game (WoW has been out for quite some time now), I'm not sure if it's worth the effort to play around with it but on the other hand, a lot has been learned about WoW's structures and thus it will be way easier to get something started.

I'm curious why there seems to be little activity in the free software area, i.e. Linux or FreeBSD.

Free operating systems make it easy as a pie to stay under the radar. For example, the grsecurity kernel patchset for Linux allows you to hide processes from certain users on the kernel level. If Blizzard even bothered to make Warden aware of WINE, they'd still have no chance to discover your nasty bits of software.

The free world has good development tools as well, take GDB for example. Of course, free operatings systems don't have many tools made specifically for reverse engineering because naturally you don't usually need to RE much when you've got the source code of everything.

Anyway, are there any Linux REs out there? Do you use (wine-)gdb or rather whip up your own memory analysis tools? Have you ever traced WoW & Warden to find out if it actually is aware of running in WINE?

Greetings,
Igor (not a native speaker)

P.S.: This thread _is not_ about which OS is better.

[Cypher]

1. Its no easier to stay "under the radar" in Wine than it is under Windows. A kernel patchset is practically no different to a 'rootkit', they're just implemented differently.
2. Blizzard IS aware of Wine, Warden already checks to see if the user is running under a Linux based client via calling GPA on a Linux-only API and seeing if Wine handles it. There is also an IsLinux function in the LUA API.
3. GDB? Horrible compared to OllyDbg, IDA, etc.
4. Windows is the primary platform for WoW, so naturally most activity will be there, regardless of the merits of other OSes.
5. You'll find that theres no need to differentiate between Wine-based reversing and Windows-based reversing because afaik if you can get your hack running under Wine properly all the memory addresses in WoW.exe should be loaded in the same place in memory.

[argh44z]

I'm sure there is a few Linux/BSD users, but when speaking in the context of WoW, without a native Linux binary, the API's and programs that you are likely going deal with are win32 ones-- running through Wine, so you're not going to find much Linux/BSD-specific discussion as the binary is the same.

Ollydbg runs fine under wine... It just tends to crash/freeze once in a while and /occasionally/ has weird display quirks, but works well for the most part.

My only real piece of advice is that if you venture into the world of injecting dll's into WoW, is to compile said dlls with Visual C++ instead of any gcc/mingw variant. I tried to do the latter initially but ran into small but very annoying differences in terms of thevtable, for example (since this is not mandated by any sort of C++ standard). Also, it's very annoying to switch between at&t-style asm (which is default in gcc) and intel-style asm. You can turn intel-style asm on in gcc, but I don't think the syntax is as natural as in Visual C++.

[s1ay]

I think he wants to keep his hacking on the other side of WINE, like me. Also you dont even need to hide the process if you build a linux program. WINE is one way. In but not out. Yes it dose know your in WINE though. Personaly I just want to build auto login and such, but I havent started yet. Probably looking for code example bing it's a bit weird. (ps -A to get PID, then look around in /proc/PID/. You might get something. Its a place to start, and where I"m at)

[RoKFenris]

If you want to do it the linux way, look for one of the rare Linux cheat engines (such as Scanmem) and get the source code. It should have everything needed to make a completely OOP hack (the addresses will be the same as for Windows). I believe injecting code should work the same way as in Windows, with the caveat that in this case I don't think Wine will offer you any extra protection over doing it under Windows.
And, of course, you could build your program INSIDE some essential Linux piece of software, such as one of the essential Wine drivers, as a module for X, or as a kernel module. Doing it as part of Wine would essentially put your code inside WoW's memory space without injecting - you could basically hijack with ease any windows API function and access WoW's memory with pointers, and the ability to debug all Windows API function calls should not be understated. The kernel module way should make you basically have full privileges over the executing process and open some very efficient ways to interact with WoW's memory.

[Cypher]

If you want to do it the linux way, look for one of the rare Linux cheat engines (such as Scanmem) and get the source code. It should have everything needed to make a completely OOP hack (the addresses will be the same as for Windows). I believe injecting code should work the same way as in Windows, with the caveat that in this case I don't think Wine will offer you any extra protection over doing it under Windows.
And, of course, you could build your program INSIDE some essential Linux piece of software, such as one of the essential Wine drivers, as a module for X, or as a kernel module. Doing it as part of Wine would essentially put your code inside WoW's memory space without injecting - you could basically hijack with ease any windows API function and access WoW's memory with pointers, and the ability to debug all Windows API function calls should not be understated. The kernel module way should make you basically have full privileges over the executing process and open some very efficient ways to interact with WoW's memory.

Windows cheats run fine under Wine, or at least, mine did last time I checked it. You don't need to "do it as part of wine", or "hijack with ease any windows API function", or "access WoWs memory with pointers". All that is very easily available under windows. Its not "very efficient", infact its LESS efficient because you're effectively screwing with the kernel when a much more safe way would just be with a DLL. You get zero extra security from using Wine than you would with Windows. If you really wanted to hook into the kernel under Windows you could just use a driver. But both scenarios suffer from the same problem in that they're not SMP-safe.

[Xarg0]

building an elf executable to cheat within wow is faar more complicated than simply using a wine compatible windows compiler (mingw, VisualStuido and Cygwin compiled programms run best with wine).

[s1ay]

If you want to do it the linux way, look for one of the rare Linux cheat engines (such as Scanmem) and get the source code. It should have everything needed to make a completely OOP hack (the addresses will be the same as for Windows). I believe injecting code should work the same way as in Windows, with the caveat that in this case I don't think Wine will offer you any extra protection over doing it under Windows.
And, of course, you could build your program INSIDE some essential Linux piece of software, such as one of the essential Wine drivers, as a module for X, or as a kernel module. Doing it as part of Wine would essentially put your code inside WoW's memory space without injecting - you could basically hijack with ease any windows API function and access WoW's memory with pointers, and the ability to debug all Windows API function calls should not be understated. The kernel module way should make you basically have full privileges over the executing process and open some very efficient ways to interact with WoW's memory.

As far as editing it goes. It'll be just as dangerous. But creating a bot would'nt be as big a problem with warden.

Read memory and do calc's native in an ELF binary. And yes it could get nasty. But, it could be a great bot. Make fake inputs in /dev/ and hack up an xorg config and it should be invisible to warden. CTRL+ALT+F8 could swap to the game and such.

[RoKFenris]

Windows cheats run fine under Wine, or at least, mine did last time I checked it. You don't need to "do it as part of wine", or "hijack with ease any windows API function", or "access WoWs memory with pointers". All that is very easily available under windows. Its not "very efficient", infact its LESS efficient because you're effectively screwing with the kernel when a much more safe way would just be with a DLL. You get zero extra security from using Wine than you would with Windows. If you really wanted to hook into the kernel under Windows you could just use a driver. But both scenarios suffer from the same problem in that they're not SMP-safe.

Don't take me wrong, my mail was not addressed to Windows using people, but to people that use Linux and might want to hack WoW. For someone that already knows his way about Wine or kernel modules but don't yet knows about code caving, injecting, etc, doing at least some parts of the bot inside a wine or kernel module could be significantly easier than using the usual methods (even though code caving, injecting, etc, should be possible from a Linux hack).

BTW, a Linux kernel module is conceptually almost the same as a Windows driver. I was not talking about doing kernel patches, making your kernel specialized in interfacing with WoW don't seen to be a sensible way to work, but a kernel module, being something reasonabily easy to write and most Linux distributions having tools to load and unload modules at will, is something much more interesting.

Sure, for the most part Windows cheats work, although because of Wine's implementation details some kinds of cheats (specially those that do heavy OOP reading or writing) could be slower - the common Linux function to read other process's memory, and the one used inside Wine's implementation of OOP reading/writing, seems to be quite slow. And I do believe there are some functions used in some cheats that are not implemented in Wine (if I recall correctly, the sample object dumper that finds the objMgr using the TLS won't work under Wine, for example).
If you are going to run your code under Linux anyway, there are some specialized memory reading/writing functions that can make quite a difference in speed, bringing the performance of a hack in userspace to what I believe is the same as it would be under Windows.

Given what is known about the current warden, I believe there is only one situation where doing something under Linux would be safer: if that hypothetical Linux hack didn't inject anything and became so widely used Blizzard started noticing it. This is unlikely at least. In most other situations doing a hack under Linux should not make you safer - unless Warden's capabilities change significantly, developers should not change to Linux if they just want safety against Warden.

building an elf executable to cheat within wow is faar more complicated than simply using a wine compatible windows compiler (mingw, VisualStuido and Cygwin compiled programms run best with wine).

Not really, when running under Wine Wow behaves as a common elf executable, with exactly the same addresses and offsets it has running under Windows. I would say doing a cheat as an elf executable is the same difficulty as doing it as a windows one.
Of course, if you have a long experience with PE executables but have yet to learn about ELF executables, doig it under windows would be easier to you. But the opposite is also true.

But, it could be a great bot. Make fake inputs in /dev/ and hack up an xorg config and it should be invisible to warden. CTRL+ALT+F8 could swap to the game and such.

You don't even need this. Wine treats every input as if it originated from the hardware, you can just use XSendEvent() and WoW (and Warden) should never notice it was not from a real hardware.
Of course, faking a piece of hardware (specially if your kernel has the UDev module loaded, as most today have) is a piece of cake, although making sure the event went to the WoW process when you are actively interacting with other programs could be an interesting problem