Section 1 - The theory
Part A: Why we do it this way, and why it works
Seeing as jagex finally got off their fat buts and decided to addin some deob and action forcing detection we can't use them methods any more. People have tried to figure out ways of bypassing this detection, but it's pretty much impossible. You see, jagex managed to add an event logger into their client, this allows them to see mouse clicks and such; this means that if you suddenly attack an NPC and you haven't clicked it, they know your autoing. Similarly, for deobed clients, they can detect if method modifiers have changed, i.e. when "final static void kaboom(int i)" is altered to "public static void kaboom(int i)" they know it's been changed and give you a banstick.

Bytecode bots, unfortunately just as bigger failure, if the fact that they take ages to update doesn't put you off, how about the fact they can detect if you run from main() and if you use the loader / navigate through the RS website (note: this also effects deobs).

So well, where does that leave us? Fugly color clickers? Nah, fortunately for us, we can create a bot that doesn't use deobs, uses the RS website and loader, and injects its bytecode at runtime. "WOWOHWOW" yes
. Any bytecode library should do the job, but in this tutorial I will be using "BCEL", seeing as it's fairly efficient, and pretty flexible (with a good API doc).

Part B: How the bot works
Okay, now you may be thinking how do we do this then, well heres the theory:
First off, we navigate through the RS site, using a "Spoof Browser", to look like a real user using a real browser (in this tutorial i'll be spoofing firefox, but it's up to you).
The bot will then select the world that you would like (by parsing the html code and finding the URL (atleast this tutorial/my bot does, ARGA finds the url from a world list)).
The bot will then load the RS loader (the archive and code files will also be parsed from HTML). The loader will then proceed to load in the RS classes, we then, right under the loaders noise (infact this is done slightly before the process is started), inject some nifty code that makes the loader load the classes through "our class loader" rather than java.lang.ClassLoader. This ultimately allows us to "swap" in our preloaded class files (these will have undergone the transformations (before the whole sequence starts, this can be done through a one off standalone updater or as my bot, and this tutorial will, before the applet is loaded (thus every time the bot is loaded).
Now we have our bot running, "yay" this means that our AccessorMethods (and scripts that extend it) can access all the bots functions such as sendPrivateMessage(String s) etc. etc.
via instance reference and a nifty little interface.

To summarise:

Bot Loads through batch -> Preloads a "static RS jar" -> navigates through RS parsing the HTML for required info -> loads RS -> swaps in our "preloaded classes" -> accesses them through instance reference (using an interface)

There are also a couple of other things, rather than action forcing, we "click", almost like a color clicker but not quite. We still use similar methods to the days of action forcing, such as getting the objects co-ords, we then do a "World to Screen" conversion, and click around the result (using some human like algorythm). In this tutorial I will send the events down the event queue for ease, however there are several methods.

This method also means that if programmed well enough, the bot is also capable of updating itself. However obfuscation makes this a PAIN IN THE ASS.

Section 2 - Building the basic applet
Part A: Building the basic applet
Ok, I thought you might be eager to get into some programming, so I thought we'd get started, nothing to deep mind; we have more theory to learn before that

We are going to build the simple applet loader, this will be detectable because we won't introduce the loader hack until section 3.

I presume you know java to a suitable level, can script fluently for ARGA and have made several programs before (old bots help).

I also recommend using a suitable folder structure and a good IDE, I will use IDEAJ.

Okay, so get yourself something like this setup:

Code:

package com.fusionbot.bot;

/**
    @FusionBot by ownagesbot
    This code is not allowed to be used without explicit permission by the owner
    The code is wrote purely for educational purposes
    All usage must fully credit the owner
*/
public class Bot {
    int world;

    public static void main(String[] args) {
        if(args.length == 1)
            new Bot(Integer.parseInt(args[0]));
        else
            System.out.println("Usage: Bot <world>");
    }
   
    public Bot(int world) {
        this.world = world;
    }
}

Join now!


Just a bit of basic OOP to begin with.
Okay, so every applet needs an AppletStub, this tells it the parameters from whatevers calling it, the codebases and all the information the applet needs, so it's time to build one.
Under

Code:

this.world = world;


Add an instance reference to your bot applet stub, appropriate naming should be used, for such I recommend BAS or something. With the class name BotAppletStub.
For now, BotAppletStub should look something like this:

Code:

package com.fusionbot.bot;

/**
*  @FusionBot by ownagesbot
*  BotAppletStub.java
*  This code is not allowed to be used without explicit permission by the owner
*  The code ...

This is a preview of the whole essay