Speed Hack

09/19/2011 16:45 Belth#1
Quote:
Originally Posted by Ian* View Post
1 method - send the attack packet and set the target uid to your own characters uid with X/Y coords at the spot you want to jump, it has like a 5 step range that way.

another method is to replace your original jump packet with another one that has an invalid map id, followed by sending another jump packet with timestamp + 2000.
you do that for each real jump the user makes, just block the real jump and send one with invalid map id and another with timestamp + 2000, it has regular jump range.
I'd just like someone to verify if both of these exploits have been fixed. The first simply disconnects the client and the second pulls back.
09/19/2011 17:03 IAmHawtness#2
Quote:
Originally Posted by Belth View Post
I'd just like someone to verify if both of these exploits have been fixed. The first simply disconnects the client and the second pulls back.
If it pulls you back, you're obviously not blocking the pull-back packet.
09/19/2011 17:40 Belth#3
Quote:
Originally Posted by IAmHawtness View Post
If it pulls you back, you're obviously not blocking the pull-back packet.
I feel like I got trolled. It never occurred to me to block a pull-back since that is essentially the server telling you where you are in it's database so it wouldn't matter... Nevertheless I blocked the pull-back, tried speeding again and eventually got a well-deserved invalid jump when I jumped further than I should've from the pull-back point.

Edit:

I was too hasty in my response. It actually works and now I feel like an idiot :p

Still getting the occasional disconnect.
09/19/2011 18:03 IAmHawtness#4
Quote:
Originally Posted by Belth View Post
I feel like I got trolled. It never occurred to me to block a pull-back since that is essentially the server telling you where you are in it's database so it wouldn't matter... Nevertheless I blocked the pull-back, tried speeding again and eventually got a well-deserved invalid jump when I jumped further than I should've from the pull-back point.

Edit:

I was too hasty in my response. It actually works and now I feel like an idiot :p

Still getting the occasional disconnect.
Yeah, that method is kinda shit to be honest :p
09/19/2011 18:11 pro4never#5
There's also methods with timestamp altering where you basically overwrite all outgoing stamps and some with doing negative stamps to basically screw with hope the server performs math on the timestamps (uint cannot be negative therefore if your new stamp is less than old it will loop to max value or w.e)


I think those are all the well known public speed methods.
09/19/2011 18:17 Belth#6
Quote:
Originally Posted by IAmHawtness View Post
Yeah, that method is kinda shit to be honest :p
Do the more stable methods involve time stamp manipulation as well?

Quote:
Originally Posted by pro4never View Post
There's also methods with timestamp altering where you basically overwrite all outgoing stamps and some with doing negative stamps to basically screw with hope the server performs math on the timestamps (uint cannot be negative therefore if your new stamp is less than old it will loop to max value or w.e)


I think those are all the well known public speed methods.
Didn't see your post initially. I'll try that later today.
09/19/2011 23:25 pro4never#7
I may not quite fully know the timestamp method. I know I tried a few of the well known ones like... a year ago and got rather confused. The one I ended up using involved the invalid map/blocking pullback packet as well as modifying timestamps.

It worked reasonably well but was again, far from perfect especially when doing more complex tasks then just jumping really fast.


Meh, it worked though.
09/20/2011 03:19 Belth#8
Ok I tried a few things besides the invalid map method including:

1. Replacing original time stamp with (TimeStamp+2000) and (TimeStamp-2000) alternatively.

2. Replacing original time stamp with -1 every other packet.

3. Replacing original time stamp with (TimeStamp-10000) every other packet.

They all worked to a degree but eventually disconnected with "invalid jump". When just faking cyclone and jumping manually they work for a fairly long time but in complex attacking/looting they disconnect after just a few jumps. Here's an open invitation to anyone willing to point me in the right direction regarding a stable speed hacking method (PM or otherwise) :p

Another thing I'm interested in is how/why TQ handles/uses time stamps. Why do they bother? I'd figure just get one time stamp and keep a running timer until the client disconnects.

One more thing. What is the purpose of the server's "jump confirmation" packet? I mean it's not like say if there's a discrepancy between where the client thinks it is and where the server says it should be that the client will update itself (the pull-back packet does that).

/semi-rant
09/20/2011 10:51 IAmHawtness#9
Quote:
Originally Posted by Belth View Post
One more thing. What is the purpose of the server's "jump confirmation" packet? I mean it's not like say if there's a discrepancy between where the client thinks it is and where the server says it should be that the client will update itself (the pull-back packet does that).
The jump response packet sets your coordinates. In the client, there's more than one variable that contains your coordinates, there's at least two variables - one that contains your visual coordinates, and one that contains the server-side coordinates.

The "server-side" coordinates are updated when you receive the jump/walk response packet, and they are used to determine for instance if you're in range when attacking a target. That's also why the higher ping you have, the more often you get the "The target is not in range" message when PvP'ing.
10/11/2011 02:35 lffmmcjf#10
ok
10/11/2011 07:04 Cyanogen#11
The first method is known as the APICT hack (Attack Packet Invalid Co-ordinate Teleport) and has indeed been patched. You didn't HAVE to set your own player id, any valid entity id worked as long as the entity was within attack range and not at the co-ordinates specified in the packet, naturally your own ID would always be in range.so that was primarily used. This method did not relocate you client side, so a relocate was required locally as well.

The second method is overly complex, the invalid map id is not required. You just have to make sure you are modifying ALL packets with timestamps, not just the jumps. Also be careful as some packets have timestamps that are XORed with the player id.
06/07/2012 22:47 holi1#12
dwadwadawdawdawd
06/07/2012 23:11 _fobos_#13
Quote:
Originally Posted by holi1 View Post
dwadwadawdawdawd
We have a Necromancer <3 :rolleyes:
Do you like dead things? I mean it's perfectly ok to admit so, it's a little gross; but to each their own right? Have a nice day!