More Hex Protection

[Moonshine]

Is it possible if....if your bot is hexed, to put the bot in some sort of lockdown??

Yes, but it all depends on what your definition of lockdown is.  You could do anything from exiting the bot to totally crashing their system (They diserve it! ).  If you wanted to perminently refuse them access from using your bot, you'd need to take other measures, which are beyond the scope of this answer.

[TheMinistered]

While any good reverse engineerer could remove protection with time to spare,  I recommend doing a CRC check.  You can try using CRC16 or CRC32 algorithms.  These algorithms are publicly available in a variety of languages.

Note:  I recommend finding an assembly implementation and using a hack around to use it in visual basic.  I say this because the CRC algorithms I've seen in visual basic are usually quite slow!

[Banana fanna fo fanna]

I'd say a combination of encrypting your important strings and doing a CRC check is all the protection you'll need. Most of the better reverse engineers on b.net write/have their own bots, so they won't bother.

[RhiNo]

just do as many people are doing now make the bot go to your auth server first.  This will allow you to control who uses your bot and make them register it first.  This will cut down on the people using your bot but it will increase the chance of your bot not being hexed if your that worried about it.

[Kp]

just do as many people are doing now make the bot go to your auth server first.  This will allow you to control who uses your bot and make them register it first.  This will cut down on the people using your bot but it will increase the chance of your bot not being hexed if your that worried about it.

Well, that'll help until someone gets around to making the bot not use an auth server and/or use a server under their control.  Without some sort of protection against exe modification, it'd be pretty easy for someone to manipulate the client's authentication code.

[Banana fanna fo fanna]

Solution is easy.

EDIT: Each executable you distribute will have a different checksum. You should probably combine this system with standard CRC checks.

Have an EXE checksum correspond to a CD key they registered beforehand. The auth server sends a seed and checksums the executable with that key. They then send the cdkey (in encrypted form/not plaintext) to the server. The server does the CD key hashing and sends the info back.

Now you can ban CD keys and your bot can't be cracked. Before someone says they can crack it and make it use their own server, if they go through all that work and know how to do it, why are they using that bot in the first place?

[Kp]

Solution is easy.

EDIT: Each executable you distribute will have a different checksum. You should probably combine this system with standard CRC checks.

Have an EXE checksum correspond to a CD key they registered beforehand. The auth server sends a seed and checksums the executable with that key. They then send the cdkey (in encrypted form/not plaintext) to the server. The server does the CD key hashing and sends the info back.

Now you can ban CD keys and your bot can't be cracked. Before someone says they can crack it and make it use their own server, if they go through all that work and know how to do it, why are they using that bot in the first place?

How does your design block the attacker from simply setting the client to treat all result codes as success?

[EvilCheese]

Move all your remote auth code into a dll.

Have your exe CRC check the dll, then use the value obtained as part of a computation or function essential to the correct working of the program.

Doing it in a transparent way would be best, ie. use the value obtained as part of a function pointer manipulation for a pointer loaded with GetProcAddress aimed back at the auth dll, so if the auth dll is compromised, the exe code will attempt to call some arbitrary code location within it, and probably cause untold weirdness.

This has the advantage that it will be quite tricky for the reverser to work out exactly why the "incorrect case" situation is failing.

[smoke]

I'm sorry, but there really is no way of doing what all of you are suggesting.  We have proven this by bypassing battle.net version checks.  No matter what sort of CRC checksum you devise, there will always be a way that the client can be changed so it always sends back valid checksums.  It doesn't matter where you put the checksum code or what you do your checksum on.  The fact remains, the only way to secure your application is to take your computer/hard drive containing the only known copy of your program, unplug it, put it in a safe, seal it in a block of concrete, and send it to the bottom of the ocean.  Only then would you truely protect your program from being tampered with.

My opinion is this, why put some much work into making it tamper proof?  If you are so concerned with people Hexing your code, then just opensource your application so they have no reason to hex it.  It really doesn't matter though, in most cases people could care less with modifying your application (unless you are afraid of viri).

-Smoke

[EvilCheese]

take your computer/hard drive containing the only known copy of your program, unplug it, put it in a safe, seal it in a block of concrete, and send it to the bottom of the ocean.  Only then would you truely protect your program from being tampered with.

You're forgetting the safe-cracking concrete-eating super intelligent asm-programming deep sea squid. They've been trying to get their hands on my code for years.

[Yoni]

This has the advantage that it will be quite tricky for the reverser to work out exactly why the "incorrect case" situation is failing.

...and the disadvantage that if the reverser is intelligent and persistent enough, he/she will eventually be able to crack your program even with such elaborate protection.

[l)ragon]

HD Serial#

[Zakath]

Once again, though, we come back to this: a programmer competent enough to overcome the sort of checks St0rm and others have suggested won't NEED to overcome them...if they're that good, they could write their own bot.

[Banana fanna fo fanna]

Solution is easy.

EDIT: Each executable you distribute will have a different checksum. You should probably combine this system with standard CRC checks.

Have an EXE checksum correspond to a CD key they registered beforehand. The auth server sends a seed and checksums the executable with that key. They then send the cdkey (in encrypted form/not plaintext) to the server. The server does the CD key hashing and sends the info back.

Now you can ban CD keys and your bot can't be cracked. Before someone says they can crack it and make it use their own server, if they go through all that work and know how to do it, why are they using that bot in the first place?

How does your design block the attacker from simply setting the client to treat all result codes as success?

Because the client doesn't know how to hash CD keys, thus it cannot be used to log on bnet.

Even if your CRC checks are bypassed, leaks won't be a problem, since it is still restricted to one CD key.

[Camel]

Because the client doesn't know how to hash CD keys, thus it cannot be used to log on bnet.

Even if your CRC checks are bypassed, leaks won't be a problem, since it is still restricted to one CD key.

but then you'll have to fight off the same lamers who attack bnls for "stealing cd keys"