Welcome to the UnKnoWnCheaTs - Multiplayer Game Hacks and Cheats.
You have to register before you can post and access any of the advanced forum features, please click the register link to proceed to the registration form. To start viewing threads or posts, select a forum that you want to visit from the selection below.
Team Fortress 2 hacks cheats tutorials downloads source code
You are Unregistered, please register to gain Full access.
I used IDA pro to disassemble client.dylib. It's really just making that file into assembly code if your not getting me.
There were some pretty interesting strings in there, but I found nothing that related to cdll_int.h or whatever it was.
So if anyone is gonna take this project up, its gonna be a lot harder than you think.
To me, this is easy. But I don't feel the pub scene deserves a free hack. There is a lot of work that goes in to the hack, and all pubscrubs do is demand more features and fixes and I see nothing in return. (Especially BR and RU)
To me, this is easy. But I don't feel the pub scene deserves a free hack. There is a lot of work that goes in to the hack, and all pubscrubs do is demand more features and fixes and I see nothing in return. (Especially BR and RU)
I'm on your side. I want to fix this for myself.
I opened the client.dylib up in a hex editor (found out thats another step of reverse engineering) and I searched for some vtables you were talking about earlier. Interesting results.
And I also found out I opened up client.dll instead of client.dylib on accident.
I found most of the netvars in world objects inside the hex editor. I found alot of the cdll_int.h vtables in the disassembler. Of course, not everything in those files needs to be updated, right?
Updating those "createInterfaceFn" strings should be easy.
EDIT:
I just used Visual Studio to build the source and make it into a DLL. I got the injector to load it correctly, but like my pass experiences with late darkstorm versions, a few error messages showed up.
Those five errors popped up one after the other in order. I looked around, and in a file called DLLMain, it had all of those variables or whatever they are.
Are you sure that all of these can be fixed in those two files? (Along with fixing the strings...)
Rustie you're going to need to do quite a bit of learning before you're ready to program your own hack. You can't just know nothing about programming or reverse engineering and expect to update the SDK / develop a working cheat. First of all you want to open up the client in IDA or OllyDbg, whichever your prefer, not a hex editor. Updating the strings are pointless, you can just use the code I posted in my Source Engine [Hooking] thread which auto finds these strings for you. I'm assuming that those errors are passed to you by the Darkstorm source you're using?
Why don't you do a search in the source code to see why you're getting those errors? My guess is that it's caused by an invalid pointer. Now if that's the case then you're going to need to make sure all those interface versions are completely correct, but all that's going to do is crash you. Even if all the interface strings are correct, all that means is that you're getting the right pointers, but what happens when you call a function in that virtual table pointer that is improperly aligned? You crash. There's more to updating the SDK than doing a simple string search.
Rustie you're going to need to do quite a bit of learning before you're ready to program your own hack. You can't just know nothing about programming or reverse engineering and expect to update the SDK / develop a working cheat. First of all you want to open up the client in IDA or OllyDbg, whichever your prefer, not a hex editor. Updating the strings are pointless, you can just use the code I posted in my Source Engine [Hooking] thread which auto finds these strings for you. I'm assuming that those errors are passed to you by the Darkstorm source you're using?
Why don't you do a search in the source code to see why you're getting those errors? My guess is that it's caused by an invalid pointer. Now if that's the case then you're going to need to make sure all those interface versions are completely correct, but all that's going to do is crash you. Even if all the interface strings are correct, all that means is that you're getting the right pointers, but what happens when you call a function in that virtual table pointer that is improperly aligned? You crash. There's more to updating the SDK than doing a simple string search.
I opened that file in a debugger. I'm just saying I found a lot of the netvars in the hex editor. I am not saying I'm using it just for RE.
And I'm not making this from scratch. Hell knows what the fk would happen. But I shouldn't be starting that up, considering that you mentioned the source. Oh, and yeah, the source I have (Darkstorm 2.6.1) gives me those errors when I compile all those files into tf2base.dll and use the GD loader to inject it in Visual Studio.
I have my fair share of C, but I have no experience in the "hacking field". I'll take a look at that topic you mentioned. Thanks.
Fine piece of work you have there! Must have taken ages to make that perfect aimbot. Is it a private hack?
Oh, by the way, I took a look at world objects, and I searched through IDA and found every netvar in world objects in IDA. What do you mean, "replace it with proper netvars"?
Fine piece of work you have there! Must have taken ages to make that perfect aimbot. Is it a private hack?
Oh, by the way, I took a look at world objects, and I searched through IDA and found every netvar in world objects in IDA. What do you mean, "replace it with proper netvars"?
Took 14 minutes 37 seconds to write that aimbot. I put it in the donator builds I give out, so technically yes it is.
Proper netvar is RecvProp. Not gonna tell you more, read the fucking SDK.
