Wie während der Laufzeit zu bestimmen, ob App für Entwicklung, App Store oder Ad-hoc-Distribution?
-
26-09-2019 - |
Frage
Gibt es eine Möglichkeit programmatisch zu bestimmen, ob die aktuell laufende App und wurde nur für die Entwicklung unterzeichnet oder ob es für die Verteilung gebaut wurde? Und kann man bestimmen, ob war Build für App-Store oder Ad-hoc-Verteilung?
Ist es z.B. möglicherweise, um die Codesignatur zugreifen und die Informationen von dort bekommen? Oder gibt es bestimmte Dateien in einer der Varianten präsentieren, die in den anderen nicht existieren? Ist ein Teil des Bündels Informationen? Oder kann es aus der ausführbaren Datei abgeleitet werden?
sind Irgendwelche Hinweise geschätzt.
Es scheint, dass die embedded.mobileprovision Datei im ASN.1-Format ist.
Lösung
Der einfachste Weg, zu überprüfen, ist bei embedded.mobileprovision
suchen ([[NSBundle mainBundle] pathForResource:@"embedded.mobileprovision" ofType:nil]
):
- Es ist ein bisschen wie ein Schmerz zu parsen, da es ein signiertes plist ist (PKCS # 7-Daten unterzeichnet, nach
openssl asn1parse -inform der
), aber ein schlechter Hack ist nur Blick für<plist
und</plist>
. - Entwicklung enthält UDIDs und
<key>get-task-allow</key><true/>
- Ad-hoc-Distribution enthält UDIDs (und get-task-allow = false)
- App Store Distribution enthält keine UDIDs.
Die andere Sache, die Sie überprüfen können, ist die eingebetteten Ansprüche in den ausführbaren Datei (otool -l
Listen es als LC_CODE_SIGNATURE
). Parsen dies noch langweiliger ist (Sie müssen die Mach-O-Header und Ladebefehle zu analysieren, und für „universal“ Binärdateien, die nun der Standard sind, werden Sie müssen die aktuell geladene Architektur oder auf allen Architekturen überprüfen).
- Entwicklung baut enthalten
<key>get-task-allow</key><true/>
- Ad-hoc-und App Store enthalten baut
<key>get-task-allow</key><false/>
Ich glaube nicht, die Ansprüche unterscheiden zwischen Ad-hoc-und App Store bauen.
Neben diesen und das Zertifikat mit unterzeichnet hat, gibt es keinen Unterschied zwischen Entwicklung / Ad Hoc / App Store-Anwendungen (es gibt ein paar anderen Dinge in den Ansprüchen / Provisioning-Profil, aber nicht mehr zuverlässig, dass ich mich vorstellen kann).
Sicherheitsüberlegungen
Keine von diesen sind so schwer zu umgehen. Für die erste Methode, die App konnte nur „swizzle“ -[NSBundle pathForResource:ofType:]
. Die zweite Methode ist ein bisschen schwieriger, je nachdem, welche API Sie verwenden, um die Datei zu lesen.
Andere Tipps
openssl asn1parse -inform DEM -in *Mobile_Provision_File* -strparse 54
ist der einfachste Weg, um Zugriff auf die Daten, die ich gefunden habe.
EDIT:
security cms -D -i *Mobile_Provision_File*
ist tatsächlich einfacher. Die OpenSSL-Befehl Blätter einige Müll in der Ausgabe.
Ich habe eine embedded.mobileprovision Datei kopiert und in einem Online-ASN.1-Viewer (zB http://www.geocities.co.jp/SiliconValley-SanJose/3377/asn1JS.html ), und das ist, was ein bekam:
SEQUENCE {
OBJECTIDENTIFIER 1.2.840.113549.1.7.2 (signedData)
[0] {
SEQUENCE {
INTEGER 1
SET {
SEQUENCE {
OBJECTIDENTIFIER 1.3.14.3.2.26
NULL
}
}
SEQUENCE {
OBJECTIDENTIFIER 1.2.840.113549.1.7.1 (data)
[0] {
OCTETSTRING 3c3f786d6c20766 ... 6c6973743e0a
}
}
[0] {
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 2
}
... [much more]
Mit diesem und einige ASN.1 Wissen, Ihre Erklärung ist durchaus sinnvoll.
Der interessante Teil ist das Oktett String beginnend 3c3f786d6c. Das ist der XML-Teil in Apples Eigenschaftsliste Format, das alle Antworten über den Verteilungstyp enthält (Entwickler, ad-hoc, App Store).
#if (DEBUG)
#define SERVER @"aaaa.com/dev"
#else
#define SERVER @"aaa.com/pro"
#endif
Das ist die Art, wie ich den Debug-und Release-Modus unterscheiden,
, aber ich habe keine Ahnung, für Ad-hoc-oder Produktion, es sei denn, die Erbringung Profilnamen
Ich schaffe einen Kern erkennen Ad-hoc-build
Siehe: https://gist.github.com/iShawnWang/d904934efded271d83b36288562df410
AdHoc erfassen mit folgenden zwei Bedingungen:
1.embedded.mobileprovision
enthält Feld ProvisionedDevices
(Debug und Ad-hoc-Erstellen dieses Feld enthält, Kein Release)
2.it ist nicht Debug-Build, können wir #ifdef DEBUG
verwenden es, zu entscheiden,
NS_INLINE BOOL isAdHoc(){
BOOL isAdHoc = NO;
BOOL isDebug;
#ifdef DEBUG
isDebug=YES;
#else
isDebug=NO;
#endif
NSData *data=[NSData dataWithContentsOfURL:[[NSBundle mainBundle]URLForResource:@"embedded" withExtension:@"mobileprovision"]];
NSString *str=[[NSString alloc]initWithData:data encoding:NSISOLatin1StringEncoding];
NSRange rangeOfDevicesUDIDs = [str rangeOfString:@"ProvisionedDevices"];
isAdHoc = rangeOfDevicesUDIDs.location!=NSNotFound && !isDebug;
return isAdHoc;
}