D-Link DIR-600 Firmware 2.10 Vulnerabilites

The D-Link router model DIR-600 had a bunch of vulnerabilities that allowed an attack to gain either knowledge about internal device and network details without being authenticated, or allowing for remote shell access1. The latter is however restricted to firmware versions 2.12-2.14, as it depends on unauthenticated access to a command.php script that allows for shell command execution.

Firmware version 2.10 does not yet possess that feature/vulnerability. However, a router feature used to test the availability of a remote host (ping) allows for shell script access through unescaped user input in the input field for the target hostname. The fact that this script is also accessible by an unauthenticated user, opens it up for exploitation.
curl http://<router ip>/diagnostic.php -d "act=ping&dst=google.com;telnetd"
will execute telnetd on the router, consequently allowing telnet access on port 23 without any login credentials. Following that, an attacker can read the contents of the /var/etc/passwd file and retrieve the unencrypted plaintext login credentials for the web interface.

In addition to that, the firmware leaks a lot of internal information, such as WPA PSK and WPS PIN, to an unauthenticated user through the getcfg.php script.

  1. http://www.s3cur1ty.de/node/672 

The Yearly Update From Space

Oh hey, looks like another year is nearly over again. I’m going to try to write a bunch of posts in the next few weeks about things I’ve been doing.

On the side of EVE I pretty much started anew by writing a library in C#/.NET to interact with EVE. The problem with Python always was that it was completely running inside EVE’s Python interpreter, which all-in-all is a bit too invasive.

The way EVE (or Stackless Python applications in general) is structured, is that there is always one main tasklet (if you don’t know anything about Stackless Python, you should probably stop reading here and check out the summary) running that handles the scheduling of other running tasklets. That of course means that you can never use a blocking call from there, or you would cause a deadlock, since you are basically yielding the remaining running time of the scheduler! Thankfully Stackless Python detects (most) such cases and merely throws an exception.

Now, if you’re hooking DirectX’s EndScene and try to invoke Python functions from there, you are in the context of that main tasklet. If you are merely passively reading values or doing simple operations on EVE, that is not going to be a problem. In fact this is how ISXEve (and I suppose most people) interact with EVE. You are only going to have problems if you are calling blocking (or in terms of Stackless Python: yielding execution time) functions. An EVE Python function is usually blocking if it involves a request to the server or a long-running function. What EVE does however, is cache most remote calls, and only refresh the received data if it’s invalid or out of date. One example would be the market interaction API, orders for a certain type ID are usually cached for a short time, but in most cases EVE has to do a remote call to the server.

There’s a bunch of ways to deal with that:

  1. call blocking functions in their own tasklet, by eval-ing a short Python script that creates and launches a tasklet executing that function.
    Problem: it is difficult/ugly to get return values from this
  2. stay completely passive, don’t use any blocking functions at all and depend on other mechanisms to invoke them (market searches for example)
    Problem: gets very messy if you want return values and is very limited
  3. have your bot main interaction function invoked from inside a tasklet

ISXEve uses method 1 and 2. It’s valid methods, but I think it is limiting what you can do and the stability of the client way too much. You might claim that is more secure, but if CCP wanted to detect a public botting library, there are easier ways than to probe for Python function hooks or malicious tasklets.

I am only going to talk about method 3 now, which is the one I eventually ended up using.

In the very first EndScene call I grab the Python GIL lock (which is required to do anything in Python), register a Python CFunction pointing to a C# function and set up a tasklet repeatedly calling that CFunction – in short, a timer. Thanks to C#’s amazing PInvoke/interop functionality, registering the CFunction as a C# function is as easy as declaring a delegate (well, and marshaling a structure to unmanaged memory):

public delegate IntPtr PyCFunction(IntPtr self, IntPtr args);

Now every time the timer calls this function, we’re sitting in our own tasklet and can call blocking functions without problems! If the called Python function yields execution, the C#/CLR stack gets stored and the Stackless Python scheduler moves on the next tasklet. Once the condition to wake our tasklet back up has been fulfilled (sleep expired, message sent to channel, data recieved from server, etc…), our C# function is continued.

All of this makes interacting with EVE so very easy, and with C# as a powerful language (especially the LINQ feature) writing bots (or anything) much more enjoyable and focused on the bot logic compared to Python. Figuring out what EVE Python functions to call isn’t really that difficult, because thanks to Python’s dynamic nature you can pretty much restore the source code to the game. For Python 2.5 I fixed up an existing decompiler to work with a few more language constructs. I didn’t bother fixing it for Python 2.6 when EVE switched to it, since most changes are very small and can be easily inspected by diffing the disassembler output of both versions.

That’s it for this post! Hopefully it wasn’t all that boring to read, and I’ll try to update more regularly. No promises though.


It has certainly been a while since the last update, mostly because I’ve been rather busy with university. But I’m going to try to catch up a bit and talk about what I’ve been up to.

In the last few months I’ve been doing a bunch of reverse engineering and bot-writing for EVE Online, looking at ways to make money with it. There are a few fundamental differences in the way botting works in these two games: In World of Warcraft the way to make money is through mineral nodes like Saronite or Titanium Ore. A bot that needs to farm these is relatively simple, all it needs to do is fly in circles and pick up nodes, eventually fighting off attackers. To get the equivalent of a few hundred USD it is enough to run such a bot for maybe 6 hours a day.

In EVE Online the comparable easy way is mining ores, too, but the real money value yield is much lower per hour spent botting, so it is required to run a bot pretty much all day. There are better methods that yield more money though, for example mission running, but due to the nature of the game, in order to successfully complete the well earning missions it is required to spend several hundred days training skills. Since I did not care about EVE previously and do not have a suitable character, this is pretty much impossible at the moment.

However, there is one important advantage to EVE: There is only one server. In World of Warcraft you get about half a thousand servers, which makes it incredibly difficult to sell the in-game currency. In EVE the only limit is how much you can make; if you don’t want to sell it yourself, there are several websites that bring you into contact with a potential buyer.

That, and the possibility of improvements (and EVE looked kinda interesting as a game too) in the form of missions made me look into botting in EVE. It turned out that is incredibly easy there, compared to World of Warcraft: Since the game is entirely written in Python and there is an old decompiled source code dump available on the Internet, it was very easy to get started there.

To get access to EVE’s Python interpreter I injected a DLL that loads or retrieves a handle to the python25.dll module of the specific process and uses GetProcAddress to retrieve function addresses for any Python function I ended up needing. It’s not really required to do retrieve all these addresses manually and specify required function prototypes for them though, since one could also link to the DLL at compile time and have the dynamic linker retrieve the addresses, then it’s possible to just use the Python functions without any problems, since EVE’s Python 2.5 version and the one from the website probably aren’t different (?).

Since calling Python functions from another thread ended up being rather problematic for me, because the normal Global Interpreter Lock (GIL) functionality did not work and a hack that ended up working was a bit too messy for my tastes, I just ended up hooking (with MS Detours for example) the Python function`PyStackless_CallMethod_Main, which EVE’s ExeFile.exe calls to set off the Python part of the game.

In trying to interact with EVE’s python base though I encountered a problem: If I just executed my Python code with execfile() or eval(), my code ended up being executed in a different execution frame (I think) and thus had a different __builtin__ (Python’s “main” module where all the .. built-in commands or variables are. The solution turned for me ended up importing the “stackless” module and just queuing a new tasklet to be executed with stackless.tasklet(execfile)(“myfile.py”). It then ended up being executed by the main frame with the correct __builtin__.

At that point I ended up hooking EVE’s Startup function that was located somewhere in a autoexec_client_main module (It becomes pretty obvious from the source) and was able to properly interact with EVE’s GUI functions and so on afterwards, but that’s mostly just toying around and unnecessary. It takes a while to dig through the EVE source and figure out how it works, but it’s necessary to do anything, and thanks to the dudes who properly decompiled the bytecode ages ago (decompyle doesn’t work with Python 2.5, and UnPyc, an attempt to build a decompiler for Pythons up to version 2.6 is not finished and apparently abandoned. Aside from that there’s just commercial decompiling companies, and they probably won’t help with the EVE code ;)).

But to get a usable interpretation of EVE’s bytecode (that’s contained in the script/compiled.code file and lib/*.ccp archives (they really are just ZIP archives) and easily extractable, but I’ll go into that in another post) it’s really enough to just run Python’s included disassembler in the “dis” module over the code objects. Some dude called Ricky26 who apparently worked on a custom EVE server has already done a bunch of work on that, he also wrote a script that deals with the extracting and disassembling of the compiled code. But again, I’ll go into that in another post, this one is already getting too long.

Gems And War

At this point I think I can say that the Harvest bot and Navigation core are pretty solid so far. In the past few weeks I have been working on avoiding getting stuck, pathfinding speed improvements (from 15 seconds for a long path down to 0.8 is pretty nice) and a bunch of bug fixing. The biggest problem I had was the movement working properly at a low FPS. The “click to move” feature of WoW did not work very well for flying navigation and started to fail horribly when the pitch angle between the player and the target was close to 90 degrees. So I ended up doing it manually which is where the problem of the low FPS came in. When the game is only running at 10 FPS it easily happens that the player overshoots the target, which is what I want to avoid because it can lead to unpredicted results (falling off a ledge/cliff or shooting off into a random direction when in druid flight form), so I ended up having to predict the position the player is going to have in the next frame and act based on that.

Other improvements are mailing functionality to clear the inventory when it’s full and continue harvesting. I ended up adding another module that keeps a journal of interesting objects (mail boxes, repair npcs, etc.) and take care of the moving to it and finding the actual object to interact with.

Similarily I have also been working on battleground functionality and with that combat related functions. Biggest problem was of course dealing with target decisions and line of sight/range. Thankfully the guys behind the old OpenBot have put a lot of thoughts into that already, so it helped it a lot. Basically there is a range in which the player will move into range of his target and another in which he will actually pull it, at which point the class routine kicks in.
Since I am currently using a manually generated navigation mesh it happens a lot that no path to the target exists and the player can’t move into range. I will be trying to move directly to the player through line of sight checks if the path to the target is empty and even. An ideal solution would be to use the map/model data from the client, but that’s a project on its own.

Anyway, here’s some videos of the bot mining and some battleground combat.

Progress, Warden, Debugging

And finally, another post, and more progress. In the last few weeks I have mainly been busy with refactoring my code base so it is easier to plug into the Warden protection I have. That basically requires that all memory changes (hooks and overwritten variables so far) are kept track of so they can be removed when Warden starts a scan and later restored again when the scan finished. I took that opportunity to refactor most of my code which has been mostly consisting of hacks and such to include newly gained knowledge from reverse engineering and such.

Additionally I did some more Warden REing to get a better idea of how it works and especially how and what it scans. So far I can at least see what memory addresses it reads, which is pretty interesting in itself, but not nearly all of what it scans. However since reverse engineering takes a bunch of time and I would like to get back to writing the bot itself again, I left it with that and am going to continue it whenever the need or time arises. I intend to set up a page here to list all addresses it currently scans and their frequency since I like statistics :)

Since the refactoring also made everything much easier I also made some progress on the flying harvesting state machine. This mostly includes a bunch of fixes to movement and combat related portions. Things that are usually obvious to a human (or should be) are not to the AI and need to be specially handled, and since a lot of these cases only happen in certain circumstances and are difficult to reproduce. For example, in this video you can see that the bot at some points attacks a mob that doesn’t even attack the player. This happened because the targeting module prioritizes targets on certain factors like health, aggressiveness, distance, etc. and valued that mob higher than the one currently attacking the player because of wrong weights on these factors.
Additionally it shouldn’t even attack mobs that aren’t specifically attacking the player (or in more accurate terms: targeting the player). But since it sometimes takes a few seconds for the combat status to drop off the player it immediately takes the target on top of the targets list and attacks that.

This is of course one of the easier problems and easily fixed, but sometimes there are problems that are difficult to make out or diagnose, at which points it becomes very difficult to reproduce them. That’s one of the big problems with writing “hacks” for closed source games, debugging them is a nightmare.

In any case, so far the harvesting state is working very well, a more up to date video can be seen here. What’s still missing is a way to recover from death, which will probably be the next part on the TODO list, since that’s a feature required by all sorts of states anyway.

Flying Gold

Not much to say lately since I don’t really want to test my bots on my main account, so there’s only the Mangos server left to test things. In any case, I have so far implemented the flying harvesting thing and it works pretty well. Here‘s a short video showing some of the features.

It starts with mounting up and ascending, at which it point it starts to follow a set of waypoints specified earlier in a “hotspots” set. Once it sees a node it flies exactly above it and descends. The first node in the video happens to be under water, so it can’t reach it. After roughly 20 seconds that node gets blacklisted (put on an ignore list) and it starts to ascend and follow the waypoints again. Once a node is reached while descending the character dismounts and starts mining + looting the node, at which point the entire thing starts over (mount up, ascend, patrol..).

While flying you can notice that it sometimes bobs horribly, that happens because the pitch of it isn’t zero, so when flying forward it actually flies down. I plan to address that too, which shouldn’t be problematic since everything required for that is available in the WoW Lua API already (GetUnitPitch, PitchDownStart/Stop, etc.).

To test all this on the live servers I intend to transfer a character to a new account so I can do it without compromising my main account. Although I am sure that I have created adequate protection, there’s always a chance left :)

Next thing to come is going to be some sort of BG bot. That’s going to be the first time combat is actually important, so it’ll involve lots of combat related revamps.


This is probably the reason for the long time since the last update, but after having a testing account getting banned for some of the memory modifications I make in WoW, there really was no way around it. Since there was very little information available on Warden and the fact that it wasn’t really my area of interest, it took some with a lot of big breaks to get this done.

As you should know, Warden is (one of) World of Warcraft’s anti-cheat tools, the main logic behind it is sent, decrypted and dynamically linked at runtime, making the reverse engineering of it a bit more involved. I don’t want to get into much detail regarding this, but what I do right now to protect myself from Warden is pretty much the “standard” way it is done right now; hooking the scan function and removing all modifications before doing the scan and reapplying them again. Some testing whether this actually works still needs to be done, but so far it is working.

This means I can actually get back on the bot development now. To get some useful results, I want to create some basic “gathering” controller for my current framework. The idea is to fly around looking for mining nodes and harvest them, defending against attacking mobs (which is probably the smallest problem since a combat state/routine framework is already present) only to mount, fly up and continue. A bit more detailed my current plan looks like this:

Harvest service

  • Works a lot like the Targets service by keeping a list of possible nodes
  • Updated each tick in order to keep the list up to date every time
  • Also filters nodes that are above the player’s skill (currently a hardcoded list of skill levels for each node, but I hope to dynamically retrieve that information either from some DBC files (they probably don’t contain that) or checking some “usable” flag on the node (whether the text on the tooltip would be red)

Mount module/functionality to determine whether the player can mount in the current situation and what mount to use (flying/ground). At the moment this information is hardcoded too.

Logic in the form of states to put the previous functionality to use. So far I intend to separate this into the following states:

  • Generic waypoint following in the air, following a predefined set of waypoints in a circle, switching to the next state when a node is found
  • Moving into range of the node to mine it by flying directly above the node and then flying straight down. Once in range, dismount and switch to the next state
  • Mining the node, looting all its content
  • Mounting up again and flying straight up, ideally to the point where the descend started, and switch back to state one again
  • In the last two states, especially in the third one, react to possible combat and switch to combat state (which is where the routine kicks in and handles things)

This is the idea so far, I’ll probably write the next post once I discover something new.

The Bot Core

In this post I will talk about the bot itself. After having roughly covered the foundation of it (which isn’t too interesting), I’d like to get a bit closer to where I am now with the development of the bot.

botdiagram2The bot itself is divided into separate modules of different types. On one side are the “service” modules which get updated every n frames, defined by the module, on the other side are normal modules which are just there to encapsulate part of the functionality. A small explanation of the modules in the diagram on the right:

  • Mapper: The core of the map and path finding, records new walkable nodes and connects them to neighbors. At runtime a quadtree is filled with the nodes in order to easily and efficiently find nodes in a radius around a point. They are stored in a simple array, without any compression so far, but that isn’t very important right now, neither is it a big problem.
  • Navigation: Takes care of player movement and puts the map data gathered by the Mapper service to an use. It finds a path from the source to the destination and then follows that path until it arrives or the movement is cancelled.
  • Harvest: Finds suitable mining nodes, herbs, corpses, chests, etc. to harvest/loot and keeps an updated list of them.
  • Targets: Keeps an updated list of possible targets and their priority, which is determined with a bunch of weights for factors like health, aggressiveness, distance, etc.
  • State: The logic behind the bot, keeps track of the current and previous state, and another global state that is always run. A state can also be a “sub state”, in which case it doesn’t override the previous state, this is helpful for state transition situations like Roam -> Pull -> Combat -> Roam.
  • Routines: Provides a loose framework for class specific functionality used by the different routines, for example pulling, combat, resting, buffing…
  • Player: Will encapsulate some generic functionality required by the different modules and especially the routines regarding player functions like targeting the best target. Not much in there yet, since there hasn’t been much work on routines yet.
  • Hotspots: Keeps track of grind hotspots the “Roam” state follows with the help of the Navigation service. It basically just cycles between a set of spots. I might replace this module with something more generic later on, since I don’t like this very much.
  • GUI: Not shown on the diagram, this service takes care of the GUI updating and displaying, it retrieves the GUI elements of the different modules (if they have a GUI) and updates them.

That’s it for the modules so far, there’s probably going to be more in the future, but since I’m not that far with the development yet, the picture will change a lot. Going to go a bit into detail on the problems I have right now in the next post I guess.

A Blog

Well, first of all, welcome to my blog, I have no idea how you got here, and especially why, but I am glad you are nevertheless.

Second of all, please don’t expect any exceptional insights into anything here, I merely keep this blog for myself to get some writing practice in and write about things I do. It’s of course great if it’s useful for someone, but don’t expect anything :)

Alright, now that I got that over with, here’s what I’m doing right now:

WoW Bot

Yeah, a WoW bot, pretty mainstream, I know, but it has the property of combining several different fields into one, making it hard to get bored. First of all you have the difficulty of making the game do what you want, so you can actually know what’s going on in the world and make the player move, etc. To achive that you have to reverse engineer parts of the game client, find out where in memory the information you need is stored, how it looks, what functions you need to call in order to move the player, retrieve informations, and so on. Once you have enugh experience in reverse engineering this, for the most part, just requires lots of time and patience debugging code, taking notes, etc. Thankfully the reverse engineering community in World of Warcraft is rather big, so most of the work has been done already and can be collected from sites like MMOwned (which is arguably 90% full of mouthbreathing retards or spoiled high school kids) or Game Deception. Obviously going into more advanced areas like not getting banned through Warden/etc. is an entirely different topic.


For my project I decided to implement that part of the bot as a DLL that is injected into the WoW process. The advantage of this is that your own custom code is running in WoW’s address space, which means you can easily read or write anything in World of Warcraft’s memory, and most importantly, call functions inside the client. Some say that DLL injection is a rather intrusive method and easily detectable, but it is in fact a perfectly fine Windows feature used by many applications, making it impossible to ban solely for that – it completely depends on what you are doing inside the process.

Anyway, the path from nothing to bot is laid out in three parts for me. The first part is the DLL that gets injected into the process which registers several additional Lua functions to make that functionality available to interface addons. By building the bot itself as a WoW addon most of the required functionality is already there, for example events and requesting information about units, etc. These additional Lua functions I create are used to retrieve information about things that are not provided by the WoW Lua API, that includes surrounding objects, object positions, model names, animations, etc. In addition to these more passive functions, there is also the part that deals with things like clicking on the terrain for “click to move” functionality, or targetting units by their GUID. The DLL is injected into the game client by an external program that invokes LoadLibrary through a remote thread inside the client.

Part two is already a WoW addon and deals with API abstraction or convenience functions in Lua, for example a Lua iterator for iterating through all visible objects – something that’d take a lot more effort if done with the Lua C API. The Ace addon framework is a huge help for everything from here on, for example the core addon fires a few events when the hook gets loaded or unloaded.

The third part is the bot logic itself to which I will get in another post. Here’s an useless uninformative video, there’s just not that much to show right now since most of the work is hidden. Just some combat and running around going on here.