More Hex Protection

[Yoni]

HD Serial#

Any check that boils down to "if (magic != somenumber) die();" can be easily bypassed. (Though you didn't specify what would be done with the HD serial #, I assume this is what you meant.)

[smoke]

I'm sorry, but no matter what people say, there is really no way to make something completely secure.  Until there are services at the Operating System level (such as the microsoft driver certification), there is really no way to prevent the owner of the computer from modifying any program installed and at the same time getting around any sort of version checking protection features.

Now, if the operating system provided a secure mechanism for both securely communicating with a server and providing a checksum, control over binaries might become slightly better, but it still won't be hack proof.  The only true way of doing it would be to have some physical device that not only performed the checksum but also securely communicated the result to a host in such a way that the host knows that it is a trusted device, then we might be getting somewhere...

But we still run into the same problem.  How can we determine whether to trust a device (or program).  To be honest, there are always going to be ways of spoofing these values until something more secure is developed (possibly quatumn computing based authentication?).  Before you go thinking that it is truely possible to prevent people from producing modified versions of your software, you should first decide how far it really is necessary to go.  Some basic checksum that is provided by the server and then verified on the server (similar to battle.net's) will probably be enough to keep people without the skills to write their own bot from hexing yours.

-smoke

[Banana fanna fo fanna]

Camel: I only do it to give vL a hard time

smoke: The way I outlined is indeed uncrackable. Perhaps they are able to modify the exe, so what? The bot still cannot be leaked.

[smoke]

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.

Sure... encrypting the strings may make it more difficult to find out where the data is stored, but it is still possible to figure out the decryption scheme to steal that information.  It's all there in the assembly code.  The fact is, no scheme is foolproof unless you can individually select trusted/non-trusted hosts by a unique identifier.  You still run the risk of the data being spoofed.

Your comment that it is indeed uncrackable is false, since the data is indeed being sent off to a server to be authenticated and there is no way the server can know for certain that the client is uncracked, there are always ways of hacking the program to send the correct information while in normal circumstances it would send the wrong data.

The encryption of data transmissions is to make it impossible for a middleman to figure out what is in the data.  It is not a means of determining if the server or client is trustworthy.  The CRC check is probably the simplest way of discouraging wannabe crackers from modifying data in the executable, true crackers could find their way around it in a heartbeat.

-smoke

[Banana fanna fo fanna]

I'm assuming the goal would be to limit usage, and that would be achieved.

[Noodlez]

Not if one person cracks it, then releases it. At one point I thought BNLS was great leak protection... since you could just change the password if anyone who you don't want to have your bot gets their hands on it. But... since BNLS id's/passwords are given out so easily, someone could just hex your bot with their own BNLS id/pw.

Although, maybe you could have your bot request the ID/PW from your own server...yet again a real cracker could bypass that.