Nothing was solved in Simi's post. I need to know because alot of my strings are showing in my hex. Important ones that I don't want hexed out of the bot. Please could someone helpe me just if it's even to hide just a few strings.

With enough effort, any string, no matter how well hidden, could be changed.

[quote author=ChR0NiC link=board=17;threadid=1397;start=0#msg10405 date=1053584189]Nothing was solved in Simi's post. I need to know because alot of my strings are showing in my hex. Important ones that I don't want hexed out of the bot. Please could someone helpe me just if it's even to hide just a few strings.[/quote]If simple un-elaborate string encoding is all you're after, then consider these statements:

Here's an example of how I add strings which I want hidden:
Chr(Asc("K"))+Chr(Asc("a"))+FlipString("Ben")+Chr(Asc("o"))+Chr(Asc("t"))

Comes out to "KaneBot". FlipString is a function which I wrote myself which does exactly that; takes a string and returns it being flipped, like so:[code]Function FlipString(Source As String)
Dim i As Integer
Dim Flipped As String
For i = Len(Source) DownTo 0
Flipped = Flipped + Mid(Source,i,1)
Next
Return Flipped
End Function[/code]

VB should store each letter and the "Ben" string separately, making it hard for anyone not knowing what they're doing to realize that it's actually a string instead of machine code that they're looking at.

Additionally, if you do this for different strings in several places, each string containing the same character(s), then if one of those characters were to get changed, other strings might not be understandable.

Take the following example along with the one given above:
Chr(Asc("B")+FlipString(" y")+"K"+Chr(Asc("e"))+"it"+FlipString("neB h")+Chr(Asc("n"))+"e"+Chr(Asc("t"))+Chr(Asc("t"))

Which is "By Keith Bennett". If VB stores the letter "K" at a single location, and references to it by both the first example and the second, then if you were to replace the "K" with some other letter, for example, "T", then the two examples would thus become:
TaneBot
By Teith Bennett


I suppose you could just do "K"+"a"+FlipString("Ben")+"o"+"t", but the added Chr(Asc())'s would help confuse people who do know a little more about what they're doing. Though, again, it is not perfect and can still easily be "fixed" by anyone who's persistant enough.


Again, this is a simple and un-elaborate scheme. Anyone who knows what they're doing and is persistant enough will easily be able to crack this.

The bright side of the, anyone who knows what there doing, problem is the people who will be hexing his bot probably wont fit into that category at all.

Consider trying an application called "telock", It'll compress your exe, and also hide all strings / recognisable data along with it. Sure it's probably reversable, but the typical user wouldn't be able to hex it. Also, you can perform checksums during runtime to check the integrity of your strings.

If you do what Kane suggested, you should also put a char *k = "Keith Bennett"; (or the vb equivolant) somewhere else in your code just to throw them off the scent.

And thanks for telling us your sceme!
[me=iago]goes to hex all kane's software[/me]

[quote author=tA-Kane link=board=17;threadid=1397;start=0#msg10416 date=1053593512]
Chr(Asc("K"))+Chr(Asc("a"))+FlipString("Ben")+Chr(Asc("o"))+Chr(Asc("t"))
[/quote]

i would think the compiler would optimize that out, no?

VB!? Optimizer!? Nah.

If you really just want to protect against dumbasses who only know how to hex and not real reverse engineers, consider base64 encrypting your strings and insert them into your code surrounded by a base64_decode function or something similar.

could RSA encrypt all your strings see if they haxor that ;)

you would have to store the private key in the exe somewhere, that makes it easily reversable :p

[quote author=Etheran link=board=17;threadid=1397;start=0#msg10440 date=1053637889]
you would have to store the private key in the exe somewhere, that makes it easily reversable :p
[/quote]

who says it has to be in the exe 8p

Well, it has to be somewhere, distributed with the bot... In which case it will be trivially reversible.

When I say "trivially" I mean once you hack it, no matter how difficult it was, you think, "well, that was easy".

Compare: Trivial, on MathWorld.

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

[quote author=ChR0NiC link=board=17;threadid=1397;start=0#msg10451 date=1053647705]
Is it possible if....if your bot is hexed, to put the bot in some sort of lockdown??
[/quote]Yes
Perhaps you'd like to ask another, different question? :)

[quote author=Yoni link=board=17;threadid=1397;start=0#msg10446 date=1053644608]
Well, it has to be somewhere, distributed with the bot... In which case it will be trivially reversible.

When I say "trivially" I mean once you hack it, no matter how difficult it was, you think, "well, that was easy".

Compare: Trivial, on MathWorld.
[/quote]

yes but still who in there stupid little mind is going to evin attempt to '1337 h4x0r' it lol.

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

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.

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!

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.

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.

[quote author=RhiNo link=board=17;threadid=1397;start=15#msg10872 date=1054044560]
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.
[/quote]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.

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?

[quote author=St0rm.iD link=board=17;threadid=1397;start=15#msg10918 date=1054087010]
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?
[/quote]How does your design block the attacker from simply setting the client to treat all result codes as success?

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.

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

[quote]
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.
[/quote]

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.

[quote author=EvilCheese link=board=17;threadid=1397;start=15#msg10972 date=1054137037]
This has the advantage that it will be quite tricky for the reverser to work out exactly why the "incorrect case" situation is failing.
[/quote]...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.

HD Serial#

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.

[quote author=Kp link=board=17;threadid=1397;start=15#msg10922 date=1054093472]
[quote author=St0rm.iD link=board=17;threadid=1397;start=15#msg10918 date=1054087010]
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?
[/quote]How does your design block the attacker from simply setting the client to treat all result codes as success?
[/quote]

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.

[quote author=St0rm.iD link=board=17;threadid=1397;start=15#msg11023 date=1054171938]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.
[/quote]

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

[quote author=dRAgoN link=board=17;threadid=1397;start=15#msg11006 date=1054155241]
HD Serial#
[/quote]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.)

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

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.

[quote author=St0rm.iD link=board=17;threadid=1397;start=15#msg10546 date=1053781625]
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.
[/quote]

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

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

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.