Faster jumping ??

Hi ,
i have a question on how to travel faster in conquer like conquer ai
i have tried to make a travel bot and it works correctly but its slow
(Thread.Sleep(750); and if i change it to -750 it disconnect)
the question : why conquer ai traveling is fast without disconnect??
Thanks.

Because it uses a proper speedhack system.

There's been a number of methods of accomplishing it but you cannot simply send jumps faster or you will get disconnected nearly instantly.

Used to be you could teleport up to 6 coords at a time by sending action packet with invalid UID using the X/Y you wanted to go to (mini hops that could be sent as fast as you could send packets without flooding and you'd get there)

Could also use invalid map ID to reset your last jump timestamp and then send a legit jump right after with spoofed timestamp + 2000 or w/e and it would work.

There were a few other methods but those were the ones I've successfully used before.

Quote:

Originally Posted by pro4never Because it uses a proper speedhack system. There's been a number of methods of accomplishing it but you cannot simply send jumps faster or you will get disconnected nearly instantly. Used to be you could teleport up to 6 coords at a time by sending action packet with invalid UID using the X/Y you wanted to go to (mini hops that could be sent as fast as you could send packets without flooding and you'd get there) Could also use invalid map ID to reset your last jump timestamp and then send a legit jump right after with spoofed timestamp + 2000 or w/e and it would work. There were a few other methods but those were the ones I've successfully used before.

Understand.

im going to try invalid jump's xD, Thanks

Quote:

Originally Posted by pro4never Because it uses a proper speedhack system. There's been a number of methods of accomplishing it but you cannot simply send jumps faster or you will get disconnected nearly instantly. Used to be you could teleport up to 6 coords at a time by sending action packet with invalid UID using the X/Y you wanted to go to (mini hops that could be sent as fast as you could send packets without flooding and you'd get there) Could also use invalid map ID to reset your last jump timestamp and then send a legit jump right after with spoofed timestamp + 2000 or w/e and it would work. There were a few other methods but those were the ones I've successfully used before.

very big Thanks,i completed it.. but
sorry another question ^_^:

What im doing without fatalstrike : find a monster - jump to the monster - attack it - sleep 250 - repeat(dcless)

What im doing with fatalstrike : find a monster - jump to the monster - attack it - sleep 25 - repeat(it kills about 10 monsters then dc)

the question :
how to make a very fast fatalstrike like other bot (Alchemy(your's), AI,Chrome,Genuis....) without dc

Quote:

Originally Posted by tariqx111 very big Thanks,i completed it.. but sorry another question ^_^: What im doing without fatalstrike : find a monster - jump to the monster - attack it - sleep 250 - repeat(dcless) What im doing with fatalstrike : find a monster - jump to the monster - attack it - sleep 25 - repeat(it kills about 10 monsters then dc) the question : how to make a very fast fatalstrike like other bot (Alchemy(your's), AI,Chrome,Genuis....) without dc

You don't need to jump to the monster if you have FatalStrike. At least not if it's in range of like 15 paces I think it is. You also need to sleep way more than 25 ms

Quote:

Originally Posted by tariqx111 very big Thanks,i completed it.. but sorry another question ^_^: What im doing without fatalstrike : find a monster - jump to the monster - attack it - sleep 250 - repeat(dcless) What im doing with fatalstrike : find a monster - jump to the monster - attack it - sleep 25 - repeat(it kills about 10 monsters then dc) the question : how to make a very fast fatalstrike like other bot (Alchemy(your's), AI,Chrome,Genuis....) without dc

There's a few limiters that can get you DC'd.


Packet flooding: Do not send action packets (jump, attack, shift, etcetc) faster than a certain rate or you get dc'd. Generally 80'ish ms is stable

Actions too close together: You can chain fatal strike very fast (60-80 ms) but do not try to jump at the same time or you will get dc'd. You need an internal delay between each action. Attack, jump, walk, etcetc all needs a delay between each.

Jump speed: sounds like your speedhack system works just fine but if you do not have a working one then jumping faster than ~750 ms will dc you unless you have an XP skill activated. Ensure your speedhack is working by spoofing update packets to client so you have cyclone + divine hare and then overwrite your client jumps to use your speedhack system. If you can jump fast without being dc'd then your system is working. if not then it's part of your problem.

Timestamp conflicts: depending on how you are speedhacking, some other packets can send their own timestamps exposing your cheating to server causing a disconnect (they don't generally ban for it but they instant DC if there's a timestamp mismatch)

Quote:

Originally Posted by pro4never There's a few limiters that can get you DC'd. Packet flooding: Do not send action packets (jump, attack, shift, etcetc) faster than a certain rate or you get dc'd. Generally 80'ish ms is stable Actions too close together: You can chain fatal strike very fast (60-80 ms) but do not try to jump at the same time or you will get dc'd. You need an internal delay between each action. Attack, jump, walk, etcetc all needs a delay between each. Jump speed: sounds like your speedhack system works just fine but if you do not have a working one then jumping faster than ~750 ms will dc you unless you have an XP skill activated. Ensure your speedhack is working by spoofing update packets to client so you have cyclone + divine hare and then overwrite your client jumps to use your speedhack system. If you can jump fast without being dc'd then your system is working. if not then it's part of your problem. Timestamp conflicts: depending on how you are speedhacking, some other packets can send their own timestamps exposing your cheating to server causing a disconnect (they don't generally ban for it but they instant DC if there's a timestamp mismatch)

yeah i think it disconnect after client send's the Tick packet(1012 as my think)

attack,action,walk,item usage, i maked the handler edit it and change the time stamp to Fake timestamp and add 3000 ms in the fatimestamp in every packet send

Quote:

Originally Posted by pro4never Because it uses a proper speedhack system. There's been a number of methods of accomplishing it but you cannot simply send jumps faster or you will get disconnected nearly instantly. Used to be you could teleport up to 6 coords at a time by sending action packet with invalid UID using the X/Y you wanted to go to (mini hops that could be sent as fast as you could send packets without flooding and you'd get there) Could also use invalid map ID to reset your last jump timestamp and then send a legit jump right after with spoofed timestamp + 2000 or w/e and it would work. There were a few other methods but those were the ones I've successfully used before.

but why TQ doesnt make the time stamp in server side only to avoid speed hacks ?

Quote:

Originally Posted by tariqx111 but why TQ doesnt make the time stamp in server side only to avoid speed hacks ?

To those who were more heavily involved in writing bots/hacks, please feel free to correct me if I explain this wrong.




The timestamp the client sends is a representation of when packets were sent. Because of how TCP works, packets may take a wildly varying amount of time to arrive at the server and be processed. They are written into packets so the server knows when the packets were originally sent (Time since client's computer booted)


The client can trick the server in two ways historically. I cannot verify which (if any) if these methods will still work.

Method 1

REDUCE the timestamp every time it's sent. Due to the way the server processes the message, it will cause an error in the math and instead show that the time since last jump/walk/etcetc is essentially uint.max. The reason for this happening is when you say...

timeSinceJump = lastJumpStamp - currentJumpStamp

If the data types will not allow for negative numbers and the data is not verified first then you end up with something like...

100 -101 = 4,294,967,294


Method 2

You can trick the server into essentially ignoring the previous timestamp from it's calculation if it recently re-set your position. You can do this by sending your jump as an invalid map.

The server (rather than disconnecting/banning you) will try to re-sync your client with its proper position by sending the syncLocation general action subtype to the client. In this process it removes your previous jump timestamp allowing you to freely send another jump packet without being flagged as speed hacking.

Note: In manual jumping you must block the sync packet to the client or else it will teleport you backwards every time you try to jump.

Quote:

Originally Posted by pro4never To those who were more heavily involved in writing bots/hacks, please feel free to correct me if I explain this wrong. The timestamp the client sends is a representation of when packets were sent. Because of how TCP works, packets may take a wildly varying amount of time to arrive at the server and be processed. They are written into packets so the server knows when the packets were originally sent (Time since client's computer booted) The client can trick the server in two ways historically. I cannot verify which (if any) if these methods will still work. Method 1 REDUCE the timestamp every time it's sent. Due to the way the server processes the message, it will cause an error in the math and instead show that the time since last jump/walk/etcetc is essentially uint.max. The reason for this happening is when you say... timeSinceJump = lastJumpStamp - currentJumpStamp If the data types will not allow for negative numbers and the data is not verified first then you end up with something like... 100 -101 = 4,294,967,294 Method 2 You can trick the server into essentially ignoring the previous timestamp from it's calculation if it recently re-set your position. You can do this by sending your jump as an invalid map. The server (rather than disconnecting/banning you) will try to re-sync your client with its proper position by sending the syncLocation general action subtype to the client. In this process it removes your previous jump timestamp allowing you to freely send another jump packet without being flagged as speed hacking. Note: In manual jumping you must block the sync packet to the client or else it will teleport you backwards every time you try to jump.

i already know about this and i have coded a speed hack without dc,,

I'm aware, I was explaining WHY they work :P

Quote:

Originally Posted by pro4never I'm aware, I was explaining WHY they work :P

xD , but they can use timeGetTime() in server side and the botter can not change the time stamp any more ?

Quote:

Originally Posted by tariqx111 xD , but they can use timeGetTime() in server side and the botter can not change the time stamp any more ?

Yes, but this is TQ.

Quote:

Originally Posted by tariqx111 xD , but they can use timeGetTime() in server side and the botter can not change the time stamp any more ?

They cannot rely on that measurement because of the ping variation.

Yes, server side time needs to be used and compared against the received timestamps BUT for accuracy in a non exploit environment requires the client timestamp.

Quote:

Originally Posted by Smaehtin Yes, but this is TQ.

Lol'd. That was my though.