Thread: So... What about UrbanTerror 4.1 for mac?

Share This Thread!

• Share on Facebook

So, anybody develop a hack for UrT 4.1 for mac yet? I've tried to compile UrTH for mac, but UrT itself won't compile.

Indeed I have, silly. Check the iTerror sticky at the top. On the second or 3rd page oughta be the latest update, which makes the GUID spoofer random and includes support for ioUrT 4.1.

--Macpunk

I am in progress of porting urth to windows.
I'm trying to get rid of all the asm code, it should be cross-platform then, and i've already got the 'base hook' including all compiler options and otherwise platform dependent functions, i only lack time ;-)
Supporting Mac too would be great.

But i don't have a Mac, nor will i buy one.
It would be limited to Mac OS >= X, because you need the unix tools to 'LD_Preload' (i think the name of LD_Preload is different).

To do it, i would need the following info:

1. OP-code (Shellcode) for JMP REL (only JMP) and address size data type if you use PowerPC architecture (you can get it with GDB, google a little bit for shellcode tutorials)
for IA32-80x86 i already have them:
#define JMP_OPCODE 0xE9
#define OPCODE_LENGTH 1
#define DATATYPE_ADDRESS long

2. The file format: does Urban Terror on Mac use ELF?
3. The Mac OSX console command for clear screen (is 'reset' available, or do i have to use 'clear')
4. The location of the current process in the proc file system:
does it use "/proc/curproc/file"
or does it use "/proc/self/exe"
(since curproc is BSD and MacOSX is FreeBSD-based, i suppose it is curproc)
5. Mac OSX pagesize and pagemask:
respectively the function to get the pagesize (does sysconf(_SC_PAGESIZE) exist? Should get you 4096 on Intel x86)
6. Does the 'mprotect' function exist on OS X? Or does it have an own API function for this like windows?
(man mprotect should help)
7. To use the new syscall hook from h1web, does OSX support Posix threads?
(try to compile: http://www.nixcoders.org/forum/index.php?showtopic=1160 and look at the error messages)
8. The adjustments i have to make to the makefile if Mac needs additional compile options...

Merh, you're better off starting a different clienthook rather than trying to support OS X using an existing hack.

However, OS X uses a specific file format called Mach-O. "clear" writes x amount of lines to the terminal in order to make it look "cleared"(blank), and "reset" is a link to /sw/bin/tset. /proc doesn't exist on OS X. Looks like pagesize is 0x1000, and pagemask 0x1000 - 1 on PowerPC at least. All those syscalls work on OS X, though they may be broken or work differently(like ptrace()), so mprotect does exist(haven't actually tried using it myself though.) Mac OS X has pthreads. I dunno bout your makefile.

But seriously...I wouldn't even recommend trying to support OS X with Linux and Windows in the same hack, just for your sanity. Reason is, OS X runs on both Intel and PowerPC. These architectures differ greatly in their instruction sets. One's LE and the other's BE. PPC is RISC, and Intel is CISC, iirc. OS X also supports both 32 and 64 bit processors(at least on PPC), and the binary format changes depending on what system it's been built for. LD_PRELOAD doesn't even exist, and the "analogous" environment variables for the dynamic linker are almost guaranteed to crash the target. Please don't do it.

I would recommend creating a new basehook using the mach_* API. It'll take care of all the technical work of hooking and injection for you. You just gotta code a small loader, and then code your real hack. I haven't done this yet out of lack of motivation, and laziness. I choose to use the Application Enhancer API, but Unsanity puts a lot of limitations on how you use their SDK for your own products(hell, my hacks are illegal I think). They make it really easy, but it's not very practical for distribution to noobs.

Feel free to PM me if you'd like. I might even consider teaming up on a hack with you. ;-)

--Macpunk

Thanks for telling me that PPC is very different. In the mean time i already found that out: gee not even JMP exist. :-(

I've informed myself: the analogon to LD_PRELOAD needs a few environment variables to be set. Then it works. But it breakes dlsym. However, my new hack doesn't require dlsym...

I've done some thinking about file formats, and concluded that since GDB must have been ported to all those platforms to debug the GNU tools ports, it's likely that GDB knows all of the file formats, so basically you can retrieve any offsets via GDB on any platform, as long as debug info is in the file (needed to recompile it for that on windows).

I've done a new hook, eliminated posix threads, and pagemask should always be (~(PageSize-1)).

If the proc file system does not exist, you will have to tell the program manually where it is. Then it will work just fine.
Otherwise, maybe there is a OS API function like "GetModuleFileName" in Windows.

So on Intel Macs you should get it to work.

The issues with PPC cannot be avoided, since C & C++ offer no facility to jump from one function to an arbitrary position in another function, so you will always need the JMP Rel32 respectively its branch equivalent on PPC.
Well, actually C & C++ do have support to jump like that, but it doesn't help for detouring a function.
(http://en.wikipedia.org/wiki/Setjmp)

To get it to work on PPC, you need to change approximately 16 lines of code ( it is not the most difficult code I've ever seen... ;-)

If you don't know how to do it yourselfs, then maybe you can find somebody who helps you with that on some of the competent Mac forums. 16 lines should be few enough to be done quickly and free of charge by a pro. I cannot help you, I do not know anything about PPC. And as PPC processors are gonna die anyway, i will not start with it now...

I recommend you to do a detour routine on PPC and test it with a hello world program. If you can do that, then the rest is relatively easy.
You can use my detour routine as an example (for x86 however).
Look at it, if you don't understand it, i can explain what it does, and why it does it.
Note that, in case you don't know it yet, to detour a function, you must be in the same virtual address space than the program that you hook the function from.
To achieve that, on Linux you use LD_PRELOAD, and on Windows you inject a dll, and probably there is a way on Mac, too.


Anyway, see my new release, read all the text files and maybe you get it to work on OS X on an Intel processor.
I've mentioned the critical lines for Mac on how_to_compile.txt at the bottom of the file.

Right now it works fine for Windows and Ubuntu, should do OK on FreeBSD, which should include any Unix (appart from MacOSX...)

I've seen you've rewritten the QVMdecompiler.
Keep up the good work!
Could you release the source?

Can't release it atm due to a bug in the software I'm using to write it. Sorry. :-(

It does more than break dlsym. For more info on it: Check the dyld man page

You can inject a dynamic library at runtime using techniques outlined numerous times on the net. A couple of examples from nemo: http://uninformed.org/index.cgi?v=4&a=3&p=15. If you want to use a method like LD_PRELOAD on Linux, you'd use those environment variables for dyld, but those fuck up a two-level namespace program.

You might want to also take a look at http://guiheneuf.org/mach%20inject%20for%20intel.html.

And for every PPC instruction you should ever need: http://developer.apple.com/documenta...section_6.html

I really don't recommend trying to support Linux, OS X, and Windows all in one hack, with the same codebase.

--Macpunk

Originally Posted by Macpunk

Can't release it atm due to a bug in the software I'm using to write it. Sorry. :-(

It does more than break dlsym. For more info on it: Check the dyld man page

You can inject a dynamic library at runtime using techniques outlined numerous times on the net. A couple of examples from nemo: http://uninformed.org/index.cgi?v=4&a=3&p=15. If you want to use a method like LD_PRELOAD on Linux, you'd use those environment variables for dyld, but those fuck up a two-level namespace program.

You might want to also take a look at http://guiheneuf.org/mach%20inject%20for%20intel.html.

And for every PPC instruction you should ever need: http://developer.apple.com/documenta...section_6.html

I really don't recommend trying to support Linux, OS X, and Windows all in one hack, with the same codebase.

--Macpunk

It's already been noted that you don't recommend it.

Non the less I think it should'nt be that difficult.
After all, the game hack is always the same, only the detour routine and the startup way differ.
The startup way i've already adjusted for dll injection on windows and ld-preload on linux. Why should it be difficult to add a 3rd way for mac?

From what I've read, I think I don't like Rentzsch's library, because it sounds like it is unreliable. Sounds as if it has problems making a code that runs on Intel and PPC.

I'd rather not use a code for all processors, but inquire with #defined (ppc) which processor the build machine has. Then, adding PPC is a bit of a pain, but it really only requires a rewrite of the 16 line routine. Well, that means that the PPC support is more difficult than the Intel support, but it's feasible. Then you just build one cheat release for PowerPC and one for Intel Processor. And if you want, you can also build another 2 for 32 and 64 bit versions.

So because I don't like Rentzsch's library, I'd actually prefer to use Apple's version of LD_PRELOAD instead of Apple's version of DLL injection, if that is possible.

From what the manual says:

Code:

 
       DYLD_INSERT_LIBRARIES
              This  is  a  colon  separated  list of dynamic libraries to load
              before the ones specified in the program.  This  lets  you  test
              new  modules  of existing dynamic shared libraries that are used
              in flat-namespace images by loading a temporary  dynamic  shared
              library with just the new modules.  Note that this has no effect
              on images built a two-level namespace  images  using  a  dynamic
              shared library unless DYLD_FORCE_FLAT_NAMESPACE is also used.
 
       DYLD_FORCE_FLAT_NAMESPACE
              Force  all  images in the program to be linked as flat-namespace
              images and ignore any two-level namespace  bindings.   This  may
              cause programs to fail to execute with a multiply defined symbol
              error if two-level namespace images are used to allow the images
              to have multiply defined symbols.
       DYLD_BIND_AT_LAUNCH
              When this is set, the dynamic linker binds all undefined symbols
              the program needs at launch time. This includes function symbols
              that can are normally lazily bound at the time  of  their  first
              call.

the startup script would look like this:

DYLD_INSERT_LIBRARIES=$PWD/urth.dylib DYLD_FORCE_FLAT_NAMESPACE=YES DYLD_BIND_AT_LAUNCH=YES /usr/local/games/UrbanTerror/ioUrbanTerror.whatever

So I'd actually advocate the combined use of a startup script and a prayer for that Urban Terror on Mac doesn't use two-level namespace images... ;-)

mach_* is plenty reliable, and I gave you a universal version. If you wanna go ahead and reinvent the wheel by writing your own detour routine, go right on ahead, but make sure you account for the differences in processor design for PPC and Intel as noted in the 3rd link I gave you.

Apple doesn't have a version of LD_PRELOAD. Apple doesn't have a version of DLL injection.

And if you're looking for stability and scalability, you're going to need more than a prayer. ;-)

--Macpunk

Originally Posted by Macpunk

And if you're looking for stability and scalability, you're going to need more than a prayer. ;-)

There's definitely a point in that ;-)

And you pointed me to nice web addresses, too.

And through your links info, I was able to find better pages than I did at first, now I only need to rewrite the code for that it fits my purposes, and allocate the stub with malloc to make it smooth:

http://www.kernelthread.com/mac/apme/frr/

Look, even the 'hello world' program is already written:
http://www.kernelthread.com/mac/apme/frr/frr.c

Greez Quandary