Sådan udføres iOS-kodeinjektion på .ipa-filer

Billede fra http://dyci.github.io/

Kodeindsprøjtning er en proces med introduktion af ekstern kode i et eksisterende softwaresystem. I dette indlæg vil jeg dele de værktøjer og teknikker, der er nødvendige for at udføre iOS-kodeindsprøjtning på iOS Apps. Med XCode er det muligt at opsætte et eksperiment for at vise iOS-kodeinjektion i aktion. Tanken er at oprette et uafhængigt sæt koder, pakke det med den endelige app og på en eller anden måde udføre de nye koder.

[Bemærk: Denne kodeinjektionsproces har vist sig at fungere på iOS 9.3, 10.0.2 og på XCode v7.3 og v8.0. Jeg har endnu ikke prøvet dette på andre OS- eller XCode-versioner]

Vi kan oprette en uafhængig binær pakke via Xcode på 2 måder:
- Dynamic Libary via (Cocoa Touch Framework) eller
- Statisk bibliotek via (Cocoa Touch statisk bibliotek)

Dynamic Library vs Static Library: Vores muligheder for at oprette en ekstern binær, der indeholder vores injektionskoder

Statisk bibliotek

  • En kodeenhed, der er knyttet sammen på kompileringstidspunktet.
  • Statiske biblioteker skal være tilgængelige under samlingen af ​​.ipa for at deres koder kan udføres
  • Swift understøttes ikke til statiske biblioteker
  • Der er ingen kendt måde at instruere en .ipa om at indlæse et statisk bibliotek
  • Vi kan ikke bruge statisk bibliotek direkte. Du skal muligvis først konvertere det til et dynamisk bibliotek

Dynamisk bibliotek

  • En kodeenhed, der er knyttet til kørsel. Xcode kræver, at afhængigt dynamisk bibliotek / rammer er tilgængelige under kompilering, men garanterer ikke, at disse afhængigheder er pakket ind i appen. Derfor kan du undertiden støde på runtime-dynamiske biblioteksbelastningsfejl som
    dyld: Bibliotek ikke indlæst: @ rpath / libswift_stdlib_core.dylib
  • Vi kan oprette Swift-koder til dynamiske biblioteker
  • Load Dylib-kommandoen er nødvendig for at blive udført på .ipa, så den indlæser det dynamiske bibliotek i hukommelsen, før applikationen startes.
  • JA VI KAN BRUGE DETTE :)

Med dylib (Dynamic Library) valgt som vores brugerdefinerede kodepakke, kan vi bruge XCode til at præsentere kodeindsprøjtningskonceptet.

Indsprøjtning af kode for koncept via XCode

Indsprøjtning af kode gennem XCode

Her er trinnene

  1. Opret et nyt XCode-projekt
  2. Opret et nyt iOS-applikationsmål.
  3. Opret et nyt "Cocoa Touch Framework" -mål. Lad os kalde det "PatchPGO"
  4. Opret en ny objektiv-C Cocoa Touch Class. Lad os kalde det "PatchLoader". Tilføj følgende metode i .m-filen.
@implementation PatchLoader

statisk tomrum __attribut __ ((konstruktør)) initialisere (tom) {
    NSLog (@ "==== Kodinjektion i handling ====");
    / *
      Placer dine kodeindsprøjtningskoder her
    * /
}

@ende

Ved hjælp af "statisk tomrum __attribut __ ((konstruktør))" som modifikator for initialiseringsmetoden, kan vi specificere, hvad vi vil gøre, når klassen indlæses i hukommelsen, før applikationen startes. Du kan betragte dette som "indgangspunkt ”For koder, der skal injiceres i iOS-applikationen.

5. Kør iOS-applikationsmålet for at sikre, at logkonsolens output udsendes som det, du ville forvente inden kodeindsprøjtningen.

6. Link nu Dynamic Framework-filen til din iOS-applikation. Sørg for, at rammen er indlejret efter behov.

iOS-appmål Generelle indstillinger: Sørg for, at din ramme er knyttetiOS-appmål-bygningsfase: Sørg for, at din ramme tilføjes under

7. Nu, hvor dit iOS-applikationsmål er korrekt knyttet, skal du køre målet og observere din logningskonsol. Vores NSLog-meddelelse er med succes injiceret i vores iOS-appmålmålapp.

Besked om logindføring af kode vises

Bemærk, at der er observeret en ændring af adfærd (ny log-meddelelse), men applikationens målkoder er ikke ændret. Bag kulisserne linkede Xcode biblioteket til målet inden kodesignering og installation af den ændrede app. I ovenstående kodeindsprøjtningseksperiment via Xcode ejer udvikleren appens kildekode. Lad os nu prøve at injicere koder i en .ipa-fil, hvor udvikleren ikke ejer kildekoderne.

Kode til injektion af kode med .ipa-fil

Her er trinnene

  1. Download og .ipa-fil efter eget valg. Du kan finde knækede .ipa-filer fra tredjepartsindholdsudbydere (f.eks. Www.iphonecake.com)
  2. Download optool (https://github.com/alexzielenski/optool) eller
    download / klon mit depot (https://github.com/depoon/iOSDylibInjectionDemo). Dette depot indeholder optool, og et script “patchapp.sh” indlæser dylibs (via optool) i en given .ipa-fil. Detaljer findes i README.
  3. Opret en mappe i iOSDylibInjectionDemo-mappen til at indeholde de dynamiske biblioteksbinarier, som vi vil injicere i .ipa. Lad os kalde det 'Dylibs'
  4. Gå til mappen rammer (den, du oprettede i XCode i ovennævnte eksperiment), og undersøg indholdet af rammemappen.
Sådan finder du mappeplaceringen for Dynamic Framework i XCode: Højreklik -> Vis i FinderIndholdet af den dynamiske ramme. Binært dynamisk bibliotek fremhæves med blåt

Find en fil, der har samme navn som rammemappen. Denne fil er det dynamiske bibliotek binære, og vi bliver nødt til at bruge denne fil til at ændre vores ipa-fil. Kopier denne binære til den mappe, vi oprettede i punkt 3. Din mappe skal nu se sådan ud

Dylibs-mappe, der indeholder vores tilpassede dynamiske bibliotekskoder

Hvis dit dynamiske bibliotek indeholder Swift-koder, skal du muligvis kopiere standard Xcode Swift-dylib-biblioteker til din "Dylibs" -mappe. Swift-dylibs findes lokalt på /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift

Sådan kan din mappe se ud, når du har tilføjet de standard Swift dylib-filer.

Standard Swift dylib kopieres og klar til kodeinjektion

5. Lad os afbryde processen med .ipa-modifikation som "programrettelse". Gå til mappen iOSDylibPatchingDemo, og kør følgende i terminal sh ./patchapp.sh cracked.ipa ./DYLIBS, hvor “cracked.ipa” er den ipa, du vil lappe, og “./DYLIBS” er den mappe med dylibs, du vil plaster med. Patch-scriptet udsender den lappede .ipa-fil som "cracked-patch.ipa" og afslutter kodeindsprøjtningsprocessen. På dette tidspunkt kan vi imidlertid ikke installere eller sidelægge denne .ipa i en ikke-jailbroken enhed endnu, fordi selv om “cracked-patch.ipa” har de indsprøjtede koder, er .ipa-kodesignaturen nu ugyldig, efter at vi har tempereret og ændret dens indhold.

6. Download Cydia Impactor fra http://www.cydiaimpactor.com. Cydia impactor er et værktøj, der giver os mulighed for at installere en hvilken som helst .ipa på en ikke-fængslet enhed ved at resignere .ipa og dens indhold ved hjælp af gyldige profiler og legitimationsoplysninger, der er knyttet til enheden.

Cydia Impactor Mac-app

Du kan begynde .ipa-installationsprocessen ved at trække og slippe "cracked-patch.ipa" ind i Cydia Impactor Mac-appen. Den vil derefter bede om dit Apple Developer-login og din adgangskode.

Cydia Impactor anmoder om dit Apple Developer-login og adgangskode under installationen

Cydia Impactor (CI) forsøger at logge ind på Apple Developer Center og downloade din leveringsprofil samt hente dit iOS-udviklingscertifikat i din lokale nøglering. CI vil derefter forsøge at underskrive .ipa-indholdet på en dybde-første måde, startende fra det dybeste mappeniveau og derefter gå videre til .ipa-mappeniveauet. Herefter installerer og sidelaster CI .ipa'en i den specificerede enhed. Denne proces ved hjælp af CI fungerer, fordi enheden vil tro, at .ipa er udviklet og underskrevet af brugeren og tillader, at den ændrede app startes på enheden med succes. Hvis du er ukomfortabel med at bruge Cydia Impactor, kan du manuelt frigive .ipa på egen hånd og sideladde .ipa ved hjælp af XCode.

Processen med at lappe en .ipa-filProcess til signering og installation af en .ipa-fil i en ikke-jailbroken enhed

7. Overhold enhedskonsolloggerne, og søg efter den NSLog-meddelelse, vi har indsat i vores dynamiske bibliotek tidligere: "==== Kodeindsprøjtning i handling ====". Hvis du formår at finde logmeddelelsen, kan du begynde at fejre, fordi du med succes har udført iOS-kodeindsprøjtning på en iOS .ipa-fil. Du kan udføre hele kodeindsprøjtningsprocessen på enhver .ipa-fil.

Hmmmm .... dette lyder ondt for mig

Jeg præsenterede dette emne i november iOS Dev Scout Meetup-gruppen (Singapore) og demonstrerede, hvordan jeg brugte kodeindsprøjtning til at bryde PokemonGo App-spillet. Under meetup-gruppen bragte publikum op hacking-ideer fra at tilføje keylogging-funktionalitet til at bryde reglerne for andre spil-apps. At komme med koder til hack-app er ikke let, da det kræver en masse gætarbejde sammen med timers prøve-og-fejl for at få det rigtigt.

En håndfuld onde ideer

  • Keylogging (https://gist.github.com/johndel/6df8aee01055ed21dd9a#file-keylogger-swift-L65)
  • Metode Swizzling (http://nshipster.com/method-swizzling/)
  • Hent klasser, ivars, egenskaber, metoden information via Objekt C runtime (https://developer.apple.com/reference/objectivec/1657527-objekt_c_runtime)
  • Få en liste over registrerede klasser (https://developer.apple.com/reference/objectivec/1418579-objc_getclasslist)

Med ideerne ovenfor kan en useriøs udvikler praktisk talt læse alle klasser og deres ivars og metoder, der er brugt i en app, og bruge disse oplysninger til at planlægge et ondskabsfuldt hack. Det bedste af alt er, at der ikke er brug for at bruge jailbroken enheder.

Hvis du er interesseret i at læse om at bruge denne kodeindsprøjtningsteknik til at hacke en rigtig app, her er mit næste indlæg om hacking af PokemonGo App (https://medium.com/@kennethpoon/hacking-the-pokemongo-ios-app-with- 3-klasser-4b81589a9f39 # .kz2vey8ir)

Så hvem er den onde?

Efter at have gennemgået hele iOS-kodeinjektionsprocessen, der er beskrevet i dette indlæg, føler jeg personligt, at muligheden for at give nogen mulighed for at fratræde .ipa-filer er en alvorlig sikkerhedsfejl. Når en ipa er underskrevet, skal den være uforanderlig, og ethvert forsøg på at temperere dets indhold skal resultere i, at den betragtes som beskadiget, og iOS-enheder bør ikke tillade, at disse .ipa lanceres.

Jeg håber, at læserne finder dette indlæg indsigt. Kommenter eller surr mig på de_poon@hotmail.com.

Video: November 2016 iOS-kode Injektionsprat