PWI Java API

Page 1 of 2

07/26/2013 21:49 nb-ben#1

Hi there,

My name is Ben and I am a Java developer. I am the author of 3rxbot for Runescape if any of you have ever heard of it (it has been a while).

I believe I have something to offer to the community, which seems to be releasing a lot of modified clients. I have been working on creating an abstracted API for scripting for PWI (this is easier than it sounds).

Now the main benefits of this is that it's easy for any Java (or other semi-mature) developer to make and release scripts, and that between versions your scripts continue to work.

Once you have a set of all the required commands at your immediate disposal, creating scripts to automatically farm instances and such becomes much easier and practical, which is where I see the potential of this endeavor.

I have began experimenting with JNA and had some success, however I feel that I could benefit a lot from having a person who has already researched the code and is more familiar with assembler. We could use my experience as a professional Java developer and your expertise in the elements client code to create something great and fast :)

I can set up SVN or an enterprise GitHub account, ventrilo if that's convenient, a wiki, and provide any other infrastructure you wish for.

If anyone is interested, I would love to hear from you either by PM or as a post here, and I will respond with my Skype account so we can further discuss it and get on working!

07/28/2013 17:28 Sᴡoosh#2

An abstracted API is pretty much what every bot author will write for himself anyhow. Since PW is dead, I doubt you'll have many followers for this project, but yeah, go ahead I guess.

07/28/2013 22:35 nb-ben#3

That's true, but with Java's JVM you get the benefit of exposing the methods to a ScriptEngine (for example JavaScript, VBScript, Groovy etc) with relative ease, and your community that doesn't have the capacity to debug assembly but is composed of people who are able to write scripts can extend the functionality while you can focus on the metal.

PW is still very much alive last time I checked. I have quit the game 1.5 years ago thinking it's going to die as well when they released R9 , but surprisingly this is not the case.

Edit: I see your bot does allow scripting in Delphi (?), I wonder what stops PW botting from evolving.

07/30/2013 09:43 dumbfck#4

I was working on a pretty extensive API for PWI a while back that could be communicated with via pretty much any language (even AutoShit lol) the end user wanted to use via very simple commands. I had most of the client side dll stuff done and front ends in C# and AutoShit and was even experimenting with python, but I abandoned it because PWI really is on its last legs. Additionally, the overwhelming majority of people generally just want a grind bot that works out of the box, so they use pGrind or Prophet bot.
Although a nice idea, it's really not worth investing the time in it when there are already established alternatives such as those and when anyone who has programming knowledge likely has their own bots or scripts. Also, the injected side still requires regular maintenance with lots of offsets to find.
But if you want to do something like that, then that's up to you :)

07/31/2013 10:23 nb-ben#5

Oh, you can safely inject a DLL to that? I have been assuming they are listening to LoadLibrary calls. This makes everything much easier than I thought.

07/31/2013 10:43 Sᴡoosh#6

You can do anything you want, as serversided gacd is still not used by any PW publisher. And even if they listened to LoadLibrary(), why would that stop you from pumping dlls into their address space all day long? As long as there are no R0 hooks for CreateRemoteThread or WriteProcessMemory, you're good.

07/31/2013 10:46 dumbfck#7

The easiest and most common way to tap into the game is via direct injection using WriteProcessMemory / CreateRemoteThread calls. There are tons of examples of that sort of thing on the forums here. However, programs with that sort of stuff typically generate false positives on most antivirus software. As I was originally intending to release my work commercially, I wanted to avoid the headache of "IT HAS VIRUS DERP YOU STEAL MY ACCOUNTS!!" so I went the DLL injection route. It's a bit harder, but personally I quite like it as once you're in, it's quite easy to access functions and stuff and everything is very fast. Plus it's not bad for debugging in Visual Studio.
But yeah, direct injection is easier if you don't mind the false positives.

Also, with an injected DLL, you need to restart the client any time you modify the code, which is a pain. I'm certain there are ways to dynamically remove a DLL and re-inject it to an already running client, but I never got around to that lol.

07/31/2013 22:18 nb-ben#8

Quote:

Originally Posted by dumbfck

The easiest and most common way to tap into the game is via direct injection using WriteProcessMemory / CreateRemoteThread calls. There are tons of examples of that sort of thing on the forums here. However, programs with that sort of stuff typically generate false positives on most antivirus software. As I was originally intending to release my work commercially, I wanted to avoid the headache of "IT HAS VIRUS DERP YOU STEAL MY ACCOUNTS!!" so I went the DLL injection route. It's a bit harder, but personally I quite like it as once you're in, it's quite easy to access functions and stuff and everything is very fast. Plus it's not bad for debugging in Visual Studio.
But yeah, direct injection is easier if you don't mind the false positives.

Also, with an injected DLL, you need to restart the client any time you modify the code, which is a pain. I'm certain there are ways to dynamically remove a DLL and re-inject it to an already running client, but I never got around to that lol.

Injecting DLLs make it easy to implement threading efficiently though, so you could for instance have your main application as a daemon/scripting interface accepting connections from your DLL that manages a thread in the game process, and you are then able to synchronize its state via IPC instead of creating a new thread for every invocation. This stuff cannot be done as well and in a timely manner by merely injecting opcode to the process

As a person that can correspond the assembly examples to C code, DLL injection seem like a walk in the park next to injecting opcode snippets, at least if you intend on doing something more than just obtaining access to the functionality.

08/05/2013 13:18 Super Aids#9

Why Java for PWI? Wouldn't something like C++ be more suitable considering Java lacks memory management and hooking etc.

08/05/2013 21:21 nb-ben#10

Quote:

Originally Posted by Super Aids

Why Java for PWI? Wouldn't something like C++ be more suitable considering Java lacks memory management and hooking etc.

It's hard for me to see myself maintaining something real in C++, if I am to do something serious given the amount of time I have to invest, I'd try to only do the necessities in any lower-level language and the rest in a higher level language, like Java or JavaScript.

JNA provides a pretty neat interface. Once you have your convenience functions set up, the advantages gained by C++ seem to not really be worth it in terms of native access...

Here are a few pictures to show you what I mean

Resolving pointers:
[Only registered and activated users can see links. Click Here To Register...]

Assembling assembly and injecting the generated opcode:
[Only registered and activated users can see links. Click Here To Register...]

So far this is how it looks, and the way scripts are written:
[Only registered and activated users can see links. Click Here To Register...]

I just did the inventory stuff, but having trouble finding NPC/Player/Item lists etc XD
If anyone could just point me in the right direction, that would be greatly appreciated]

Edit: ugh, bbcode img don't work :(

08/06/2013 00:12 Interest07#11

Think you can only post pictures after a certain number of posts. Seems similar to something I worked on with C# that would accept javascript scripts. It's probably a good idea in general, and should still provide with quite a bit of fun to develop.

last time I updated my offsets, you could find the lists here:

Code:

playerList = [[[[base] + 0x1C] + 0x1C] + 0x20]
npcList = [[[[base] + 0x1C] + 0x1C] + 0x24]
itemList = [[[[base] + 0x1C] + 0x1C] + 0x28]

nEntries = [xList + 0x14]
randomItemList = [xList + 0x18]
sequentialPlayerList = [playerList + 0x90?] //Not sure, I don't have this one in my database for some reason, I recall it being something like 0x80 or 0x90
sequentialNPClist = [npcList + 0x50]
//there is no sequential list for items so use the randomItemList. sequential means you'll find the entries like a regular array. random means, theres a list of size 0x300 with mostly null-pointers that you have to go through and check for non-null.

There's quite an old discussion in [Only registered and activated users can see links. Click Here To Register...] about it.

I haven't done anything with pwi for a year or two though, so those offsets will probably be slightly out of date. Funnily enough theres a similar list with a list of tree types that shows all the trees in the terrain :) This used to be at:

Code:


treeList =  [[[[base] + 0x1C] + 0x1C] + 0x3C]
sequentialTreeTypeList = [treeList + 0x208]
treeTypeCount = [treeList + 0x20C]

//then for each tree type you could find a list of individual trees at
sequentialTreeList = [sequentialTreeTypeList + i * 4] + 4B0]
count = [sequentialTreeTypeList + i * 4] + 4B4]

then trees had their coords at 0x8, 0xC and 0x10 for x, y, z respectively.

If you need some more info on how the lists work I can post something tomorrow.

08/06/2013 00:22 dumbfck#12

** EDIT ** Ninja'd lol

Some of that does look quite neat actually lol. Shame Java is so bloated though, but each to their own - It must be a million times better than AutoIt which most people around these forums seem to have latched on to :rolleyes:
If you have experience in Java, naturally you'll want to use that, so I wish you the best of luck and hope you have some fun doing it.
Your images won't work properly in posts until you have (I think) 20 forums posts.

As for player / items / NPC lists...

Code:

NPC count
[[[[[[baseCall]+0x1C]+0x1C]+0x24]+0x14]
NPC ordered list base
[[[[[[baseCall]+0x1C]+0x1C]+0x24]+0x58]
e.g., NPC name
[[[[[[[[[baseCall]+0x1C]+0x1C]+0x24]+0x58]+i*4]+0x264]+0]

Player count
[[[[[[baseCall]+0x1C]+0x1C]+0x20]+0x14]
Player ordered list base
[[[[[[baseCall]+0x1C]+0x1C]+0x20]+0x94]
e.g.,player name
[[[[[[[[[baseCall]+0x1C]+0x1C]+0x20]+0x94]+i*4]+0x67C]+0]

Nearby items / materials count
[[[[[[baseCall]+0x1C]+0x1C]+0x28]+0x14]
Item list (unordered)
[[[[[[baseCall]+0x1C]+0x1C]+0x28]+0x1C]

Note that the nearby items / materials list is not ordered, i.e., it has gaps in it so you have to traverse the list to find the non-empty slots.

Hope that helps :D

08/06/2013 00:42 nb-ben#13

Hmm.. I think I may not be using the right base or something.
Here is what I've attempted and the result to get the amount of NPCs:

Code:

[[[[[base(0xc0cdec)] + 0x1c] + 0x1c] + 0x24] + 0x14]

That returns 4 no matter where I am or how many NPCs are around me :p

I actually been manually bruteforcing this, trying to increase pointer values all around but

Code:

[[[[[[[[[base(0xc0cdec)] + 0x1c] + 0x1c] + 0x24] + 0x14] +N(random)] + 0(first npc)] + 0x4] + 0x124]

did not yield the level of the only NPCs around me :(

I am starting to think about killing mobs and then running filtering with CE for the mobcount, however if you can easily spot a mistake and save me from inflicting this pain upon myself I will undoubtfully appreciate it XD

Edit: DAMN. baseCall! why have I not tried that...! Thank you Interest07 and dumbfck :)

Quote:

Originally Posted by Interest07

If you need some more info on how the lists work I can post something tomorrow.

That would be pretty cool, if we can map all of the objects + walls, it opens up the possibility of doing automatic pathfinding :)

Quote:

Originally Posted by dumbfck

Some of that does look quite neat actually lol. Shame Java is so bloated though, but each to their own - It must be a million times better than AutoIt which most people around these forums seem to have latched on to :rolleyes:

Yeah well, the JVM does add up a lot of memory overhead to objects, though in terms of performance if you keep your data structure organized it's normally not very significant. In a big project, I'd much rather type Java and keep safe of the technical debt normally associated with hackathon software development than spare a dozen mbs of memory overhead :P Though yeah, the same program typed in C++ would outperform in terms of speed, looks, and memory footprint any program that runs on the JVM.

08/06/2013 17:12 Sᴡoosh#14

Quote:

Originally Posted by nb-ben

In a big project, I'd much rather type Java and keep safe of the technical debt normally associated with hackathon software development than spare a dozen mbs of memory overhead :P

Isn't the technical debt actually the reason we do this? Wouldn't it be boring otherwise, like lots of other areas of development? :)

I don't understand the Java choice either, but as dumbfck said, each to their own. I wish you luck with this, even if that may sound strange coming from somebody who hates open source development.

08/06/2013 17:25 Interest07#15

Quote:

Originally Posted by Sᴡoosh

Isn't the technical debt actually the reason we do this? Wouldn't it be boring otherwise, like lots of other areas of development? :)

I don't understand the Java choice either, but as dumbfck said, each to their own. I wish you luck with this, even if that may sound strange coming from somebody who hates open source development.

I love open source development (when it comes to external 'tools' for games) and I still wish you the best of luck with your botting business, nothing strange about it ;)

I'm also not a very big fan of Java, but unless you run 30+ bots, I doubt the language of choice will matter much, assuming you're not looking for 1ms response times in decision taking by bots.

My C# bot would require pretty much 0% CPU running 4 simultaneous clients and it was at no point coded for efficiency, I'd imagine Java would have no trouble reaching pretty much the same.

Page 1 of 2