Minimal Precautions for In Process Applications

[draco1219]

Hi everyone,

I didn't see much posted on this and thought it would be good to have a thread discussing this topic.

My question is, what in your opinion is the precautions you should take or conventions you should employ when creating an in-process bot?

My application is written in C# and uses the approach which Apoc elegantly outlines in one of his threads.

I inject a bootstrap DLL (unmanaged) into WoW which loads the CLR and loads the C# DLL Domain Manager, which then loads the for lack of better words Bot.exe (which references the engine we'll call it engine.dll which uses WhiteMagic, etc).

So in this scenario I have a bootstrap.dll --> domainmanager.dll ---> Bot.exe (Using WhiteMagic.dll and an engine.dll).

If you use ProcessExplorer you can see all of the modules loaded into WoW.Exe, so obviously it wouldn't be smart to name any of your modules anything malicious such as Bot.exe.

Besides naming conventions for DLLs/EXEs what in your opinion are precautions you should take when developing your in process bot? Please keep in mind this is a bot/application which is private and is not intended to be released.

Thank you again for your response!

[DrakeFish]

If warden is watching DLL names, then please Blizzard fire the man who coded it. I'm pretty sure the minimal protection you could do is make your DLL dynamic by adding random bytes into it at each injections. This will change the bytes size of your dll and it's file hash (unique to each files). I guess there are some information in the PE Header you might want to modify too to make it even more dynamic, but I couldn't tell about them without doing some research.

As stated before, if your injected application is private, there shouldn't be any problem as long as you don't touch to something Warden already watched.

[jjaa]

Don't write to warden scanned memory regions..that's about it...Also wardens uses hashes to scan for dlls so name it w/e you want (ofc you may to avoid malicious names anyway).

[draco1219]

Don't write to warden scanned memory regions..that's about it...Also wardens uses hashes to scan for dlls so name it w/e you want (ofc you may to avoid malicious names anyway).

Ahh thanks for the response! So when you say uses hashes to scan for dlls, it's explicitly looking for known hashesh correct? So if my bot is private, they wouldn't really "know" about it so therefore wouldn't be able to generate any hashes. With that being said, is there any real value into modifying the DLL size by adding a few bytes each time or modifying the PE header like the post mentioned above?

[jjaa]

Ahh thanks for the response! So when you say uses hashes to scan for dlls, it's explicitly looking for known hashesh correct? So if my bot is private, they wouldn't really "know" about it so therefore wouldn't be able to generate any hashes. With that being said, is there any real value into modifying the DLL size by adding a few bytes each time or modifying the PE header like the post mentioned above?

Correct, warden uses a blacklist of hashes to detect modules. A private dll can not be added to the blacklist, as they don't have it. With that in mind i would say that adding a few bytes ect. would just be a huge waste of time.

[reggggg]

With that in mind i would say that adding a few bytes ect. would just be a huge waste of time.

Can you elaborate? This seems like a very obvious counter-detection strategy to me, which perhaps could be defeated by hashing only a static part of a module, though risking false positives and perhaps forces us to start heavily obfuscating the code.

Can anybody demonstrate why this is not an effective strategy to avoid detection?

[jjaa]

Can you elaborate? This seems like a very obvious counter-detection strategy to me, which perhaps could be defeated by hashing only a static part of a module, though risking false positives and perhaps forces us to start heavily obfuscating the code.

Can anybody demonstrate why this is not an effective strategy to avoid detection?

I'm not saying that its not valid method of counter-detection, it would prob be worth looking into for a popular public hack. However its overkill for a private dll. If the dll has not been hashed and its not being scanned for, whats the point?

In any case warden is a relatively timid anti-cheat system, and for majority of private applications can be completely ignored.

[Cypher]

If warden is watching DLL names, then please Blizzard fire the man who coded it. I'm pretty sure the minimal protection you could do is make your DLL dynamic by adding random bytes into it at each injections. This will change the bytes size of your dll and it's file hash (unique to each files). I guess there are some information in the PE Header you might want to modify too to make it even more dynamic, but I couldn't tell about them without doing some research.

As stated before, if your injected application is private, there shouldn't be any problem as long as you don't touch to something Warden already watched.

Lol...

Don't write to warden scanned memory regions..that's about it...Also wardens uses hashes to scan for dlls so name it w/e you want (ofc you may to avoid malicious names anyway).

^ This.

[amadmonk]

For a long, long, LONG time, I ran my primary code in a library called... bot.dll. Still not banned yet Think about it; if they scanned for a dll with the word "bot" in it, then folks running "AbOtrack.dll" (or whatever) would get nailed. Again, I think they fear false positives more than they fear missing a few private botters. Private botters like us really don't threaten their revenue stream very much; it's the widely-spread, commercial bots that they hate.

(Yes, I finally changed the name.)