Mobile bot development


#1

Anybody else excited to see Runescape coming to mobile? Runescape on Mobile

I’ve already been researching the Dalvic Virtual Machine, so I hope it gets ported to Android. I noticed a couple of weeks back that they were going to make the switch to mobile when I started a new account for the first time in years and it reminded me of a mobile game I played called “Celtic Heroes”. Everything was in place for the switch to mobile and now it’s official.

I’m going to start on an apk to Java source code decompiler using either ANTLR or just building it from scratch. Hopefully we get to see some new fresh things and maybe it’ll revive the community. Who knows? :slight_smile:

I’m ready for Round 2.


#2

It’s gonna be fun making a private server out of this! I reckon protocol etc will be the same anyway so hopefully, it’ll just be a matter of changing the IP.


#3

It will be interesting whether they will use Java or something else to write this mobile client.


#4

It mostly depends on what platform they’ll be using. Android apps are usually developed in Java then compiled to the dex file format (.dex file) and packaged in an Android package file (apk).

The apk is really just a zip file so you can use your favorite compression tool too inflate it. Inside the apk are some images, resources, etc. However, the most interesting thing is a file called classes.dex that contains all of the code needed by the application to run on the Dalvik Virtual Machine (DVM) in earlier versions of Android and the Android Runtime (ART) in later versions.

There are many differences between the dex file format and Java’s class file format since the DVM is a register based machine while the JVM is a stack based machine. I’d expect some mild obfuscation in the beginning, but more aggressive obfuscation the older the app gets as I think ART will actually compile Dalvik Executables directly to native code.

Native code has many more tricks up its sleeve when it comes to obfuscation as Jagex will have the ability to implement the same protection as more popular games like WOW, etc. Or come up with new variants of their own.

If they chose to develop for the iPhone iOS then it would be written in objective C. Which is what I’m researching now as well.

Summary

What’s in an APK? What’s the difference between the DVM and JVM? What are Jagex’s options concerning obfuscation?


#5

To be honest, a bit of me would like to see a modern attempt based on computer vision rather than code injection.
Something with OpenCV maybe, but relying on pattern recognition instead of colour recognition.


#6

I have done research into OpenCV object recognition algorithms as well. The state of the art is probably SURF or ORB (at least the respective research papers were hinting at massive speed improvements). However, in practice, algorithms like SIFT are used. I think a mix of both CV and bytecode instrumentation are a good way to go using one as a failsafe for the other. I was going to write a device driver (.sys file) and remove it from the doubly linked list structure Windows has containing currently loaded device drivers, etc. (basically go all out and implement this as a rootkit), but now that Runescape is going mobile, I should make a mobile rootkit. But the app will be released on the iPhone and I have not taken the necessary time out to learn Swift much less iOS internals.


#7

But then again, it might actually be worth looking into writing this as a memory bot. This option seems to be often overlooked because most people see Runescape running bundled inside the JVM which leads them to think that somehow it is inaccessible for memory monitoring and instrumentation, but that is a logical fallacy from the perspective of an x86 asm programmer. You can do quite a few interesting things with x86 and x64 asm as well: self-modifying code that can alter itself during runtime to save space, cross-modifying code that allows one processor to achieve code execution on another processor, etc., (concepts often overlooked or nonexistent in higher level languages)

The move to Graphics Processing Units (GPU) are another option. Modern GPUs have hundreds of cores. Each core has the ability to run a dedicated bot. GPU acceleration would allow for many bots to run in parallel using a single modern graphics card. This would enable us to imitate the numerous bots that are spawned using a network bot. This would also allow bot scripters to write scripts from the perspective of a parallel programmer (more advanced scripts incorporating collusion could be pioneered e.g., a Vorago boss script). It is possible to utilize GPU programming libraries like OpenCL or CUDA to speed up the process, so proprietary NVIDIA GPU architectures like Tesla or Volta (the latest) do not have to be reversed engineered.

The idea of a bot developed using the Java Virtual Machine Tool Interface (JVMTI) was toyed with in the past, but the hurdle was event monitoring. Too many events were firing off for the programmer to keep track of what was happening. By utilizing a GPU’s inherently massively parallel architecture, this limitation can be overcome paving the way for a JVMTI bot.

It is entirely possible to write a boot loader and then implement a lightweight OS or kernel made specifically for Runescape cheating.


#8

I don’t think you’d want to write it as a memory bot. The JVM is whimsical in that if it performs a garbage collection then suddenly your memory is moved out from underneath you.

I suppose you could theoretically monitor the GC, staying abreast of any heap memory compaction (memory relocation), and act accordingly but that sounds challenging.

I know little about the rest of what you’ve said.


#9

How about an advanced network bot. Machine learning and Artificial intelligence are both sufficiently advanced enough to get past this dynamic packet ID hurdle I keep hearing about. And maybe there is an even better or easier way in practice. I am not sure; I never made it deep enough into the client to see that obstacle.


#10

So as far as packet capture bots go, they don’t really work either (without interfering with the integrity of the client).
When you login to the game, the client uses RSA to establish a shared secret with the server. The client and server then use this shared secret to seed an ISAAC cipher, and that cipher deterministically modifies the packet id when sending the packet.

Because the game uses a TCP stream, and there’s no risk of packet loss within the context of the TCP stream itself, the cipher stays in-sync at both ends and this scheme works.

Now you can thwart this by extracting the shared secret from the client, which would let you identify the true packet id just as the server does (by keeping your own ISAAC cipher in sync with the client’s).
This could be achieved by manipulating the code such that the secret, once mutually established by client and server, is made retrievable by you.
However this then gives them the opportunity to detect your actions since most people would inject code to do this.

At the end of the day, I’m not entirely sure what the state-of-the-art is when it comes to JVM class integrity. Like if you use ASM / BCEL / etc to do code injection then I don’t know what the conditions needs to be for detecting that.
I’d honestly expect though that maintaining confidentiality of your approach, along with credible game play, would go a long way to getting away with it. I’m sure I’ve read Jagex remarks where they’ve implied that at least some of their bans are behavioural-based (overly mechanical play, inhuman playtime, etc with respect to a behavioural baseline).


#11

I have no idea what @unlimitedorb is saying but whatever lothy has said is pretty general knowledge in the rsps scene.

They wouldn’t use objective c anymore, they have now killed it by creating swift.


#12

Well, yes my-swagger, however, I don’t think it has been written as clearly before.

Swift code co-exists along side your existing Objective-C files in the same project, with full access to your Objective-C API, making it easy to adopt.

If they were already writing code for Runescape on mobile before Swift was released, they may just keep their old Objective-C code and make it interface to their newer Swift code. However,

Swift 4
The powerful programming language that is also easy to learn.

Swift is a successor to both the C and Objective-C languages.

it would probably be best for them to use Swift exclusively and if they have Objective-C code lieing around to eventually port it all to Swift code instead of interfacing it with Swift code.

I suppose that makes you correct. I edited my post.


#13

It’s actually really dumb that Apple even used Objective-C in the first place tbh. They’re literally the only people that use it and failed to see that C++ is superior.