Originally Posted by
Jetamay
You're starting in the wrong place. You should detour xTrap BEFORE trying to hack the game.
I'm not going to get into this, detouring gives me a headache, too much testing & building + I suck at it.
Couple of tips though that will HOPEFULLY safe you time(and I've never looked at xtrap in my life, so they could be off) It's probably communicating with a kernel driver(which you probably will not be able to find). And probably via named-pipes, or symbolic links to the driver(hereby refereed to as server) is creating a symbolic link which is being opened by xtrap's main dll(which will be loaded into the application being protected, hereby refereed to as client). My guess is the client is sending information to the server to be processed, which results in the 'ban', or w\e the fuck happens. You can either simulate the server(by recording messages send\recieved and figuring out their protocol + how to respond to messages) and I don't recommend you do. Or find out what's causing the certain messages to be sent, which results in the ban.
I'd start by hooking any imported APIs which open any sort of communication to the driver. Accessing named-pipes or symbolic links to devices will be similar to the way any file is opened. I.e through OpenFile, CreateFile, fopen, etc.. The sort of path your looking for will look like a path to a directory. I.e '//someShiz/asdf' . Once you've located the correct call, you steal the handle, and log all file related operations with that handle. If you're lucky the communication won't be encrypted, if you aren't -- idk, I've never gotten this far, but I'm if you follow the execution you'll find decrypting methods.
Good luck yo. I wasted a lot of my time wondering in the wrong direction last time I tried to crack an anti-hack.