iOS Datalagre: En Guide til Sandboxing og Stier

At navigere i iOS' filsystem kan ofte føles som at lede efter en nål i en høstak, især når man forsøger at spore, hvilken applikation der er ansvarlig for at placere data et bestemt sted. Med Apples strenge sandboxing-politikker og brugen af unikke identifikatorer (GUID'er) for hver app, er det ikke altid ligetil at finde frem til den information, man søger. Denne artikel vil kaste lys over de forskellige datalagringssteder i iOS, med særligt fokus på stier som /private/var/containers/Data/System, og give dig værktøjer til at dechifrere, hvem der ejer hvilke data.

Det primære frustrationselement for mange, der dykker ned i iOS-data, er de kryptiske applikations-GUID'er. Disse unikke ID'er tildeles hver app på enheden og kan ses i stier som /private/var/mobile/Containers/Data/Application/APPGUID. Heldigvis har værktøjer og den fantastiske indsats fra eksperter som Alexis Brignoni med ApplicationState.db i FrontBoard-mappen gjort det lettere at kortlægge disse GUID'er til de faktiske applikationsnavne. Denne database fungerer som et slags 'skattekort', der forbinder den unikke ID med den tilhørende applikations bundleID, hvilket forenkler processen med at finde ud af, hvilke apps der 'bor' hvor.

Nøglen til Identifikation: .com.apple.mobile_container_manager.metadata.plist

Selvom ApplicationState.db er yderst nyttig, kan der opstå situationer, hvor du står over for en fil af interesse inden for en mappe og skal matche mappestien til en applikation, måske med begrænset adgang til værktøjer eller kun med et råt billede af enheden. I disse tilfælde er der en anden, ofte overset, ressource: filen .com.apple.mobile_container_manager.metadata.plist. Denne fil findes ved roden af applikationsdatastien og er unikt navngivet i hver applikationsmappe. Den indeholder nøgler, der direkte angiver applikationens bundleID. Dette er en uvurderlig genvej, hvis du er i klemme og ikke ønsker at hoppe frem og tilbage mellem databaser eller værktøjer.

En søgning efter denne .plist fil på tværs af en iOS-enhed afslører, at den dukker op mange steder, ikke kun i applikationsdata-mapper. Dette indikerer et bredere system for containerhåndtering, som Apple benytter sig af. For at forstå dette fuldt ud, skal vi først tale om sandboxing.

Forståelse af Sandboxing i iOS

Apple anvender i høj grad sandboxing i iOS. Dette er en kritisk sikkerhedsforanstaltning, der forhindrer applikationer i at få adgang til data, de ikke har tilladelse til. Hver applikation tildeles sin egen 'sandkasse' at lege i, og kun dette område er tilgængeligt for den. .com.apple.mobile_container_manager.metadata.plist-filen giver os mulighed for at se, hvilken sandkasse vi befinder os i, og hvem der ejer den sandkasse fra et applikationsperspektiv. Ved at bruge denne information kan vi nedbryde de forskellige stioplysninger for at finde ud af, hvorfor visse apps opbevarer data et bestemt sted.

Udforskning af iOS Containerstier

Lad os dykke ned i de specifikke stier, hvor .com.apple.mobile_container_manager.metadata.plist-filen typisk findes, og hvad de hver især betyder:

/private/var/containers/Bundle/Application/APPGUID/

Denne mappe er, hvor selve .app-filen (applikationsbundtet) ligger på enheden. Ud over selve applikationen kan vi her finde yderligere data om applikationen og hvem der downloadede den til enheden. Sammen med .app-filen findes der også iTunesMetadata.plist og BundleMetadata.plist-filer, som kan liste information som f.eks. hvornår applikationen blev downloadet, hvilken version af appen der blev downloadet, og hvilket AppleID der faktisk downloadede den. Dette er uvurderlig information for både app-udviklere og efterforskere.

/private/var/containers/Shared/SystemGroup/APPGUID/

Denne mappe ligner den ovenfor, men vedrører kerneapplikationer i iOS-enheden. Der er mindre information her, men stadig en .plist-fil, der kan afsløre, hvilken systemapplikation der er ansvarlig for containeren. Disse er typisk systemtjenester, der kræver en vis grad af isolation, men som stadig kan deles på et systemniveau.

/private/var/containers/Data/System/APPGUID/

Igen, ligner mappen ovenfor, men disse synes at være systemapps, der ikke ønskede at dele information mellem kerneapplikationer. Data her er ofte mere isoleret fra andre systemkomponenter, hvilket giver en yderligere grad af sikkerhed eller adskillelse. Også her findes den vigtige .plist-fil, der afslører bundleID'et for den applikation, der ejer containeren. Dette er den specifikke sti, som mange brugere og dataforskere undrer sig over, da den repræsenterer en form for 'privat' systemdata, der ikke nødvendigvis er direkte forbundet med en brugerinstalleret app.

/private/var/mobile/Containers/Shared/AppGroup/APPGUID/

Nu begynder den virkelige sjov! Som nævnt tidligere, siger Apple, at applikationer ikke må dele information uden først at anmode om det via officielle kanaler. For at dele information kan applikationsudviklere tildele en 'gruppe' til deres applikation. Ifølge Apples udviklerinformation kan disse App Groups derefter dele data med hinanden. Du har muligvis også set disse i backup-lignende billeder, der er listet som "AppDomainGroup-group.bundleID" i stedet for den mere almindelige "AppDomain-com.bundle.ID" struktur. Denne sti er ofte brugbar, når man ikke kunne finde de data, man ledte efter i den primære applikationsdatasti.

Ulempen er, at ApplicationState.db ikke indeholder information om denne sti. Fordelen? Hver applikations "Shared/AppGroup"-mappe vil have en af vores .com.apple.mobile_container_manager.metadata.plist-filer! En applikation kan også have mere end én mappe i denne sti. Eksempler inkluderer Dropbox-applikationen, der kan have over 4 forskellige containere her, og Spark-e-mail-appen, der havde 2. Vigtigere er det, at nogle applikationer kan opbevare alle deres relevante data her i stedet for i /private/var/mobile/Containers/Application/Data/-mappen. Et fremtrædende eksempel er Spark Email-applikationen, som vælger at gemme alle sine relevante databaser inden for /private/var/mobile/Containers/Shared/AppGroup/-mappestrukturen i stedet for den mere almindelige. Andre bemærkelsesværdige eksempler inkluderer WhatsApp og Signal, som også ofte gemmer vigtige data i deres AppGroup-containere.

/private/var/mobile/Containers/Data/Application/APPGUID/

Dette er det sted, hvor vi forventes at lede efter app-data. Det er velkendt og dokumenteret. Men som vi har set, er det ikke altid der, vi ender med at finde alt.

/private/var/mobile/Containers/Data/InternalDaemon/APPGUID/

På test-enheder har disse vist sig at være Apple-tjenester (eller interne dæmoner, som navnet antyder), der kunne spores ved hjælp af de samme .com.apple.mobile_container_manager.metadata.plist-filer. Disse dæmoner udfører baggrundsopgaver og systemfunktioner, og deres data er også organiseret i sandkasse-containere.

/private/var/mobile/Containers/Data/PluginKitPlugin/APPGUID/

Denne sti er blevet afgørende i visse sager, hvor studerende eller efterforskere har forsøgt at forstå, hvor afgørende data er endt. Da Apple tillader applikationer at bruge plugins til at binde sig sammen (tænk på Giphy-tastaturet eller foto-vælgeren i Beskeder), kan disse plugins opbevare data inden for denne mappestruktur. I et eksempel kunne en analytiker, ved hjælp af .com.apple.mobile_container_manager.metadata.plist-filen, finde ud af, hvilket plugin der hjalp med at placere data i denne mappe, og hvilket bundleID pluginet tilhørte. Dette er især relevant for at forstå, hvordan data introduceres eller modificeres af tredjeparts- eller systemplugins, selv uden at hovedapplikationen startes. For eksempel kan com.apple.mobileslideshow.photo-picker (en del af Fotos-appen) opbevare data her.

Nu hvor vi kender til plugin og hvilken applikation mappen tilhører, kan vi forsøge at generere data for at bevise, hvordan denne information kommer ind her. Ved at bruge KnowledgeC (en intern Apple-database, der logger brugerinteraktioner og systemhændelser) eller PowerLog kan man se, hvordan filoprettelser inden for PluginKitPlugin/APPGUID/-strukturen overlapper med brugen af MobileSMS-applikationen og andre plugins. Denne synergi mellem filer og systemlogger er afgørende for dybdegående analyse.

Oversigt over iOS Containerstier

Hvad med /var/mobile?

Spørgsmålet om /var/mobile er et hyppigt diskussionspunkt. Når du ser en sti som /var/mobile/Applications/FF0F1AB2-AD1F-4E42-8815-9E399EEF5027/Documents/, refererer den til en placering direkte på selve iOS-enheden. /var/mobile er enten et symbolsk link eller den faktiske rodmappe for brugerrelaterede data på en iOS-enhed, der kører i 'mobil' brugerkontekst. Når du kører en app på din iPad forbundet til Xcode til fejlfinding, kører appen på iPad'en, og dens dokumentmappe er derfor også på iPad'en.

Du kan ikke direkte 'gå til' /var/mobile på din lokale Mac-maskine, fordi denne mappe ikke eksisterer der; den er en del af iPad'ens interne filsystem. Adgang til dette filsystem kræver typisk en jailbroken enhed, specialiseret forensisk software, eller brug af Xcode's Organizer til at hente 'app-containere' (som er en pakket version af appens data) fra enheden. Organizer giver dig mulighed for at downloade applikationsdata til din lokale maskine, men det er ikke en direkte filsystem-montage, hvor du kan navigere i realtid. Det er derfor, du ikke kan finde en 'mobile' undermappe under /var på din computer – den eksisterer kun på den tilsluttede iOS-enhed.

Ofte Stillede Spørgsmål

Hvad er sandboxing i iOS?

Sandboxing er en sikkerhedsforanstaltning i iOS, der isolerer hver applikation i sit eget afgrænsede område af filsystemet. Dette forhindrer apps i at få uautoriseret adgang til data fra andre apps eller systemet, hvilket øger sikkerheden og stabiliteten.

Hvordan finder jeg en apps bundleID, hvis jeg kun har stien?

Den nemmeste måde er at finde filen .com.apple.mobile_container_manager.metadata.plist i roden af applikationens containermappe. Denne fil indeholder direkte applikationens bundleID.

Hvad er forskellen mellem /Data/Application og /Shared/AppGroup?

/Data/Application er den primære, sandkassede mappe for en individuel apps data. /Shared/AppGroup er en delt mappe, der giver flere apps fra samme udvikler mulighed for at dele data, hvis de er konfigureret med den samme app-gruppe-identifikator. Nogle apps vælger at gemme en stor del af deres data i AppGroup-mappen for at facilitere deling eller for at omgå visse sandboxing-begrænsninger.

Kan jeg få adgang til disse mapper direkte fra min computer?

Normalt ikke, medmindre enheden er jailbroken, eller du bruger specialiseret forensisk software. Når du debug'er via Xcode, kører appen på enheden, og stierne refererer til enhedens filsystem. Xcode's Organizer giver mulighed for at downloade app-containere, men det er ikke en direkte live-adgang til filsystemet.

Hvad er formålet med /private/var/containers/Data/System?

Denne sti bruges af kerne iOS-systemapplikationer, der kræver en høj grad af isolation og ikke nødvendigvis deler data med andre systemkomponenter på samme måde som SystemGroup. Det er en form for privat datalager for bestemte interne systemprocesser.

At forstå iOS' komplekse filsystem er afgørende for alle, der arbejder med mobile enheder, fra udviklere til dataforskere. Med viden om sandboxing, de forskellige containerstier og nøglefilen .com.apple.mobile_container_manager.metadata.plist, har du nu en bedre måde at bygge dine egne 'skattekort' på og finde de data, der markerer 'X'et på stedet.

Hvis du vil læse andre artikler, der ligner iOS Datalagre: En Guide til Sandboxing og Stier, kan du besøge kategorien Mobil.