Introduction Into RS Client Hacking

[iJava]

Ok now I'm no expert but I'll give you guys a little insight into client hacking(RuneScape).

We'll begin with the basics,

Reflection

Reflection is a java library and is a way to read values from class files, this does not modify any class files, it just simply reflects a value so we can read it without being detected.

Injection

Injection in RuneScape client hacking is mainly used via ASM and BCEL which are both java libraries. BCEL was the old way and most new bots use ASM since it's got more of an active development. This involves modifying the class files in the RuneScape client to get values, we do this by using setters and getters to get values from the RuneScape client.


Hooks

Now you may have heard this term being thrown around before. Basically inside the RuneScape client there are many classes which contains fields, methods etc. A hook is a field/method so we use hooks to get data, for example say you had the hook for DisplayMode and it was kw.a then kw = the class and a is the field or method in which the data is stored, in this example it is the field. We get hooks by finding a pattern over multiple revisions for one field/method, for the DisplayMode hook I search for a field which uses java.awt.DisplayMode. So basically a hook is something which stores a value/ a method that we can use when creating a bot such as current position, we can return our current position by using a hook.


Updaters

Updaters are a hot topic in RS client hacking, they allow us to get hooks at the click of a button. We create patterns and use them in our updater and our updater prints out the hooks location. For this thread I'll be using the RSH Framework which can be found here http://rs-hacking.com/resources/index.php?dir=tools/rhf/, this was created by the developer of SCAR Freddy1990.

An easy way to hook a field is too find if it uses an import such as the DisplayMode field uses java.awt.DisplayMode; you can find this by opening a decrypted client with jd-gui(google it) the decrypted client for revision #688 can be found here, http://www.megaupload.com/?d=R99RI4RB thanks to Marneus901. So if we open this with jd-gui and navigate to the class "kw" in the left hand panel, once you open it you will see :

private GraphicsDevice b;
  private DisplayMode a;

Now if we look at the imports :

import java.awt.DisplayMode;
import java.awt.Frame;
import java.awt.GraphicsDevice;
import java.lang.reflect.Field;

As you can see two match our fields, this means that java.awt.DisplayMode is required for the field "a". Now we have to write our hook, if you're using the RHF framework you could do,

    package com.rshacking.updater.transforms;
     
    import java.util.Iterator;
     
    import org.objectweb.asm.tree.FieldNode;
     
    import com.rshacking.rhf.files.ClassContainer;
    import com.rshacking.rhf.updater.Transform;
    import com.rshacking.rhf.updater.hooks.ClassHook;
    import com.rshacking.rhf.updater.hooks.HooksList;
     
    public class Graphics extends Transform{
     
    @Override
    public boolean canActivate(HooksList hooks, ClassContainer cc) {
    // TODO Auto-generated method stub
    	return cc.containsFieldType("Ljava/awt/DisplayMode");
    }
     
    @Override
    public boolean execute(HooksList hooks, ClassContainer cc) {
    ClassHook ch = hooks.add("Graphics", cc.getName());
    Iterator<FieldNode> it = cc.getASM().fields.iterator();
    	while (it.hasNext()) {
    		FieldNode fn = it.next();
    	 if(fn.desc.equals("Ljava/awt/DisplayMode;"))
    		ch.add("DisplayMode", fn);
    	}
    return true;
    }
}

This means that if a field is using java.awt.DisplayMode that it will be recorded under DisplayMode. Now we just add this line under loadTransforms in our main updater class(check out rs-hacking.com for info on this),

updater.addTransform(new Graphics());

This will load our graphics transform and when you run it you should get this printed somewhere,

 ^ kw implements hooks.Graphics
 * getDisplayMode() --> field Ljava/awt/DisplayMode; kw.a

This tells us the class and field name of DisplayMode. I began hooking like this as they were the easiest to find and shouldn't break, I've been using this transform from #660 and it hasn't failed on me even after the bot nuke.


There are many other ways in which you can hook(different patterns) a field or method and this is just the simplest. Instead of looking through all the classes take a look at an updater log on rs-hacking.com and look for any imports such as the DisplayMode shown in the log then navigate to that class and work it out from there, however make sure that if you do this you use the same client that they used, they should provide it and it needs to be decrypted/deobfuscated.

Hopefully this gave you some idea on the inner workings of the rs client and bots if you managed to follow this the whole way.

 

[nissan nut]

Very educational for the average bot user. But what is with users posting there guides in the cheating section?

 

[iJava]

Not really a guide more of an informative thread, bots = cheating.

 

Sucks that since bot nuke, neither are possible :/

 

[iJava]

Sucks that since bot nuke, neither are possible :/

They are still possible just a lot harder, you can't stop reflection being used.

 

They are still possible just a lot harder, you can't stop reflection being used.

I know they are possible, the client is java anyways.

The randomized obfuscation that doesn't let updaters get hooks is the problem.

 

[iJava]

I know they are possible, the client is java anyways.

The randomized obfuscation that doesn't let updaters get hooks is the problem.

That's not hard to fix at all, you'd just have the bot send the jar that is being used to the updater(PHP) and then the updater would produce the hook locations.

Congratz on rank btw.

 

That's not hard to fix at all, you'd just have the bot send the jar that is being used to the updater(PHP) and then the updater would produce the hook locations.

Congratz on rank btw.

On each update of the client, old times, most of hooks didn't change in every update. and they were in classes whose code was always similar to last version. Finding and being able to update the updaters to get the hooks was easily.

Now that values are arranged in arrays with random indexes, the updaters can't use the values of last version and keep changing on every update.

Otherwise we could easily know the hook for the inv items or characters and reflect them.

 

[iJava]

On each update of the client, old times, most of hooks didn't change in every update. and they were in classes whose code was always similar to last version. Finding and being able to update the updaters to get the hooks was easily.

Now that values are arranged in arrays with random indexes, the updaters can't use the values of last version and keep changing on every update.

Otherwise we could easily know the hook for the inv items or characters and reflect them.

Not all are found in large arrays, it really just depends on the pattern you use and how strong it is. I know of people who have had the same pattern for their hooks which they created after the bot nuke and they haven't broke yet. That's about 20 revisions with them still working as they were. It's quite simple, base your hook of a weak pattern and expect a weak hook. Saying all this a lot of the hooks they currently have are those found outside of arrays and they are only beginning to work on the fields within the large arrays.

JaGeX have changed the way in which the client is loaded twice since the bot nuke and it has confused a lot of people, the gamepack.jar you now download is more of a loader.jar(pre bot nuke)and contains inner.pack.gz which is encrypted and contains what was in runescape.jar pretty much.

 

[iJava]

Bump.....