Jump to content

Welcome to DreamBot!

Download for Free

Supercharge Your Bots

Run unlimited bots today using DreamBot's Covert Mode and
stay more protected.

Upgrade Now
Frequently Asked Questions
  • Are you not able to open the client? Make sure you have Java 8 installed
  • Still not working? Try downloading and running JarFix
  • Help! My bot doesn't do anything! Enable fresh start in client settings and restart the client
  • How to purchase with PayPal/OSRS gold? You can purchase vouchers from other users
  • Try asking for help in the chatbox
OSRS Gambling

Interested in advertising your business? Reach out today!

Download the DreamBot client today!

Things you may need to know about the RS engine

Recommended Posts

Some of you may not have as much experience in Runescape hacking as the developers or some of the more advanced scripters, this thread's objective is here to help you understand some of the important structure of RuneTekk 3 engine. 




Each world has the same services, JS5/World/Game/HTTP. When you first connect you indicate which service you'd like to use, 15=JS5, 14=Login Availability, 16=Login, 17=HTTP. From there the protocols differentiate. The login protocol uses RSA to encipher the sensitive session data, and it's impossible unless you factor the keys and yeah good luck doing that, to grab the ISSAC cipher seeds used for randomizing the game packet ids.


Game packets are shuffled every build and make it nearly impossible to create a packet bot. It also makes it a bitch in emulation to port multiple clients to the same server. There are also special types just for game packets which make it hard to read information over the wire. Such as ByteA, ByteS, ByteN, various endian types.




Cache system is exactly what it sounds like. Its a cache entry file system where the expectation is that files will grow in size and be overwritten. I won't get into detail about how that works exactly because it's slightly complex. Jist is that there is a blob file where all entries are contained, and index files where references to the first block (a 520 byte chunk of information in the block which has a reference to the next chunk of information) are contained. Blob file is main_file_cache.dat2. Index files are main_file_cache.idx0, etc


All entries in the cache are encapsulated in a container which contains a byte which describes the compression, a compressed and optional uncompressed size, then the compressed data. Container payloads can also be optionally encrypted. They are for landscape block files.


Index 255 is reserved for meta tables for indices, an index contains entries of a similar structure or purpose. All configurations are built in a similar manner, a collection of opcodes and data with the 0 opcode being the end of file.


Entries in the cache, as defined in the meta tables can be named. Djb2 hash is used. Linear hash tables are used for fast lookup. Meta tables also define the revision of entries. Meta tables, depending on implementation, have a revision as well.


JS5 is the transfer protocol to request and check for entry updates in the cache. Its similar to HTTP chunked transfer. I say similar, but not exactly. 




I define the scene as the virtual space that the world exists as. In newer engines this space can be variably sized however historically the default size is 104 by 104 tiles. Runescape map blocks however are 64 by 64 tiles and a lot of their processing is done in 8 by 8 chunks. When you reach the edge of your scene, up to 16 tiles away it is rebuilt and it is recentered at your current position. Landscape map blocks are encrypted using XTEA, and the keys are provided when your scene is rebuilt for the regions that your client needs to decrypt.  


From the API you can grab any entity that is within your scene without seeing them. However I think that there may be a fog of war mechanic to prevent this in its entirety for entities that are not apart of the natural landscape, projectiles, mobiles. I have not tested that in great detail, and that's a nuance of the server. I'd just expect it to be a behavior.


Your client keeps a matrix of information used in finding paths to certain objectives. This isn't just organized as a buffer of data which represents which directions you can navigate but rather where walls, occupants exist, and tiles are blocked. A good resource for this, since they use the same class in every engine, to take a peek at the API. It also defines a way to determine  line of sight. Not as important.




Widgets is a pretty loose term thats been thrown around a lot. I prefer using the terms interfaces and components, that's how they are named in the cache. They make up the user interface. Widgets have a type, along with other data and widgets have similar fields even if they arent the same type the way they are decoded is different. Around the time of OSRS, because of the move to CS2 jagex has two formats for widgets. The old format was used in their older engine, obviously.  Widgets are loaded ONLY when they are open, so a good way to determine if a widget is open is if the index in the widgets array is non null.


The client has a scheme where the fixed and resizable HUDs are separate widgets. Then from the server, widgets are mapped to the opened HUD widgets which represent the different tabs, or windows you may have open. This is a newer feature in the Runescape engine since about revision 400. In the older engines they were slots for tabs, windows, and the chatbox.


Widgets have children which are dynamically created by scripts. In the API they are called 'grandchildren'. I'm not a fan of the naming, they really aren't grand children they are children of widgets. Widgets make up user interfaces.


Client scripts, or widget scripts can be executed from the server to do tasks it would take multiple packets to do. So its more efficient.




Configs are better named variables. They are just a block of memory reserved for a variety of states for the player save. They include object states (farming states), quest states, settings, etc. From variables you derive bit variables or varbits, and player variables or varps. Internally on their servers Jagex has variables for minigames, npcs, and other entities. They only expose the mentioned to the client.

Share this post

Link to post
Share on other sites

Do they really encrypt the map tiles?


Do you have any insight into why that is? Seems unnecessary to me, but idk anything about game development.

To prevent bots from easily being able to calculate paths across the map, and to make it harder to emulate their game without getting the keys.

Share this post

Link to post
Share on other sites

To prevent bots from easily being able to calculate paths across the map, and to make it harder to emulate their game without getting the keys.


Makes a lot of sense!

Share this post

Link to post
Share on other sites

I wanted to try and help people who may need this resource, then realized theres a lot I would want to talk about. I may just end up writing a small book of what I know. Thanks guys. 

Edited by sini

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...