So as far as packet capture bots go, they don’t really work either (without interfering with the integrity of the client).
When you login to the game, the client uses RSA to establish a shared secret with the server. The client and server then use this shared secret to seed an ISAAC cipher, and that cipher deterministically modifies the packet id when sending the packet.
Because the game uses a TCP stream, and there’s no risk of packet loss within the context of the TCP stream itself, the cipher stays in-sync at both ends and this scheme works.
Now you can thwart this by extracting the shared secret from the client, which would let you identify the true packet id just as the server does (by keeping your own ISAAC cipher in sync with the client’s).
This could be achieved by manipulating the code such that the secret, once mutually established by client and server, is made retrievable by you.
However this then gives them the opportunity to detect your actions since most people would inject code to do this.
At the end of the day, I’m not entirely sure what the state-of-the-art is when it comes to JVM class integrity. Like if you use ASM / BCEL / etc to do code injection then I don’t know what the conditions needs to be for detecting that.
I’d honestly expect though that maintaining confidentiality of your approach, along with credible game play, would go a long way to getting away with it. I’m sure I’ve read Jagex remarks where they’ve implied that at least some of their bans are behavioural-based (overly mechanical play, inhuman playtime, etc with respect to a behavioural baseline).
