Finding a Pointer Undetected
Finding a Pointer Undetected
hi,
I want to deliver some cheats, but I'm able to bypass xtrap and be able to search for addresses, but I can't debug cos it will get detected by xtrap. I think more people have this and i'm guessing there must be somebody who knows how to get a pointer withouth debugging(attaching), or how to do it undetected.
Please if you reccomend me ollydbg gimme a link on tutorial.
tits in return:
I want to deliver some cheats, but I'm able to bypass xtrap and be able to search for addresses, but I can't debug cos it will get detected by xtrap. I think more people have this and i'm guessing there must be somebody who knows how to get a pointer withouth debugging(attaching), or how to do it undetected.
Please if you reccomend me ollydbg gimme a link on tutorial.
tits in return:
General section 
lulz ull get more help in assembly
TL;TR
ONLY LOOKED AT PIC TY.
ONLY LOOKED AT PIC TY.
dis aint 4chin ******
This is not /b/
edit: fku god mofucka stealing what I wanted to say
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 sure 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.
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 sure 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.
Originally Posted by radnomguywfq3
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.
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.
Holy crap you gave a really good explanation of what he should do
Originally Posted by radnomguywfq3
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 sure 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.
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 sure 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.
Originally Posted by DoubleDutch
Summary:
GOOGLE
@Jetamay
Thanks, I used to 'NOP' functions in PB so I might research a litle, and I agree Dave prolly won't tell. Maby I can find some more on the UC forums.
edit:
xtrap files are encrypted.
Also I found this will it do?
http://www.codeproject.com/KB/DLL/funapihook.aspx
Not really. There's a lot more involved. Idk, I suck at detouring, so if he wants good information he should be asking Dave. But I doubt Dave will say anything.
