Need advice on hacking software development

Question

I am currently working on a project where I need to create some architecture, structure or any standards with which I can "at least" increase the method of hacking software, namely add it to software security. There are other ways to activate software, which includes Internet activation, keys, etc. I am currently studying several research papers. But there are many more things I want to discuss.

Can someone bring me to some decent forum, mailing list, or something like that? or any other help would be appreciated.

Answer 1

I'll tell you the closest to crackproof: a web application.

Desktop applications are doomed for many other reasons, but running your application “in the cloud” in a browser gives you much more control over security.

Desktop software runs on the client computer, so the client has full access to it. The web application runs on your server, so the client sees only a little of it.

Answer 2

Isn't that a sign of success when your product is hacked? :)

Seriously, however, one approach is to use license objects that are serialized in XML and then encrypted using public / private key pairs. They are then read back at runtime, de-serialized, and processed to make sure they are valid.

But there is still the ubiquitous IsValid () method, which can be hacked to always return true.

You can even put this method in a signed assembly to prevent unauthorized access, but all you did was create another layer, "IsValid ()", which could also be hacked.

We use licenses to enable or disable various functions of our software and to check support / update periods. But this is only for our legitimate customers. Anyone who wants to get around him, perhaps, can.

We trust our legitimate customers not to try to circumvent licensing, and we agree that our illegal customers will find a way.

We would spend more money trying to emphasize the "proof of injustice" of our decision, which we lose to people, pirated programs.

In addition, you should consider the pain for our legitimate customers and ask them to insert a license line from their online account page - this is the same pain as I would like to miss it. Why create additional barriers for potential customers?

In any case, depending on what solution you already have, my description above may give you some ideas that can reduce the likelihood of someone hacking your product.

Answer 3

You need to start by breaking into a local gang of hackers, introducing an 11-year-old who wants to “hack”. Once you have earned the trust, you can find out which features they find most complex. Since you are secretly releasing “undetectable” software on local bulletin boards, you can see what they do with it. Build your knowledge until it can no longer crack your software. When this is done, let your personality be known. Ideally, this will be seen as a sign of betrayal that you are working against them. Hopefully this will force them to contact other hackers outside the local community to attack your software.

Continue until you reach the top of the hacker mafia. Write your dissertation as a book, sell it to HBO.

Answer 4

As nute said, any code that you release to the client machine can be hacked.

Do not try to "reveal". Try "hold back enough to reasonably protect my assets."

There are many ways you can try to increase the cost of hacking. Most of them cost you, but there is one thing you can do that actually reduces your costs by increasing the cost of cracking: deliver often.

There is the ultimate cost of hacking any given binary. This cost increases by the number of binary files. If you release new functionality every week, you will essentially split your users into two groups:

• Those who do not need the latest features and can wait for a crack.
• Those who need the latest features and will pay for your software.

Using traditional methods to combat cracking, you can multiply the cost of hacking a single binary file and, therefore, widen the gap between the release of a new function and its availability on the black market. To top it all off, your expenses will drop, and the amount of value that you deliver over a period of time will increase — making it free.

The more often you release, the more you find that quality and cost are rising, cost is decreasing, and the less likely people are to steal your software.

Answer 5

As already mentioned, as soon as you release the bit to users, you have given up their control. A special hacker can change the code to do whatever he wants. If you want something that is closer to the crack, do not release the bit for users. Store it on the server. Provide access to the application via the Internet or, if the user needs a desktop client, store critical bits on the server and provide them access through web services.

Answer 6

Like other users, there is no way to create full-fledged software with cracks, but there are ways to complicate the work with the software; most of these methods are actually used by bad guys to hide malware inside binary files and by game companies to make it harder to crack and copy games.

If you are really serious about this, you can check for example which executable packages such as UPX. But then you also need to implement the unpacker. I really do not recommend doing this, but studying the defenders of the game and binary obfuscation can help you in your quest.

Answer 7

First of all, in what language do you write this? It’s true that a crack program cannot be achieved, but you can always make it harder. A naive approach to application security means that a program can be cracked in minutes. Some tips:

If you deploy a virtual machine, this is too bad. There are not many alternatives. All popular vms (java, clr, etc.) are very simple to decompile, and no obfuscator and signature are enough.

Try to separate the programming of the user interface with the base program as much as possible. This is also a great design and will make work on the cracker more difficult from the graphical interface (for example, enter the serial window) in order to track the code in which you are actually checking.

If you compile the actual native machine code, you can always install the assembly as a release (so as not to include any debugging information), with optimization as high as possible. Also, in critical parts of your application (for example, when checking software), be sure to make it a built-in function call, so that you will not get a single point of failure. And this function is called from different places in your application.

As already mentioned, packers always add another layer of protection. And although there are many reliable solutions now, you can ultimately be identified as a false-positive virus by some anti-virus programs, and all known variants (for example, UPX) already have quite frank unpackers.

There are some anti debugging tricks that you can also find. But this is a hassle for you, because at some point you will also need to debug the release application!

Keep in mind that your priority is to make the critical part of your code as possible. Clear text strings, library calls, gui elements, etc. These are all points at which an attacker can use to track critical parts of your code.