Xtrap crap bypass method for PT gameclient 2010 and...

possibly other game clients that use Xcrap like "Martial Empires" Online. I have read this guide and felt my brain tingle when I read over something It understands but most of this leave my mind confuse but keep reading and driven till it understands that pacific paragraph. This guide on stopping Xtrap from running was posted up this year so to me that is great news. I will post up this Xtrap guide here and the credit to this guide go fully directed to [Only registered and activated users can see links. Click Here To Register...]. I have not yet started using this info to break Xtrap Martial Empires because I feel I will need you guys help to help me understand this. I am good at fixing PC if they crash or need cleaning but when in come this stuff I get confuse. Now I use to do hex editing, binary reading, Perl, VB and had a C++ book that I started on back when I was 18 and C++ was the hardest so I stuck with Perl for about 4 month just to find out I can not really do anything with it, so I stop learning Perl "the blue book with a camel on it" and got into net work security stuff dealing with hex and other fun stuff. I forgot that book name but it was dark dark blue paper back book that was very very fun to read and great at teaching you how the net works. I was learning way to much with in them 8 months, so I took a break and slip into MMORPG and forgot every got damn thing I was studying..... I just get glimpse on things when someone ask me a question dealing with VB, Perl or anything else I can not answer them but they feel I know something, or when I read stuff like this guide my mind tells me "hey I kinda understand this but your dumb ass don't, why you stop learning?" Well here is the guide.

Disabling XTrap Requirement in a PT Client
First off, an apology that this has been sat on my hard drive as a Rich Text file for months now, unfinished.

I wanted to cover the harder clients to remove XTrap from, but it's just too technical to explain any more than to follow the guide I wrote about removing redundant code and follow your nose.

Back on track.

Introduction
Tools of the Trade
Simple Beginnings
A More Complete Removal
More Complex Executable (Incomplete)

Introduction
Okay, so I promised that I would write a basic guide to removing XTrap from PT game client. Now the big point I want to make about this, is that there are many ways of doing it, and the method pioneered by the SGPT team (QuantumFusion, Shagpub et.el) and sold to us as NoXTrap or "XTrap remover" doesn't actually "remove" either XTrap, or the games ability to utilise it... what it does "remove" is the games refusal to operate without XTrap present.

The reason this distinction is important, is that many new users take a NoXTrap client, and replace the game.exe in their regular PT install with that and then wonder why it just crashes every time they try to run it. The answer is that XTrap is still part of their client installation folder, and the "NoXTrap" game.exe will still load it and use it. It then identifies that this client is not the officially sanctioned one and shuts it down before it's even gotten started. The solution is to simply delete XTrapVa.dll and (optionally) any other files associated with it. Then everything works just fine.

If they had deleted XTrapVa.dll or anything associated with it before using the "NoXTrap" version of game.exe however, they would have the same result as using the "NoXTrap" version with XTrap files present.

So while this method works... it's not exactly clean, clear or well thought out.

The second point that I want to make, is that I have now worked on removing XTrap from a number of different language versions of the PT client and I can tell you that it is actually implemented differently by different PT distributors in different locations. Some are easier to deal with than others, and things like "offsets" which the "Debug Environmentally Challenged" among us love so much become worthless when looking at unrelated client versions. Things like "XTrap Remover" tools cannot work from one language version to another either, and they become worthless ever 7 to 10 releases of a single language version.

So it's far better, IMHO, that I document how to actually debug the executable, recognise where the important XTrap code is, and disable, or remove it your self. If people want to continue to make simple patches for those who don't understand, or have the time to follow this guide, that's fine... but this guide should remain relevant into the indefinite future, where anything that relies on offsets, searching for hex and so on will definitely become irrelevant, historic shortcuts.

So that's the premise. I'm not writing for noobs. But I'm not going to continue doing the work for everyone else. It was fine for me to get the hang of it, and it's a good exercise for anyone who wants to get their feet wet with Olly. But make sure you set the time aside to do it. If one particular version is sufficiently popular, we can make a binary patch for those who don't know and don't care to know how it's actually done.

Tools of the Trade
Here's a list of tools I'm going to use in this analysis and re-engineering project. I'm not going to tell you "you have to use these tools" and "nothing else will work" because I know that there are other tools that are equally good, and some of them I use, have used, or would like to use if I could afford them. However, these are the ones I'm going to use and if you use the same tools (at least the first time you follow this guide) you will have less trouble understanding what I'm doing.

OllyDbg v2.00j beta (not the newer v2.00k beta because that has a bug which is problematic here)
My OllyDbg.ini (will make the disassembly look and work the way mine does. And you may prefer something else, but it just might make the screenies and such make more sense)
IsXunpack 0.99 & Unshield 0.5 (or you could just install to your hard disk, but I don't recommend doing that with too many clients.)

A test client downloaded preferably from the Korean (18xx, not 23xx) or Japanese (currently blocking non-JP IP addresses) PT web sites. (I'll try to link the JP client here for the JP proxy impaired later)

Simple Beginnings
I've already mentioned that different PT distributors use different methods of implementing XTrap protection into their client... the easiest to strip out are the Korean and Japanese test clients, and that's probably why most of the developer clients found on these forums are based on the Korean Test client. For your first attempt, I strongly recommend you use one of these.

Set up your working environment. This means ensuring that you have OllyDbg v2.00j installed and (optionally) copied my ini file in the same folder. If you run on Vista with UAC active then make sure you set the Compatibility options properties tab to launch it with Administrative privilages. It doesn't debug properly without that, but it will mean you get a UAC warning each time you launch Olly.

Download a client and extract it to a working folder. It's preferable to extract it from the installer rather than installing it to your machine, because you can't redistribute the installer, so you need to know how the client behaves when it's just extracted from a zip / rar or whatever and run. Not only that, but if you are going to be trying this with lots of clients, then you will very quickly end up with a very messy machine from all the registry changes and un-installers installed by each client. I'm using PsTale(Test_1872).exe from the Korean web site for this guide. If you want to see the exact same version as me, and they haven't changed the Test download yet, just don't run the updater... another advantage of this is that until you run the updater, XTrap doesn't actually get installed, because XTrap needs to be updated every time anything changes in the client.

Every scientist collects empirical data (based upon real world experience) before devising theories to further their understanding, and design tests to prove or disprove these theories in another empirical fashion. So what can we see happen with the game client with regards to XTrap?

Well... if you run game.exe (not the launcher or the updater) from a fresh install... it looks like nothing happens except you get a "waiting" cursor for just a fraction of a second. If you watch the task list in Task Manager (or similar) you will however see that game.exe is loaded, and then immediately unloaded.

If you run the game.exe with XTrap installed, and try to inject another process (dll) into it's memory space, or modify it's memory in any way... it will just shut down without any warning or anything, like it just crashed and didn't even ask if you wanted to "Send a report to Microsoft".

If you modify game.exe even just a single byte while XTrap is installed, and run it... the result is the same as if you didn't have XTrap installed. game.exe starts, and then immediately quits.

Now on to theorising. There are a couple of ways that this can be achieved.

We could try to load XTrap, and if that succeeds continue playing the game until the user chooses to quit... and if it fails, we will continue as if the user has already chosen to quit. In other worlds, if we can't load XTrap, we simply return to the OS.
We could also request that the OS "unload" our application and all it's sub-threads if we can't load XTrap... this is reasonably equivalent to using the "End Task" button on Task Manager.

Either way... if XTrap finds a problem, it is clearly using the "End Task" method of shutting the game down the moment you try to modify it.

Assuming you've done your homework, and know a little bit about the Win32 programming platform and it's APIs you will know that the Win32 Kernel is actually a platform that runs on top of the NT micro-kernel, or (in older versions) on top of DOS.

So we can ignore the NT core kernel and concentrate on the Win32 sub-system, which is primarily in kernel32.dll (the executive KE module which handles memory management, tasks, threads, processes, input output and interprocess communication) and it's user-land partner user32.dll (which is there primarily for handling user session data, profile data, performance tweaking and user interface details such as desktop and window management and so on and so fourth, with the help of GDI32, the primary interface to the GPU and Graphics memory).

Because the KE handles memory management, tasks, processes and threads, it's not surprising to find that TerminateProcess() and TerminateThread() can be found there in Kernel32.dll. These will be prime targets to look out for.

But there is another key issue to look for. If you examine the headers of game.exe, and in particular the import and export sections, you can see that there is nothing about XTrap in them... therefore XTrap must be late loaded into the program and, as we know from my discussions on adding code to game.exe via DLLs, that requires the use of another kernel32.dll call; LoadLibrary().

Now you can grub around in your hex editor looking for strings of text that look like they have something to do with XTrap (there are lots of them) and trying to find bits of code that reference them (there are lot's of those too) all you like... but there are only about 3 places where TerminateProcess() is called (Quit Game, Close the window & No XTrap found) and 2 places where LoadLibrary() is called (late load User32.dll to access MsgBox() in case of a fatal error which may have corrupted the on-load version, and late load XTrap) and I'm inclined to say that tracing one of those calls back to a subroutine will get you to the code you need quicker than anything else.

Let's get dirty with our copy of PsTale1872, and load it into Olly. Next, right click the disassembly and select "Search for" -> "all intermodular calls" sort the listing by "Destination" (if you have ignored my warning and are using the v2.00k version instead of the v.2.00j version you will now see nothing but the dlls and a bunch of numbers after them, which is why I told you not to do this) and scroll down the list till you get to T for TerminateProcess().

The three calls can be found (at least in the Korean clients) the one you are looking for is very simple. It looks like this:-

Spoiler

push 0 ; ExitCode = 0
call [<&KERNEL32.GetCurrentProcess>] ; KERNEL32.GetCurrentProcess
push eax ; hProcess
call [<&KERNEL32.TerminateProcess>] ; KERNEL32.TerminateProcess
ret

Now... having found that tiny piece of code you can simply Assemble a new ret instruction over the top of the first push 0, save your altered executable and your patch is as good as the generic.

Actually, you can nop out the rest of the instructions to clean it up some more, and you can also follow each of the links to that code and jmp over the nops you are going to blank out the call with.

That routine is called from a number of places, each of which (in this client) are in some way related to client errors... if you set a breakpoint on push 0 instead of assembling ret over it, you will see the one that relates to XTrap not found -> Quit as the last address on the stack when the breakpoint is hit. So to cleanly remove just the games reliance on XTrap, you can simply jmp over that one call. If you want to make the absolute minimum change to the executable, with minimum effect on any other aspect of it's operation, do that.

Ok what I do not understand is the Push statements "Assemble a new ret instruction over the top of the first push 0" and jmp over the nops. The other guides on the way