Printable View
Anyone heard of any successful packet injections between the client and server?
Seeing how ShowEQ has done so much of the foot work to decrypt the packets flying between the server and client I was curious if anyone's successfully done any sort of packet injection..
Not that I know what it is or ..
anything..
:P
yes, you could feasably do this, and still get caught when the server does its check on the returned data.
there is very little client side anymore that isnt server side verified due to live memory hacking (which is basicly duplicating what your asking for, and a hell of a lot easyer)
I knew some server side checking had to be in place but I didn't know how much. And I'm not going to risk my accounts to find out either :)
Thx Circles! I guess some noob like me has to ask this question once every 6 months or so.
What you want to do (and yeah, I'm too chicken-**it to to do it too) is avoid CHANGING the data that gets sent, but change the WAY that it is sent. Many of these techniques require that you be in the middle of the communication. For example, you could be on the Windows box running EQ or you could be on a box that's acting as router/filter. Under Linux you could, for example, write a user-space iptables filter that watches and manages the EQ data-stream.
Here are some examples of how you might manage the data stream to your advantage (mostly by exploiting the fact that the protocol is unreliable in the first place, so we know the client and server need to cope with slow, duplicated or delayed packets and cannot assume they indicate cheating):
1. Delay or block client-side updates that are unfavorable.
This is a simple tactic. One way you might do it is to take updates that you don't particularly like from the client and randomly delay and/or block them getting to the server. This is a statistical hack meant to skew the bell curve in your favor. I don't know what unfavorable updates the client might generate (vs. server-side decisions).
2. Delay client-side updates that come in pairs to synchronize the pairs.
The example I can think of here is swapping weapons. If (and again, I'm guessing at the packet stream) you had a "remove weapon1 from slot" and a "place weapon2 in slot" message, you would want to make sure that they go in together.
3. Block incoming updates that cause the client to switch state.
Here you might prevent the client from knowing that you had dropped below certain thresholds (e.g. 0 mana, 10%HP, 0 HP). The client will continue in its previous state. It would be interesting to see how the server dealt with this. Would it accept combat commands from a client whose character had already died server-side? Could you get off that spell that was in mid-cast as you die if the client doesn't know it's dead? Testing would be required.
4. Duplicate messages.
It's not clear to me how smart EQ is. Does it use a sequence number on client updates? Would it know that, say, a combat message like a weapon swing from the client was a dup? The server does get duplicated packets, that can't be avoided when you're using UDP. Are there cases where it uses them both? If you could cause your character to swing just 10% more often than they do by default, that could change things quite a lot.
There are some other things I've thouht about. One of the things that gets me is that it seems the server keeps track of players as a vector. That is, you have a position, direction and velocity. However, when the client and the server disagree about the distance traveled, the servers seems to adjust to the client's pov.
The best example of this is the lag-induced stutter-run you see in places like the bazaar. Someone will "run" past you several times as they run forward, warp back, run forward, etc. In this case, what would happen if you introduced that lag deliberately when the update might be detrimental? For example, if you try to chase a mob, but move past it. What if the client never got the server update saying that it had passed the mob?
Another example: let's say you're running along a ledge (e.g. in Katta) and you simply don't allow the client to see (or send to the server) updates that say that you've run off the edge? Could you prevent yourself falling off?
All of these techniques need to be applied carefully. You would have to test each one very infrequently so that generic lag problems mask your activity. Test each client and server response to your changes and develop a model for how the server is dealing with these changes in the data stream.
It could be very interesting...