Its been a while since I posted here so I thought I'd start it off with a warning to all those players who play on shared computers.
If you play on a computer that has previously had a SWF Changer run on it, you could accidentally be detected as a bot user.
I came across this issue when debugging some code and found that the way caching works with DarkOrbit, changes in the game files can actually carry across to other accounts before the cache expires. Whilst its a rare issue, I know for a fact that I play on computers that are shared with my brothers who are both clean players, but could accidentally be detected by the issue.
So far this hasn't happened but I thought I would warn users who share computers.
Also to note is that the specific way they detect pixel bot users is extremely vulnerable to enterprise proxies or other proxies that intercept and modify web pages to inject ad's and other things. By doing this they change the hash of the resources.xml file which can trigger a false positive in their bot detection code. I actually managed to reproduce this issue accidently by using the game on a University campus. Their proxy modifies and caches web pages and does other things that modify the resources.xml file as well as modify other xml game files. By playing behind these types of firewalls you greatly increase your chances of being caught accidently as a bot player.
On top of all that, the entire system is extremely vulnerable to all sorts of caching issues. If you accidently get served an old version of resources.xml for instance (because your browser cached it or for whatever reason) this can also trigger a false positive in their anti-bot code.
Just so I don't sound like I'm pulling facts from my arse I'll explain how their anti-bot code works. In the resources.xml file it lists all the game resources and SWF files that DarkOrbit uses in game. Along with their names and locations they also store a MD5 hash of the file. When the game loads it runs a bit of extra code for any resource that is either Palladium or a bonus box. What this code does is verify the hash in the resources.xml file against the hash of the actual file downloaded. If they don't match, it sends an event along their 'eventstream' as well as modifies two ingame variables that affect the X and Y coordinates sent in the hero movement packets. What this means is that any slight discrepancy between the expected hash of the file and the actual hash of the file gets you flagged as a botter.
You might ask how many actual, real world scenarios could trigger a false positive in this seemingly well thought out bot detection code? Let me make you a list:
Now those three cases might not seem that prevalent but I'd like to point out one other situation that I have ACTUALLY BEEN IN that this has happened. A lot of big education institutions run caching proxies on their internet connections to decrease the bandwidth used by their students. One place I visited ran Squid with the "Compress all SWFs" plugin enabled. What this does is intercepts all SWF files and recompresses them to save bandwidth. Obviously, this changes the hash of the file and causes you to be flagged as a botter.
I'm not trying to make it seem like there is no fool-proof way of detecting botters, I'm just trying to point out that the way Bigpoint currently does it is extremely delicate and that they should not be banning users with a permanent ban, and then reply to users who complain in an email that "All Bans are final and we do not discuss them". Do I have to remind you of the time all those people who played on Mac's got banned incorrectly and they had to go back and unban everyone? Yea, Bigpoint, 100% accuracy there ;)
-jD
If you play on a computer that has previously had a SWF Changer run on it, you could accidentally be detected as a bot user.
I came across this issue when debugging some code and found that the way caching works with DarkOrbit, changes in the game files can actually carry across to other accounts before the cache expires. Whilst its a rare issue, I know for a fact that I play on computers that are shared with my brothers who are both clean players, but could accidentally be detected by the issue.
So far this hasn't happened but I thought I would warn users who share computers.
Also to note is that the specific way they detect pixel bot users is extremely vulnerable to enterprise proxies or other proxies that intercept and modify web pages to inject ad's and other things. By doing this they change the hash of the resources.xml file which can trigger a false positive in their bot detection code. I actually managed to reproduce this issue accidently by using the game on a University campus. Their proxy modifies and caches web pages and does other things that modify the resources.xml file as well as modify other xml game files. By playing behind these types of firewalls you greatly increase your chances of being caught accidently as a bot player.
On top of all that, the entire system is extremely vulnerable to all sorts of caching issues. If you accidently get served an old version of resources.xml for instance (because your browser cached it or for whatever reason) this can also trigger a false positive in their anti-bot code.
Just so I don't sound like I'm pulling facts from my arse I'll explain how their anti-bot code works. In the resources.xml file it lists all the game resources and SWF files that DarkOrbit uses in game. Along with their names and locations they also store a MD5 hash of the file. When the game loads it runs a bit of extra code for any resource that is either Palladium or a bonus box. What this code does is verify the hash in the resources.xml file against the hash of the actual file downloaded. If they don't match, it sends an event along their 'eventstream' as well as modifies two ingame variables that affect the X and Y coordinates sent in the hero movement packets. What this means is that any slight discrepancy between the expected hash of the file and the actual hash of the file gets you flagged as a botter.
You might ask how many actual, real world scenarios could trigger a false positive in this seemingly well thought out bot detection code? Let me make you a list:
- Caching troubles: Any difference between the actual resources.xml and the one your browser has and gives to the game can cause a false positive. If the hash in the resources.xml that your browser has cached doesn't match the one the game currently uses, even though you have never used a hack or cheat or bot ever before, can cause a false positive to be triggered.
- Corruption of resources.xml: If somehow your resources.xml gets modified or corrupted in transit but is still readable, you can cause a false positive.
- Corruption of bonus box SWFs: This is the big one in my opinion. If somehow the process of loading the SWF is interrupted or intercepted it can cause the SWF's hash to be incorrect when checked and also trigger a false positive.
Now those three cases might not seem that prevalent but I'd like to point out one other situation that I have ACTUALLY BEEN IN that this has happened. A lot of big education institutions run caching proxies on their internet connections to decrease the bandwidth used by their students. One place I visited ran Squid with the "Compress all SWFs" plugin enabled. What this does is intercepts all SWF files and recompresses them to save bandwidth. Obviously, this changes the hash of the file and causes you to be flagged as a botter.
I'm not trying to make it seem like there is no fool-proof way of detecting botters, I'm just trying to point out that the way Bigpoint currently does it is extremely delicate and that they should not be banning users with a permanent ban, and then reply to users who complain in an email that "All Bans are final and we do not discuss them". Do I have to remind you of the time all those people who played on Mac's got banned incorrectly and they had to go back and unban everyone? Yea, Bigpoint, 100% accuracy there ;)
-jD
