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.
Related
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm searching for a C++ and open source library to protect a commercial software again crack etc...
Do you know one ?
I have a phrase I like to use for these types of situations: "You can't solve a social problem with a technological solution". If someone is sufficiently motivated to do something you don't like, you can't stop them. The harder you make it to do something, the harder they'll try to get around your barrier. In the end, the only way is to diminish their motivation, and that needs a social solution.
Effectively preventing software from being cracked is an incredibly hard cat and mouse game. With every advancement you can make protecting your program, someone is going to figure it out and get around it. After all, your program does have to run on a computer, and if the computer can understand what it's doing, given enough time, a sufficiently motivated person can do it.
I'm not saying that crack-protecting isn't useful. If you make it hard enough, it will take crackers so long to subvert your software that once they do, that version's so out of date that it's useless. But doing this right is very difficult, and unfortunately there are no simple band-aid solutions that a lay-person can just slap on. Like Tom said, any "just stick it in" method of crack proofing can be just as easily be "snipped right out". Your program needs to be designed from the start to have an anti-cracking approach.
With no intention to insult you, if you're asking this question, then its clear that you don't know enough about software protection to design it in or to use it effectively, and you clearly aren't prepared for the arms race you need to be in to keep your software really powerfully protected.
Most likely whatever you're writing isn't worth the effort of locking it down to an extreme level. Take the simple approach. Your goal should be to keep honest people honest. Just write a plain old, simple verification routine to check if the user's key, when combined with the user's name, address, and other info, passes some checksum. For every copy you sell, take the user's info, generate the key and give that to them. Change the checksum with each version so users can't use old keys. If you must, combine that with some type of periodic "phone home" system over the internet, where a list of leaked (and thus rescinded) keys is published.
Keep in mind that phone home systems tend to piss off your honest customers, and it's far worse to burn a good customer with bad copy protection (a sale you'll never get again) than to keep a non-customer from getting a copy of your program (a sale you wouldn't have gotten anyway).
Sure a cracker can get around it, but crackers aren't your customers. You can't stop them or change their motivations. In the end, they're going to do what they're going to do.
Sure a bad customer could give out their key, or use it against the terms of your license (like run it on too many computers). A key could leek out or be stolen, and a bad person could use it, or they could use a cracked version. You can't prevent those things from happening, but you do have the legal system (a social solution) to deal with it when it does.
The important thing is that you avoid spending too much effort on locking things down and that you avoid making things too draconian for your legitimate customers. After all, you write software for your those customers, not for the crackers. Pissing off your customers to make thing just a little harder for the crackers is never worth it.
Yeah, you see, that's the thing. If such a thing existed it would use predefined library functions which would be very easy to detect from a crack... This is exactly why Apple doesn't provide sample code for its App Store protection on Mac: making an open-source library for it makes it easier to crack apps rather than harder. After all, if you implemented something like this you wouldn't add extra protection anymore and the cracker could make a generic crack for all software.
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#.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
I need to create an application which will be reading and writing to files(C++/MFC). but I need the process not to appear in process monitor (which comes with SysInternals).
From the reactions of others, I now confirm that this seems "illegal". but that is the request of the client I'm dealing with. so, I guess I just have to satisfy the client's request.
One of the uses of Process Monitor is to find and remove malicious software that tries to hide from the user:
Process Monitor is an advanced
monitoring tool for Windows that shows
real-time file system, Registry and
process/thread activity. It combines
the features of two legacy
Sysinternals utilities, Filemon and
Regmon, and adds an extensive list of
enhancements including rich and
non-destructive filtering,
comprehensive event properties such
session IDs and user names, reliable
process information, full thread
stacks with integrated symbol support
for each operation, simultaneous
logging to a file, and much more. Its
uniquely powerful features will make
Process Monitor a core utility in your
system troubleshooting and malware
hunting toolkit.
I am not saying that what you want to do is impossible, rather that you are trying to do something that feels a bit dishonest.
That being said I would like you to consider the fact that you are trying to hide a process from a utility that was written to find anything and everything by folks that are a lot smarter than you and me.
I'll assume you're not planning to do anything malicious. If that's the case, it's important you don't hide your application from diagnostic tools. You can't guarantee your application is bug free. Even if it is, you can't predict its interaction with other applications. Because of that, you should leave it visible so other technical people can troubleshoot if something goes wrong.
Regarding your comment, "so, I guess I just have to satisfy the client's request" - not if it's illegal or technically dangerous for them. You need to protect yourself and them from bad judgment.
PM reads data at a very low level so to hide from it you have to actually take over certain NT kernel structures and methods to report different information to PM than what Windows itself sees. Doing this is platform and version dependent ( ie. Windows XP SP1 is different than Windows XP SP2 is different than Vista x64, etc.). It's nearly impossible to do correctly without creating an incredible number of system instability issues.
While it's not strictly illegal, every company that has done it and been discovered (which you will) has enjoyed lots of backlash and criticism from users and security professionals. Again while not explicitly illegal, the kinds of changes required can open severe security holes on the end users' machines. Should they have major system crashes or be exposed to hackers/viruses you may be legally liable for the damage.
Possible semi-legitimate (though I wouldn't want my name associated with them) applications you would want to keep people from seeing are DRM enforcers and nanny-cam style monitors for kids and errant spouses.
That said, I don't think your client really wants you to subvert such an important system. They likely want something less rootkit-like but they picked up the vocabulary watching "24" and have failed to adequately express what it is they want done.
My advice would be to go back to them for clarification. If they do indeed want something to be completely undetectable then you need to decide based on your own conscience whether to proceed or leave the client.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
We are trying to offer a license mechanism for every feature our Linux application is running, and we are thinking of controlling it in a centralized way using a license server:
Our aim for licensing is:
Deny features the operator has not bought.
Offer trials (features which expire if they are not bought).
Activate features for periods of time, and make them available just for some period of time.
Is there any server license which allow us to do this (basically, we would use sockets to communicate with our application)? What else can we do (for example, use some open source software, read, etc.) to get started?
Do you really need to "phone home"?
I've seen a relatively painless license system, through which the user was provided an XML file that described the period the license was valid, an optional IP address, and the list of "unlocked" features. A digital signature was generated using the vendor's private key, which was reinserted into the license file. At startup, the application was reading the license, validating it, checking the IP and unlocking the features accordingly.
The vendor can provide newer licenses to the client when needed.
Although you could theoretically fool the license by changing the machine's local time and fudging with the IP address, in that case this would have made the application quite cumbersome to use, so this was not a problem.
If you really want to use a license server then make sure that your application does not have to contact it all the time to authorise use - this will lead to no end of problems when people lose their Internet connection or your server goes down or crashes.
I would suggest having something where a key is downloaded and stored locally, thus reducing round trips to the server all the time. The key can be encrypted based on the user's machine details so that keys cannot be shared.
We've used the HASP hardware key in the past and while they defnitely work and provide a solution, I don't think they are what you want as they are programmed once and that's that. For example, you wouldn't be able to update the HASP key to close a trial period.
There are times when software does need protection - check out these guys here - they provide hardware and software solutions.
FLEXnet (formerly known as FLEXlm) is a licensing package that is commonly used by high-end or specialized software packages, for example in the electronic design automation market. You can lock a license to a single machine (by hostid, usually an Ethernet MAC address) or to a portable hardware dongle, or have a networked server handle sharing a limited pool of concurrent licenses to clients running your software. Licenses can be granted for a limited time or permanently, and also can be limited by a version number. A license file describes the features that are licensed.
FLEXnet includes several APIs for integrating with your application, including one for C++. I imagine it uses public key cryptography of some kind. Generally, an application using FLEXnet only "phones home" when you ask it to through your use of the API. Many applications check the license once, at startup, or reserve a license from the pool for the duration of the application's runtime.
You pay an annual license fee, of course, to use FLEXnet in your products, starting above USD 1k. The fee varies by the revenue of your company and by the number of platforms (OS/CPU combination) you want your licensing scheme to be able to run on.
I would say it's not worth it to use something like FLEXnet if your product sells for less than several thousand USD per seat. It is onerous to use (the source of a good percentage of support calls for our company), but corporate customers may already be familiar with using it, depending on the market.
FLEXnet, like every DRM scheme I've heard of, is easily cracked. At least I assume it is, since unlocked versions of our products are regularly found on warez sites.
This is such a Dilbert-esque way of doing things. Just say no.
Although hated, this is a standard feature in high-end specialized software which costs tens of thousands of dollars. Think 3D scanners and CNC stuff.
If you do plan to code something up yourself, a common mechanism that I have seen is to tie the license to a MAC address.
Having used various packages that make use of license servers like this, I can tell you it is one sure way to make your software universally hated by its users.
A common licensing software is flexlm. However I would think twice if I would impose these restrictions on my users. Many users dislike them; especially from the FOSS/Linux environment.