Cracking methods and how to stop them

[c4s]

@utopiomania
Sure, why not, I (we?) can try it out. But I think Rescator is the better one here.

[Thorium]

To answer the initial question: Yes, the .exe can be dumped, no problem. There are Plugins for OllyDbg like PEDump, that do it full automaticly. No need to actualy crack anything with your "protection".

The problem is how you check if something is valid. If you just use "if... else...", it will be cracked in seconds. That will compile into jumps which can be easiely patched. There are very complex methods with hashes and virtualization but it takes a huge lot of time to get into that and produce something actualy usefull.

[Marlin]

Just some random thoughts:

If the "cracked" version of a software is more convenient to use
than the "legal" one,

which version would you want to use?


If resources go to "protection"
(trying to prevent the usage of the product
[if the right preconditions are not met])
instead of improving the product,

couldn't it be, that another product with more resources
for improvement would be or soon become a better choice?

[Rescator]

@Marlin
Exactly, which is why I'm using Paint.net http://www.getpaint.net/ instead of a "certain" graphics package...

[DoubleDutch]

I often buy the original game, but use the NoCD cracked version. Can't stand having to put the original CD back in the drive.

[utopiomania]

@utopiomania
Sure, why not, I (we?) can try it out. But I think Rescator is the better one here.

Great, I'll have a little crack-me ready for you in a few days.

[Rescator]

@c4s I'm no cracker, heck I can't disassemble stuff by hand even, I've dabbled with making some trainers (using ArtMoney or CheeatEngine on the odd game), so my interest in this stuff is mostly as a developer and a user.
So my mentality is... How much time and energy do I want to waste on protection as a developer, and what kind of system would I be willing to put up with as a user myself.

[Trond]

I'm sorry SFSxOI but me and Trond are kinda ganging up on ya here

Well, yeah, but thats OK, its sort of expected on subjects like this. You just don't see the reality of what is actually happening, and the systems in the labs today with the concepts already proven and moving towards deployment stage, we are even testing some of them here so I know they work for a fact. So i'm thinking what will be and you are thinking what already is, its a matter of time frame relationships thats all. The company I work for even hired well known (but now reformed - after they got arrested of course ) software pirates/crackers to validate the two part binary approach and they were not able to keep up after the first release and not one of their cracks worked did not work after the first hour initial release as they were always behind and their cracks and hacks did not work on the updated authenticated releases after the initial release. The ones that did not have the proper hash and were not recognized by the server did not work and failed despite the things being cracked and hacked to ignore those things or work around them as they were never able to get the second part from the server that was needed for the whole thing to work. Piracy with such a system would be so burdensome to the pirates that the pirating rate would drop to almost 0.

Hey, don't blame anyone but DRM and big content, they are the push behind it.

Of course, if you keep making new versions, new cracks will have to be made for each new version. But making a new version every hour is not feasible for an independent developer.

[utopiomania]

But making a new version every hour is not feasible for an independent developer.

It's just a matter of reprotecting the original exe. Just open the right project, protect it, save, and you have
a completely different exe.

Here is some methods one obfuscator use to protect your work:

Virtual Opcodes Obfuscation
Code Virtualizer will create a unique virtual machine for your application. That unique virtual machine can only understand a specific machine code language (virtual opcodes); hence, Code Virtualizer will convert your sensitive x86 binary code into virtual opcodes. The Virtual Opcodes Obfuscation option will produce more complex opcodes for the generated Virtual Machine, making it even more difficult for a cracker to understand the format of each virtual opcode.

Note that the more complex the virtual opcodes you select, the bigger the size your sensitive x86 will be when converted into virtual opcodes.

Virtual Machine Complexity
Code Virtualizer will create a unique virtual machine that will be embedded inside each protected application, executing the virtual opcodes that where converted from your sensitive x86 code. The generated virtual machine will know how to execute each virtual opcode in order to produce an equivalent execution as the original application.
The Virtual Machine Complexity option gives you the ability to produce a more complex virtual machine, making it harder for crackers to reverse the unique virtual machine generated for your application.
Note that the complexity level has a direct impact in the size and performance of the generated virtual machine.

Multiple Virtual Machines
Code Virtualizer offers the option to generate several virtual machines inside your application, exponentially increasing the security level of your sensitive code. Each virtual machine is totally different and can only understand a specific virtual opcode format.
When you select more than one Virtual Machine, your sensitive x86 code will be converted into different virtual opcode formats. In this way, your sensitive code blocks will be executed by different specific virtual machines.
For example, if you insert 10 sensitive code blocks to be protected by Code Virtualizer and you choose 5 virtual machines, each virtual machine will execute 2 sensitive blocks. The following table represents this example:
...
Again, note that the more virtual machines you add into your application, the bigger the size of the protected application will be.

Last Section Name
Code Virtualizer will place the virtual opcodes and the unique virtual machine inside the last section of your application (at the end of your application code and data). If you want, you can re-name the last section to a different one or you can leave it untouched, completely hiding the presence of Code Virtualizer inside your protected application.

Strip Relocations
This option will remove the relocations section in EXE files, making your protected application smaller in size.

Re-Virtualization
Re-Virtualization is a powerful technology against Reverse Engineering. It's based in re-virtualize each generated virtual machine, exponentially increasing the protection in each protected block.
The disadvantage of this technology is the performance decrease in each protected block, taking much more time the execution of protected blocks. If you insert lots of processing inside protected blocks, we don't recommend to enable the Re-Virtualization technology. You should test your application with the Re-Virtualization option enable to make sure that your protected blocks run smoothly.
Notice that Re-Virtualization can increase the size of your application about 100 Kb!

Opcodes Mutation
Code Virtualizer can mutate the internal virtual opcodes into another opcodes, giving more complexity to the final virtual machine. Notice that opcodes mutation will make your macros bigger when protected and you can also notice a performance decrease in your protected application. We recommend you to make a general test over your protected application to make sure that your Virtualizer macros are executed as fast as expected.
The mutation level can also be set for each specific block by using the VIRTUALIZER_MUTATIONx_START (VirtualizerMutationxStart) macros. If you set the mutation level for a specific block, no matter which Opcodes Mutation level you set up in the Code Virtualizer user interface, the block will be always mutate with the level selected in each specific macros. The Opcodes Mutation level will specify the mutation level for macros which do not specify any mutation level, that is, for VIRTUALIZER_START macros.

Fake Stack Emulation
Fake stack emulation is a very specific option for applications which pressume non allocated values in the stack be initialized to zero. This happens in some PureBasic applications and should be only enabled if your application really requires it.

Multi Branch Technology
This option will insert multiple conditional branch instructions inside your unique virtual machine. The Multi Branch Technology makes much harder for a cracker the analysis of your virtual machine because he needs to know when a specific branch is taken or not to continue analyzing your unique virtual machine. Notice this option will increase the size of your protected application a few Kbs.

You can easily set the protection level from low to 'the full monty' in each project to your own liking.

I Just post this quote so it will be easier for the whizkids amongst you to eat my crackme for breakfast.


I'll have my crackme ready in a short while, I would like to make it a good one. It's been an oval weekend here,
and today is the Norwegian Constitution Day, so I haven't started on it yet, but I will tomorrow.

[AndyMK]

I think SFSxOI two part binary system is a pretty good idea if done properly but only if the app in question is an internet based app (mine is). If your internet connection is down, your not going to be able to use the app anyway. I would have no idea how to implement it though.

[codewalker]

Forget about armadillo, it has been broken many times.
cw

[Blue Steel]

anything that can be written to protect software can and will be able to be broken or circumvented eventually. itys the nature of Software .. ie: its SOFTware so it can be edited, hacked, patched, etc .. a lot easier than HARDware .. ie: game cartridges etc .. even these can be duplicated and copied.. as again its the nature of it.. if you can read it (which you need to do to run it) you can save it out and hence have a copy which you can then manipulate / edit / hack / distribute

NO security system is 100% secure NONE.. given time and resources it'll get hacked/ brocken.
and whats more the tuffer it is the more attention it'll get from the true hackers. (ego trip.. anything you can do they can get around.. eventually)

[utopiomania]

True, but that isn't the end of this discussion.

Protection will be broken eventually, but if a hacker needs to work 24/7 for the next 12 month to
crack my little crackme, then I'm a winner, and the cracker is a looser.

So you can ignore the theoretical argument that anything can be cracked. In real life, they will
give up if it's too much work for nothing.

Also, everybody will steal your app if it's unprotected and you ask money for it.

[Trond]

Also, everybody will steal your app if it's unprotected and you ask money for it.

Not if you have to pay to get access to the unprotected version.

Then give each customer a unique file with a warning that the file is unique, and if it's distributed you will know who did it and go after them.

[c4s]

Depends on who is using your application. I mean there are users that don't know about cracks and don't want to either. So if your target user is one of the honest people you still get some money even if there isn't any protection.

And giving up is one point but when it's coming from a large producer like Ubisoft the hackers see it as a challenge / game to beat where you even get famous for. I think under certain circumstances a harder protection can attract even more hackers.