Is it possible to provide a service in which one free trial is given to each device without the possibility of an individual being able to get multiple free trials on a single device. If its impossible, do you know of a way of making it difficult to obtain multiple free trials.
You can generate the license key based on the device's unique ID, the request date, and your own private key to create a license that is only valid up to certain date.
You application will verify that the license key is valid by decoding the license key with your public key, and comparing its expiration date and device ID. People can't forge a bogus request, since the license key is only valid for the prescribed date and a given device ID.
(hint: read about public-key cryptography)
However, it's not totally foolproof. A really determined attacker can root his device, and install a custom firmware which allows him to control identifier returned by "getDeviceId()". This isn't something that most people would be willing to do, most people would rather find an alternative free app or just buy the app rather than going through that route. Against crackers with that sort of determination and skills, there is not much you can do about.
Alternative avenue of attack would be to replace the public key you ship with the application with the attacker's private/public key combination, and he can potentially write a key generator that can generate license key for the forged application. You can make this attack difficult by self-verification of your own executable.
However, no security scheme is foolproof, java/android application can be reverse engineered and a determined hacker can forge your application and disable its license checks. The only foolproof way to prevent unauthorized usage of an application is to not distribute the application at all.
I imagine you could get 99% of the effect of a more complex scheme with a brain-dead-simple one: just store a file somewhere on the device that indicates that the trial has expired. Granted, tech-savvy users would be able to find and remove the file, but the vast majority won't bother - the device is an inscrutable slab of magic to them, meddling with the internal files might displease the tiny gnomes peddling furiously behind the screen.
You can make things more challenging by hiding the lock file, changing the name and location based on the device id - that way it's a lot more difficult for someone to share instructions on how to evade your trial scheme.
As the other answers have noted: no system is foolproof, there is always someone out there who is cleverer than you and who will relish cracking your scheme. The trick is to not waste your time giving this guy a mental workout and instead cater for the majority.
Sure, but you'll need to be set up to store device identifiers on your own server. On an iphone, you can obtain the UDID using
UIDevice *device = [UIDevice currentDevice];
NSString *uniqueIdentifier = [device uniqueIdentifier];
You might make a database call and acompare uniqueIdentifier to your stored list, ensuring that only one trial can be activated per device.
In android, getDeviceID() gives you a unique device identifier. check the documentation for more info on this.
If I am not missing something, my solution would be straightforward. I will make the expire the service provided by the app, not the app itself. This can be done by using some token mechanism like oAuth. (with an expiring token with a considerable lifetime, in this case your trial period). While the client registration process, I will create the request token as a function of android device id and the requested time. Checkout oAuth, it could be a hassle, but almost all major service providers use it.
How about storing the MAC address of wifi adapter? Possibly on you server and you app will query the server if that MAC is already registered.
WITH USER'S PERMISSION, on the first run of app, query the server if current device's MAC address is already registered? If not, store the MAC address on your server. If already registered, ask user to purchase the app in order to continue using.
This method can be supplemented by some cryptographic algorithms as suggested by Lie Ryan to provide additional security and locks and/or trial period.
I don't know much about iPhone but I believe that every iPhone has wifi adapter and every wifi adapter has unique MAC address. Also check the legal side of this solution as storing the MAC may raise privacy issues/concerns. So, before using this, check laws applicable.
Related
I would like to know if it is possible, and if it's ok with apple if my app will use the iPhone's GUID with my server, as I don't want to nag my users for User/Passwords ...
Thanks !
Apple is crazy about privacy and UDID still allows to differentiate devices etc so I suggest to calculate some hash for example md5 and only afterward to pass it to the server. Such approach will guaranty privacy to your users even if your DB will be compromised.
Apple generally allows this and a lot of analytics frameworks use the device ID for tracking purposes.
You should however consider whether your users' data contains any personal information. If this is the case, I would strongly recommend against using device IDs for identification as they might not be really secret, e.g. because other developers need users' device IDs for beta testing etc. Also, other developers transmit device IDs to their servers and could use those to get at personal information from your users.
See this article for a concrete example of how device IDs could be abused.
So I'm making an app where I want the users to be able add, edit and rate content, but I do not want to force them to register. Instead I was planning on just using their device id or device token to identify them. I'm planning on making both an iPhone and Android version, so I'm looking for a general solution, but the iPhone version has higher priority, so an iPhone specific solution would also be welcome.
The problem is that I don't want just anyone to be able to use my web service by sending a phony device id or someone else's device id.
How would the client prove to the server that it is providing the correct device id?
In theory, you cannot. A device ID is not particularly secret, and in most cases, it can be easily spoofed. As for Android, there's no reliable device ID on that OS at all - see the gory details here: Is there a unique Android device ID?
All you can rely upon is security by obscurity - hoping that no one will be determined enough to reverse-engineer the code and analyse the authentication protocol. And not disclosing the code is not an option - you are distributing the app after all.
That said, one not-particularly-secure auth method would be - send the device ID and a hash of device ID concatenated with a secret, hard-coded in the client code string (the shared secret). The service would contain a copy of the secret, recalculate the hash (using the device ID provided) and match the hashes. Not breakable by protocol analysis, only by digging in the code for the secret. Vulnerable to replay attacks though. Feel free to obfuscate the secret in the code - e. g. combine it together from parts stored in separate places right before use.
For a stronger solution, authenticate users, not devices. This is up to your customers, and depends on the nature of the business.
I am no Android expert but the IMEI code I think is unique for the device. I dont know though how you can read it and transmit it.
Is there a way for the developer of an App Store application to tie a sale to an individual user/device ID/Apple account? In other words, a method for the developer to double-check that a specific user has legally purchased the software?
I haven't been able to find a reliable answer to this yet. I'm not looking for specific code examples, just some sort of idea as to how possible (or difficult) this is.
My intent isn't to penalize piracy; it's to be able to provide additional benefits to paid customers. As such, I'm not looking for a way to identify a cracked or pirated version, which I gather has already been solved.
Thanks in advance for any help you can provide!
None of the answers were all the way there, so I'll summarize.
First, as per Tim's answer, Apple does not give you any information to identify customers of a standard app purchase, or to identify one specific sale from another.
However, using In-App purchases provides you with a method to identify a valid purchaser, directly from Apple. The information you receive in this manner is uniquely identifiable; it doesn't give you a user's device ID and/or Apple Store account, but it can be used to verify a specific transaction.
Apple's documentation on verifying store receipts.
You can roll your own system to do this. You're not permitted to look into Apple's information elsewhere on the phone, but you can let your users create an ID in your system, through your application's interface. Gather the information voluntarily from your customer at the time you have them create their Profile on your system. You can get the Device ID, but you may want to collect something like an email address, too, so that you can continue to provide them with consistent service, as they upgrade to a new iPhone, or add an iPad to their fleet of Cocoa Touch devices.
Be sure to use an encrypted http connection when you're talking to your server, so that you don't accidentally expose your customer's information.
To quote "Dr. Touch"...
AntiCrack contains proven technology
to mitigate the risk of your apps
getting pirated by automatic cracking
tools
You do not have access to any purchaser information from the Apple store. Apple considers these customers THEIR customers, not YOUR customers and so will not make any customer identification information available to you...
-t
I have a iPhone app which needs to have a self destruct option. This app is going to be use on sensitive locations and holds some algorithms which are not to be known by anybody except the iPod Holder.
What would be the most "complete" way of deleting the app?
I was thinking of some how writing zeros to the nib file. or the actual application.app but I believe this folders are write protected and sandboxed.
Anybody have any ideas of better ways to achieve this?
Elaboration (Taken from original poster's comments):
This is for a jailbroken iPhone.
These devices are going to be provided to military personnel this device falling into enemy hands would be the least of my concerns. It's going to have a button so wipe the app once the app is written to zero or better yet corrupted with garbage all over the "exe" the app has no way of working and it would require inspection of the iPod flash chip with equipment that i 100% know the wrong people wont have
If you are openly storing the code that contains this algorithm within your application, there's nothing stopping the "wrong people" from jailbreaking the device and copying the complete file structure of the device before you run your "wipe" process.
Additionally, if you are dealing with a U.S. Government customer, I doubt that they will approve of the purchase of a jailbroken device, given that the vendor of such a device has claimed that jailbreaking is illegal. Whether or not this will hold up in court, the government tends to be conservative in these matters and err on the side of caution. Because Apple is a large U.S. company and a vendor to the government, I wouldn't expect the government procurers to take the jailbreakers' side in this.
My recommendation would be to encrypt the particular algorithms within a file in your application's bundle, and require the user of this application to decrypt this file into memory with the correct (difficult) password. That way, even if the "bad guys" were to gain access to the application, they wouldn't have everything they need to access these algorithms and would have to brute-force the password on the encrypted portion. This could be done on a standard, non-jailbroken device.
The U.S. Army is rolling out iPods in the field, with custom applications on them, so I'm sure that you're not the first person facing this challenge. If this work is being funded through a Department of Defense SBIR grant (or similar), you may even be able to contact your contracting officer and see if they can put you in touch with people at the appropriate agency who may be able to help you out with this (or even determine if it an issue to begin with).
I'm going to go out on a limb here and say you may not want to use the iphone for this type of app. There are intentional limitations to this exact type of action on the iphone and in springboard. If you are doing something so sensitive that it can't fall into unauthorized hands my recommendation would be to use a different and more customizable/controllable platform.
Unless you're working from a jailbroken device, you're probably going to run into problems here.
Even if you can find a way to automatically delete the app, you're still running the risk of those algorithms getting into the wrong hands - you would essentially be running into the same problems that Apple has with jailbreaking - once the device is in someone else's hands, it only takes the proper amount of motivation for the data to be accessed.
The only way to secure your algorithms is to pass the data to a remote server and get the results. There's still a possibility of a security breach, but it's much, much lower.
I don't know how well this would work, but you could store the algorithm as a file inside the application bundle, run the algorithm from that file possibly using a scripting language or something, and delete that file if you need to.
The folders are sandboxed, but your application is in there. On my jailbroken iPhone I see that all the permissions are owned by mobile so I don't see any reason why you can't just overwrite all the files with zeroes and then delete them.
The application bundle is effectively read-only, perhaps you should store some of the information in an encrypted form somewhere on a network.
Even if you find a way to write over the app in the flash memory, you really aren't erasing the app. Flash memory chips use wear leveling algorithms to reduce writes to the same blocks and so when you write out zeroes they are typically written to a new block of memory and not to the same block used before, so you really aren't erasing anything. The data can still be recovered from the flash chip (by a pro).
Another option is to separate out the parameters of the algorithm so that the algorithm is no longer sensitive (or at least not usable) and provide the parameters encrypted in a file. Then provide the key to authorized users via the network and don't store that key into flash, only RAM. They would need to get the key every time they start the app. Only give the key to authorized users. Of course, you'll also need to encrypt that key for transmission over the network with another key... There are systems for doing this, don't invent your own, in any case you'll need a crypto expert to do this right.
I would use the built in encryption to store the data, with a key the user has to enter to decrypt it. Without the key it doesn't matter if the data blob is recovered from the device.
Is it possible to assign different identifiers to copies of an app downloaded from the app store that is hard coded into the application? Or is their anyway of permanently storing an identifier in the application bundle such that when it is copied, the key remains within the bundle?
EDIT: Ok, how about iTunes reciepts, can they be used to verify when it was downloaded as the user has to register their app with the server within say 5 hours of them downloading it.
thanks in advance
I'm assuming your goal here is to disable part of the functionality of your app by having a master list of bogus serial numbers somewhere. Unfortunately there is no per-copy serial number available, and if there were it would be the first thing the bad guys would change before posting your app for download.
Instead you'll need to detect whether your app bundle has been tampered with from within the app. See this question:
Reducing piracy of iPhone applications
You'll then need to decide how subtly or obviously you want to limit functionality. Probably the best solution would be to do something innocuous but slightly annoying that generates a specific kind of support request, at which point you can gently prod the deadbeat into considering buying a legit copy.
An approach with more false positives but potentially fewer false negatives would be to check if the app is running on a jailbroken device. The downside there is that jailbreakers may well have legitimately purchased your app, so you're alienating honest customers for little to no extra benefit.
For the app I'm working on, which has a big social/viral aspect (I hope), I've decided that potential deadbeats probably have enough honest friends to pay for the server cycles that they're stealing, and it's just not worth worrying about.
No, there's no way to do either of these. The closest you could come would be to store device IDs on a central server.