Does anyone have Hex Protection for Vb...So when the user hexes your bot with a hex editor , they wont be able to overwrite your current settings...If you dont have a comment to help me , then please dont post it

The simple way to do it would be to caluculate the MD5 checksum of the original exe, and have it checked upon execution of the bot. If it's changed, it's been hexed.

There are plenty of ways around that as shown in them program hacking site thingies, im willing to guess you dont know anything about that, anyways. The best way would be to find a site like www.gamehacking.com and use a compresser and/or encrypter. I'd look for an unpopular one, because them fiendish hex editors have gotten around the encryption methods used by the big boys.

Maybe you shouldnt do a simple "If" then? And if you intend on using a packer or compressor, write your own.

Maybe you shouldn't assume that he knows anything about calculating executable checksums then? I was just providing an alternative if he doesn't.

[quote]Maybe you shouldn't assume that he knows anything about calculating executable checksums then?[/quote]

then he'll ask for more help

Maybe.

[quote]It would be kinda pointless but you could do Form_Load() and then do all that stuff like form1.Caption = "Project Name" and all that stuff.  ::)[/quote]

that wont stop a half way decent hexer ^^

Form1.caption = chr(&h40) & chr(&h41) & ...

would be slightly more secure :)

or have a string:
dim Str = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
and do form1.caption = mid(Str, 5, 1) & mid(Str, 20, 1) & mid(Str, 2, 1) & mid(Str, 10, 1).. etc

That makes it fairly difficult to find what's going on, then put a couple dummy strings so they *think* they've found the right spot, but really they're just changing "form1.tag" or something :)

thats not a bad idea right there :-P

(Thanks to www.try2hack.nl for the idea ;-))

The problem with using Checksums is the fact that there resides a simple cmp and (C or U) jmp which can easily be patched in a few seconds.

Not if your executable is encrypted based on the checksum ;)

yeah unless you use your own encryption, cause just about every popular encryption has public decryption methods everywhere...

Heres another way to prevent strings from showing up in hex/string refrences (idea stolen from Raihan :P)

[code]Dim x1 as long
x1= 779581303
Dim x5 as long
x5= 1685024622
Dim x9 as long
x9= 779773292
Dim x13 as long
x13= 6779503
xz = MakeDWORD(x1) & MakeDWORD(x5) & MakeDWORD(x9) & MakeDWORD(x13)
MsgBox xz 'will be www.noodlez.org[/code]

It looks hard, but not if you write a program to do it for you (like I did)

[quote]Heres another way to prevent strings from showing up in hex/string refrences (idea stolen from Raihan :P)

[code]Dim x1 as long
x1= 779581303
Dim x5 as long
x5= 1685024622
Dim x9 as long
x9= 779773292
Dim x13 as long
x13= 6779503
xz = MakeDWORD(x1) & MakeDWORD(x5) & MakeDWORD(x9) & MakeDWORD(x13)
MsgBox xz 'will be www.noodlez.org[/code]

It looks hard, but not if you write a program to do it for you (like I did)[/quote]
That still leaves it as plaintext in a hex editor...

http://www.un4seen.com/petite/
excellent app
provides anti-hex
checks itself for virus too (like whats his name's checksum idea)

Writing it yourself is better because there won't be premade unpackers.

It's not that hard either, just xor your exe header or something ;)

what you could do is make a routine thats starts in the program that checks to see how many bites the main exe and if its not the right size end the program but you would probally want to use controls to do this. so make a label that is invisible and has the size of you program on there and then have the size check the the ivisable label.

this wont prevent people from opening your program in hexworkshop or what ever but they wont be able to change things easly

I'm just trying to explain you how my protection scheme works cause
i don't think .net code would help you much:

All program code is encrypted inside the installer. When installing it's getting decrypted and based off some hardware and registry specific data on the client computer encrypted again. This way the encryption value that works for one pc doesn't really help the other guys using the program. To get the decryption value you would have to know where the program collects the data from. To make it a little bit harder just collect some data you don't use while decryption and make it look like they'r important for you ;)
When decrypting put the data into the isolated storage (win only), protect the folder and delete it on exit.

btw, the installation is web-based with a checksum from a mysql db so it's sure there wasn't anything modified.

Of course you could add alot more like a md5 checksum calculated off important parts of your exe to the decryption too, but i don't think someone will effort that much work into getting just the above decryption scheme for hexing or modifying a bot :'(

[quote author=NetNX link=board=17;threadid=642;start=15#msg9840 date=1052813746]
what you could do is make a routine thats starts in the program that checks to see how many bites the main exe and if its not the right size end the program but you would probally want to use controls to do this. so make a label that is invisible and has the size of you program on there and then have the size check the the ivisable label.

this wont prevent people from opening your program in hexworkshop or what ever but they wont be able to change things easly
[/quote]

That's silly. Most 'hexes' of bots don't change the size. They just change the data, the filesize remains the same. Even if they did grow or shrink, a checksum of the file is a better approach, since that would detect any changes to the file.

It's easy to make the executable work only on one computer: encrypt it based on some magic hardware code.

The hard part is having people give out the decrypted executable.

[quote author=Skywing link=board=17;threadid=642;start=15#msg5018 date=1043919992]
[quote]Heres another way to prevent strings from showing up in hex/string refrences (idea stolen from Raihan :P)

[code]Dim x1 as long
x1= 779581303
Dim x5 as long
x5= 1685024622
Dim x9 as long
x9= 779773292
Dim x13 as long
x13= 6779503
xz = MakeDWORD(x1) & MakeDWORD(x5) & MakeDWORD(x9) & MakeDWORD(x13)
MsgBox xz 'will be www.noodlez.org[/code]

It looks hard, but not if you write a program to do it for you (like I did)[/quote]
That still leaves it as plaintext in a hex editor...
[/quote]

wouldn't that just turn back in to plain text (split up 4 chars at a time, possibly reversed) post-compile?

What you also have to consider when doing this is the actual time and effort the people involved are going to be willing to put in to get their name on your bot.

Also their relative skill-levels. Above a certain level of skill and they could easily write their own bot anyway and likely wouldnt bother to hex yours.

When I've wanted to get literals past various scanning methods in the past, I've stored them XORed within my program source and then un-XORed them at runtime in a simple function and stored them in dynamically allocated memory.

Other effective approaches I've seen include the aformentioned checksum checking approach, and another method which involves hashing the whole process space of your application at runtime and using that value as part of a one-way decryption of a key function, causing a code-flow redirection. If the exe is altered in any way, the code flow remains unchanged and the important function is skipped.... outputting an error message or carrying out whatever malicious revenge you wish to carry out against your would-be hexer.

This would probably be enough to deter all but the most ardent/skilled reverse engineer.... but those people are going to work around WHATEVER you implement, so it's a case of judging your target audience and setting protection appropriate to the realistic level of skill and effort you expect them to expend trying to "break" your program.

There are quite a few examples of all of these mentioned protections around on the net. If you want a particularly interesting read... then do a google search for v-box technology as used to protect Macromedia trial software. It's a VERY impressive protection, but has still been compromised.

Another good read is the dongle protection technology used on older versions of 3D studio MAX. That used a value obtained from a serial-port hardware "dongle" to alter and decrypt various code-flow paths.. so even when cracked.. without the dongle it would slowly leak memory and performance would degrade until it crashed.

[quote author=Camel link=board=17;threadid=642;start=15#msg10006 date=1052969127]
[quote author=Skywing link=board=17;threadid=642;start=15#msg5018 date=1043919992]
That still leaves it as plaintext in a hex editor...
[/quote]
wouldn't that just turn back in to plain text (split up 4 chars at a time, possibly reversed) post-compile?
[/quote]
Erm, that sounds like the same thing.

wouldn't it make more sense to create a unique pair of functions for encoding and decoding an encrypted string, and use it only for your strings that need to be protected?