I struggle with the licence of the software I wrote in C(the core) and C++(the GUI).
At the beginning I thought I'd use some crypto algorithm, but it was very easy to read the password stored inside the executable.
So to prevent hacks I decided to store all the valid serials inside the executable, my optimistic guess was there would be 1000 serials. No need to encrypt anything. But I read that it is possible to edit the executable, this means that if I write:
if(tb->is_demo)
{
//check limits
}
Somebody can by-pass it and write:
if(false)
{
//check limits
}
So, it becomes hard to protect my software, each solution that comes to mind, earlier or later there is a main if somewhere that can be bypassed.
The question are two:
Is possible edit an executable?
If yes, what can I do to avoid to get edited?
is possible edit a executable?
Without surprises, Yes.
if yes, what can I do to avoid to get edited?
You cannot completely avoid it. Big software development firms are working on the subject, yet their softwares (Professional software, games, ...) are hacked and used for free anyway.
What you can do is make the hack more expensive than your licence cost. You also can accept being "frauded". Or you can protect yourself by other means that technological ones (think law suits).
You may ask how to "make the hack more expensive than your licence cost?". This is off-topic on Stackoverflow. But be sure libraries answering that need exist. Now is the time to make your google skills pay ;)
Anyone can easily edit your executable so I would advise not to store all the valid serials in your program.
You could look into this open source project Open license manager
Another option is to store all your valid serials in a database on some server and create an API that you can make requests to whenever you want to check if a serial is valid or not.
You could use python and flask to create the API and the server
Yes, an executable can be edited. Many software have been cracked through this method. There are however two ways of doing this:
Hash editing
Through third-party software
It is possible to "avoid" them. You can either encrypt these files or you can lock the data from being streamed out.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I would like to start selling some software I have developed in C++. The first line of protection will be the fact that C++ produces an executable. Within that, I will also apply algorithmic and manual obfuscation techniques to make it very hard to understand even once cracked.
With regards to licensing, my plan is to create an API you can send a request to. The data will include your license key and your device fingerprint. Upon receiving this data, the API will check for the license key in the database, and ensure the device fingerprint matches the fingerprint stored. If it does, it will reply with some sort of cryptographic response that must match a certain pattern. The client will then check if that response matches the pre-determined pattern, and if it does the software will be allowed to be used. If it does not, the user will be locked out. And this response will be empty if the API check failed, so that will also cause the user to be locked out.
I am aware that this is not unbreakable, but I would like to make it as difficult to break as possible without investing a ridiculous amount of time. The reason I wanted to add some cryptographic response is so the user can't just spoof the response from my server. Although I will also be using HTTPS on top of that. If this is a good idea, what sort of cryptographic check would you recommend?
The idea of the fingerprint is to prevent users from using the software on multiple computers at a time. I'm not quite sure what to use for this, but I was thinking of hashing a combination of the MAC address, computer name and something else. Any suggestions?
Is there anything else I should be doing to protect my software?
Thanks.
Don't waste your time. It's impossible to stop everyone, and even if you stop 99.999% of the people from cracking it, it only takes a single person to crack it and upload it to all the pirate sites. And the harder you make it, the more it will annoy legitimate users.
I'm working professionally on creating software licensing system. I can tell you, that's not easy to make software protecting system that will be safe enough to discourage people before they break it.
Yes, all systems are crackable. It's only matter of time before someone finds a way to bypass security. Our job is to make it as hard as possible giving them as few clues as possible.
I will also apply algorithmic and manual obfuscation techniques to make it very hard to understand even once cracked.
The goal is not to understand application, but run it without valid license.
With regards to licensing, my plan is to create an API you can send a request to. The data will include your license key and your device fingerprint. Upon receiving this data, the API will check for the license key in the database, and ensure the device fingerprint matches the fingerprint stored.
What you're describing is called License Server. It holds licenses and makes sure that the system users do not exceed their number.
and ensure the device fingerprint matches the fingerprint stored
Those fingerprints are called hostids and there are many types of them: bios id, harddrive serial number, MAC address, donlge (usb stick with license on it), username running application, etc. Most of them are pretty easy to forge. But as I said. The goal is to slow them as much as possible.
I am aware that this is not unbreakable.
That's very wise of you.
but I would like to make it as difficult to break as possible without investing a ridiculous amount of time
You've cat to be kitten me.
Unless license server will be in the same network as your software, it won't be able to run without internet connection. It might not be an issue for you, but it is for many companies.
I'm not saying it's a bad idea. Writing such a system is great exercise and I very recommend it to every programmer, but that's not an easy piece of bread.
I am trying to create an executable that will only run on one machine. What is the easiest way to achieve this? A license file? Or is there a machine address much like the MAC for network connections I could hardcode into the executable?
If it will run on only one machine, then... simply secure the machine and only store the executable on this machine.
That's, unfortunately, about the only reliable method.
Longer answer:
bits can be copied
programs can be dissassembled
dissassembly can be reverse engineered (though it's sometimes long)
the cost of reverse engineering can be made higher than the value produced by the program, possibly at a higher cost that the value produced by the program.
If you look long enough at the software industry:
DRM: fail
Licenses: fail
Licenses with web activation: fail
If it's worth cracking, it'll get cracked.
The easiest way would be to make it illegal via licencing. Trying to enforce this technically is impossible, and only hurts your users (user?): What if they reinstall the OS, or change their network card, or upgrade their CPU?
There is no solution that is 100% effective, and there is no solution that is "easiest" and also "highly effective." There typically is a continuum of "effective" and "drives users crazy" that you need to be very careful about.
The MAC address is not a horrible place to start. It's not that difficult to change your MAC address, but if you have multiple instances of the same MAC on the same subnet, their machine won't work, so it's good for keeping many people on the same subnet from running your product without licenses. The problem with MAC is that on desktops, the MAC changes if the network card changes; that ticks off your paying users.
A license file is generally better than modifying the binary. You should sign the license file, however, so that it can't be easily modified.
Your application itself is always the weakest link. A dedicated attacker will just remove the test from your application. There is no universal solution to this problem. A good approach is always around "keeping honest people honest" by making it easy to license your application correctly, and easy for the user to determine if they've done so. You can easily spend huge amounts of money trying to annoy people who will never pay you anyway.
I think my answer to another question applies here.
This is a legal issue, not a technological issue. Your goal should be to make it easy for people who want make sure they have valid licenses to your software. Rather than securing your code against people who want to steal it, you should focus on helping customers that are worried about accidentally using it without a proper license.
I'll also repeat my comment from yet another question:
I think "keeping honest people honest" is the right mind set to
approach this problem. Nothing can be cryptographically secure, but
having some sort of unique key or number for each license can actually
make it easier for business customers to account for their software,
and that adds value to your product. Onerous DRM (that doesn't work)
aimed at thwarting criminals (who'd never pay anyway) is just an
obstacle to paying customers.
If you want to create only one copy of your executable file and if you have access to the machine on which you have to install the executable file, then it is okay to hardcode the MAC address into your executable file. In case you want to distribute more than one copies of your executable file and if you don't have access to all the machines, then you might code the executable file to demand a license file which is generated form the MAC address of the machines. It is a sort of software activation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We have a custom license check method, which is very simple, we just check a registry key(a string, set by another process based on different parameters) and grant license or reject.
I came to know that, anybody can simply crack this, once they get to know which regkey we are looking for. Or by searching for cmp instruction in assembly code.
I just wanted to know better solution for this license check problem. I may not need very complex procedure or any such. But if it should be little better than current one.
I use C++\VC++ with windows 7.
Thanks & Rgds, calvin
The only way to totally prevent cracking is to use a pay as you go based hosted application accessed by users remotely.
That way someone without a valid paid account can not use the application, and anyone handing his account credentials to other will pay for their use as well as his own.
No code (except possibly a stub to allow logging in) is ever sent to the client, let alone stored there, so the client can't ever operate without connecting to your server (which will hopefully not get compromised, but that's a sysop problem, not a coding problem).
Any other system you may adopt will essentially have to rely on the legal clout behind your license to deter people from cracking it.
You need to somehow protect your code against reverse engineering; there are many so-called executable file protectors and I will not name it here. Regardless of what you calculate, just two NOP instructions will push the flow of the protection check in undesired direction.
Of course, it really matters what kind of code you are protecting; for interpreted languages it is almost impossible to protect yourself.
Ah, sorry, I can name one, non-commercial: infamous Yoda's PE Protector.
You could calculate a hash from a hardware-specific value and check for that value in the registry. This way it wouldn't be enough to find which value you are looking for, but also the algorithm.
A mathematically sound way of doing this is would be to turn the computer-specific value (e.g. MAC address) into a prime number, multiply it with your own magic prime number and store the product.
Edit: Note, though, that it usually is not worth bothering with any protection scheme except very simple ones. Even large corporations are struggling with this problem.
Any logic running locally will always be prone to circumvention. With regard to the actual storage of a license depending on your application I would write a web service and run your own server. Get the app to check with your service each time it starts that the license is still valid.
This also gives you much more flexibility for example you could revoke a licence if payment doesn't clear.
You can accomplish this using public/private key encryption. Have local signed file instead of the registry that contains information about the license and having a web server to check the license is valid once in while. This should give you enough protection.
This can be done with LicenseSpot. On the site there's sample code, although only in c#.
I'm looking into C/C++ libraries (Win/Linux) that allow me to synchronize information over network. I want to run multiple instances of my program (on different PC's), and want to synchronize files locally instead of accessing files remotely over the network at a single location.
If all instances are to maintain DB consistency it also needs to bee aware of any message delivery errors, so an ack mechanism is necessary.
I stumbled into a couple of solutions, but I'm still trying to figure out what my best solution would be.
Any suggestions are appreciated and feel free to ask about any clarifications.
Edit
I've been looking into enet and UDT does anyone has any experience using them?
I think the design space for such a thing is pretty huge, but it reminded me of a kinda cool library I saw the other day, VAST. The idea is that it's a spatially-represented distributed publish/subscribe model. Maybe it is adaptable to your purpose.
Another thing that is probably immediately useful if you are most interested in file synchronisation -- librsync. It implements the rsync delta algorithm, by the looks.
I will soon be shipping a paid-for static library, and I am wondering if it is possible to build in any form of copy protection to prevent developers copying the library.
Ideally, I would like to prevent the library being linked into an executable at all, if (and only if!) the library has been illegitimately copied onto the developer's machine. Is this possible?
Alternatively, it might be acceptable if applications linked to an illegitimate copy of the library simply didn't work; however, it is very important that this places no burden on the users of these applications (such as inputting a license key, using a dongle, or even requiring an Internet connection).
The library is written in C++ and targets a number of platforms including Windows and Mac.
Do I have any options?
I agree with other answers that a fool-proof protection is simply impossible. However, as a gentle nudge...
If your library is precompiled, you could discourage excessive illegitimate use by requiring custom license info in the API.
Change a function like:
jeastsy_lib::init()
to:
jeastsy_lib::init( "Licenced to Foobar Industries", "(hex string here)" );
Where the first parameter identifies the customer, and the second parameter is an MD5 or other hash of the first parameter with a salt.
When your library is purchased, you would supply both of those parameters to the customer.
To be clear, this is an an easily-averted protection for someone smart and ambitious enough. Consider this a speed bump on the path to piracy. This may convince potential customers that purchasing your software is the easiest path forward.
A C++ static library is a terribly bad redistributable.
It's a bot tangential, but IMO should be mentioned here. There are many compiler options that need to match the caller:
Ansi/Unicode,
static/dynamic CRT linking,
exception handling enabled/disabled,
representation of member function pointers
LTCG
Debug/Release
That's up to 64 configurations!
Also they are not portable across platforms even if your C++ code is platform independent - they might not even work with a future compiler version on the same platform! LTCG creates huge .lib files. So even if you can omit some of the choices, you have a huge build and distribution size, and a general PITA for the user.
That's the main reason I wouldn't consider buying anything that comes with static libraries only, much less somethign that adds copy protection of any sort.
Implementation ideas
I can't think of any better fundamental mechanism than Shmoopty's suggestion.
You can additionally "watermark" your builds, so that if you detect a library "in the wild", you can determine whom you sold that one to. (However, what are you going to do? Write angry e-mails to an potentially innocent customer?) Also, this requires some effort, using an easily locatable sequence of bytes not affecting execution won't help much.
You need to protect yourself agains LIB "unpacker" tools. However, the linker should still be able to remove unused functions.
General thoughts
Implementing a decent protection mechanism takes great care and some creativity, and I haven't yet seen a single one that does not create additional support cost and requires tough social decisions. Every hour spent on copy protection is an hour not spent improving your product. The market for C++ code isn't exactly huge, I see a lot of work that your customers have to pay for.
When I buy code, I happily pay for documentation, support, source code and other signs of "future proofness". Not so much for licencing.
Ideally, I would like to prevent the library being linked into an executable at all, if (and only if!) the library has been illegitimately copied onto the developer's machine. Is this possible?
How would you determine whether your library has been "illegitimately copied" at link time?
Remembering that none of your code is running when the linker does its work.
So, given that none of your code is running, we can't do anything at compile or link time. That leaves trying to determine whether the library was illegitimately copied onto the linking machine, from a completely unrelated target machine. And I'm still not seeing any way of making the two situations distinguishable, even if you were willing to impose burdens like "requires internet access" on the end-user.
My conclusion is that fuzzy lollipop's suggestion of "make something so useful that people want to buy it" is the best way to "copy-protect" your code library.
copy protection and in this case, execution protection by definition "places a burden on the user". no way to get around that. best form of copy protection is write something so useful people feel compelled to buy it.
You can't do what you want (perfect copy protection that places no burden on anyone except the people illegally copying the work).
There's no way for you to run code at link time with the standard linkers, so there's no way to determine at that point whether you're OK or not.
That leaves run-time, and that would mean requiring the end-users to validate somehow, which you've already determined is a non-starter.
Your only options are: ship it as-is and hope developers don't copy it too much, OR write your own linker and try to get people to use that (just in case it isn't obvious: That's not going to work. No developer in their right mind is going to buy a library that requires a special linker).
If you are planning to publish an expensive framework you might look into using FLEXlm.
I'm not associated with them but have seen it in various expensive frameworks often targeted Silicon Graphics hardware.
A couple ideas... (these have some major draw backs though which should be obvious)
For at compile time: put the library file on a share, and give it file permissions only for the developers you've sold it to.
For at run time: compile the library to work only on certain machines, eg. check the UIDs or MAC ids or something
I will soon be shipping a paid-for static library
The correct answer to your question is: don't bother with copy protection until you prove that you need it.
You say that you are "soon to be shipping a paid-for static library." Unless you have proven that you have people who are willing to steal your technology, implementing copy protection is irrelevant. An uneasy feeling that "there are people out there who will steal it" is not proof it will be stolen.
The hardest part of starting up a business is creating a product people will pay for. You have not yet proven that you have done that; ergo copy protection is irrelevant.
I'm not saying that your product has no value. I am saying that until you try to sell it, you will not know whether it has value or not.
And then, even if you do sell it, you will not know whether people steal it or not.
This is the difference between being a good programmer and being a good business owner.
First, prove that someone wants to steal your product. Then, if someone wants to steal it, add copy protection and keep improving your product.
I have only done this once. This was the method I used. It is far from foolproof, but I felt it was a good compromise. It is similar to the answer of Drew Dorman.
I would suggest providing an initialisation routine that requires the user to provide their email and a key linked to that email. Then have a way that anyone using the product can view the email information.
I used this method on a library that I use when writing plugins for AfterEffects. The initialisation routine builds the message shown in the "About" dialog for the plugin, and I made this message display the given email.
The advantages of this method in my eyes are:
A client is unlikely to pass on their email and key because they don't want their email associated with products they didn't write.
They could circumvent this by signing up with a burner email, but then they don't get their email associated with products they do write, so again this seems unlikely.
If a version with a burner email gets distributed then people might try it, then decide they want to use it, but need a version associated to their email so might buy a copy. Free advertising. You may even wish to do this yourself.
I also wanted to ensure that when I provide plugins to a company, they can't give my library to their internal programmers to write plugins themselves, based on my years of expertise. To do this I also linked the plugin name to the key. So a key will only work for a specific plugin name and developer email.
To expand on Drew's answer - to do this you take the users email when they sign up, you tag a secret set of characters on the end and then hash it. You give the user the hash. The secret set of characters is the same for all users and is known to your library, but the email makes the hash unique. When a user initialises the library with their email and the hash, your library appends the characters, hashes it and checks the result against the hash the user provided. This way you do not need a custom build for every user.
In the end I felt anything more complex than this would be futile as someone who really wanted to crack my library would probably be better at it than I would be at defending it. This method just stops a casual pirater from easily taking my library.