Anti cracking tool

[hutch--]

I have just written this piece to test out an idea that is very easy to do and performs a useful function for people who need to try and protect software that they write and sell. It is not in itself a protection scheme but a method of randomly changing the actual file and loaded image of a binary file every time it is built by simply changing the order of included files in the project.

The utility attached does no more than randomly shuffle the order of lines in a file. The use is to have an application broken up into a large number of seperate files that can be included in the main project, have a seperate include file that has all of the other include files for the app in it and each time you build the file, it shuffles the order of the include files so that the resulting binary image is different every time it is built.

This means that if you are selling registered copies to end users, you can build each end user a unique file that is different to any other version that you have built with the same code. The virtue of every file being unique is that patching the file is far more difficult to do when there are a multitude of different versions around, even if they look the same and have identical functionality.

It is not a protection scheme in itself but should be very useful for people who need to design protection systems.

[attachment deleted by admin]

[Dom]

Hi Hutch,
well just came here from the win32asm community to get some new stuff for reading...
so after a very long time i'm finally registered again ... (one or more hacks were between).
And somehow I think this post is wired.

First of all the method itself. When software is published, I think its mostly done
(1) pretty often, or (2) for download in the web. In both cases your anti-cracking
way cannot be applied, once for compilation time and 2. because people will
cancel the download before some wackin script compiled a new binary that they can download.
The only way where it might be useful is when a cracker stays with one file
and never wonders about why the crack only applies to his version.
Besides why is "hutch" in need of a 10kb file to re-sort strings within a file, i don't get it...
could you give more info on that? From my point of view shuffle.exe is pretty
much designed like a blackbox so why don't you flush the resort thing and
stay with the stuff you applied on shuffle.exe !?

still, nice to be back.
Dom

[PBrennick]

I think the idea has merit.

The only way where it might be useful is when a cracker stays with one file
and never wonders about why the crack only applies to his version.

Well, that is the point.  That is where we want it to be useful.  :U

Paul

[hutch--]

Hi Dom,

Glad to see you back again. All shuffle does is change the order of lines in a given file and in the context of creating unique versions of a final exe file, it can help by changing the order of include files so that the binary image is different every build. I have tested it and while the exe looks identical and works exactly te same, a FC on any two builds shows the content to be different every time. It is possible to get a duplicate if the count of lines is low or if a massive number of builds are made.

It will not help with a single distribution but in the context of an author who builds a version for each registered user, it ensures every version is unique or close to it and it makes patching registered version a real pain in the ass. The real win is its automatable easily so if someone wants to run the idea from a distribution point, it can be done.

It is up to the author to put any protection sysem in place as shuffle is a tool for people who wish to protct teir binaries, it is not a protction tool in itself.

[Dom]

it is not a protction tool in itself.

...but still GOT some protection (shuffle.exe). Any infos on that one? Please let me know...
regards, Dom

[hutch--]

Dom,

shuffle.exe does nothing more than random shuffle the order of lines of text. Where it can be used by a programmer designing a protecion scheme for an applicaion is in its capacity to randomly shuffle a set of include statements so that they are in a different order every time the app is built. You would use it something like this. make an include file for the asm app that is itself called by another include file.

Code Select Expand


include file1.asm
include file2.asm
include file3.asm
include file4.asm
include file5.asm
include file6.asm
include file7.asm
include file8.asm


Run shuffle on the file that has this content and it randomly changes te order of the include files which changes the order of code that is included in the application. The app looks identical, runs identically but its binary image is different every time it is built and this is a disaster for patchers. Its no joy for in memory patchers either and its very easy to do. Run the result through an EXE compessor and it gets even messier to patch the file.

This is not a protection scheme but its a useful toy for people who need to create protection for an app they may be selling where they can routinely build a custom version for every paying customer, bury what they like in the file as far as user names, serial numbers etc ..... and make each one a different pig to patch.

[Dom]

sorry I think there is some misunderstanding.
so far I think I got your method, hutch. What I'm interested in is the stuff you applied on shuffle.exe so that
it grew to 10kb, i.e. it loads its imports by itself, has relocation data (in an executable?)... and pretty
un-readable code...
Dom

[hutch--]

Dom,

Its been a while but from memory most of the PE structure methods, trick import tables and the like have been busted long ago but you do have a few other tricks that are no fun either. Try dynamically loading code from data into allocated memory and running those functions that way. Encrypt the code and store it as either data in the data section or dump it in the code section as raw DB data where it will not be executed.

Using shuffle would still be useful here as it makes each binary image diferent as well. The main advantage in protection schemes is complexity and work load, anyone can bust something if they are good enough and take long enough but making every binary image different and using a pile of tricks that are aimed at increasing the complexity by some powers solves many problems.

There will never be a simple pat formula for protecting binary code but ever increasing complexity is a good substitute and being ideosyncratic about it makes them work harder again.

[hutch--]

I had the time to make an example using one of the older examples from the masm32 example code. It is the richedit sample and it runs the same, looks the same and builds the same size but every binary image is different. All I have done with the example is split it up into a lot more include files which increases the range of different combinations available by shuffling the include files.

[attachment deleted by admin]

[Mark Jones]

This might help against a patchng-style attack, but if your app needs a password to be registerred, and some cracker breaks that routine, this method is moot. :boohoo:

Hmm... what we need is an "assembly to spaghetti" source code converter. :bdg

[QvasiModo]

I'm not sure how good it is to prevent cracking, but this method can be useful for hiding a watermark. It's not bulletproof: IDA with the bindiff plugin will defeat it.

[Igor]

Sorry for writing in so old topic but i just wanted to point out that there is no point in protecting exe in this way. Because when cracker manages to crack your application, than he can just send that specific exe file that he managed to crack...

[BogdanOntanu]

It is still very useful for watermarking the executable in a transparent way...

For example:
- IF you sell small shareware games and you know each of your buyers from their credit card details..

Then if you find a leaked cracked copy on the internet you can detect who is the buyer who's binary was used for the crack...
:D

Then assume your game has some extra features that are internet enabled from your server. For example: storing high scores in a web hall of fame, playing internet multilayer games or the benefit of periodic downloads for new levels or updates.

In this case you can disable those features for all cracked copy... :D

[ecube]

Hutch,
this is an interesting idea and code, thanks for sharing. I was thinking about extending it to support proc's shifting while leave the rest of the code untouched. I think the best way to do this is

- count how many lines are in the source file
- find all procs and add to an array the line number of each
- add all proc names to another array, randomize the order
- then create a file and write the untouched data and new proc's shifted around

I think that'd be the easiest approach, atleast that's how i'm going to go about writing it, if you have an easier one feel free to share :D

[hutch--]

cube,

Breaking the source code up into as many procedures as possible makes the variation a lot larger but it means you have many more small files to deal with. No big deal in itself but you have to set up an app to do that. Within the boundaries of what you can achieve with a tool of this type the capacity to produce a different binary image for every build is very useful for people who regularly write software like shareware or similar.

When I get the time one day I will have a play with a dynamic version that changes the loaded binary image every time the app starts but it is a bt more complex in terms of design. You can do it by dynamically constructing procedures on the fly as the app loads by writing the code to executable memory and you can also use DLLs that are loaded on call rather than statically as you can then change the load order so that on every start each DLL is loaded into a different memory address.

The general drift is to increase the complexity that the attacker must put in place to have any chance of succeeding and dynamic variation if done properly would be a genuine headache to have to deal with from an attackers point of view.

Something that will come in time is methods that utilise multiple threads again constructed at runtime dynamically that will make live patching and similar trick a lot more complex again.