The easiest way to check is to look at embedded.mobileprovision
([[NSBundle mainBundle] pathForResource:@"embedded.mobileprovision" ofType:nil]
):
- It's a bit of a pain to parse since it's a signed plist (PKCS#7 signed data, according to
openssl asn1parse -inform der
), but a bad hack is to just look for <plist
and </plist>
.
- Development contains UDIDs and
<key>get-task-allow</key><true/>
- Ad Hoc distribution contains UDIDs (and get-task-allow=false)
- App Store distribution contains no UDIDs.
The other thing you can check is the entitlements embedded in the executable (otool -l
lists it as LC_CODE_SIGNATURE
). Parsing this is even more tedious (you need to parse the Mach-O header and load commands, and for "universal" binaries which are now the default, you'll need to check the currently-loaded architecture or all architectures).
- Development builds contain
<key>get-task-allow</key><true/>
- Ad Hoc and App Store builds contain
<key>get-task-allow</key><false/>
I don't think the entitlements distinguish between Ad Hoc and App Store builds.
Apart from those and the certificate it's signed with, there's no difference between Development/Ad Hoc/App Store apps (there are a few other things in the entitlements/provisioning profile, but nothing more reliable that I can think of).
Security considerations
Neither of these are that difficult to circumvent. For the first method, the app could just "swizzle" -[NSBundle pathForResource:ofType:]
. The second method is a bit more difficult depending on what API you use to read the file.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…