I've seen a lot of discussion on here about copy protection. I am more interested in anti-reversing and IP protection.
There are solutions such as Safenet and HASP that claim to encrypt the binary, but are these protected from reversing when used with a valid key?
What kinds of strategies can be used to obfuscate code and throw off reversers? Are there any decent commercial implementations out there?
I know most protection schemes can be cracked, but the goal here is to delay the ability to reverse the software in question, and make it much more blatant if another company tries to implement these methods.
There are solutions such as Safenet and HASP that claim to encrypt the binary, but are these protected from reversing when used with a valid key?
No. A dedicated reverse engineer can decrypt it, because the operating system has to be able to decrypt it in order to run it.
Personally, I wouldn't worry. Admittedly I don't know anything about your business, but it seems to me that reverse engineering C++ is relatively difficult compared to languages like Java or .NET. That will be enough protection to see off all but the most determined attackers.
However, a determined attacker will always be able to get past whatever you implement, because at some point it has to be turned into a bunch of CPU instructions and executed. You can't prevent them from reading that.
But that's a lot of effort for a non-trivial program. It seems a lot more likely to me that somebody might just create a competitor after seeing your program in action (or even just from your marketing material). It's probably easier than trying to reverse engineer yours, and avoids any potential legal issues. That isn't something you can (or should) prevent.
hire some of the people I've worked with over the years, they will completely obfuscate the source code!
Read this
http://discuss.joelonsoftware.com/default.asp?joel.3.598266.61
There are two main areas on this:
Obfuscation - Often means renaming and stripping symbols. Some may also rearrange code by equivalent code transformations. Executable packers also typically employ anti-debugging logic.
Lower level protection - This means kernel or hardware level programming. Seen in rootkits like Sony, nProtect, CD/DVD copy protection.
Its almost impossible to truely obfuscate code in such a way that it will be totaly impossible to reverse engineer.
If it was possible, then computer virus would be absolutely unstoppable, no one would be able to know how they work and what they do. Until we are able to run encrypted code, the encryption is at some point decrypted and "readable" (as in, someone that can read machine code) before it can be executed by the cpu.
Now with that in mind, you can safely assume that cheap protection will fend off cheap hackers. Read cheap as in "not good", it is totaly unrelated to price you pay. Great protection will fend off great hackers, but ultimate protection doesn't exist.
Usually, the more commercial your solution is, the more "well-known" the attack vectors are.
Also, please realise that things such as encrypted applications imply extra overhead and annoy users. USB dongles also annoy users because they have to carry it around and cost a fortune to replace. So it also become a trade-off between you being happy that you've been protected against a handful of hackers and all of your customers which will have to carry the hindrances your protection method bears.
Sure, you can go to all sorts of clever lengths to attempt to defeat/delay debuggers and reverse-engineering. As others have said, you will not stop a determined attacker, period...and once your app is hacked you can expect it to be available for free online.
You state two goals of your desired protection scheme:
1) Make it hard to reverse engineer.
2) Make it blatent somebody is ripping you off.
For #1, any obfuscator/debugging-detector/etc scheme will have at least some impact. Frankly, however, the shrinking % of engineers who have ever delved into compiler output means that compiled C/C++ code IS obfuscated code to many.
For #2, unless you have a specific and legally protected algorithm/process which you're trying to protect, once the app is reverse engineered you're sunk. If it IS legally protected you've already published the protected details, so what are you trying to gain?
In general, I think this is a hard way to "win" and that you're better off fixing this on the "business-side" -- that is, make your app a subscription, or charge maintenance/support...but the specifics are obviously dependant on your circumstances.
You need to set a limit of how far you will go to protect your code. Look at the market and what your are charging for your solution. You will never secure your product 100% so you should evaluate what method will give you the best protection. In most cases, a simple license key and no obfuscation will suffice.
Delaying reverse engineering will only 'delay' the inevitable. What you need to focus on is deterring the initial attempt to breach copyright/IP. A good legal Terms and Conditions notice on the About page, or a bold copyright notice warning that any attempts to reverse engineer the code will result in a pick-axe through the spinal column...
Most people will back off attempting to rip something off if there is a chance they will be served some legal action.
We use SafeNet and our clients see it as 'official' protection. That in itself is a good deterrent.
Related
I create a Program, and I want to make a Rent option, and need secure it from RE,
I want that a user that rent the Program I created will have any authentication that even if the User Reverse it, the software wont work,
What should I do? What should I add?
Looking for suggestions to how secure my program that will have the option to rent
edit:
change it from c# to c++
It possible?
edit2:
I see it not possible, What can I do to make the RE harder?
I have website that i can use to authentication.
This is a common desire. First and foremost, understand that you can never truly make a program that cannot be reverse engineered. Most "anti-reverse engineering" techniques are aimed at making the job of a reverse engineer harder, and are likely only going to be very effective against amateurs. I'll list two popular techniques I've been exposed to from reverse engineering malware. This is a field of reverse engineering that likely sees some of the most sophistication in anti-RE methods as malware authors are constantly improving techniques to make their original code less accessible and less readable.
Anti-debugging & Anti-disassemblers. This involves including code in your program that will cause known (common) debugging or disassembling software to either malfunction or crash if the program is run through them. OR the ability to prevent code from running, disabling itself, or even crashing the OS if a disassembler or debugger is found to be installed on the machine when the program is run. See: IsDebuggerPresent function (msdn), "Stack Necromancy: Defeating Debuggers By Raising the Dead", and "Anti-Disassembly techniques used by malware (a primer)".
Code obscurity. This involves writing the original code in confusing and distracting ways (spaghetti code) to make it difficult to determine the intent and behavior of the program. Keep in mind this could backfire if implemented incorrectly as making your code difficult to make heads or tails of will obviously affect both parties. See: "Obfuscation (software)" and "Cryptographic obfuscation and 'unhackable' software".
For an actual implementation guide of these techniques, see: "An Anti-Reverse Engineering Guide".
Please keep in mind however that using anti-RE techniques on legitimate software (although sadly common) is a bad security practice and is frowned upon by the security community. Not to mention that if something is hard to break into, it typically presents itself as a challenge. See: "Security through obscurity" and "Hacker ethic".
I developed a special business algorithm into a static library, and my other developers write non-critical code which will link to this static library when compile. I want to restrict only my company computer(Linux) can link this static library, to prevent this static library from being stolen and abused.
if not a good solution,any other suggestions is appreciated!
Thank you very much!
Very difficult to do this in a way that isn't easily bypassed by someone with some skills in doing such things. A simple solution would be to check the network card MAC-address, and refuse to run if it's "wrong" - but of course, anyone wanting to use your code would then just patch the binary to match their MAC-address. And you have to recompile the code whenever you use it on another computer.
Edit based on comment: No, the linker won't check the MAC-address, but the library can have code in it that checks the MAC-address, and then prints a message.
A more likely to work solution is to request permission from a server somewhere. If you also use some crypto-services to contact the server along with a two-part key, it can be pretty difficult to break. There are commercial products based on this, and it that didn't work, then they wouldn't exist - but I'm sure there are people who can bypass/fake those too.
As always, it comes down to the compromise between "how important it is to protect" vs. "how hard is it to break the protection". Games companies spend tons of money to make the game uncheatable and hard to copy, but within days, there are people who have bypassed it. And that's not even state secrets - government agencies (CIA, FBI, KGB, MI5, etc) that can have 100 really bright people in a room trying to break something will almost certainly break into whatever it is, almost no matter what it is - it just isn't worth the effort unless it's something REALLY important [and of course, then it is also well protected by both physical and logical protection mechanisms - you don't just log onto an FBI server from the internet, without some extra security, for example].
Recently I inherited a business critical project at work to "enhance". The code has been worked on and passed through many hands over the past five years. Consultants and full-time employees who are no longer with the company have butchered this very delicate and overly sensitive application. Most of us have to deal with legacy code or this type of project... its part of being a developer... but...
There are zero units and zero system tests. Logic is inter-mingled (and sometimes duplicated for no reason) between stored procedures, views (yes, I said views) and code. Documentation? Yeah, right.
I am scared. Yes, very sacred to make even the most minimal of "tweak" or refactor. One little mishap, and there would be major income loss and potential legal issues for my employer.
So, any advice? My first thought would be to begin writing assertions/unit tests against the existing code. However, that can only go so far because there is a lot of logic embedded in stored procedures. (I know its possible to test stored procedures, but historically its much more difficult compared to unit testing source code logic).
Another or additional approach would be to compare the database state before and after the application has performed a function, make some code changes, then do database state compare.
I just rewrote thousands of lines of the most complex subsystem of an enterprise filesystem to make it multi-threaded, so all of this comes from experience. If the rewrite is justified (it is if the rewrite is being done to significantly enhance capabilities, or if existing code is coming in the way of putting in more enhancements), then here are the pointers:
You need to be confident in your own abilities first of all to do this. That comes only if you have enough prior experience with the technologies involved.
Communicate, communicate, communicate. Let all involved stake-holders know, this is a mess, this is risky, this cannot be done in a hurry, this will need to be done piece-meal - attack one area at a time.
Understand the system inside out. Document every nuance, trick and hack. Document the overall design. Ask any old-timers about historical reasons for the existence of any code you cannot justify. These are the mines you don't want to step on - you might think those are useless pieces of code and then regret later after getting rid of them.
Unit test. Work the system through any test-suite which already exists, otherwise first write the tests for existing code, if they don't exist.
Spew debugging code all over the place during the rewrite - asserts, logging, console prints (you should have the ability to turn them on and off, as well specify different levels of output i.e. control verbosity). This is a must in my experience, and helps tremendously during a rewrite.
When going through the code, make a list of all things that need to be done - things you need to find out, things you need to write tests for, things you need to ask questions about, notes to remind you how to refactor some piece of code, anything that can affect your rewrite... you cannot afford to forget anything! I do this using Outlook Tasks (just make sure whatever you use is always in front of you - this is the first app I open as soon as I sit down on the desk). If I get interrupted, I write down anything that I have been thinking about and hints about where to continue after coming back to the task.
Try avoiding hacks in your rewrite (that's one of the reasons you are rewriting it). Think about tough problems you encounter. Discuss them with other people and bounce off your ideas against them (nothing beats this), and put in clean solutions. Look at all the tasks you put into the todo list - make a 10,000 feet picture of existing design, then decide how the new rewrite would look like (in terms of modules, sub-modules, how they fit together etc.).
Tackle the toughest problems before any other. That'll save you from running into problems you cannot solve near the end of tunnel, and save you from taking any steps backward. Of course, you need to know what the toughest problems will be - so again, better document everything first during your forays into existing code.
Get a very firm list of requirements.
Make sure you have implicit requirements as well as explicit ones - i.e. what programs it has to work with, and how.
Write all scenarios and use cases for how it is currently being used.
Write a lot of unit tests.
Write a lot of integration tests to test the integration of the program with existing programs it has to work with.
Talk to everyone who uses the program to find out more implicit requirements.
Test, test, test changes before moving into production.
CYA :)
Two things, beyond #Sudhanshu's great list (and, to some extent, disagreeing with his #8):
First, be aware that untested code is buggy code - what you are starting with almost certainly does not work correctly, for any definition of "correct" other than "works just like the unmodified code". That is, be prepared to find unexpected behavior in the system, to ask experts in the system about that behavior, and for them to conclude that it's not working the way it should. Prepare them for it to - warn them that without tests or other documentation, there's no reason to think it works they way they think it's working.
Next: Refactor The Low-Hanging Fruit Take it easy, take it slow, take it very careful. Notice something easy in the code - duplication, say - and test the hell out of whatever methods contain the duplication, then eliminate it. Lather, rinse, repeat. Don't write tests for everything before making changes, but write tests for whatever you're changing. This way, it stays releasable at every stage and you are continuously adding value, continuously improving the code base.
I said "two things", but I guess I'll add a third: Manage expectations. Let your customer know how scared you are of this task; let them know how bad what they've got is. Let them know how slow progress will be, and let them know you'll keep them informed of that progress (and, of course, do it). Your customer may think s/he's asking for "just a little fix" - and the functionality may indeed change only a little - but that doesn't mean it's not going to be a lot of work and a lot of time. You understand that; your customer needs to, too.
I've had this problem before and I've asked around (before the days of stack overflow) and this book has always been recommended to me. http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
Ask yourself this: what are you trying to achieve? What is your mission? How much time do you have? What is the measurement for success? What risks are there? How do you mitigate and deal with them?
Don't touch anything unless you know what it is you're trying to achieve.
The code might be "bad" but what does that mean? The code works right? So if you rewrite the code so it does the same thing you'll have spent a lot of time rewriting something introducing bugs along the way so the code does the same thing? To what end?
The simplest thing you can do is document what the system does. And I don't mean write mind-numbing Word documents no one will ever read. I mean writing tests on key functionality, refactoring the code if necessary to allow such tests to be written.
You said you are scared to touch the code because of legal, income loss and that there is zero documentation. So do you understand the code? The first thing you should do is document it and make sure you understand it before you even think about refactoring. Once you have done that and identified the problem areas make a list of your refactoring proposals in the order of maximum benefit with minimum changes and attack it incrementally. Refactoring makes additional sense if: the expected lifespan of the code will be long, new features will be added, bug fixes are numerous. As for testing the database state - I worked on a project recently where that is exactly what we did with success.
Is it possible to get a separation of the DB and non-DB parts, so that a DBA can take on the challenge of the stored procedures and databases themselves freeing you up to work on the other parts of the system? This also presumes that there is a DBA who can step up and take that part of the application.
If that isn't possible, then I'd make the suggestion of seeing how big is the codebase and if it is possible to get some assistance so it isn't all on you. While this could be seen as side-stepping responsibility, the point would be that things shouldn't be in just one person's hands usually as they can disappear at times.
Good luck!
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.
We have a lot of open discussions with potential clients, and they ask frequently about our level of technical expertise, including the scope of work for our current projects. The first thing I do in order to gauge the level of expertise on staff they have now or have previously used is to check for security vulnerabilities like XSS and SQL injection. I have yet to find a potential client who is vulnerable, but I started to wonder, would they actually think this investigation was helpful, or would they think, "um, these guys will trash our site if we don't do business with them." Non-technical folks get scared pretty easily by this stuff, so I'm wondering is this a show of good faith, or a poor business practice?
I would say that surprising people by suddenly penetration-testing their software may bother people if simply for the fact that they didn't know ahead of time. I would say if you're going to do this (and I believe it's a good thing to do), inform your clients ahead of time that you're going to do this. If they seem a little distraught by this, tell them the benefits of checking for human error from the attacker's point of view in a controlled environment. After all, even the most securely minded make mistakes: the Debian PRNG vulnerability is a good example of this.
I think this is a fairly subjective decision and different prospects would react differently if you told them.
I think an idea might be to let them know after they have given business to someone else.
At least this way, the ex-prospect will not think that you are trying to pressure them into giving you the business.
I think the problem with this would be, that it would be quite hard to do checks on XSS without messing up their site. Also, things like SQL injection could be quite dangerous. If you stuck with appending selects, you might not have too much of a problem, but then the question is, how do you know it's even executing the injected SQL?
From the way you described it, it seems like a poor business practice that could be a beneficial one with some modification.
First off, any vulnerability assessment or penetration test you conduct on a customer should be agreed upon in writing by that customer, period. This covers your actions legally. Without a written agreement, if you inadvertently cause damage (application crash, denial-of-service, data leak, etc) during your inspection, you are liable and could be charged (under US law; other countries have different standards).
Even if you do not cause damage, a clueless or potentially malicious customer could take you to court claiming damages; a clueless judge might just award them.
If you have written authorization to do so, then a free vulnerability assessment to attract potential customers sounds like a show of good faith and demonstrates what you want -- your skills.