• Welcome to Valhalla Legends Archive.
 

Hex Protection

Started by SiMi, January 27, 2003, 05:40 PM

Previous topic - Next topic

Skywing

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

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

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

Atom

#16
http://www.un4seen.com/petite/
excellent app
provides anti-hex
checks itself for virus too (like whats his name's checksum idea)
I am back! aINC is dead, ThinkTank PRO is alive.
VB, JAVA, ASM, C, its all yummy to me.

Banana fanna fo fanna

#17
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 ;)

NetNX

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

Smurfling

#19
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  :'(

Arta

Quote from: NetNX on May 13, 2003, 03:15 AM
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

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.

Banana fanna fo fanna

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.

Camel

Quote from: Skywing on January 30, 2003, 03:46 AM
QuoteHeres another way to prevent strings from showing up in hex/string refrences (idea stolen from Raihan :P)

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


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

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

EvilCheese

#23
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.

Yoni

Quote from: Camel on May 14, 2003, 10:25 PM
Quote from: Skywing on January 30, 2003, 03:46 AM
That still leaves it as plaintext in a hex editor...
wouldn't that just turn back in to plain text (split up 4 chars at a time, possibly reversed) post-compile?
Erm, that sounds like the same thing.

Camel

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?