问题
What are accepted methods to reduce iPhone application piracy, which do not violate Apple\'s evaluation process?
If my application \"phones home\" to provide the unique device ID on which it runs, what other information would I need to collect (e.g., the Apple ID used to purchase the application) to create a valid registration token that authorizes use of the application? Likewise, what code would I use to access that extra data?
What seem to be the best available technical approaches to this problem, at the present time?
(Please refrain from non-programming answers about how piracy is inevitable, etc. I know piracy is inevitable. I am interested in programming-based answers that discuss how to reduce it. Thanks in advance for your understanding.)
回答1:
UPDATE
Please visit and read
Thanks to chpwn in the comments.
Code that's way too old! - 11th May 2009
For now there's an easier way to detect if your iPhone application has been cracked for piracy use. This does not involve you to check the iPhone unique IDs against a list of accepted IDs.
Currently there are three things crackers do:
- Edit the Info.plist file
- Decode the Info.plist from binary to UTF-8 or ASCII
- Add a key-pair to Info.plist{SignerIdentity, Apple iPhone OS Application Signing}
The last one is easiest to check with this code:
NSBundle *bundle = [NSBundle mainBundle];
NSDictionary *info = [bundle infoDictionary];
if ([info objectForKey: @"SignerIdentity"] != nil)
{ /* do something */ }
Generally we don't have SignerIdentity in any of the App Store applications we build so checking for nil then performing set instructions should make it more difficult for crackers and pirates.
I can't take credit for this so please visit How to Thwart iPhone IPA Crackers. There's loads of information there about piracy on iPhone and how to curb it.
回答2:
As pointed out by Andrey Tarantsov in the comments, looking for the "SignerIdentity" string in the binary (using an app like HexEdit) and replacing it is pretty easy.
You could encode that string, but then again all you have to do is change one char of it and the app is not going to look for the "SignerIdentity" key anymore but for some other key that probably doesn't exist (therefore is null). That key being null, the app thinks it isn't cracked (since SignerIdentity should be null if the app isn't cracked).
Instead, I'd rather check the size of the info.plist and compare it to a reference value. I noticed Simulator and Devices builds don't have the same info.plist file size. Same goes for Debug, Release and Distribution builds. Therefore, make sure you set the reference value using the info.plist file size for the Device Distribution Build.
How to look for the filesize at launch:
回答3:
It looks like saving MD5 checksum of Plist and checking CryptID should do well till some time.
回答4:
Check iTunesMetadata.plist for the date of Purchace as sometimes, when an app is cracked, that date is changed to something outrageous.
Also check to see if the purchacer name field exists. In my experience with cracking apps for personal use, that is usually removed. If anyone knows how the anti dump protection of Temple Run works, you could use that in conjunction with some protection that poedCrackMod can't get (google poedCrackMod create hackulo.us account, go to dev center look for poedCrackMod, install it on iDevice).
Clutch which will not crack things with Temple Run like protection, has a feature called OverDrive intended to silence an app's crack detection. poedCrackMod has LamestPatch, which isn't as good. Also poedCrackMod is an open source bash script that can be reverse engineered. To recap, you have an app that has copy protection that can't be circumvented with clutch / overdrive but can be cracked with poedCrackMod. However poedCrackMod can't circumvent the app's in app piracy checks. It is hard to manually patch integrety checks in the app's executable. So your app is hard to crack.
来源：https://stackoverflow.com/questions/846309/reducing-piracy-of-iphone-applications