iOS Runtime Mobile Exploration mit Objection oder Hack unserer eigenen Anwendung

Gepostet von Andrey Batutin, Senior iOS Developer, DataArt.

Mehr als ein- oder zweimal, als ich zur Arbeit kam (oder gerade aus dem Bett kam), fand ich einen verärgerten Brief in der Post, dessen Kern darin bestand, dass in der Appstor-Baugruppe der Anwendung nichts funktioniert und alles dringend repariert werden muss.

Manchmal war der Grund meine Untiefen. Manchmal meine Kollegen. Und manchmal sogar Apple Inc selbst .

Die tödlichsten Szenarien betrafen jedoch Fehler, die nur in App- / Release-Builds reproduziert wurden. Nichts verwirrt und bringt Sie zum Heulen vor einem MacBook, wie die Unfähigkeit, einen Debugger mit Ihrer eigenen Anwendung zu verbinden und zu sehen, was dort passiert.

Ähnliche Schwierigkeiten treten bei APNS und seiner Fehlerbehebung bei Release- / Ad-hoc-Assemblys auf.
Auf Baugruppen mit einer Produktions-APNS-Umgebung können Sie keinen Debugger verbinden.
Auf den Assemblys, auf denen sich ein Debugger befindet, gibt es keine APNS-Produktions-Pushs. Aber sie fallen normalerweise ab.

Apple bietet wie der Gott des Alten Testaments mit einer Hand eine Plattform, auf der Jailbreak bald in die Geschichte eingehen wird (und die Piraterie im App Store auf dem Niveau statistischer Fehler bleibt), und die andere lässt den Entwickler sich wie ein armer Verwandter fühlen, der kleine Oliver Twist, der es wagte, nach mehr Brei zu fragen.


Voice-over: "Onkel Apple, bitte geben Sie mir ein weiteres Vertriebszertifikat ..."

Für einen durchschnittlichen Programmierer war es fast unmöglich, etwas mit dem Release / App-Build einer iOS-App zu tun. Es war einfacher, vor der Veröffentlichung zu beenden.

Kurzum:

Der Release-Build ist vom Distributionszertifikat signiert und verwendet das Distributionsbereitstellungsprofil. Die Berechtigung verbietet das Anhängen eines Debuggers an den Anwendungsprozess. Außerdem wird beim Herunterladen von ipa aus dem App Store die Binärdatei verschlüsselt. App-Erweiterungen werden separat signiert.

Das heißt, der Autor der Anwendung scheint in der Lage zu sein, die App Store-Assembly mithilfe des Bereitstellungsprofils mit einem Zertifikat zu signieren und erneut zu signieren. Aber Sie müssen immer noch wissen, wie es geht. Aber auch danach bleibt die Frage offen, wie der Debugger mit dem Anwendungsprozess verbunden werden kann.

Daher müssen wir uns ausschließlich darauf konzentrieren, uns in der Entwicklungsphase nicht anzupassen. Und fangen Sie alle Fehler ab, bevor die Anwendung den App Store verlässt. Und Protokolle, mehr Protokolle für den Gott der Protokolle!



Aber in letzter Zeit zeichnet sich eine neue Hoffnung ab.



Im vorherigen Teil haben wir uns mit Frida getroffen, einem wunderbaren Framework für die dynamische Code-Injection. Und damit SSL-Pinning im exzellenten Projekt FoodSniffer umgangen .

In diesem Artikel lernen wir ein auf Frida basierendes Framework kennen, das die Manipulation von Release-Builds von iOS-Anwendungen erheblich erleichtert.

Einspruch

Mit Objection können Sie FridaGadget in die iOS-Assembly einfügen und mit dem erforderlichen Zertifikat und Bereitstellungsprofil erneut signieren.

Vorbereitung

Zuerst brauchen wir den Release Build von FoodSniffer.

Ein wichtiger Hinweis: Deaktivieren Sie beim Erstellen eines IPA die Option "Bitcode für iOS-Inhalte einschließen".



Dann benötigen wir ein Bereitstellungsprofil für den Build-Build.

Um es zu bekommen:

1. Installieren Sie die Anwendung über Xcode auf dem Gerät.
2. Finden Sie FoodSniffer.app im Finder.
   
   
3. Gehen Sie zum FoodSniffer-Bundle.
   
   
4. Kopieren Sie embedded.mobileprovision von dort in den Ordner mit Ihrer Release-IPA.
   
   

Sie sollten so etwas wie das Folgende bekommen:



Installieren Sie danach den Einspruch gemäß den Anweisungen . Ich empfehle dringend, die Option virtualenv zu verwenden.

Zusätzlich zu den Einwänden benötigen wir ios-deploy , um die gepatchte Anwendung auf dem Gerät auszuführen.

Unterschreiben Sie die Bewerbung erneut!

Finden Sie im Terminal den Hash der Codezeichenidentität heraus, die wir benötigen:

Sicherheit Find-Identity -p Codesigning -v



Wir sind an der 386XXX-Identität interessiert, da sie dem Batch-Zertifikat entspricht, mit dem die Anwendung während der Installation über Xcode signiert wurde, von dem wir das Bereitstellungsprofil erhalten haben.

Injizieren Sie FridaGadget und signieren Sie unsere Anwendung erneut:

Einspruch Patchipa - Quelle FoodSniffer / FoodSniffer.ipa --Codesign-Signatur 386XXX --Provision-Datei embedded.mobileprovision



Als Ergebnis sollten wir FoodSniffer-frida-Codesigned.ipa erhalten .

Jetzt benötigen wir ios-deploy , um FridaGadget zu installieren und eine Verbindung herzustellen. Dies ist ein wichtiger Schritt. Wenn Sie ipa einfach über iTunes oder Xcode auf Ihrem Gerät installieren, funktioniert die Verbindung zu FridaGadget nicht.

Nach dem Auspacken von FoodSniffer-frida-Codesigned.ipa :

Entpacken Sie FoodSniffer-frida-Codesigned.ipa

Wir starten unsere gepatchte Anwendung auf dem Gerät:

ios-deploy --bundle Payload / FoodSniffer.app -W -d

Wenn alles gut gegangen ist, sollte die Anwendung auf dem Gerät gestartet werden, und im Terminal werden wir sehen:



Verbinden Sie nun auf einer anderen Registerkarte des Terminals den Einwand mit dem FridaGadget:

Einspruch erforschen



Gewinn!

Die Brötchen, die der Einwand liefert

SSL Pinning Bypass

Hier ist alles einfach:

ios sslpinning deaktivieren



Jetzt können Sie Proxy Server ganz einfach verwenden, um den Datenverkehr unserer Anwendung zu überwachen, wie im ersten Teil beschrieben .

Dump UserDefaults

ios nsuserdefaults bekommen

Am Ende der Müllkippe sollten wir "Mood_state" = "Ich habe Hunger" sehen.

Dump App Schlüsselbund

ios Schlüsselbund-Dump



Und hier ist unser super geheimes Passwort.

Abrufen von Daten aus einer SQLite-Datenbank.
In der Anwendung habe ich von hier aus die SQLite-Datenbank chinook.db hinzugefügt.

Mit Objection können Sie wie folgt Abfragen direkt an die Datenbank stellen.

1. Verbindung zur Datenbank:
   
   sqlite connect chinook.db
   
   
2. Bitte an sie:
   
   SQLite Execute Query Select * aus Alben
   
   

Fazit

Objection und Frida ermöglichen schließlich eine relativ normale und einfache Arbeit mit Ad-hoc- und Distributions-Builds von iOS-Anwendungen. Sie geben dem Programmierer die Macht über ihre eigene Anwendung zurück, versteckt hinter den Schutzschichten, mit denen Apple iOS-Anwendungen so sorgfältig umhüllt. Außerdem arbeiten Objection und Frida auf Geräten ohne Jailbreak. Darüber hinaus sind sie relativ einfach zu bedienen.

Mit ihnen habe ich die Hoffnung, die iOS-Entwicklung wieder großartig zu machen. Vermeiden Sie sicher, das neue Apple-Hauptquartier von innen zu untergraben.

Hyper (nützliche) Links

Ein Amsterdamer Student zum Thema iOS Code Sign .

https://labs.mwrinfosecurity.com/blog/repacking-and-resigning-ios-applications/

https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/october/ios-instrumentation-without-jailbreak/ .

Quellcode der FoodSniffer iOS-App .

Frida Telegramm

Besonderer Dank geht an @manishrhll .

Hinweis Alle oben genannten Punkte sollten nur auf ihre Anwendungen angewendet werden und nicht versuchen, den "Zunder" oder etwas anderes zu brechen. Es wird immer noch nicht funktionieren!