A little detection experiment

We see that a lot of people seemingly report new bans, but we have no idea as to why they are busted. We got everything from obvious trolls, to people stating "HB is detected", without even explaining what they did to hide HB on their system at all.

It's clear that you can detect HonorBuddy.exe in the process list if you run HB on the same user account as WoW (i.e. as admin or an admin privilege account). It's also possible to see what DLLs are loaded in such a case, such as greymagic.dll, as well as monitoring what network connections are up the PC (open TCP streams to HB auth servers and such). I'm not going to start another legal argument, but lets assume that in your country, by signing the ToS/EULA, you agree to the following:

(This text is now added to the bnet account manager after entering a game key, and you won't be able to add the key unless you agree)

It does NOT mean that the bot can't be detected upon injecting stuff into the WoW client. However, that Blizzard is asking such explicit permissions to scan your computer, we can pretty much assume that they will scan anything viable for signs of HB and other bots they might target.

If anyone could be bothered and have a spare key, it would be great to know if they can detect HB if WoW is run from the Guest account or another non-privileged account, and HB is started from another Admin account. Obviously with all files related to HB in a directory that the Guest account cannot read. The Guest account can't access the processes the admin user is running, nor snoop its network connections or loaded DLL list. I.e. start wow on your guest account, switch user to Admin, start HB and attach to wow.

It would be cool to do this in some kind of arranged pattern between several users, so that some just attach the bot without starting it (i.e. attach but not hit start), some run Enyo and play manually to prevent movement/action patterns, and eventually someone running some profiles or somthing. Also, obviously remove all traces of HB from your registry if you ever used the Installer, as well as rename the HB dir and executable.

If possible, run it off a fresh bnet account and try to reset your router to obtain a new IP address if you're not on static IP, as some ISPs seems to only assign new addresses through DHCP when router is reset/started. Mine is running on a year lease time. Also, for max tinfoil factor, make sure there are no bookmarks, open browser tabs to HB related web sites on the guest account.

I'm still in doubt if they can actually see what the bot is doing and most likely have crossed the line to scan your environment for the actual files. This is extremely doubious in a lot of countries, and they will at least have to state exactly what they are looking for and how they use it, and not ask for a general consent to mooch through your private stuff.

 

Only me getting extremely tired of these posts?

 

If you don't care, then don't read or reply. If you can't comprehend why it is posted or what it is saying, I understand it might come across as pointless to you, but for those who care to try and run HB safely (or confirm that indeed it is the bot's actions that is detected and not from the environment), this is completely legit and noone ever posted something similar as far as I have seen. In case, I'd like you to point that out, and where.

Edit: After re-reading your post, I can't find any other reasons behind it than you don't understand shit of what it is asking, or you have some kind of agenda. If you simply don't care, I don't see your motivation to be here in the first place.

 

So, you think that your thread is the one thread out of the hundreds that have been posted over the years that is going to be the one to ***** the code, huh?

 

Please go and have a hysterectomy or what ever, you have no need to reproduce.

Thanks...........

 

No, I don't think anything. We're obviously seeing (or saw) a ban wave, we don't know what caused it, and some people keep reporting being banned still. We don't know what they did, if these are real reports or whatever.

Blizzard added this policy change to their account agreement very recently, which means that the only reason HB and other software hasn't been up for grab before, is that they have considered not legally sound to just scan your computer without consent. That makes it pretty different from before, and also we didn't see people banned like this wave. It also makes it a completely legit question if detection is indeed caused by scanning for very visible things on your PC, now that they claim the right to do so.

Do you have some personal problem with people trying to figure how to protect their accounts as best as possible, by minimizing the risks of getting busted?

 

No, I (and most of this forum) have a problem with hundreds of useless threads popping up and having to wade through them to find any threads with useful, important information. I have a huge problem with people tying up mod and developer attention when there are more important things going on, like Hawker and Bossland deciding whether or not to continue to support AFK Battlegrounds or implement better pathing so that we're not at as good a risk of being banned for using it.

TLDR If you want to help them figure out where we can all be more secure, submit a Ban Report in the Ban Section. Otherwise, don't pollute the forums.

 

I wish Bossland would just implement a a random number generator into the naming string of honorbuddy.exe would take only a few minutes and would give a large percentage of users peace of mind it seems.

or, just scrap the nice gui and straight up inject a DLL

 

You have this wrong. Blizzard can ONLY scan inside its own memory space / processes. Anything else is highly illegal, even here in the States. Just because you agreed to have Blizz scan their own processes does NOT mean they have the right to scan all visable processes...

 

That is a feature issue, not a security one. Personally, as a PvPer, I rather see the bots get the hell out of PvP, but I accept that you think otherwise and I'm fine with that. I won't argue for or against that, other than in a security perspective. One kind of botting isn't superior over another. My message wasn't aimed at any devs or mod, but to find some other HB users willing to try out some stuff. If you feel like I'm stealing attention from your more important issues, that's for you to deal with. So far I think you're doing a pretty crappy job at that, trying to bully people from posting stuff that isn't important to you personally.

Which is an issue, to add randomization offsets to absolute coordinates and so on, but it doesn't make a question about the entire foundation of how the bot is executed in the environment less important. If you can see the bot clearly, who cares about minor security fixes?

I am asking people to help ruling out different ways of detection. If it turns out that the bot is detected by plain disk/process/memory scanning, we can counter it by increased local computer security. If we're certain HB is detected with no access to read that information, then there is obviously other things that needs doing and either the insertion method is detected itself, or something that is inserted into the client is.

I'm doing some experiments myself, but n=1 isn't exactly statistically significant. If I do not get banned by my own measures, it proves that I'm either lucky or my strategy works, which I'd never know.

 

Many people agree with you on the legal aspect, whereas others don't. Reading the ToS changes and the explicit consent they now ask, it's clear that they are asking to scan your computer as a whole, and not the process memory space (read the excerpt in my OP). We can say it's malware by some definitions if they scan outside of it's own process memory, but we can also speculate that they after legal review have found it less risky to scan (with "consent") than the consequences of number of bots running out of control. They scan inside their own process all the time, by definition, as they iterate over data in their own memory space and obviously don't need permission for that. Anything else would basically outlaw any computer program from working.

This was just a simple request asking for some more people willing to try out this experiment and see if they still can detect HB. I for one wouldn't dare to run HB right now out of the open on an admin account along with the game itself.

 

this ^ ill do it for free lel

 

There are plenty of ways to make processes invisible/undetectable, and not only the process itself but also the installation dir and other components. As you said, it will somehow interfere with user friendlyness, but still a compromise would be to only do config UI stuff when Blizzard's stuff isn't running (think resident agent.exe, Launcher, Wow itself). Right now, we're relying on legal assumptions for protection and we don't know if Blizzard have found it worthwhile to try to cross that line based upon calculated risks. WoW is their main income still, and you can pretty much be sure that they aren't going to gamble with it, if they feel threatened.

 

Guys... you should learn how detection is done....

Warden doesn´t scan what is running on your PC, instead it is watching few WoW functions, that are usually hooked (that is way, how HB is communicating with WoW) and check, if there is call from outside of WoW memory space (from HB for example).

Buddyteam know exactly what Warden is doing, because Warden was reversed by Buddyteam members back in 2010 and they are checking it during every update (that is reason why HB is down for some time after WoW update).

Second thing is, that Tripwire is system that is checking if there wasnt some change in Warden.

So stop repeating same thing over and over....


Btw Learn something about IT, because you can find HB process even if it is not marked as "Honorbuddy.exe". You can rename HB´s process to Explorer.exe and even after that, you can detect it very easily.

 

So basically, you're contradicting yourself by saying Warden can detect data/call injection from another process, whereas at the same time Bossland knows what Warden is doing and check it before every HB release vs. Warden, hence the conclusion is that no other form of detection occured. Bingo.

You can detect programs by signatures or hashing/checksum them just fine, as long as there is consistent data to look for (i.e. no randomization of binaries etc, and no encryption of plaintext searchable data inside the executable). You might want to learn something about logic and computer security, if you start looking for footprints in your attic if your front door is wide open and someone decided to take the legal risk to walk straight in.

 

Detection of bot can be made without client. You can detect bot by searching in Blizz DB or by server side logs.

Problem is, that HB is written in .Net you cant do this type of manipulation in .Net. Also you should be able to do not 100% but pretty good detection based on PEB and TEB

 

Obviously, this is an option, but I think the vast diversity of what people being suspended ran the bot for, it seems to be related to HB iteself or the combat routines. I don't know exactly what is logged server side, but logging every LUA call or every key press from any client from now and forever, still makes it a pretty hard task to datamine potential botters from the CR actions unless they are doing something very different from skilled human players. That would potentially create millions of events every second.

My point again wasn't to argue that other explanations doesn't exists, but rather go for the most obvious one first and eventually rule it out. My take is that if they get desperate enough, they will do it. Providing evidence based upon CR log data alone unless there is some dead giveaway, would be shaky proof.

You can still do it by cloaking or modifying the executable by another tool, but .net isn't the ultimate platform for writing system hacks and self modifying code.

I just find it hard to believe that people blatantly think that HB can't be detected on your own computer and that it isn't just legal issues holding that back. In the light of the recent license changes, I'd not be surprised if they did just cross that line and maybe removed the scanning code from whatever part of their software that did it after. We will not know until it's tried legally.

 

I would not go that far.. in 2010 warden in WoW afaik was simply a single set of 100+(forget exact #) modules streamed to players every so often, some times not always streamed to every one at the same time or even the same modules to every one at once. Any one or several of the modules only would contain the 'real' detection code, even possible none would contain anything but junk.

This means as long as they had all the current modules known - they would have to push a warden update to introduce a new model, once again made up of 100+ 'sub modules'. When you have static number of modules known, and a new one is introduced it is very easy to detect and flip the tripwire.

However, it's not always as simple as things were in 2010 and for a long time after. Lots of things they could do differently. They could use something like their old "ExtraWork" when you login to the game to hotpatch in a new warden module, and then later push the new model into the streamed modules to users over time. If they streamed each sub-module every 2 hours, and there were 100 of them to make up the warden module, assuming they sent the exact same submod to every single user online like clockwork every 2 hours, it would take 8 days at the least to analyze every single module of which any single one of the 100+ could detect you.

So even you decide to disable HB for eight days, what stops them from just pushing another update like that on login for a brand new set of 100+ submods, do you just disable the bot right away again for eight days? That is not an option - or the bot would be permanently unusable if you wanted to be safe. I'm not sure how they tried to or did counter this possibility, I'm clueless at this stuff and could be way way off. Ignoring the ExtraWork on login would not work, because when they streamed the new warden modules you would be unable to respond to them properly, getting kicked off/crash after a little. You could relay all the info from a clean client to your client to "fool" the check to looking clean, but that is not even safe to statechecks. You would need full access to the exact memory state of the client at all times.. not realistic.

 

The thing is, if you're running WoW on an unprivileged account with no write access to anything and explicitly just grants write permission to safe files it needs to modify (very few), there is no way they'd be able to do anything but mocking around within it's own process memory. Changing any code on the fly ("streaming") would either mean they'd be running self modifying code, or make some kind of shielded execution space/VM that they can temporarily download code into for execution, in a separate thread. Now, the only thing that code could do, is still limited to accessing WoW's own process memory. If you were to detect call injections from an outside process, you'd have to do so by comparing the return stack with whatever memory offsets are legit inside of WoW, which is a bit tricky and also depends on the implementation of HB (which I'm unaware of); if the calls are actually ran in WoW's context or HBs. In the latter case, it's incredibly tricky to detect and you'd need a lot of assembly code + a lot of other shit compiled into a Game client written in (most likely C++). I don't know HB or WoW in detail, but I know quite a lot about hacking stuff.

 

They can update the game at any time, via the server. It goes like this: Send you a packet, that packet tells your client to download some file, such as a .MPQ. Then just simply extract ExtraWork.dll, and call the ExtraWork function contained in it. This would allow them to update for example the warden at any point and time, and then stream you the updated modules, even while you're actually playing in-game. A lot of the anti-detection is premptive, such as tripwire, to try and avoid detection from ever occurring in the first place by unloading and shutting down.

So what happens if they they do something like this:

1. Send packet to you on login, triggering extrawork to do a 'hotpatch' warden update.
2. The warden, which is just a set of 100+ modules, now contains a single individual new model with detection code out of 100+.
3. They send these new hotpatched warden modules to users one module at a time, changing to a different one out of the 100+ every few hours.

This leaves you in a situation where they could update the warden when ever they please, and every time they do it would take days, maybe weeks, even month+ to analyze every module as you only get them once in a while and there are 100+ of them. If you simply disable the bot every time it sees a new module, it's disabled permanently. If you simply ignore the forced hotpatch update by ignoring ExtraWork to begin with, your client will incorrectly respond to the new streamed warden modules and you will be kicked off the game completely with in a minute.

So simply not allowing them to apply the ExtraWork hotpatch does not solve anything. Looking at the call stack has many ways to avoid, I'm not so sure that has anything to do in of it's self of the recent detection.