SRL Archive - Senior Scripts and Snippets

[YOUTUBE]DSESHp4vXTU[/YOUTUBE]

My bot listens to sent and received internet packets. It can also modify, block and send packets. Just made a script which can tell the location of the tile you walked to.

This is what the script looks like. Not releasing the bot. Atleast not yet.

import java.additions.event.events.PacketEvent;
import java.internet.Packet;
import script.Script;


public class CoordinateScript extends Script implements java.additions.event.listeners.PacketListener {
    
    @Override
    public boolean packetReceived(PacketEvent e) {
        return true;
    }

    @Override
    public boolean packetSent(PacketEvent e) {
        if (e.getPacket().len == 21) {
            Packet p = e.getPacket();
            if ((p.b[p.off+1] == 0) && (p.b[p.off+4] == 1)) {
                System.out.println("WalkedTo: ("+(p.b[p.off+16]*256+p.b[p.off+17])+", "+(p.b[p.off+19]*256+p.b[p.off+18])+");");
        
            }
        }
        return true;
    }

    @Override
    public void onStart() {
    }
    
    @Override
    public void onFinish() {
    }
    
    @Override
    public boolean loop() {
        return true;
    }
}

It doesn't show coords every time because sometimes the packets contain more information (perhaps mouse coordinates) which my script wont capture.

Sent packets are relatively easy to understand but received packets are difficult.

Doesn't use bytecode injection to the client.

Where'd you learn all this hubub from?!
Works via Java I assume? Not OGL/DX/Color?

Is this safe/undetectable I thought packet stuff was no good?

Sweet start looking decent so far, very interesting indeed keep updated with videos/pics!

From: YoHoJo
Where'd you learn all this hubub from?!
Works via Java I assume? Not OGL/DX/Color?

Is this safe/undetectable I thought packet stuff was no good?

Sweet start looking decent so far, very interesting indeed keep updated with videos/pics!

It's not detectable to only analyse the packets like that script does. However if you edit/block/create packets it couldwould be detectable (detectable <> detected) at least if done improperly. They might be able to detect the client though just like they could probably detect SMART.

How did I learn this? When I heard about the method of rewriting the canvas to get colors etc like SMART does I figured I could rewrite the SocketOutputStreams to let my script decide what to do with incoming and outgoing packets.

Java? Yes.

u hav 4 rep squares now! <3

From: YoHoJo
u hav 4 rep squares now! <3

Thanks. In theory I could even make it so that when I close the client the bot would still continue to send packets but it would be extremely difficult to keep up with the protocol because sending just one invalid packet makes you disconnect and would be detectable. Perhaps I will try to make an autotalker, teleport or something else very simple this way in the future. Would save a lot of ram and cpu.

It's been a long time since I've heard about something like this. Looks very interesting, weequ, best of luck with it. :) Keep us updated.

This doesn't seem like a good way to identify packets since you don't have a packet id to work with and you're essentially guessing at the data order and format. Do you have any plans to learn the protocol (to avoid the guessing) or emulate the client (to eliminate much of the resource load)?

From: Method
This doesn't seem like a good way to identify packets since you don't have a packet id to work with and you're essentially guessing at the data order and format. Do you have any plans to learn the protocol (to avoid the guessing) or emulate the client (to eliminate much of the resource load)?

What do you mean with a packet ID? The sent packets can be pretty easily identified. And no I don't have any big plans with this as I know it's not gonna work.

Edit: Also I'm not guessing. I check what bytes change when I move North and what changes when I move East to find out :spongebob: Ofc they can change the protocol at any time but they don't do that often.

From: weequ
What do you mean with a packet ID? The sent packets can be pretty easily identified. And no I don't have any big plans with this as I know it's not gonna work.

Edit: Also I'm not guessing. I check what bytes change when I move North and what changes when I move East to find out Ofc they can change the protocol at any time but they don't do that often.

I hope it's clear what a packet id is. If not, it's the piece of data that uniquely identifies each packet. Presumably you just ignore the first byte of data (which should contain the id) and instead just try to manually parse the packet structure by trial and error or lots of data mining (the "guessing" I mentioned in my last post). Relying on parts of the packet to stay constant probably won't work out very well for very long, especially when multiple packets have the same size and are sent at around the same time.

They can and do change the protocol every time the client is updated, by the way.

If you're not interested in actually making this work (i.e. making an actual packet bot that doesn't need to override core Java functionality), then I guess this is irrelevant and doesn't matter much to you.

From: Method
I hope it's clear what a packet id is. If not, it's the piece of data that uniquely identifies each packet. Presumably you just ignore the first byte of data (which should contain the id) and instead just try to manually parse the packet structure by trial and error or lots of data mining (the "guessing" I mentioned in my last post). Relying on parts of the packet to stay constant probably won't work out very well for very long, especially when multiple packets have the same size and are sent at around the same time.

They can and do change the protocol every time the client is updated, by the way.

If you're not interested in actually making this work (i.e. making an actual packet bot that doesn't need to override core Java functionality), then I guess this is irrelevant and doesn't matter much to you.

I still don't get the packet ID thing. Does it identify a walking packet from mining packet and a mining packet from thieving packet? First byte I read is usually a "random" number but the server requires them in exactly the same order. Is the ID your talking about somehow hidden and how it can be accessed?

From: weequ
I still don't get the packet ID thing. Does it identify a walking packet from mining packet and a mining packet from thieving packet? First byte I read is usually a "random" number but the server requires them in exactly the same order. Is the ID your talking about somehow hidden and how it can be accessed?

There's no such thing as a mining packet or thieving packet, but yes, the packet id is used to distinguish between different types of packets. The number isn't random, but the packet id is encrypted using an ISAAC cipher. You'd either need access to the client (e.g. using reflection or editing bytecode) or you'd have to communicate with the server yourself to figure out the cipher's seed / IV that is shared between the client and server.

From: Method
There's no such thing as a mining packet or thieving packet, but yes, the packet id is used to distinguish between different types of packets. The number isn't random, but the packet id is encrypted using an ISAAC cipher. You'd either need access to the client (e.g. using reflection or editing bytecode) or you'd have to communicate with the server yourself to figure out the cipher's seed / IV that is shared between the client and server.

yeah now I know what you mean. One option is to block some packets, put the ids on a queue and every time a packet is sent to the server use the first id in the queue and put the new one at the end of the queue. Then you could send as many packets as you've blocked at any time assuming each packet only has one of those ids. Having the Isaac algorithm with the correct key would be most efficient though I guess.

From: weequ
yeah now I know what you mean. One option is to block some packets, put the ids on a queue and every time a packet is sent to the server use the first id in the queue and put the new one at the end of the queue. Then you could send as many packets as you've blocked at any time assuming each packet only has one of those ids. Having the Isaac algorithm with the correct key would be most efficient though I guess.

No, that won't work. For one, the server and the client share the ciphers, so blocking some packets but letting others through would result in the client and server becoming out-of-sync. In addition, it's incredibly likely that each packet will have a different encrypted id each time it's sent, so saving the encrypted ids is pointless.

From: Method
No, that won't work. For one, the server and the client share the ciphers, so blocking some packets but letting others through would result in the client and server becoming out-of-sync. In addition, it's incredibly likely that each packet will have a different encrypted id each time it's sent, so saving the encrypted ids is pointless.

it works because the server receives the ids in the same order as the client originally sent them. I've tested. But I think the client might sometimes send a packet that contains information about previous packets. Then you dc when that fails.