Bot development : Hero Online Discussions

The Tault Hero Online community seems rather small and if you don't have a premium already it's fairly difficult to 'earn' one. I thought it might be helpful to collectively help each other while we are on the outside.

My initial bot attempts failed because it seems like xTraps is preventing my script from sending keyboard commands. From what I can gather, the xTrap bypasses that are available simply hide the process of your 3rd party application from xTraps. A post by inosan suggesting the use of a rootkit to hide a packet logger/generator from xTraps seems confirm this.

However, I have so far been unable to send keyboard/mouse commands with my program. Here are the steps I am using:

1. Start the game and log in
2. Launch my macro script, execution is bound to a hotkey
3. Locate the PID of the script and hide that process
4. Verify the script is no longer visible with taskmgr
5. Tab back into the game and try the macro.

What methods have you guys tried? Is anyone familiar with the mechanics of the xTrap bypasser?

I still have not figured out a bypass method, but I was able to finally send keyboard commands. It seems that if you send a key-down event and then wait 1000ms and send a key-up event, the game will register that the key has been pressed.

For the last couple days I have been trying to debug the xtrap process.

The first time through I used Olly to attach to the Hero loader. Once you click 'Play Game', Hero and xTrap.xt are launched. xTrap, being the clever little anti-hacking system, detects Olly is monitoring the loader and terminates the game. (This was version 120 btw).

So now I pull open my collection of rootkits and attempt to hide Olly and repeat the process. xTrap is still wise to my scheme and kills the game.

xTrap 124 gets installed.

Now when I attempt the above, xTrap tells me that I'm using an abnormal program and then kills the game. But I already knew that...

So rather than try to remove particular functions of xTrap I decide to just skip xTrap all together. The goal here is to alter the execution of code between clicking "Play Game" and before Hero and xTrap gets loaded. So far I've ended up with immediate system reboots or blue screens.

From what I've read on another forum, the usermode application xTrap.xt interfaces with the kernelmode driver XTrapD12.sys. XTrapD12 hooks into Windows at various points and watches for certain things. As a side note, xTrap has started flagging Banlist (a 3rd party application for Warcraft III - DotA) as an abnormal application. I wonder if it's the winpcap or DirectX hooks that are triggering this?

I wonder...When using a program called ProRat, a user sets up a server on a other computer which then allows the installer to have access to the other computer(full control)

Now you may think "whats hacking got to do with this?" well then, take a look at this...ProRat can not be detected by an anti virus..hmmm

Dangerous but it can be looked at by the user UNLESS you use an encryptor to hide it fully...

The encryptors i know of are; UPX, and Armadillo. What if we encrypted the executable macro to hide it from other programs such as Xtrap? I wonder...

Anyone think this could be a possibility?

The encryption is a good idea, but it will only bypass the signature based detection used by xtrap. you would still need some way to keep xtrap from noticing the use of certain functions like keystroke generation or pixel checking.

I'm getting pretty close to giving up on bypassing xTrap on my own... my cracking abilities just aren't up to par.

The last three options I see are:

Create a virtual USB device to emulate a keyboard. This would involve a hardware device driver to make windows think this is the real deal and then a usermode application to control what keypresses to generate on the virtual keyboard. Repeat for mouse if mouse control is needed. Pros: I have yet to see a technique like this in use and it is rather undetectable as far as I can tell. Cons: I've never written a device driver so development time would be fairly long. It also doesn't help out with video checks to allow for intelligent bots that can check HP and such.

OS Emulation: VMware, VirtualPC, etc can take care of all the dirty work by emulating the entire system. Hero Online (xTrap) would just see a clean OS with nothing trying to interfere. The bot code would be loaded on the host OS, outside of the reach of xTrap, which is confined to the guest OS. Pros: Easy setup. Cons: Emulating the whole hardware layer is slow and I only get 12-15/fps as it is... (I *really* need to spend some cash and upgrade my system)

Leech: Just wait for a bypass to fall into my hands. Pros: Easiest method of all. Cons: Will likely never happen.

Darn...so we need to some how emulate keystrokes....wait...how can xtrap tell the difference?

i don't think having a custom driver is really that detectable. i could be wrong though. Unfortunately I can't help, seeing as I've never taken the initiative to even investigate how xtrap works. maybe i will one day.

edit: i thought i read that you said that custom drivers are detectable, I need more sleep.

Windows operates based on layers, sort of like an onion. Every time you peel off the outside layer there is a layer below that. I'm simplifying but picture something like this, where the top is the outside layer and the bottom is the inner layers:

Program
Windows API
Windows HAL (Hardware Abstraction Layer)
Hardware

When Hero runs it starts up xTrap. Part of xTrap sits on the outside Program layer. Another part connects to different parts of the Windows API layer using a method called hooks. A hook is basically like a gate keeper. It guards the path and every time you want to go down that route you have to go through it.

The Windows API contains built in functions that programs can use to do certain things such as check if the spacebar has been pressed. In addition to checking for keypresses, a program can actually set a keypress state to true. This is what macro programs use to fake keypress and mouse movements. But remember from above, xTrap put a hook into the Windows API and sits between the macro program and the real Windows API. Every time your macro program tries to set a key to the 'held down' state, xTrap sees the request and doesn't let it through.

Macro Program -> xTrap -> API -> Hero Program

As seen above, the keypress request gets blocked before reaching the real API function and thus Hero never sees a keypress.

Now if we look at the layer model again, we can see that Windows HAL sits under the Windows API. Since the hook only attaches to the Windows API then if we sneak something in at the HAL layer then it would go undetected. Fortunately Windows allows for multiple input devices (keyboards/mice), which means if you plugged in a 2nd keyboard and installed the drivers you would be able to type on either keyboard and it would work with your programs.

My idea is to place a fake keyboard driver to pretend like a 2nd keyboard is installed. Since we don't actually have a real 2nd keyboard installed we would also install a program that talks with the fake keyboard driver and tells it what keys is supposedly being pressed on the fake keyboard.

Fake Keyboard Program -> HAL (fake keyboard driver) -> xTrap -> API -> Hero

Since the keypress is originated in the HAL, xTrap has no choice but to assume it is legitimate. Further down the line, if they decided to block this type of trick, they would probably need to create signatures of legitimate keyboard drivers on the market and then not allow unapproved drivers to pass keystrokes up the chain. I doubt this would ever happen because even Microsoft's attempt with 'Genuine' MS-approved drivers didn't take hold and is really too difficult to manage on a global scale.

whew... I guess that post quickly turned long winded.

excellent explanation.

That is exactly why a custom driver would be great for this situation, the only problems are that
1. creating drivers are hard, way beyond what a lot of us can do. some people go to college just to learn how drivers work, and how to make them.
2. you only solve 1 problem: sending keys. what about memory reading, or pixel reading?

with those in mind. it would probably just be easier to somehow disable Xtrap in the end.

some additional ideas:
Im almost positive HO uses DirectInput, couldnt we just hook that? Ive never looked into the subject, but from what i understand, it does not operate on the same level as the API, which may mean that Xtrap can not prevent if from being hooked. I may be totally wrong here, since ive only done very, very brief reading on DirectInput.

Im not sure exactly where Xtrap Hooks into the windows API, but don't programs like Process gaurd prevent prevent certain hooks like that (all depending on a number of factors of course)?

learn the inner workings of Xtrap and hook into Xtrap itself and render it useless by allowing everything to pass through their hook via intercepting messages and then sending fake ones?

Going off of what ive seen from other bypasses, it almost appears you can disable xtrap purely by changing a few memory addresses, perhaps Xtrap is really a piece of crap as I have suspected all along and theres a few values in there that you can change to render thier API hook useless.

its probably pretty obvious that i do not know a whole lot about this subject, as I am still learning.

Sounds like you've done your homework Catinthebox.

I hope to see this become a reality because this is a really good idea.

Unfortunately, in the information age, keyboard hooks are used for keyloggers to get the information they need so some people may be hesitant to use or work on such an application.

Hopefully your intentions are honorable. If they are and this is produced you will get a lot of points and respect from this community.

On another message board a pair of guys working together have already created a hook into the xTrap hooks. The last I heard, the hooking was successful but xTrap would occasionally complain and cause failures. Shortly afterwards they started worrying that their conversations would be read by xTrap developers and decided to take the rest of their research offline.

I just had a little boy this morning and since I have no background in driver development, a project this daunting is a bit out of my reach at the moment. The topic is still very interesting to me though so I'd love to keep in touch with anyone that pursues this path.

CONGRATULATIONS!

yes congrats

congrats..

i sort of understand whats going on...about the layers