I'm not entirely sure if this a SO or SF question, but I'll give it a go here.
We're offering DMGs for download and a MD5 checksum to go with each. The question is how to instruct users of how to actually checksum and compare with the given checksum. Users aren't going to be all that tech savvy.
One idea was to produce a copy-paste bash command (a string built with the current checksum) which when executed says "yes" or "no". But that involves the user pulling up the Terminal, which isn't very friendly and means that most users don't know what they're doing. 'Black magic' isn't good for security.
Another idea would be to provide a GUI app to do the verification, but that would require initial trust, which breaks the point of offering a checksum.
So how do you boot-strap this kind of thing?
I was explaining this verification concept to a "beginer level" audience. They understood the concept of ensuring the checksum generated from the download needed to actually match the software author's actual checksum.
It was pointed out that checking manually was long winded and human error prone. The simplest method was to use Finder within Terminal(cmd & f) and then simply pasting in your own generated checksum and then "finding" the author's genuine checksum thus confirming a match!
Related
I'm trying to get a better understanding of OSX Code Signing and the advantages that it affords me in terms of protecting my software. Could someone please clarify certain questions for me?
Given an application that is Code Signed but not sandboxed:
Should a hacker change the application's binary the application is no longer considered as signed. However will it still run correctly (with the Caveat that Lion will warn the user about the application not being code signed)?
Given an application that is Code Signed and sandboxed:
What will not happen if a hacker changes the code in this case? Can he/she simply remove the entitlements file to create an unsigned version of the application that no longer has any sandbox restrictions?
Given a signed but not sandboxed application that contains a signed and sandboxed XPC service helper is there anything I can do to guarantee that a hacker can't create a non-signed (and modified) version of either part. It seems to me that as it currently stands a hacker can do the following:
Create a binary-modified version of the helper. This new version
would thus be non-sandboxed and non-signed.
Create a binary-modified version of the main application. This new
version would thus also be non-sandboxed and non-signed, and able to
start up the new version of the helper.
Am I wrong? If so, why?
Thanks,
Tim
You're basically right. What you're looking for is copy protection, and that's something nobody's ever figured out how to do (well), and it's not something that either code signing or sandboxing attempt to do. What sandboxing does is limit the damage if your program is taken over at runtime and made to do things it's not supposed to. What code signing does is prevent someone else from passing their program off as yours.
I used the words "their program" intentionally. You have to realize that once "your program" is on someone else's computer and they start messing with it, it's not really yours anymore; it's theirs, and they can do pretty much anything they want with it. They can take parts out (sandboxing, etc) add parts (malicious code, etc), change things, ... They could even write a "completely new" program that just happens to include parts (or the entirety of) your program.
There are things you can do to make your code hard to modify/reuse, but nobody's ever figured out how to make it impossible. Apple isn't trying; their security measures are aimed at other targets.
Oftentimes when you download a file, the site offering the download will list the MD5 hash for the file being downloaded.
But I've never had a problem with getting a bad download. In fact, I thought that since FTP was a TCP protocol, you couldn't get bad downloads.
Is there any data on how often bad downloads occur (i.e. when checking the MD5 hash tells you the download is bad)?
It's not so much a problem with the TCP/IP protocol accidentally swapping a bit (although that DID happen sometimes in the old days, it's not much a concern now).
MD5 is especially helpful when downloading a file from a mirror site. For example, getting an ISO for a new OS. The original site can give you the MD5, and then you can download the ISO from another company. To make sure that mirror has not tampered with the image at all, you can use the MD5.
In summary, MD5 is to validate the authenticity of the file - that may or may not mean a hardware level mishap. Usually it's something a bit more intentional and mischievous.
It is not for bad downloads mostly it is for verifying authenticity of downloadable to ensure that no one has tampered the downloadable.
Let's say that the file is outside of webserver you are connected to. The website has information about checksum, file size, file name.
When user has no assurance, that the file could be replaced with one which looks the same, but has some additional features, like malware, wrong mine-type, you can check check-sum to be sure about that.
I'm a bit stumped at this. I have a pretty unique hashing algorithm, etc. for key/license creation; i'm not worried about that part.
what i do need ideas on is how to disable a product on invalid...er, validation.
it's on a linux platform and uses config files, etc.
i have a couple choices for action based on invalid license:
-wipe out config files (however, easily restored from backup)
-replace the binaries with non-functional binaries (but these can easily be restored from backup etc.)
-simply flag the support staff for later contact, but that still doesn't solve the problem of disallowing non-licensed copies.
ideas? i don't really have a satisfactory solution to this so far.
Whatever you do, don't mess with the to program to the point of breaking it. If your validation algorithm fails and a valid license is flagged as invalid, you have one angry paying customer who can no longer use his paid program.
I'll just display a modal window on startup that reads something along the lines:
This copy of the program has not
passed the license validation. It is
possible that you are running an
illegal copy (maybe purchased at an
unethical retailer). Please cal
1-800-whatever or send a mail to
licensing#whatever.com to put a
solution to this problem. If you think
that you are running this program with
a valid license and this message is an
error on our part, contact the above
phone/mail and we'll correct this.
Does anyone knows what exactly happens behind the scenes when Mac OS X verifies a disk image (.dmg) file? Is there any way to extend or customize the procedure?
EDIT: I would like to create a disk image that verifies that it does exactly what it should do and nothing more. For example, if I distribute some software that manages passwords, a malicious user could modify my package to send the passwords to an unwarranted third party. To the end user, the functionality would appear to be identical to my program, and they would never know the package was sabotaged. I would like to perform this verification at mount time.
To my knowledge, you cannot modify this procedure (unless you do some system hacks which I don't recommend). I believe it compares it with the internal checksum and makes sure that the disk's volume header is OK. It goes through all of the files to see if any of them are corrupted.
My understanding of dmg's is limited but as I understand it's essentially an osx specific archive format, similar to zips. One option would be to also distribute the checksum of your dmg. This isn't very useful as if an attacker can change the dmg a user downloads from your site they can also modify the checksum.
The functionality I believe you're looking for is codesigning. It's a cryptographic verification that an app hasn't been modified since it was signed by the author. There's a bit of a barrier to using this as you need a developer certificate from the apple developer program.
Apple's documentation on codesigning can be found here:
https://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html#//apple_ref/doc/uid/TP40005929-CH4-SW5
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.