War Rock Cheat Programming Discussion

#req
asm_vehicleradargps source

Quote:

Originally Posted by Raz9r Well the problem is that there may be two packets from the game whose logical timestamps only differ by one. So far I'm putting both the games and my cheats packets into one concurrent queue to properly update the logical timestamps and thus delay the send operation by up to 100ms, which can be critical for certain packets. Also the difference between the timestamps differs for a few packet types, so I really need to use some kind of a concurrent priority queue aka. a performance killer.

WarRock is P2P based right?
I guess there is no clean way to calculate the timestamp correctly.
How does the WarRock client calculate the timestamp?

Quote:

Originally Posted by Omdihar WarRock is P2P based right? I guess there is no clean way to calculate the timestamp correctly. How does the WarRock client calculate the timestamp?

It is but when talking about the timestamp we're talk about the 'TCP' Packets from the Client to the WarRock Server.
They use a simple 'timeGetTime() [winmm.dll]' to generate the Timestamp.
For WarRock this isn't any problem because this is done in one single thread so it can't happen, that a timestamp < as the last timestamp.

When working with a Cheat, you normally create your own thread.
now when for example the WarRock Client generates a packet ( With a timestamp ) but before he could send it, your thread comes in and generates a Packet and sending it, so the last timestamp in the Server will be the one of the Packet, which comes from your thread.
Now when the WarRock client is ready to send his Packet, the timestamp will be lower as yours and it will lead to a disconnection.

Quote:

Originally Posted by Cyno™ It is but when talking about the timestamp we're talk about the 'TCP' Packets from the Client to the WarRock Server. They use a simple 'timeGetTime() [winmm.dll]' to generate the Timestamp. For WarRock this isn't any problem because this is done in one single thread so it can't happen, that a timestamp < as the last timestamp. When working with a Cheat, you normally create your own thread. now when for example the WarRock Client generates a packet ( With a timestamp ) but before he could send it, your thread comes in and generates a Packet and sending it, so the last timestamp in the Server will be the one of the Packet, which comes from your thread. Now when the WarRock client is ready to send his Packet, the timestamp will be lower as yours and it will lead to a disconnection.

I am not sure if I have understood you properly, but then you could hook timeGetTime to get the last timestamp calculated by the client and calculate a new one which is not less than the original one?

Quote:

Originally Posted by Omdihar I am not sure if I have understood you properly, but then you could hook timeGetTime to get the last timestamp calculated by the client and calculate a new one which is not less than the original one?

This would require you to make timeGetTime thread-safe, which causes a huge amount of lag. timeGetTime needs to be a real-time function. Also IIRC Hackshield checks its signature.

You could hook the sendPacket function and simply compare if the timestamp is less than your last sent packet.

Quote:

Originally Posted by Omdihar You could hook the sendPacket function and simply compare if the timestamp is less than your last sent packet.

Which essentially is the main part of my first suggestion regarding this topic.
Recap what we got so far:
– Hooking send from WinSock2 and queuing all custom packets with a certain priority. Forces you to send your packets from the games main thread or to use mutual exclusion, which is bad. Also forces you to analyze every single packet in a hook before passing them to the original send function.
– Hooking timeGetTime to change the logical time order. Requires you to lock some pipelines.
– Hook send from WinSock2 and have a concurrent queue (with non-blocking pop_front/pop methods) filled with the custom packets from a new thread. Whenever a packet is sent, check for the queue not being empty; then after sending the games packet send the first packet in the queue with the timestamp being increased by one. Also hook timeGetTime and double the result to have at least one free timestamp in between every result of timeGetTime. Creates almost no lag at all, but does not properly work with chat packets as their timestamps need further adjustments.

What I'm doing so far is the following:
I'm mainly using the third way, but whenever I need to send a chat packet, I override my hook temporarily with the first. This only makes the game lag when I'm sending custom chat packets, which almost never happens. Almost lock-free. :-)

Quote:

Originally Posted by Raz9r ...

Im actually hooking into the Thread of WarRock for sending my packets and it works fine

Hast jemand die CPlayerInfo Structs ?^^

Quote:

Originally Posted by GTGameerish Hast jemand die CPlayerInfo Structs ?^^

They didn't update?

is there someone who has a copy of gameguard server files before WarRock changed its anti hacking software to hackshield?

Quote:

Originally Posted by kevin0152 is there someone who has a copy of gameguard server files before WarRock changed its anti hacking software to hackshield?

WarRock had previously Punkbuster. GameGuard has not been used in the International version.

Quote:

Originally Posted by kevin0152 is there someone who has a copy of gameguard server files before WarRock changed its anti hacking software to hackshield?

WarRock Global = Punkbuster -> Hackshield
WarRock PH = Punkbuster -> Gameguard

Quote:

Originally Posted by BustyWar WarRock had previously Punkbuster. GameGuard has not been used in the International version.

ah good to know thanks for the info