Most of these names come directly from the NXT/TFU clients, though a few
are made up as we don't know the official name.
Signed-off-by: Graham <gpe@openrs2.org>
I think it's actually fine to stick the jars in the nonfree/lib folder.
When we package up the entire OpenRS2 distribution, the fat jar is
placed in the lib folder, so using nonfree/lib is consistent with that.
Signed-off-by: Graham <gpe@openrs2.org>
These effectively duplicate the master index tables, but in a less
flexible manner - as they don't support importing a master index where
some of the indexes are missing.
This commit also combines MasterIndexImporter with CacheImporter, to
make it easier to re-use code.
Signed-off-by: Graham <gpe@openrs2.org>
This is in preparation for adding a new deob module which invokes the
bytecode deobfuscator, decompiler and AST deobfuscator in turn.
Signed-off-by: Graham <gpe@openrs2.org>
This is slightly per correct than nonfree/lib, as the /lib
directory is for architecture-specific code. The original client code is
not architecture-specific.
Signed-off-by: Graham <gpe@openrs2.org>
Closes#116.
This commit also changes the output directory from
nonfree/var/cache/bundle to nonfree/var/cache/client.
Signed-off-by: Graham <gpe@openrs2.org>
Excluding the 0xFF trailers, the first block is actually 512 bytes, and
the remaining blocks are all 511 bytes. I had mistakenly written the
code and tests on the basis of all blocks being 511 bytes.
The Js5ResponseDecoder now works with OSRS.
Signed-off-by: Graham <gpe@openrs2.org>
I have a small collection of these from when I ran a service that polled
the JS5 server for the master index back in 2009. We'll probably be able
to find some in old Rune-Server threads too.
They'll be useful for verifying caches with an unclear provenance.
Signed-off-by: Graham <gpe@openrs2.org>
I have spent a while thinking about the best way to implement this,
especially after I discovered that OSRS treats the packets sent during
the handshake stage as normal packets (see share/doc/protocol/login.md
for a longer explanation).
I have settled on a design where the same Rs2Decoder and Rs2Encoder
instances, which deal with decoding packet opcodes and lengths, will
remain the same for the entire connection - unless it switches into a
mode where a completely different framing scheme is used, such as
JAGGRAB and JS5.
Rs2Decoder and Rs2Encoder both support optional opcode encryption. The
initial cipher is set to NopStreamCipher. It will be set to an
IsaacRandom instance during the login process.
As the scrambled opcodes used in-game overlap with the opcodes used
during the login process, a class called Protocol is used to represent a
set of opcodes that can be used in a particular state. The protocol can
be changed at any time. Rs2Decoder sets isSingleDecode to true initially
to help do this safely, but once in the final in-game state this can be
disabled for performance.
Unlike previous servers, like Apollo and ScapeEmulator, intermediate
frame objects are not used. Rs2Decoder and Rs2Encoder call PacketCodec
to directly translate an inbound ByteBuf into a POJO, or an outbound
POJO into a ByteBuf. This saves a memory allocation per packet.
PacketCodec implementations must provide both an encode() and a decode()
method for every packet. This will ensure the library is usable as both
a client and server, allowing the development of tools, such as a JS5
client, a game server stress-tester or even a proxy server for
inspecting the flow of packets.
PacketCodec implementations may optionally override getLength() to
return their exact length, to optimise the size of the ByteBuf passed to
the decode() method. (It is not necessary to override getLength() for
fixed packets, as the size is already known.)
The 256-element packet length array is automatically generated by the
Protocol class based on the length attribute of the PacketCodec objects
passed to it. This is less error-prone than populating the array
manually. However, it does mean stub implementations of every packet
packet will need to be provided during development - all lengths must be
known in advance to ensure the client and server remain in sync.
For the moment, it is legal to throw NotImplementError from a decode()
method. Rs2Decoder catches this exception, prints a warning and then
proceed to the next packet. Once all packets have been implemented, this
code may be removed.
Signed-off-by: Graham <gpe@openrs2.org>
Spotted by Desetude.
I think this was an accident, as the similar Js5Index.Entry class can't
be a data class (as it contains an array).
Signed-off-by: Graham <gpe@openrs2.org>
