I need to guide me to lock my project against "unauthorized use" with a certain registration key which I will send it personally.
I also want to inform me if this lock method can break it with reverse engineer method.
I use visual basic for my project in visual studio 2010.
There is no general case method of preventing someone from reverse engineering your application. It is code, and therefore it is possible to analyze. This is exacerbated by tools such as Reflector, which take a .NET assembly and dump out a complete Visual Studio solution capable of building the given .NET assembly. A malicious user could simply dump your assembly, remove the licensing bits, and then recompile the assembly.
However, you can use a code obfuscation tool (i.e. Dotfuscator (disclaimer: PreEmptive Solutions is my employer)) to make your code confusing enough that it's extremely difficult to figure out where exactly the registration bits are located.
That said, merely obfuscating the code still doesn't protect you the way you're trying to be protected, because you want to embed a secret (that is, the registration code) in the binary. Code obfuscators can help with this (i.e. string encryption), but this is in general a weak area -- your program has to get the constant in cleartext at some point, therefore the method to get the cleartext must exist in your program somewhere. After all, there are cracks and things for Windows and pretty much every video game on the planet, despite the millions companies like Sony spend on anti-copying technology.
If you want to secure your project from re-engineering and reading then,
Try obfuscation for securing your application at CERTAIN level.
Product Key,
Before few months back our team was discussing about
"How to secure our Product from Illegal Copying,ReEng etc"
Following are the conclusions,
for re-eng - Obfuscation
Copying - Decided to create a Product key based on Some Client + Other Details(Harddisk#+BIOS#) and we maintained the separate database for it.
So its upto you,I mean how much you want to secure your application.
Since you mentioned that you will be separately sending product key then it can be any combination like CustomerName+Date etc.
Also some obfuscation tool provide the way to generate product key, don't remember the name.
Related
how can i limit the redistribution of source code on different machines. I want that the source code should not compile/build within visual studio /TFS if it is redistributed to some other machine with different visual studio license?
If there is no built in mechanism i need some direction. perhaps i need to install an add in for visual studio that will check on compile time if it is not installed it will simple not allow the code to compile?
Store all of your developer infrastructure (developer workstations, TFS infrastructure, etc) in an isolated building. This building should have no internet access whatsoever.
Post security guards outside the building. Armed is preferable, but not strictly necessary.
Each person entering the building should be stopped by the security guards and forced to surrender all personal effects (cell phones, cameras, tape recorders, thumb drives, etc). Nothing should be allowed to come into this room or exit the room. This includes things like eyeglasses and clothing, since they could have covert recording devices embedded in them.
All people entering or exiting the room are thoroughly searched, both upon entry and exit from the room. Ideally they would be cavity searched and x-rayed, although finding security guards comfortable with performing cavity searches could be challenging, and they would almost certainly command a higher salary.
This will prevent your employees from:
emailing code to themselves
taking pictures of the code on their screen
writing code down on sheets of paper
dictating the code into a recording device
copying code to a thumb drive and smuggling it out of the room
Of course, this doesn't account for the possibility that an employee has an eidetic memory. If that's the case and you find out, you'll have no choice but to have them killed upon their departure from the company.
Please note that the 'having former employees killed' portion is satire. I do not actually recommend having people killed. That is illegal and immoral.
Do not allow people to access your source code if you don't want them to steal it.
There is no way to do this out of the box and no known third party tooling for this.
About to complete a wp7 application, which uses bing map services for locations etc. I need to know if obfuscation will hamper its performance.
There are some tools available like Dotfuscator etc, but concerned about the performance of the app. Please give your suggestions
I do not have much experience with obfuscation, however what I do know is there are two methods.
Simply renaming of variables and functions to make it difficult to read the logic when decompiled using Reflector; and
The other where program flow is be rearranged.
With name obfuscation the IL code and runtime performance is the same. There is apparently a difference in performance with the second method, however the only benchmarks/articles I can find are for Java.
You are deploying to a secure device and file system so there is no need to obfuscate a WP7 application. As Chris pointed out, you can actually get the application package file by intercepting the HTTP request from the marketplace and extracting the GUID as detailed in a blog post by Marius Gheorghe. As Marius explains this is because the XML stream is not encrypted and that the assembly package can be retrieved using a simple request. I would expect Microsoft to patch/fix this soon (and I will mention it to our Microsoft account manager).
As for WP7 obfuscation there is a detailed blog post here that should help.
...
If you want to secure your application, I would spent the time encrypting your persisted data (i.e. save files) so that your users data is secure. That is what did for the WP7 Full House Poker game.
There is only one way to be sure: you should test.
Obfuscation will probably not impact performance much but, again, you should test.
EDIT
Before you obfuscate, do realize that obfuscation is not the same as encryption. Never store any secrets in your client side code!
Performance is hampered but ignorable if you measure in milliseconds, the bottom line is that you may do not obfuscate if you are creating a free application or open source.
A small ma and pa shop came to me recently with a request to update a vb6 program one of their former part time employees made for them while home from college. On the cd the student provided is both the source code and a installer for the program, which extremely helps. I would like to just give them a new cd with a new installer and the updated source code. My question is, how do I go about creating or if easier updating a installer for a language that entered "Non Supported Stage" back in 2008?
Update:
Just to answer some of the questions, the updates they are asking for are just changing the wording of some labels and changing one control from a textbox to a combobox. They are a ma and pa shop and don't want to pay the cost to have the app re-written to a newer language, even though it has been recommended.
You're going to need a copy of Visual Basic 6 (or Visual Studio 6) which is difficult. If you have an MSDN subscription, I'm quite sure you can download it from their archive, but if not, you might need to buy a copy. Check EBay. Have the ma and pa shop purchase it at their own expense, and they should own it in case they want to make future changes. You can use it on their behalf to do work for them, if you're the only one using it, and just uninstall it when you're done.
Also, if you have a copy of Visual Studio 2005, technically you can "downgrade" to VS6 but you have to call Microsoft and have them send you the install program, and you're not allowed to use VS2005 concurrently with VS6. Yeah, I know...
Ok, so if you've got that far, get the source on your computer and get it under source control. I suggest Mercurial (specifically the TortoiseHg client). I've had lots of luck with it on a VB6 project, and it's free. (Don't use SourceSafe, even if it comes free with VS6!) The distributed nature of the Mercurial repository means you can hand them back a CD with the entire repository on it, and the next poor sap who has to make changes will at least be able to do a diff and know what you did.
As someone else here said, VB6 has a built-in utility for making install programs, but I think you had to have the Enterprise version for that. It's worth finding that out before you get a copy.
Now go ahead and make changes, but be very careful. Remember that you probably don't have any unit tests, so you're likely to break stuff. If you want to be professional about it, there are unit testing frameworks out there for VB6. For instance, vbUnit. Again, I suggest having the customer buy a copy (about $99 for a single developer seat, I think). If the change was anything more than changing the company logo on the splash screen, then this is something I'd invest in. Write tests that cover every module or feature you're going to change. If all the logic is in event handlers in the form itself, carefully remove the code you need to change out into modules that you can write unit tests for. Write the tests to verify the current functionality first.
Then go ahead and make your changes. If you've gone to the trouble of setting up a testing framework, then you might as well use some TDD and write your tests first. Write a test, make sure it fails, write enough code to make it pass, and repeat.
All of this still requires you to have a solid manual test plan to check the functionality at the end. That means you need a solid grasp of what it does. You can pretty much assume that no matter how careful you are, you'll break something you didn't understand. Make sure to give yourself enough time to fix other problems that pop up after you deliver it.
I recommend against re-writing it in .NET unless it's a really simple program with only one form. The effort likely isn't worth it.
Caveat: beware of 3rd party components the original programmer might have used, but not included on the CD. If they used some ActiveX or COM stuff that they purchased from a 3rd party, but they didn't license it to your customer, you might have to end up purchasing it again just to get it to compile.
EDIT:
Based on your extra information, if you're really just changing a couple of controls and wording, then I think you can get away without a unit testing framework. I would definitely use some source control though.
I do remember using the Package and Deployment Wizard, and I agree it sucked. I actually used a 3rd party installer, now that I think about it. However, if the changes are small and the original application used the PDW, I'd probably stick with that.
You Can Convert VB6 projects to .NET.
If you have Visual Studio 2005 or higher...
Or the worse case is re write the code using VB.NET.
Go to this Link.
Convert VB6 - .NET
If I recall correctly, Visual Studio 6 came with a rudimentary wizard for creating an installation program for a VB6 application. So, assuming that you have Visual Studio 6 installed for VB6, there should be an installer wizard that you can use. However, it may have problems deploying the VB6 runtimes on Vista or Win 7 machines. Perhaps another SO guru will have the answer to that one.
You can also use the freeware Inno Setup to create an installer for a VB6 application. More information can be found here. However, it requires more manual effort than what came with Visual Studio.
I'm writing a software application that the user needs to buy a license for and activate it. I need suggestions on how to start about writing a powerful algorithm for code generation and of course, code checking. I know that people can reverse engineer the code and make a keygen, however, my question is two parts:
In general, regardless of the application being cracked this way, how can I start writing an algorithm to accept a certain Serial or String or a combination. (e.g is that the right thing? e.g: the first number is from 3-9 the second should be the first - 3, while the third number should be the second * + ....whatever...??)
What is the best approach for protecting a Desktop application from piracy without dealing with the internet. Is it the algorithm (make it harder to reverse engineer), protect the source code from being seen after application is installed somewhere?? ...??
PS: Maybe it is worth to mention that I am using Java as my development language.
Thanks
It sounds like you might benefit from the public-key cryptography approach.
This can be broken down into two sub points:
A. Have you read this thread here on SO? It might give you some breadth on the issue.
B. As #Jaka said, it's not a great challenge (from what I've read) to produce human readable code from Java byte code. You can run your code through an obfuscator to make it more difficult for someone to produce human readable code from it, but if someone really wants to read your code, they'll almost always find a way. The best approach to combat this is to take the advice in the SO thread I linked to: make it easier for someone to buy your app than for someone to steal it.
(edited after stated he's using Java)
For the license keys you could use an encryption with public-private keys. In this way you could either embed the private key into the software and encrypt a string which would mean something to your software (like which features of your software are licensed). Or you could embed the public and give the software a string with special meaning and sign it with your private key. The software could then check if the signature is valid.
edit: labratmatt was faster with the public-private key answer :)
Obviously second part of your protection would need to deal with making your software hard to disassemble and debug (this is how crackers examine your software and try to bypass the protection with a patch or they try to figure out how they can make a keygen). This part is actually much harder and involves techniques like encryption the whole executable and wrap it inside a loader which decrypts it at runtime. The loader can also use various techniques to detect the presence of debuggers.
edit: Since you mentioned that the application is written in JAVA, then this encrypting and packing step is even more important as JAVA can easily be decompiled into a very human readable form. There are "obfuscator" programs which mess around with the classes so that the decompilers can't generate readable code, but cracking this is still much easier than cracking something compiled to machine code.
If you don't want to spend time with developing your own protection you can also use one of commercial protection software. There are quite a lot of them to choose from and they offer numerous protection schemes (dongles, time based licenses,...)
Lots of commercial software uses packages like FlexNet, HASP, Wibu-key
Suggestion: encrypt the part of the application that provides licensed-only functionality. The user needs a key you provide on purchase in order to use that portion of the code.
If you ever let the user run the code you want to protect before they've purchased, there is no significantly secure offline solution. At best, you can stop the most casual piracy.
You should also thing about doing it in a way that one key cannot be used on two different computers. Just to prevent a company buying one key and using it for many instalations.
Did you write your own JRE too? Building a secure, capable activation system that deals smoothly with the range of user scenarios you'll encounter (people with no network connection, a firewall, a proxy server etc) and has been thoroughly tested in the field takes considerable domain expertise and time.
As a supplier of such systems we do have as self-interest to declare, but we also have data - we see many companies who put their trust in a developer who says they can put together a licensing system, then later they come back to us as it never did what they needed. This article (of mine) expands on the issues: http://knol.google.com/k/dominic-haigh/issues-to-consider-before-building-your/2zijsseqiutxo/6#
https://superuser.com/questions/14224/how-to-explain-drm-cannot-work/14254#14254
Even if you did put a very powerful lock on your software, pirates would still find a way to crack it and put it on a torrent site. (case in point: Spore)
You are talking about DRM, and there's no easy way (if any) to lock pirates out of pirating your software. And besides, you are competing with free products that can do what your software does (always the case), so you should focus more on making your software easy to install and use, not hard to install and use for more than you intended.
I am facing a severe problem with my program, which gets reproduced only in the customer place. Putting logs, are not helping as I doubt the failure is happening in a third party dll. For some reasons, I couldn't get help from the library provider. I am thinking of producing a dump at the point of failure, so that to analyze it offline. Is this a recommended practice? Or any alternatives?
Yes, this is something that every program should have and utilize as often as possible.
I suggest that you don't use third party libraries. Create your own dumps instead. It's very simple and straight forward. You basically need to do the following:
Your program needs to access dbghelp.dll. It's a windows dll that allows you to create human readable call stacks etc. The debugger uses this dll to display data in your process. It also handles post mortem debugging, i.e. dumps of some sort. This dll can safely be distributed with your software. I suggest that you download and install Debugging Tools for Windows. This will give you access to all sorts of tools and the best tool WinDbg.exe and the latest dbghelp.dll is also in that distribution.
In dbghelp.dll you call e.g. MiniDumpWriteDump(), which will create the dump file and that's more or less it. You're done. As soon as you have that file in your hands, you can start using it. Either in the Visual Studio Debugger, which probably even might be associated with the .dmp file extension, or in WinDbg.
Now, there are a few things to think of while you're at it. When checking dump files like this, you need to generate .pdb files when you compile and link your executable. Otherwise there's no chance of mapping the dump data to human readable data, e.g. to get good callstacks and values of variables etc. This also means that you have to save these .pdb files. You need to be able to match them exactly against that very release. Since the dump files are date stamped with the date stamp of the executable, the debugger needs the exact pdb files. It doesn't matter if your code hasn't changed a single bit, if the .pdb files belong to another compilation session, you're toast.
I encourage every windows win32 developer to check out Oleg Starodumov's site DebugInfo.com. It contains a lot of samples and tutorials and how you can configure and tune your dump file generation. There are of course a myriad of ways to exclude certain data, create your custom debug message to attach to the dump etc.
Keep in mind that minidumps will contain very limited information about the application state at exception time. The trade off is a small file (around 50-100 kB depending on your settings). But if you want, you can create a full dump, which will contain the state of the whole application, i.e. globals and even kernel objects. These files can be HUGE and should only be used at extreme cases.
If there are legal aspects, just make sure your customers are aware of what you're doing. I bet you already have some contract where you aren't supposed to reveal business secrets or other legal aspects. If customers complain, convince them how important it is to find bugs and that this will improve the quality of the software drastically. More or less higher quality at the cost of nothing. If it doesn't cost them anything, that's also a good argument :)
Finally, here's another great site if you want to read up more on crash dump analysis: dumpanalysis.org
Hope this helps. Please comment if you want me to explain more.
Cheers !
Edit:
Just wanted to add that MiniDumpWriteDump() requires that you have a pointer to a MINIDUMP-EXCEPTION-INFORMATION (with underscores) struct. But the GetExceptionInformation() macro provides this for you at time of exception in your exception handler (structured exception handling or SEH):
__try {
}
__except (YourHandlerFunction(GetExceptionInformation())) {
}
YourHandlerFunction() will be the one taking care of generating the minidump (or some other function down the call chain). Also, if you have custom errors in your program, e.g. something happens that should not happen but technically is not an exception, you can use RaiseException() to create your own.
GetExceptionInformation() can only be used in this context and nowhere else during program execution.
Crash dumps are a pretty common troubleshooting method and can be very effective, especially for problems that only reproduce at the customer's site.
Just make sure the customer/client understands what you're doing and that you have permission. It's possible that a crash dump can have sensitive information that a customer may not want (or be permitted) to let walk out the door or over the wire.
Better than that there are libraries that will upload crash data back you.
BugDump and BugSplat
And there's the Microsoft way:
http://msdn.microsoft.com/en-us/library/aa936273.aspx
Disclaimer: I am not a lawyer, nor do I pretend to be one, this is not legal advice.
The data you can include in logs and crash dumps also depend on what domain you are working in. For example, medical equipment and patient information systems often contain sensitive data about patients that should not be visible to unauthorized persons.
The HIPAA Privacy Rule regulates
the use and disclosure of certain
information held by "covered entities"
(...) It establishes regulations for
the use and disclosure of Protected
Health Information (PHI). PHI is any
information held by a covered entity
which concerns health status,
provision of health care, or payment
for health care that can be linked to
an individual.[10] This is interpreted
rather broadly and includes any part
of an individual's medical record or
payment history. --Wikipedia
It should not be possible to link health information to an individual. The crash dumps and logs should be anonymized and stripped of any sensitive information, or not sent at all.
Maybe this does not apply to your specific case, so this is more of a general note. I think it applies to other domains that handle sensitive information, such as military and financial, and so on.
Basically the easiest way to produce a dumpfile is by using adplus. You don't need to change your code.
Adplus is part of the debugging tools for windows, as mentioned in the article above.
Adplus is basically a huge vbscript automation of windbg.
What you have to do to use adplus:
Download and install Debugging tools for windows to c:\debuggers
start your application
open a commandline and navigate to c:\debuggers
run this line "adplus -crash your_exe.exe"
reproduce the crash
you'll get a minidump with all the information you need.
you can open the crash dump in your favorite debugger.
within windbg, the command "analyze -v" helped me in at least 40% of all the crashes that only happened at customer site and were not reproducible in house.