RuneScape Protocol

Hello I would like to take the time to discuss some things about the runescape server protocol, such as legal issues and some things that are good to know.

First on the list: legal issues.

Some people believe that the I/O protocol is copyrighted by runescape, when infact only few of the methods used are actually different then a regular DataOutputStream and a DataInputStream, and many other I/O libraries.
The thing is, runescape packets are split into pieces because in I/O you're never sure when all of the bytes are going to reach the server or the client. So what JaGeX did was develop a way to initialize access of writing packets and ending it when the packets are finished, and they are written as bytes..Also, updates are written in bits. For those of you who don't know, there are 8 bits in a byte, unlike an int or long. For example, an int is a 32 bit integer, which means it's split into 4 bytes.

Write an integer:

Code:

---

    public void writeDWord(int i) {
        buffer[currentOffset++] = (byte)(i >> 24);
        buffer[currentOffset++] = (byte)(i >> 16);
        buffer[currentOffset++] = (byte)(i >> 8);
        buffer[currentOffset++] = (byte)i;
    }

---

Write a packet: (note: this uses the ISAAC algorithm to ensure that packets are cryptographically secure.. I'll talk about that later.)

public void createFrame(int id) {
buffer[currentOffset++] = (byte)(id + packetEncryption.nextInt());
}

The point is, this protocol is widely used among thousands of applications you probably use, and not just in Java either.

In cryptography, ISAAC is a pseudorandom number generator and a stream cipher designed by Robert Jenkins (1996) to be cryptographically secure. The name is an acronym for:
Indirection
Shift
Accumulate
Add
Count.

What a pseudorandom number generator can do, is generate a random number from a seed, given the the equivalent seed, we can produce the same number again. Thus we use this for securing packets.

This is also, a very widely used method alongside RC4, of which it was inspired, for stream ciphering

Another thing that is nice to know about the server protocol is that, if you or someone else wrote the code, it is not illegal, as long as the code is not copyrighted or privately licensed.

The thing about winterlove is that the "stream" and "cryption" classes are both stolen from the 317 client..
It is deobfuscated code but the actual protocol remains the same, a server like hyperion, rs2dv, or any custom frameworks most likely use a custom packet system and ISAAC algorithm(there are a couple Java implementations.)

Part two: Things to know about clients

Clients are not illegal, although the cache is. Really jagex has no way of proving that the code was deobfuscated from their own, although they can prove it is done over a wide basis in the rsps communities. What they can prove: is that you are abusing their contracts by using and raping their images, models, sounds etc. And not to mention their cache format ;)

Really, this isn't a problem because by conventions of law, they can not prosecute for a crime being held in an over-sea or third world country, unless aided by a federal government. So a solution to this problem of hosting servers is that they must be hosted over seas, (or in a third world country) to avoid being prosecuted, although you may still be taken to court.

Another issue brought up in the past is that JaGeX may try to sue you, I mean, hell they've done it before for other things, i.e. frugoo in 06', or impsoft just a couple years ago. (if you want the link to the case summaries provided by the lawyers I would be happy to oblige)
The thing is, unless you're causing runescape major disruption by either stealing players or encouraging breaking of their terms of service of a massive scale, there's no way they will even notice your server.. You can avoid them going on your site by using terms and conditions on the splash page, this could be brought up in court and have all case evidence throw out that was gathered from your website, and JaGeX knows this. The only evidence they could possibly hold against you is evidence they gathered from THEIR servers.

Part three: Viruses in sources?

There is no such thing. It is impossible for text to contain viruses! I don't know how many times I've seen the first post for a release to be "virus scan pls"! It's annoying! Unless a person is releasing something that's super sketchy it's most likely legit, I've never... EVER downloaded a source containing a virus, and I've been at the rsps scene for the past 4 years.

Anyway, those are some of my discussion points, if anybody would like to add to any of this or discuss it you can here. Also I would be happy to answer any and all questions about any of the methods of encryption or I/O I have discussed in this thread.

The only reason the clients use a buffering system that is close to hte native buffering system is because the java numbering libraries are fucked. Java doesn't deal with unsigned integers at all, therefore it throttles numbering capabilities. Ints in c# are twice as large as ints in java purely because java forces signed integers.

Based on that logic, Java cannot conform to the standard web transmission libraries... The byte protocol on an internet pipeline is a number between 0 and 255. Well java's byte is -128 to 127... Pretty limiting. JaGeX has to use Java's built in system because java forces that limitation.


Based on part two, you can get around expensive offshore hosting by changing how you get cache. My current design, which uses a webclient and jagex's cache streaming protocol involves keeping only the cache stored offshore. Actually, it's zipped up and stored with a file host with a premium account. Upon startup, the server downloads the cache, then unzips it and works with it. It's perfectly legal because we're not storing it at all, and if they think I am, I shut down the game server and the cache is completely removed from the machine.

As for part three, you're partially wrong. While a source may not contain a virus, it can still be malicious... Using the java.rmi.* packages, the java runtime can exucute programs and naitive libraries. The java code can stream a download of a malicious application and run it before you even know. It isn't picked up by a virus scan until it's too late. Java can still be malicious, although it's very hard to do so discreetly.

I'd also like to add to point 3, much like Daniel said Java can still be used in malicious fashions, but not only that, many years ago in the dawn on RS development there was a user who will go unnamed, he became rather big and alot of people followed his sources, using his code bases.

What was most interesting was the fact that inbedded into this code was a segment which would at the time, take the users character details (username and password) and actually use those to crack into real RS accounts. This was highly effective back in the day as not only did every single one of his copies send all of this data back to him if there was a hit on an account, he never had to risk his own ip's with jagex, and people were just generally very foolish then to use their RS details on a server.

Also shows why having an understanding of the code you're using comes in useful, no-one using his sources really discovered this for a long time, took a few members of the old communities to raise flags to this for people to finally see sense.

So yeah, even though something may not be flagged by virus scanners, doesn't mean the code in the background isn't running some malicious processes.

I'm glad we've got there sorts of discussions going on, it might liven the section up.

Also why didn't Jagex just force the unsighed bytes Dan? I mean that's completely feasable in Java....

Quote:

---

Originally Posted by GhostSnyper

The only reason the clients use a buffering system that is close to hte native buffering system is because the java numbering libraries are fucked. Java doesn't deal with unsigned integers at all, therefore it throttles numbering capabilities. Ints in c# are twice as large as ints in java purely because java forces signed integers.

Based on that logic, Java cannot conform to the standard web transmission libraries... The byte protocol on an internet pipeline is a number between 0 and 255. Well java's byte is -128 to 127... Pretty limiting. JaGeX has to use Java's built in system because java forces that limitation.


Based on part two, you can get around expensive offshore hosting by changing how you get cache. My current design, which uses a webclient and jagex's cache streaming protocol involves keeping only the cache stored offshore. Actually, it's zipped up and stored with a file host with a premium account. Upon startup, the server downloads the cache, then unzips it and works with it. It's perfectly legal because we're not storing it at all, and if they think I am, I shut down the game server and the cache is completely removed from the machine.

As for part three, you're partially wrong. While a source may not contain a virus, it can still be malicious... Using the java.rmi.* packages, the java runtime can exucute programs and naitive libraries. The java code can stream a download of a malicious application and run it before you even know. It isn't picked up by a virus scan until it's too late. Java can still be malicious, although it's very hard to do so discreetly.

---

No, JaGeX uses buffer protocol like this because that's how it's done, even in NIO. But you are right about Java not supporting unsigned things, it's because the size is increased substantially when you add 255 to every 8 bits. Using a bitwise AND you can mask all but the last 8 bits of an integer.

Yes it is true, java applications CAN contain malicious software, really a source could contain a virus, just don't think that a worm is going to infect your text files. lol
But another thing is, few people in this forum or any other forum have the capability or writing something in java that could do damage, I mean 95% of the rsps community doesn't know what programming is lol it's all about the coding 662 and shit now

Quote:

---

Originally Posted by -fedexer-

I'd also like to add to point 3, much like Daniel said Java can still be used in malicious fashions, but not only that, many years ago in the dawn on RS development there was a user who will go unnamed, he became rather big and alot of people followed his sources, using his code bases.

What was most interesting was the fact that inbedded into this code was a segment which would at the time, take the users character details (username and password) and actually use those to crack into real RS accounts. This was highly effective back in the day as not only did every single one of his copies send all of this data back to him if there was a hit on an account, he never had to risk his own ip's with jagex, and people were just generally very foolish then to use their RS details on a server.

Also shows why having an understanding of the code you're using comes in useful, no-one using his sources really discovered this for a long time, took a few members of the old communities to raise flags to this for people to finally see sense.

So yeah, even though something may not be flagged by virus scanners, doesn't mean the code in the background isn't running some malicious processes.

I'm glad we've got there sorts of discussions going on, it might liven the section up.

Also why didn't Jagex just force the unsighed bytes Dan? I mean that's completely feasable in Java....

---

I agree, I left that out in part three that Java does definately have the capability to create havoc in a pc.
And they do force unsigned bytes, we just use 0xFF for unsigned bytes..

Code:

---

public void writeUnsignedByte(byte b) {
    buffer[currentOffset++] = b & 0xFF;
}

---

Like daniel said, java does not support unsigned integers natively so we have to use something like this, and do the same thing in reading..

Code:

---

public void writeUnsignedWord(int i) {
    buffer[currentOffset++] = (byte)(i >>> 24) & 0xFF;
    buffer[currentOffset++] = (byte)(i >>> 16) & 0xFF;
    buffer[currentOffset++] = (byte)(i >> 8) & 0xFF;
    buffer[currentOffset++] = (byte)(i) & 0xFF;

}

---

Thanks for posting guys. And fedexer, I know I was hoping some old members will come out of the wood work. And I'll probably be posting a lot in this section, I want to get her going again.

OH, and another thing to mention would be the words:

Word = 16 bit integer (short)
DWord = 32 bit integer (int)
QWord = 64 bit integer (long)
Big Endian = reversed byte order when reading/writing

A lot of people believe that the "stream" class is deaply obfuscated, but that's not true. When the first winterlove was made, the IO protocol was taken from the client and refactored,
317 Buffer: Class30_Sub2_Sub2
377 Buffer: Class50_Sub1_Sub2