Univerzita Hradec Králové Fakulta informatiky a management Katedra informatiky a kvantitativních metod
Extrakce dat ze zařízení na platformě iOS Diplomová práce
Autor: Michal Jirman Studijní obor: Aplikovaná Informatika
Vedoucí práce: Ing. Pavel Janečka
Coventry
srpen 2015
Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury. V Coventry dne 6. srpna 2015
Michal Jirman
Poděkování: Rád bych poděkoval zejména svému vedoucímu Ing. Pavlu Janečkovi za cenné rady, věcné připomínky a vstřícnost při konzultacích a vypracování této diplomové práce. Poděkování patří také mým rodičům, přítelkyni Mausami za podporu při studiu a společnosti Infinity Wireless, Ltd., ve které jsem měl možnost získat cenné zkušenosti v oblasti bezpečnosti dat v mobilních zařízeních.
Anotace Cílem diplomové práce je průzkum problematiky bezpečnosti dat a jejich extrakce na platformě iOS.
Práce poskytuje souhrnný přehled a praktické použití metod pro
extrakci dat s využitím fyzického a logického přístupu, doplněného o extrakci dat z úložiště iCloud. Součástí práce je návrh způsobu extrakce smazaných záznamů z SQLite databází s využitím různých algoritmů.
Annotation Title: Data extraction from iOS devices The goal of this thesis is to research the area of data security and extraction on devices using the iOS platform. This work provides a comprehensive summary and practical approach of using methods for data extraction divided into logical, physical and iCloud data extraction. It also proposes methodology and algorithms for extraction of deleted records from SQLite databases.
Obsah 1.
Právní náležitosti ................................................................................................................................... 7
2.
Úvod ............................................................................................................................................................ 8
3.
Apple zařízení ....................................................................................................................................... 10 3.1. Apple iPhone .............................................................................................................................. 10 3.2. Apple iPod Touch ..................................................................................................................... 11 3.3. Apple iPad ................................................................................................................................... 12 3.4. Apple Watch ............................................................................................................................... 12
4.
Vývoj operačního systému iOS ....................................................................................................... 13 4.1. Úvod............................................................................................................................................... 13 4.2. Vývoj .............................................................................................................................................. 14
5.
Typy dat na iOS zařízení ................................................................................................................... 16 5.1. Souborový systém na iOS zařízení ..................................................................................... 16 5.2. Oddíly souborového systému na iOS zařízení ............................................................... 17 5.3. Databáze SQLite ........................................................................................................................ 17 5.4. Property List .............................................................................................................................. 18
6.
Metody extrakce dat z iOS zařízení............................................................................................... 20 6.1. Logická extrakce dat ............................................................................................................... 20 6.1.1.
Zálohy z programu iTunes ................................................................................... 20
6.1.2.
Šifrovaná záloha programu iTunes .................................................................. 23
6.1.3.
Šifrovaní dat na disku iOS zařízení ................................................................... 23
6.2. Fyzické extrakce dat ................................................................................................................ 25 6.2.1.
Extrakce dat s využitím služeb na iOS zařízení ............................................ 25
6.2.2.
Extrakce dat za pomocí Jailbreaku ................................................................... 30
6.2.3.
Extrakce dat za pomocí zavedení upraveného Ramdisku ....................... 38
6.3. Zálohy ze služby iCloud .......................................................................................................... 39
6.3.1.
iCloud zálohy ............................................................................................................. 39
6.3.2.
Metodologie útoku na službu iCloud ............................................................... 39
6.3.3.
Komunikační protokoly služby iCloud ............................................................ 43 Inicializace .............................................................................................. 44 Autentizace ............................................................................................. 45 Uživatelské nastavení......................................................................... 45 Zálohy iOS zařízení .............................................................................. 45
7.
Obnova dat z SQLite databáze ........................................................................................................ 51 7.1. Specifikace .................................................................................................................................. 51 7.2. Struktura a nastavení SQLite databáze ............................................................................ 51 7.2.1.
Formát stránky binárního stromu .................................................................... 53
7.2.2.
Hlavička stránky binárního stromu ................................................................. 54
7.2.3.
Stránka typu list binárního stromu .................................................................. 54
7.2.4.
Formát Varint............................................................................................................ 55
7.2.5.
Datový obsah buňky ............................................................................................... 57
7.3. Implementace algoritmů pro extrakci smazaných záznamů................................... 59 8.
Shrnutí výsledků a závěr .................................................................................................................. 64
9.
Seznam obrázků ................................................................................................................................... 66
10. Seznam tabulek .................................................................................................................................... 67 Reference......................................................................................................................................................... 68
1. Právní náležitosti Text této práce se detailně zabývá metodami získávání dat ze zařízení na platformě iOS. Tyto metody je možné využít například při penetračním testování či celkovém testování bezpečnosti operačního systému iOS a instalovaných programů. Smyslem takového testování je odhalování potenciálních či reálných chyb využitelných k napadnutí operačního systému či aplikací dříve, než je odhalí samotní útočníci. To vede ke zvyšování kvality aplikací i systému a zlepšování zabezpečení osobních dat uživatelů. V případě využití extrakce dat ze zařízení je nutné respektovat právo na osobní informace. Pouze vlastník zařízení má právo na data uložená v tomto zařízení. Může dojít k situaci, kdy vlastník zařízení nemůže získat svá data ze zařízení standardní cestou. Mezi tyto případy patří nefunkčnost zařízení z důvodu značného fyzického poškození, odcizení zařízení, či situace kdy data byla ze zařízení smazána omylem nebo systémovou chybou. Cílem této práce není poskytnutí informací za účelem ilegálního získávání dat či jiných protiprávních jednání, a tím i porušení licenčních ujednání společnosti Apple Inc.
7
2. Úvod Mobilní zařízení rapidně nabyla na popularitě a rozšířila se do celého světa. Se zvýšenou popularitou těchto zařízení se i výrazně navýšil počet dat, která tato zařízení uchovávají. Tato data jsou uchovávána a spravována v rámci operačního systému, který zajišťuje jejich bezpečnost a integritu. Mezi nejpopulárnější mobilní operační systémy v současnosti patří iOS, Android, Blackberry a Windows OS. Mobilní operační systém iOS byl představen v roce 2007 společností Apple Inc. výlučně určený pro Apple zařízení. Je odvozený z desktopového operačního systému Mac OS X. Mac OS X nabyl na popularitě s příchodem Apple zařízení, jako jsou Macbook, Macbook Pro a Macbook Air. Zařízení využívající platformu iOS, jako jsou chytré telefony či tablety, uchovávají a zpracovávají velké množství uživatelských i systémových dat. Nové verze těchto zařízení přinášejí novější a novější technologie s požadavkem na větší uložiště dat. Například v poslední verzi telefonu iPhone je možná kapacita úložiště až do výše 128 GB. Operační systém iOS je navržen tak, aby umožnil tato data efektivně zpracovávat i uchovávat. Mezi data, která jsou nejčastěji uchovávána na těchto zařízeních, patří textové zprávy, záznamy o hovorech, hlasové zprávy, emaily, chat, fotky, videa, informace o poloze a mnoho dalších dat a záznamů. Tato osobní data jsou velmi cenná například při forenzním vyšetřování. V rámci tohoto vyšetřování je velmi obvyklé, že zařízení není fyzicky dostupné, nebo vlastník zařízení nemůže nebo není ochoten poskytnout informace umožňující standartní přístup k jeho datům. Příkladem může být neochota vlastníka zařízení sdělit heslo k tomuto zařízení. Často je tak nutné využít i jiných metod, jak tato data bezpečně získat z mobilního zařízení při zachování integrity dat a samotného zařízení tak, aby bylo možné výsledná data použít v případě dalšího vyšetřování. Mezi používané metody k extrakci dat patří takzvaná logická a fyzická extrakce dat, dále je to extrakce dat za pomocí datového úložiště iCloud. Metoda označovaná jako logická extrakce dat se zabývá postupem získání dat bez nutnosti fyzického přístupu k zařízení. Tento postup zahrnuje práci se zálohou iOS zařízení vytvořenou prostřednictvím aplikace iTunes. Tato záloha je často automaticky vytvářena na počítačích, ke kterým bylo zařízení v minulosti připojeno. Záloha samotná je skrytě uložená na počítači a s využitím speciálních programů je možné tuto zálohu dešifrovat a číst. 8
K využití metody fyzické extrakce dat je již nutné mít fyzický přístup k zařízení. Tato metoda využívá skutečnosti, že je na iOS zařízení spuštěno nebo je možné spustit několik významných služeb. Tyto služby umožňují získání různých dat z iOS zařízení, a to často bez nutnosti znalosti hesla k zařízení. Další možností je využití postupu známého pod názvem Jailbreak zařízení. Při tomto postupu je využíváno systémových zranitelností iOS k získání plných práv k systému a instalaci libovolných programů na zařízení. S využitím instalovaného SSH serveru je tak možné se k zařízení připojit a získat prakticky jakákoliv data. Poslední metoda extrakce dat využívá záloh zařízení uchovávaných na úložišti iCloud. Pokud jsou známé přihlašovací údaje k této službě, je možné pomocí komplexního útoku na službu a metodami reverzního inženýrství zrekonstruovat komunikační protokoly, tím tak stáhnout data uchovávaná v rámci záloh. Samostatnou kategorií v oblasti extrakce dat je obnova smazaných dat z SQLite databází, které jsou hojně využívané na iOS zařízeních. S využitím podrobné znalosti fungování těchto databází, je za pomoci speciálních algoritmů možné některé smazané záznamy obnovit. Tyto algoritmy umožňují nalézt a zobrazit smazané záznamy uvnitř nepřiřazeného prostoru v rámci databázového souboru.
9
3. Apple zařízení První zařízení společnosti Apple, využívající mobilní operační systém iOS, bylo představeno pod názvem iPhone. Dále bylo následováno zařízeními iPod Touch (2007), iPad (2010), iPad Mini (2012), Apple TV (2010) a v neposlední řadě i v Apple Watch (2015). Tato zařízení se velmi rychle stala populární na trhu, v průběhu roku 2015 je odhadováno dosažení hranice 1 miliardy prodaných kusů mobilních zařízení využívajících platformu iOS. [3, 14, 20] Operační systém iOS klade velký důraz na kvalitu uživatelského rozhraní, intuitivnost při práci se zařízením a nabízí nespočetné množství funkcí. Uživatelské rozhraní rovněž nabízí dotykové ovládání a mnoho grafických prvků zvyšujících efektivitu.
3.1. Apple iPhone Apple iPhone patří do kategorie chytrých mobilních telefonů s operačním systémem iOS s podporou dotykového ovládání. První generace těchto telefonů byla uvedena v červnu roku 2007, která umožňovala komunikaci v sítích GSM, podporovala GPRS nebo EDGE technologie pro přenos dat. Varianty, které byly nabízeny, se lišily ve velikosti datového uložiště, které mohlo mít kapacitu 4 GB, 8 GB nebo později i 16 GB.
Obrázek 1: iPhone 3GS [21]
10
Společnost Apple představila v červnu 2008 druhou generaci těchto telefonů pod názvem iPhone 3G, která již umožnila komunikaci v sítích 3G a UMTS-HSDPA. iPhone 3G byl prodáván pouze ve dvou variantách, a to s úložištěm o velikosti 8 GB nebo 16 GB. Součástí byl navíc integrovaný čip GPS umožňující satelitní navigaci a instalace novější verze iOS ve verzi 2.0. Zásadní novinku představovala služba App Store sloužící k distribuci aplikací pro operační systém iOS. App Store umožnuje stažení a nahrání aplikací distribuovaných společností Apple, ale prakticky i komukoliv, kdo se registruje jako vývojář pro platformu iOS. [21] Po uplynutí zhruba jednoho roku od uvedení druhé generace chytrých telefonů byl představen nový model pod názvem iPhone 3GS. Hlavní změny se odehrály v navýšení celkové výkonnosti telefonu, rozlišovací schopnosti fotoaparátu, možnosti natáčení videa a podpory ovládání hlasem. V roce 2009 byl uveden na trh iPhone 4, který se výrazněji lišil od svých předchůdců. Z hlediska designu je tento telefon tenčí, využívající hliníkový rám, tělo má zpevněné minerálním sklem. Apple také použil nový typ displeje pojmenovaný Retina Display s podporou vysokého rozlišení. Čip, který byl integrován v tomto zařízení, je znám pod názvem Apple A4, je vyráběn společností Samsung. Apple A4 je založen na architektuře ARM čipu, kombinuje jednotky ARM Cortex-A8 CPU a PowerVR GPU na jednom sdíleném čipu. Mezi dalšími vylepšeními byla i nová verze iOS 4, přední kamera, podpora CDMA sítí, navýšení operační paměti na 512 MB DRAM. [22] V příloze E této práce je možné přehledně vidět vývoj mobilního telefonu iPhone na časové ose.
3.2. Apple iPod Touch
Řada produktů Apple iPod byla poprvé představena v roce 2001. Apple iPod je víceúčelové přenosné zařízení s primárním zaměřením na přehrávání multimédiálních dat. Poslední verze tohoto produktu byly představeny v roce 2012 v podobě produktů iPod Shuffle, iPod Nano a iPod Touch. Tato zařízení disponují externím úložištěm o kapacitě v rozmezí 2 až 160 GB v závislosti na modelu. Hlavními využívanými čipy v této řadě jsou Samsung ARM a Apple A5. Operační systém distribuovaný v těchto
11
zařízeních je iOS od verze 5 až po verzi 8, která je podporovaná pouze v posledních modelech. [23]
3.3. Apple iPad Apple iPad patří do skupiny tabletů společnosti Apple, který byl poprvé představen v roce 2010, jeho poslední verze iPad Air 2 a iPad Mini 3 byly představeny v roce 2014. Tato zařízení disponují displeji s podporou dotykového ovládání a virtuální klávesnice tak jako v případě Apple iPhone zařízení. První verze tohoto produktu nabízely displej o úhlopříčce 9.7“ s integrovaným čipem Apple A5 a VGA kamerami na přední i zadní straně zařízení. Další generace přinesly dvě významná vylepšení v podobě Retina displeje a nového čipu Apple A5X. Poslední verze tohoto zařízení již disponují čipy Apple A6X, A7, A8X a čtečkou otisků prstů. [24]
3.4. Apple Watch Poslední zařízení od společnosti Apple založené na platformě iOS je známé po názvem Apple Watch. Apple Watch byly představeny v září roku 2015 ve verzích Apple Watch, Apple Watch Sport a Apple Watch Edition. Apple Watch patří do relativně nové kategorie chytrých hodinek, které postupně nabývají na popularitě. Tyto hodinky nabízejí zajímavé funkce, jako je monitorování zdravotních funkcí či sportovních výkonů a mobilní platební službu Apple Pay. Hodinky disponují dvěma typy displejů v závislosti na verzi. Tyto displeje jsou označovány jako „Strengthened lon-X glass“ a „Sapphire crystal“. Součástí těchto hodinek je nový čip s názvem Apple S1, operační paměť o velikosti 8 GB a bezdrátové technologie jako jsou Bluetooth 4, NFC či Wi-Fi. Apple Watch využívají operační systém iOS ve verzi 8.2 a výše, který plně integruje nový framework WatchKit SDK. Aby hodinky mohly vykonávat i jiné než základní funkce, tak je nutné vlastnit spolu s hodinkami i jiné Apple zařízení, jako je například iPhone či iPad. Toto zařízení musí být propojeno s hodinkami Apple Watch. [25]
12
4. Vývoj operačního systému iOS 4.1.
Úvod
Mobilní operační systém iOS od společnosti Apple je založen na desktopovém operačním systému OS X pro Mac zařízení, tak jako Windows Phone či Android mají své základy v operačních systémech Windows a Linux. Původní název tohoto operačního systému byl „iPhone OS“, a to až do roku 2010, kdy došlo k přejmenování na název iOS, který byl původně registrován společností Cisco. Název iOS, tak nyní reprezentuje operační systém pro celou řadu Apple zařízení označovaných jako „i-Devices“. Operační systém iOS je využíván již od roku 2007 a k dnešnímu datu zaznamenal již několik verzí. [12] Operační systém iOS není úplně totožný s Mac OS X. Jedním z významných rozdílů je zvolená architektura. iOS zařízení využívají čipy založené na ARM architektuře, a tak jsou jádro a binární soubory operačního systému iOS zkompilovány pro ARM architekturu, na rozdíl od architektur Intel i386 a x86_64 používaných v Mac OS X. Hlavním důvodem pro zvolení ARM čipů, které jsou využívány i na platformě Android, je jejich efektivita v oblasti řízení spotřeby, což je jedna z kritických oblastí ve výrobě mobilních zařízení. Dalším rozdílem je fakt, že iOS zdrojové kódy nejsou na rozdíl od Mac OS X veřejně zpřístupněny a také to, že iOS jádro je zkompilováno účelově jinak, než jádro v systému Mac OS X, a to s ohledem na vlastnosti mobilních zařízení. Grafické uživatelské rozhraní využívané v systému iOS je Springboard, které je zaměřené na ovládání dotykem, na rozdíl od Aqua zaměřeného na navigaci pomocí myši v rámci okenního systému. Správa paměti je v systému iOS více striktní pro vývojáře, tak aby byla zaručena maximální efektivita při práci s pamětí. Navíc je iOS platforma úmyslně upravena z hlediska bezpečnosti. Příkladem může být to, že systém umožňuje pouze aplikacím od Applu plný přístup k systému a složkám v něm, na rozdíl od všech ostatních aplikací, či získání neomezeného („root“) oprávnění. Ostatní aplikace jsou podrobeny kontrole v rámci procesu publikace do App Store, v případě jakýchkoliv bezpečnostních rizik může být aplikace odmítnuta. Platforma iOS je úmyslně uzavřená platforma a vývojáři mohou používat jen ty funkcionality systému, které jsou schválené a považované za bezpečné společností Apple, což má za následek to, že vývojář nemůže plně využít potencionálu hardwaru v i13
Device zařízeních. Tato omezení jsou uměle vytvořená, i když iOS platforma umožňuje prakticky všechno, co je možné v Mac OS X. Výše zmíněné omezení je možné odstranit pomocí postupu zvaného Jailbreak, i když tento postup je to v rozporu s podmínkami Applu.
4.2. Vývoj První verze operačního systému iOS byla vydána již roku 2007 při představení prvního mobilního telefonu iPhone a později i iPod Touch. Kódové označení je známé jen pro některé verze iOS. První verze měla označení „Heavenly“. Tato verze obsahovala i mnoho symbolů pro debugování, nebyla šifrovaná, a tak bylo možné snadno využít techniky reverzního inženýrství („reverse engineering“) pro analýzu kódu, které byly nutností pro získání neomezených práv v rámci operačního systému iOS. [12] Verze 2.0, označovaná jako „BigBear“, byla vydána roku 2008 a stala se velmi populární spolu s nově vydaným mobilním telefonem iPhone 3G. Nemalou zásluhu na této popularitě měla i služba App Store, která se stala jednou z největších platforem pro distribuci software na světě. Další verze, které následovaly, jsou 2.1 („SugarBowl“) a 2.2 („Timberline“). Verze 3.0, označovaná jako „KirkWood“, přinesla mnoho grafických vylepšení a také nové funkce, jako jsou „tethering“, „spotlight search“ a podporu pro Nike+ technologii. Další verze následovaly v podobě 3.1 („NorthStar“) a 3.2 („WildCat“). S příchodem verze označované jako „WildCat“ byl představen i nový tablet pod názvem iPad. Další nové funkce byly přidány ve verzi 4. x vydané v roce 2010 spolu s novými produkty jako jsou iPhone 4, Apple TV a iPad 2. iOS 4. x také přidává podporu multitaskingu a bezpečnostního prvku ALSR (Address Space Layout Randomization), který měl zastavit metodu Jailbreak, která nabývala na popularitě od verze iOS 3.0, kdy hacker pod názvem „Comex“ představil jeden z prvních Jailbreak programů. Tento hacker také později prolomil nově zavedené zabezpečení ALSR, což vyústilo v představení nové verze Jailbreak programu. Apple následně začlenil tohoto hackera to svého týmu. iOS 5. x (označován jako „Telluride“ a „Hoodoo“) byl představen v roce 2011 spolu s mobilním telefonem iPhone 4S, iPad 3 a novými funkcemi jako je ovládání hlasem, pod názvem Siri, a zálohovací službou iCloud. iOS 6. x byl představen v roce
14
2012 spolu s mobilním telefonem iPhone 5 obsahující vylepšení pro uživatelské rozhraní a aplikace pro mapy, Passbook, Siri a další. [12]
15
5. Typy dat na iOS zařízení Zařízení s platformou iOS, jako jsou chytré telefony či tablety, uchovávají a zpracovávají velké množství uživatelských i systémových dat. Nové verze těchto zařízení přináší novější a novější technologie s požadavkem na větší uložiště dat. Například v poslední verzi telefonu iPhone je kapacita paměti až 128 GB. Operační systém iOS je navržen tak, aby umožnil tato data efektivně zpracovávat i uchovávat. Mezi data, která jsou nejčastěji uchovávána na těchto zařízeních, patří textové zprávy, záznamy o hovorech, hlasové zprávy, emaily, chat, fotky, videa, mapy a mnoho dalších dat a záznamů. Tato data jsou velmi cenná při forenzním vyšetřování, kdy je cílem získat data ze zařízení a přitom zachovat jejich integritu. [16, 38]
5.1. Souborový systém na iOS zařízení iOS platforma využívá odlišný souborový systém, než jaký známe z platformy Windows či Unix. Jedná se o nový souborový systém představený společností Apple v roce 1985 a použitý prvně na Mac OS počítačích. Tento souborový systém je znám pod názvem Hierarchical File System (HFS) a využívá formátování s velikostí 512 bajtů v rámci jednoho bloku, který je možné rozdělit na logické a alokační bloky. Logický blok je číslován od prvního bloku do posledního a zůstává neměněn na oddíle. Alokační bloky můžou být dále spojené do skupiny bloků. Celý souborový systém navíc obsahuje hlavičku oddílu (header file), soubor pro inicializaci (startup file), alokační soubor (allocation file), soubor atributů, katalogový soubor (catalog file) a soubor obsahující všechny alokační bloky. [16]
16
5.2. Oddíly souborového systému na iOS zařízení Data na iOS zařízení jsou uložena na uložišti typu NAND a rozdělena na oddíl firmwaru a uživatelských dat. Oddíl firmwaru je obvykle formátován na velikost okolo 1 - 2.7 GB, je nastaven pouze pro čtení s výjimkou situace, kdy je firmware aktualizován. Pro aktualizaci firmwaru na iOS zařízení se využívá program Apple iTunes, který přepíše starý firmware novým. Oddíl obvykle obsahuje pouze základní aplikace či systémové a aktualizační soubory. Uživatelská data jsou ve druhém oddílu obsahujícím také všechny iTunes aplikace a uživatelské profily.
5.3. Databáze SQLite SQLite je populární relační databáze pro mobilní zařízení, webové prohlížeče a další. Jedná se o open source projekt vyvíjený v jazyce C a distribuován ve formě knihovny. Na rozdíl od jiných databází, které jsou spouštěny v separátním procesu, se tato knihovna připojí ke kódu aplikace (linking), která ji využívá. Mnoho aplikací na platformě iOS využívá SQLite databáze pro uchovávání dat. Mezi tyto aplikace patří jak nativní aplikace, jako jsou Messages, Safari, Call History, Notes, Photos, Calendar a Address Book, tak i aplikace distribuované prostřednictvím App Store, jako jsou například WhatsApp, Viber a další. Pro práci s daty uloženými v SQLite databázi existuje mnoho nástrojů, jako jsou například SQLite Manager plugin do webového prohlížeče Firefox, aplikace SQLite Browser, DB Browser for SQLite a další. Zároveň je také možné využít aplikaci SQLite Shell a pracovat s daty prostřednictvím příkazů v příkazové řádce. Na obrázku níže je ukázán plugin do webového prohlížeče Firefox.
17
Obrázek 2: SMS SQLite databáze otevřená v programu SQLite Manager
5.4. Property List Property List, zkráceně plist, je datový soubor vyvinutý společností Apple k uchovávání různých dat na platformě iOS a Mac OS. Data mohou být uložena ve formě XML nebo v binární podobě. Plist může obsahovat různé typy dat, jako jsou například textové řetězce, číselné hodnoty, data, pole, binární data a další. Tato data jsou ukládána 18
do plist souborů jako výsledek serializace datových typů z aplikačního frameworku Core Foundation, jak je patrné na obrázku níže, v případě formy XML. XML plist můžeme na rozdíl od jeho binární verze zobrazit téměř v jakémkoliv textovém editoru. Pokud chceme číst či upravit binární plist, tak je nutné využít speciální program, jako je například Plist Editor pro Windows nebo TextWrangler pro Mac OS. Další možností je použít program v příkazové řádce po názvem Plutil. Tento program umožnuje převést binární plist soubor do jeho XML verze a je kompatibilní s operačními systémy Windows, Mac OS a Linux. Na obrázku níže jsou zobrazeny standartní datové typy z aplikačního frameworku Core Foundation a jejich XML ekvivalenty. [4, 16, 26]
Obrázek 3: Datové typy z aplikačního frameworku Core Foundation a jejich XML ekvivalenty [4]
19
6. Metody extrakce dat z iOS zařízení V rámci forenzního vyšetřování je často nutné získat data ze zařízení, které není fyzicky dostupné. Další častou situací je, že vlastník zařízení nemůže nebo není ochoten poskytnout informace umožňující standartní přístup k datům na tomto zařízení. Příkladem může být situace, kdy vlastník zařízení odmítá poskytnout heslo k zařízení. Často je tak nutné využít speciálních metod, jak tato data bezpečně získat z mobilního zařízení a přitom zachovat integritu dat a samotného zařízení pro další kroky vyšetřování. Mezi používané metody k přístupu dat patří takzvaná logická a fyzická extrakce dat, či extrakce dat za pomocí datového úložiště iCloud. Tyto metody jsou v následujících kapitolách podrobně probrány.
6.1. Logická extrakce dat Extrakce dat není jednoduchá, pokud není zařízení fyzicky k dispozici. To ale neznamená, že je to často úplně nemožné. Velmi známé možnosti, jak data získat bez fyzického přístupu k zařízení, je využití iTunes záloh, které jsou obvykle automaticky vytvářené na klientském počítači za pomoci aplikace iTunes.
6.1.1.
Zálohy z programu iTunes
Každé zařízení, které bylo alespoň jedenkrát fyzicky připojeno k počítači, na kterém je nainstalován program iTunes, může obsahovat vytvořenou zálohu ze zařízení. V dřívějších verzích programu iTunes byl tento typ zálohování automaticky předvolen, ale v novějších verzích byl nahrazen zálohováním na webovou službu iCloud. Zařízení může být zálohováno na disk počítače prostřednictvím programu iTunes manuálně nebo automaticky jako je tomu v případě aktualizace operačního systému iOS. Zálohy jsou ukládány v odlišných umístěních na různých operačních systémech, jako jsou Windows a Mac OS X, tak jak je možné přehledně vidět na obrázku níže.
20
Obrázek 4: Umístění iTunes záloh [2]
V těchto umístěních je možné najít specifické zálohy iOS zařízení. Názvy složek reprezentují unikátní identifikátor každého zařízení označovaný jako UDID. Tento identifikátor je možné zjistit například prostřednictvím programu iTunes, a to kliknutím na pole Serial number v informacích o zařízení. Výpočet UDID je rozdělen do dvou základních kroků. Nejprve je nutné získat 60 (eventuálně 59) znaků dlouhý textový řetězec a následně ho použít jako vstup do hašovací funkce SHA1. Výsledkem této funkce je hledané UDID. Textový řetězec je vytvořen spojením sériového čísla, čísla IMEI nebo ECID, Wi-Fi MAC adresy a Bluetooth MAC adresy. [18]
21
Obrázek 5: Složky záloh různých iOS zařízení
Každá složka zařízení obsahuje mimo jiné i informace o záloze a zařízení, ze kterého byla záloha vytvořena. Tyto informace jsou obsaženy v souborech Info.plist, Manifest.mbdb, Manifest.plist a Status.plist. V případě neúspěšné zálohy může dojít k vytvoření pouze jednoho či několika z těchto souborů v závislosti na tom, ve kterém kroku byla neúspěšná záloha přerušena. Nejčastěji se jedná o situaci, kdy je k dispozici pouze soubor Status.plist. Soubor Status.plist obsahuje informace o poslední záloze zařízení. Jedná se o typ souboru označovaný jako Binary Plist, a tak je nutné využít speciální editor pro čtení či editaci obsahu tohoto souboru. Jedním z použitelných programů je například program s názvem PlistEditor for Windows. Po otevření souboru v editoru je možné získat informace jako je datum a čas zálohy, stav zálohy, verzi zálohovacího softwaru a identifikátor UUID. Mnohem více informací je možné nalézt v souboru Info.plist. Tento soubor je uložen v klasickém XML Plist formátu, s možností čtení či editace v prakticky jakémkoliv textovém editoru. Soubor Info.plist obsahuje informace o zařízení, které je možné použít pro ověření informace, k jakému zařízení záloha patří. Můžeme v něm nalézt pole Build Version, Device Name, Display Name, GUID, ICCID, IMEI, Serial Number, Target Identifier, Unique Identifier, iTunes Version a další užitečné informace o zařízení nebo záloze. Dalším neméně důležitým souborem je Manifest.plist uložený ve formátu Binary Plist, který obsahuje v elementu Applications seznam nainstalovaných aplikací a jejich základní informace. Mezi základní informace o aplikaci, které jsou dostupné, patří CFBundleIdentifier a Path. První slouží jako identifikátor aplikace a druhý obsahuje 22
cestu k nainstalované aplikaci uložené na disku iOS zařízení. Dále je také možné nalézt elementy BackupKeyBag, Date, IsEncrypted, Lockdown, SystemDomainsVersion, Version, WasPasscodeSet.
6.1.2.
Šifrovaná záloha programu iTunes
Program iTunes nabízí možnost šifrovaných záloh, které není možné jednoduše číst a procházet, tak jak je tomu u nešifrovaných záloh. Aby bylo možné zálohu číst, je nutné ji nejprve dešifrovat s využitím předem známého hesla nebo programu pro prolamování hesel. Jednou z možností je využít komerční produkty, jako jsou SmartPhone Data Recovery, Elcomsoft iPhone Password Breaker, iPhone Backup Extractor a jiné. Další možností je využití python skriptů z projektu iphonedataprotection. Jak už bylo zmíněno v předchozí kapitole, záloha iTunes obsahuje soubor Manifest.plist s elementem BackupKeyBag. Tento element obsahuje binární data reprezentující náhodné třídy klíčů pro každou zálohu. Data jsou uložena ve stejném formátu jako systémové KeyBag klíče používané přímo na iOS zařízení, ale nejsou totožné.
6.1.3.
Šifrovaní dat na disku iOS zařízení
Zařízení iOS obsahují citlivé uživatelské informace, a tak je důležité zajistit jejich ochranu. Pro tento účel iOS obsahuje Data Protection API, které umožňuje vývojářům aplikací dostatečně ochránit uživatelská a Keychain data v případě, že je zařízení ztraceno či odcizeno. Keychain je označení pro systém správy hesel představený poprvé na platformě Mac OS X. S využitím tohoto API je možné pro vývojáře stanovit, které soubory a položky Keychain mohou být použity vzhledem k aktuálnímu stavu zařízení. Příkladem tak může být situace, kdy je možné určité soubory či položky použít pouze v případech, pokud je zařízení odemknuto a naopak. Vývojář má možnost přiřadit k souborům a Keychain položkám třídy označované jako Protection class. V Data Protection API je přesně stanoveno, jaké třídy je možné použít a jakou ochranu poskytují. Na obrázku níže můžeme vidět, jak jsou jednotlivé třídy vytvořeny za pomocí dalších klíčů a dat.
23
Obrázek 6: Hierarchie bezpečnostních klíčů použitých v Data Protection API (iOS4) [31, 32]
24
6.2. Fyzické extrakce dat Situace, kdy je zařízení fyzicky k dispozici, poskytuje mnohem více možností pro extrakci dat, než je tomu u logické metody. Fyzický přístup extrakce dat ze zařízení umožňuje využití služeb běžících na iOS zařízení, Jailbreaku nebo zavedení Ramdisku.
6.2.1.
Extrakce dat s využitím služeb na iOS zařízení
Nejrozšířenější metodou získávání dat z iOS zařízení, která je nejčastěji nabízena komerčními forenzními softwarovými produkty, je získávání dat s využitím služeb na iOS zařízení. Tato metoda umožňuje extrahovat velké množství dat přímo ze zařízení, které je připojeno k počítači přes USB port. Příkladem komerčního produktu využívající těchto služeb je například iPhone Explorer, který umožňuje zobrazit některá data obsažená v zařízení. Mezi tato data patří historie hovorů, textových zpráv, multimédia, kontakty, internetové záložky a další. Logická extrakce dat je závislá na několika základních službách, které musí být spuštěny na pozadí operačního systému iOS. Mezi tyto služby patří com.apple.mobile.house_arrest, com.apple.mobile.file_relay,
com.apple.pcapd,
com.apple.iosdiagnostics.relay,
com.apple.mobile.installation_proxy a com.apple.syslog_relay využívající komunikační protokol AFC. Tyto služby nebyly až do nedávné doby nikde dokumentovány a některé z nich představují bezpečností rizika. Služba com.apple.mobile.house_arrest je oficiálně navrhnuta jako služba, která je využívána aplikací iTunes za účelem kopírování souborů do Documents složky v rámci instalovaných aplikací prostřednictvím App Store. I když kopírování souborů do jiných složek v rámci dané aplikace není aplikací iTunes umožněno, tak služba samotná tuto funkcionalitu umožňuje. Služba tudíž umožňuje přístup ke složkám, jako jsou Library, Caches, Cookies a Preferences, obsahující citlivé informace, které by neměly být volně přístupné. Například s využitím programu iFunBox je možné tyto složky procházet či upravovat jejich obsah tak, jak je možné vidět na obrázcích níže.
25
Obrázek 7: Správa souborů v rámci iOS aplikace s využitím programu iTunes
Obrázek 8: Správa souborů v rámci iOS aplikace s využitím programu iFunBox
26
Kromě komerčních produktů je možné také využít open source knihovnu pod názvem
libimobiledevice
za
účelem
využití
výše
zmiňovaných
služeb.
Libimobiledevice je knihovnou umožňující komunikaci s iOS zařízením na nejnižší možné úrovni, kterou je možné použít v operačních systémech Windows, Linux či Mac OS X. Knihovna je implementována s využitím reverzního inženýrství na aplikaci iTunes. Konkrétně bylo nutné extrahovat komunikační protokoly například z knihovny iTunesMobileDevice.dll na platformě Windows s využitím programu typu disassembler, jako je například IDA Pro. S využitím této knihovny je možné komunikovat se zařízením a například i zjistit, jaké soubory se nachází v Documents složce, nebo i nějaký soubor stáhnout či nahrát zpět do zařízení. Základní práce s touto knihovnou a službou com.apple.mobile.house_arrest je ilustrována v příloze B. Zatímco služba com.apple.mobile.house_arrest je určena pro komunikaci mezi iOS zařízením a externí aplikací iTunes nainstalovanou na klientském počítači, tak naproti tomu služba com.apple.mobile.file_relay je specifikována jako diagnostická služba, kterou Apple využívá k diagnostice zařízení a řešení případných problémů. Tato služba také nebyla nikde dlouhou dobu dokumentována a je umístěna v umístění /usr/libexec/mobile_file_relay na iOS zařízení. Oficiální Apple aplikace, jako jsou iTunes či XCode, tuto službu nevyužívají. Ačkoliv byla služba později označena společností Apple jako služba pro přenos diagnostických dat, umožnuje i přenos celé řady jiných dat, a to i v případě, že je zařízení uzamčeno a mělo by být chráněno v rámci Data Protection API. Navíc bylo možné stáhnout tato data, i když je zařízení nastaveno pro vytváření šifrovaných záloh. Data je možné stáhnout ze zařízení v podobě cpio.gz archivu. Služba byla prvně klasifikována a nahlášena společnosti Apple jako bezpečností riziko iOS výzkumníkem Jonathan Zdziarski [35, 39], ale byla zabezpečena až s příchodem iOS 8. V iOS 8 již není možné službu volně využít [35, 39]. Práci s touto službou opět můžeme ilustrovat na ukázce kódu v příloze A této práce. V ukázce kódu z přílohy A je vidět, jak je možné nastavit tzv. zdroje dat, reprezentující data, která je možné stáhnout ze zařízení ve formě archivu. V tabulkách níže můžeme vidět všechny možné zdroje dat pro iOS ve verzi 2 a 7, které je možné s využitím ke konfiguraci této služby.
27
Zdroje dat služby File Relay v iOS 2. x AppleSupport
WiFi
CrashReporter
Network
UserDatabases
SystemConfiguration
Tabulka 1: Zdroj dat služby File Relay v iOS 2. x
Zdroje dat služby File Relay v iOS 7 Accounts
CoreLocation
IORegUSBDevice
MobileInstallation
Address Book
DataAccess
HFSMeta
MobileMusicPlayer
AppleSupport
DataMigration
Keyboard
MobileNotes
AppleTV
Demod
Lockdown
NANDDebugInfo
Baseband
Device-o-Matic
MapsLogs
Network
Bluetooth
EmbeddedSocial
MobileAsset
Photos
CrashReporter
FindMyiPhone
MobileBackup
SafeHarbor
CLTM
GameKitLogs
MobileCal
SystemConfiguration
Caches
itunesstored
MobileDelete
tmp
Ubiquity
UserDatabases
VARFS
VPN
Voicemail
WiFi
WirelessAutomation
Tabulka 2: Zdroj dat služby File Relay v iOS 7
Zdroj dat označovaný jako Accounts umožnuje stáhnout účty uchovávané v iOS zařízení, jako jsou například email, Twitter, iCloud, Facebook a další. AddressBook umožňuje získat kopii SQLite databáze uchovávající všechny kontakty uložené v zařízení. Jakoukoliv SQLite databázi je možné navíc dále zpracovat a pokusit se obnovit smazané záznamy, což je detailně vysvětleno v rámci této práce. Caches obsahují snímky posledních zobrazených obrazovek, sdílené obrázky, offline obsah, obsah zkopírovaný do schránky, cache klávesnice a další osobní data. CoreLocation obsahuje GPS lokační data zaznamenaná v zadaném intervalu. Kompletní meta informace o souborovém systému jsou dostupné v rámci zdroje HFSMeta. Tyto meta informace obsahují datum a čas, název a velikost všech vytvořených souborů. Další obsažená data poskytují například informace o tom, kdy bylo zařízení naposled aktivováno či smazáno, seznam všech nainstalovaných aplikací včetně jmen všech souborů v Documents složce, názvy všech emailových příloh, seznam všech emailových 28
účtů na zařízení, párovací klíče a časy mezi iOS zařízením a host zařízením, telefonní čísla a časy obsažené v předpřipravených SMS a časovou osu všech aktivit. Zdroj dat označovaný jako Keyboard obsahuje kopii cache automatických oprav klávesnice. MobileCal a MobileNotes zdroje obsahují SQLite databáze s informacemi o událostech v kalendáři, včetně všech upozornění, a informace o poznámkách uložených na zařízení. Photos zdroj poskytne kompletní kopii všech fotek uložených v aplikaci Photos na zařízení, kromě složky pojmenované Camera Roll. Pokud chceme stáhnout ze zařízení pouze důležité SQLite databáze, můžeme využít zdroj UserDatabases, který umožňuje získat data ve formě SQLite databází jako jsou kontakty, kalendářové události, historie hovorů, SMS databáze a emailová meta data. Posledním zajímavým zdrojem dat je Voicemail, umožňující stáhnout záznamy z hlasové schránky ve formátu AMR. [16] Další službou, která je aktivní na každém iOS zařízení ve verzi 7. x a níže, je služba com.apple.pcapd, která spouští na iOS zařízení program libpcap. S pomocí této služby můžeme stáhnout ze zařízení HTTP příchozí a odchozí síťovou komunikaci. Služba běží na zařízení bez jakéhokoliv vizuálního upozornění. Na zařízení běží i další služby, jako jsou com.apple.iosdiagnostics.relay poskytující detailní
síťovou
komunikaci
pro
každou
nainstalovanou
aplikaci
zvlášť,
com.apple.mobile.installation_proxy, která umožňuje nahrát uživatelskou aplikaci do zařízení, a to plně na pozadí a na závěr i služba com.apple.syslog_relay poskytující detailní informace o aktuální činnosti zařízení, a to i logovací informace z nainstalovaných aplikací.
29
6.2.2.
Extrakce dat za pomocí Jailbreaku
Extrakce dat za pomocí Jailbreaku je technika, při které se instaluje Jailbreak na zařízení za účelem možnosti volně zpřístupnit souborový systém a instalovat další programy na zařízení. Pokud je například nutné získat data ve formě plného obrazu disku, je nutné, aby bylo zařízení Jailbreaknuté, k čemuž je možné využít například program Redsn0w. Program Redsn0w umožňuje s využitím intuitivního postupu uvést zařízení do DFU módu, nahradit oddíl firmwaru a také nainstalovat programy včetně alternativního programu Cydia k App Store. Program Cydia umožňuje stáhnout a nainstalovat program OpenSSH za účelem připojení počítače k zařízení. Získání obrazu disku z iOS zařízení je možné provést za pomocí příkazu: ssh
[email protected] dd if=/dev/rdisk0 bs=1M | dd of=iosdisk.img. Tento příkaz, umožní počítači navázat připojení se zařízením, konkrétně s SSH serverem, a příkaz dd zkopíruje obsah disku do souboru ve formátu obrazu disku. Data zkopírovaná ze zařízení iPhone 3GS a výše jsou šifrovaná, a tak je nutné nejprve získat Keychain klíče, které je možné využít k dešifrování dat v obrazu disku. Soubor obrazu disku je možné dále analyzovat s využitím dalších open source i komerčních forenzních programů jako jsou FTK imager, HFS+ images, Strings, Find, DD, Scalpel. Data obsažená v obrazu disku obsahují mnoho SQLite databází, Plist a dalších různých typů souborů se standardní informací o tom, kdy byl soubor naposledy změněn, přistoupen a vytvořen. Struktura dat je shodná napříč všemi iOS zařízeními a zároveň podobná Unixovým systémům. Defaultní aplikace, jako jsou Address Book, Maps, Safari, SMS, Mail a další nainstalované na zařízení, jsou dostupné v umístění /private/var/mobile/Library. Aplikace stáhnuté a nainstalované z App Store do umístění /private/var/mobile/Applications/,
kde
je
nejprve
vytvořena
složka
aplikace
s unikátním identifikátorem ve formátu GUID. Každá aplikace má danou strukturu podsložek, které jsou documents, temp a library. Documents podsložka obsahuje soubory samotné aplikace, temp podsložka obsahuje dočasné soubory využívané při běhu aplikace a na závěr library podsložka uchovává cache data a konfigurační soubory. Kromě podsložek je zároveň běžné, aby aplikační složka obsahovala další konfigurační soubory ve formátu Plist.
30
Fotky a videa na iOS zařízení můžeme nalézt v podsložkách 100APPLE, 101APPLE a 102APPLE v umístění /private/var/mobile/media/DCIM, a to ve standardních grafických formátech. Názvy jednotlivých fotek a videí vytvořených na zařízení využívají formát IMG_XXX a MOV_XXX, kde XXX je nahrazeno hodnotou číselnou, jako je např. 0001 pro první
fotku
či
video.
Zařízení
také
využívá
SQLite
databázi
v umístění
/private/var/mobile/Media/PhotoData s názvem Photos.sqlite pro uchovávání informací o všech fotkách a videích tak, jak je možné vidět níže na obrázku.
Michals-iPhone:/private/var/mobile/Media/DCIM root# ls 100APPLE/
101APPLE/
102APPLE/
103APPLE/
Michals-iPhone:/private/var/mobile/Media/DCIM root# cd .. Michals-iPhone:/private/var/mobile/Media root# ls AirFair/
HighlandPark/
Recordings/
Airlock/
LoFiCloudAssets/
Safari/
ApplicationArchives/
MxTube/
com.apple.itdbprep.postprocess.lock
Books/
PhotoData/
com.apple.itunes.lock_sync
CTC/
PhotoStreamsData/
general_storage/
CloudAssets/
Photos/
iTunes_Control/
DCIM/
Purchases/
ifbfav.plist
Downloads/
Radio/
panguaxe.installed
Michals-iPhone:/private/var/mobile/Media root# cd PhotoData/ Michals-iPhone:/private/var/mobile/Media/PhotoData root# ls AlbumsMetadata/
ModelInterest.sqlite-shm
Photos.sqlite-shm
changes-shm
Caches/
ModelInterest.sqlite-wal
Photos.sqlite-wal
changes-wal
MISC/
PhotoBulletins.plist
Thumbnails/
Metadata/
PhotoCloudSharingData/
Videos/
ModelInterest.sqlite
Photos.sqlite
changes
Obrázek 9: Umístění multimediálních dat na iOS zařízení
Slovní výrazy použité v rámci zařízení jsou uchovávány v souborech typu dynamický slovník v umístění /private/var/mobile/Library/Keyboard. Tyto soubory jsou uchovávány separátně pro každou zemi a jazyk na zařízení, jako je tomu v případě vytvořeného souboru en_GB-dynamic-text.dat. Tento soubor slouží k funkci jako je napovídání a doplňování slov uživateli v průběhu psaní na zařízení. Mezi slovní výrazy patří i výrazy použité v rámci aplikací Messenger, Facebook, WhatsApp, Notes, Safari a mnoho dalších aplikací. Auto opravy textu zadané manuálně v rámci zařízení jsou uchovávaný v SQLite databázi s názvem CloudUserDictionary.sqlite. 31
Michals-iPhone:/ root# cd /private/var/mobile/Library/Keyboard/ Michals-iPhone:/private/var/mobile/Library/Keyboard root# ls CloudUserDictionary.sqlite
en_GB-dynamic-text.dat
CoreDataUbiquitySupport/
Obrázek 10: Umístění souboru en_GB-dynamic-text.dat uchovávající slovní výrazy
Operační systém iOS disponuje manažerem hesel uchovávaným na zařízení v podobě souboru, a to ve formátu Apple Keychain. Tento soubor můžeme nalézt v umístění /private/var/Keychains, a to pod názvem keychain-2.db. S využitím příkazů file a sqlite3 je možné zjistit, že se jedná o SQLite databázi ve verzi 3, která obsahuje tabulky cert, genp, inet, keys a tvertion. Dále je možné pomocí standartních SQL příkazů procházet data v těchto tabulkách. Data obsažená v těchto tabulkách obsahují účty i hesla použitá na zařízení, a tak je možné nalézt hesla k aplikacím, hlasovým zprávám, Wi-Fi sítím a mnohým dalším. Data jsou šifrovaná, a tak je nutné tato data nejprve dešifrovat například s využitím projektu iphone-dataprotection a příkazu python keychain_tool.py -d keychain-2.db DeviceEncryptionKeys.plist. Alternativou také být využití komerčního programu Elcomsoft iPhone Password Breaker.
32
Michals-iPhone:/ root# cd /private/var/Keychains/ Michals-iPhone:/private/var/Keychains root# ls TrustStore.sqlite3
keychain-2.db-wal
accountStatus.plist
keychain-backup.plist
caissuercache.sqlite3
keychain-ota-backup.plist
caissuercache.sqlite3-journal
ocspcache.sqlite3
keychain-2.db
ocspcache.sqlite3-shm
keychain-2.db-shm
ocspcache.sqlite3-wal
Michals-iPhone:/private/var/Keychains root# file * TrustStore.sqlite3:
SQLite 3.x database
accountStatus.plist:
Apple binary property list
caissuercache.sqlite3:
SQLite 3.x database
caissuercache.sqlite3-journal: data keychain-2.db:
SQLite 3.x database
keychain-2.db-shm:
data
keychain-2.db-wal:
data
keychain-backup.plist:
Apple binary property list
keychain-ota-backup.plist:
Apple binary property list
ocspcache.sqlite3:
SQLite 3.x database
ocspcache.sqlite3-shm:
data
ocspcache.sqlite3-wal:
data
Michals-iPhone:/private/var/Keychains root# sqlite3 keychain-2.db SQLite version 3.7.13 Enter ".help" for instructions sqlite> sqlite> .tables cert
genp
inet
keys
tversion
Obrázek 11: Umístění souboru keychain-2.db
Aplikace Notes uchovává poznámky v SQLite databázi pod názvem notes.sqlite v umístění /private/var/mobile/Library/Notes. Z této databáze je možné získat nejenom obsah všech poznámek, ale i datum a čas jejich vytvoření a upravení.
33
Michals-iPhone:/ root# cd /private/var/mobile/Library/Notes/ Michals-iPhone:/private/var/mobile/Library/Notes root# ls notes.idx
notes.sqlite
Michals-iPhone:/private/var/mobile/Library/Notes root# sqlite3 notes.sqlite SQLite version 3.7.13 Enter ".help" for instructions sqlite> .tables ZACCOUNT
ZNOTE
ZNOTECHANGE
ZSTORE
Z_PRIMARYKEY
ZNEXTID
ZNOTEBODY
ZPROPERTY
Z_METADATA
Obrázek 12: Umístění souboru notes.sqlite uchovávající poznámky
Textové zprávy v iOS zařízení je možné nalézt v SQLite databázi v umístění /private/var/Library/mobile pod názvem sms.db. Tato databáze uchovává informace o SMS
a iMessage zprávách v tabulkách
message,
chat, handle,
attachment,
chat_handle_join a chat_message_join.
Michals-iPhone:/ root# cd /private/var/mobile/Library/SMS/ Michals-iPhone:/private/var/mobile/Library/SMS root# ls Attachments/
Drafts/
EmergencyAlerts/
sms.db
sms.db-shm
sms.db-wal
Michals-iPhone:/private/var/mobile/Library/SMS root# sqlite3 sms.db SQLite version 3.7.13 Enter ".help" for instructions sqlite> .tables _SqliteDatabaseProperties
chat_message_join
attachment
handle
chat
message
chat_handle_join
message_attachment_join
Obrázek 13: Umístění souborů uchovávajících data o textových zprávách
Webový prohlížeč Safari uchovává zajímavá data v umístění /private/var/mobile /Library/Safari, kde jsou uloženy soubory záložek a vyhledávacích nástrojů s názvy Bookmarks.db a SearchEngine.plist. V dalším umístění /private/var/mobile/Applications /**APP_GUID**/Library /Safari je možné nalézt soubor History.plist uchovávající záznamy o posledních navštívených stránkách. Tento soubor je aktualizován pouze v případě, že je v aplikaci Safari vypnutý režim označovaný jako Private. Navíc se jedná o binární verzi souboru typu Plist, a tak je nutné nejprve tento soubor převést do čitelné podoby ve formě XML s využitím programu plutil. [16] 34
Michals-iPhone:/ root# cd /private/var/mobile/Applications/BDBA4FC6-CD144D85-B34D-CC6949F40498/Library/Safari/ Michals-iPhone:/private/var/mobile/Applications/BDBA4FC6-CD14-4D85-B34DCC6949F40498/Library/Safari root# ls History.plist
RecentSearches.plist
SyncedTabsMetadata.plist
History.xml.plist
SuspendState.plist
Thumbnails/
Michals-iPhone:/private/var/mobile/Applications/BDBA4FC6-CD14-4D85-B34DCC6949F40498/Library/Safari root# vim History.plist Michals-iPhone:/private/var/mobile/Applications/BDBA4FC6-CD14-4D85-B34DCC6949F40498/Library/Safari root# cp History.plist History.xml.plist Michals-iPhone:/private/var/mobile/Applications/BDBA4FC6-CD14-4D85-B34DCC6949F40498/Library/Safari root# plutil -convert xml1 History.xml.plist Converted 1 files to XML format Michals-iPhone:/private/var/mobile/Applications/BDBA4FC6-CD14-4D85-B34DCC6949F40498/Library/Safari root# vim History.xml.plist Michals-iPhone:/private/var/mobile/Applications/BDBA4FC6-CD14-4D85-B34DCC6949F40498/Library/Safari root# head -10 History.xml.plist
plist
PUBLIC
"-//Apple//DTD
PLIST
1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
WebHistoryDates <array> <string>https://www.google.co.uk/search?q=kebab+covehtry+cv1&ie=UTF -8&oe=UTF-8&hl=engb&client=safari#istate=lrl:iv&rlimm=14864269016341449323 D
Obrázek 14: Umístění souboru History.plist
35
Adresář
kontaktů
můžeme
/private/var/mobile/Library/AddressBook,
kde
nalézt jsou
uchovávány
v umístění soubory
AddressBook.sqlitedb a AddressBookImages.sqlitedb. První soubor obsahuje tabulky s důležitými daty o kontaktech, jako jsou ABAccount, ABGroup, ABPerson a mnoho dalších.
Michals-iPhone:/ root# cd /private/var/mobile/Library/AddressBook/ Michals-iPhone:/private/var/mobile/Library/AddressBook root# ls AddressBook.sqlitedb
AddressBookImages.sqlitedb
AddressBook.sqlitedb-shm
AddressBookImages.sqlitedb-shm
AddressBook.sqlitedb-wal
AddressBookImages.sqlitedb-wal
Michals-iPhone:/private/var/mobile/Library/AddressBook root# sqlite3 AddressBook.sqlitedb SQLite version 3.7.13 Enter ".help" for instructions sqlite> .tables ABAccount
ABPersonFullTextSearch_segdir
ABGroup
ABPersonFullTextSearch_segments
ABGroupChanges
ABPersonFullTextSearch_stat
ABGroupMembers
ABPersonLink
ABMultiValue
ABPersonMultiValueDeletes
ABMultiValueEntry
ABPersonSearchKey
ABMultiValueEntryKey
ABPhoneLastFour
ABMultiValueLabel
ABRecent
ABPerson
ABStore
ABPersonBasicChanges
FirstSortSectionCount
ABPersonChanges
FirstSortSectionCountTotal
ABPersonFullTextSearch
LastSortSectionCount
ABPersonFullTextSearch_content
LastSortSectionCountTotal
ABPersonFullTextSearch_docsize
_SqliteDatabaseProperties
Obrázek 15: Práce se soubory uchovávající data o kontaktech
Druhý soubor poskytuje primárně informace, uložené v tabulkách ABFullSizeImage a ABThumbnailImage, o profilových obrázcích k jednotlivým kontaktům v různých formátech.
36
Michals-iPhone:/ root# cd /private/var/mobile/Library/AddressBook/ Michals-iPhone:/private/var/mobile/Library/AddressBook root# sqlite3 AddressBookImages.sqlitedb SQLite version 3.7.13 Enter ".help" for instructions sqlite> .tables ABFullSizeImage
_SqliteDatabaseProperties
ABThumbnailImage
Obrázek 16: Umístění souboru AddressBookImages.sqlitedb
Záznamy o telefonních hovorech můžeme nalézt v umístění /private/varwireless/Library/CallHistory, kde je uchováván soubor call_history.db obsahující tabulku s názvem call, která poskytuje informace o telefonním záznamu jako je typ záznamu, telefonní číslo, datum a čas hovoru, doba hovoru a mnohé další informace.
Michals-iPhone:/ root# cd /private/var/wireless/Library/CallHistory/ Michals-iPhone:/private/var/wireless/Library/CallHistory root# ls call_history.db Michals-iPhone:/private/var/wireless/Library/CallHistory
root#
call_history.db SQLite version 3.7.13 Enter ".help" for instructions sqlite> .tables _SqliteDatabaseProperties
call
Obrázek 17: Umístění souboru call_history.db
37
sqlite3
6.2.3.
Extrakce dat za pomocí zavedení upraveného Ramdisku
V rámci tohoto typu extrakce dat je nutné opět využít speciálního programu jako je Redsn0w, tak jako tomu bylo v případě extrakce dat za pomocí Jailbreaku. Tento program umožňuje využití jednoho z výše zmíněných Boot ROM exploitů k zavedení takzvaného Ramdisku s upraveným jádrem, které umožňuje spouštění nepodepsaných programů na zařízení. Jádro systému v tomto případě standardně neobsahuje všechny běžné změny, které jsou obvyklé v případě Jailbreaku. Práce se zařízením je pak naprosto totožná jako v případě metody Jailbreaku. Rozdílem je, že po restartu je zařízení opět uvedeno do původní podoby, jelikož se veškeré změny odehrály v operační paměti zařízení.
38
6.3. Zálohy ze služby iCloud iCloud je název pro webové úložiště dat představené společností Apple v říjnu roku 2011 společně s příchodem iOS 5. Apple volně nabízí úložiště o velikost 5 GB s možností zakoupení většího datového prostoru. Již v roce 2013 bylo naměřeno přes 300 milionů aktivních uživatelů tohoto úložiště.
6.3.1.
iCloud zálohy
Zálohy iOS na iCloud úložiště umožňují uchování mnoha různých dat, jako jsou kontakty, textové zprávy, historie hovorů, aplikační data, nastavení zařízení, fotky a videa, nákupy z App Store, emailové účty, nastavení sítě včetně Wi-Fi sítí, historie a záložky webového prohlížeče Safari a mnoho dalších. Záloha na iCloud v rámci iOS zařízení je inicializována denně, a to za podmínky, že je zařízení připojeno k Internetu přes Wi-Fi síť, uzamčeno a zároveň připojeno k nabíjení. Zároveň je také možné si inicializaci zálohy vynutit manuálně na zařízení, a to v položce nastavení a subkategorii iCloud.
6.3.2.
Metodologie útoku na službu iCloud
iCloud API představuje rozhraní pro komunikaci mezi iOS zařízením a iCloud úložištěm, které není veřejně známo. Z toho důvodu je nutné využít komplexního útoku za účelem analýzy a extrakce komunikační protokolů. Tento útok se skládá z několika kroků, které jsou dále popsány. K provedení tohoto útoku je nutné získat iOS zařízení, které bylo Jailbreaknuté a umožnuje nainstalování aplikace Open SSH. Následně je nutné využít Proxy server k Man-in-the-middle útoku (MITM), který slouží k monitorování a dešifrování komunikace mezi iOS zařízením a iCloud servery. Jednou z možností Proxy serveru je využití aplikace Fiddler, kterou je nutné nainstalovat na lokální počítač využívaný k útoku. V aplikaci je nutné povolit připojení z jiných zařízení k serveru, jak je možné vidět níže.
39
Obrázek 18: Konfigurace připojení jiných zařízení k Proxy serveru
Dále je nutné server nastavit tak, aby HTTPS komunikace byla monitorována a navíc i dešifrována, jak je možné vidět na dalším obrázku.
40
Obrázek 19: Konfigurace monitorování HTTPS komunikace a její dešifrování
41
Posledním krokem konfigurace na straně Proxy serveru je exportování certifikátu, který je nutné nahrát do zařízení s využitím aplikace Apple Configurator na Mac OS X zařízení tak, aby se server jevil jako důvěryhodný a bylo možné dešifrovat HTTPS komunikaci mezi iOS zařízením a iCloud servery. Certifikát, nahraný v zařízení, je uložen do Keychain uložiště v podobě záznamu SQLite databáze. Na zařízení je také nutné nastavit Proxy Wi-Fi připojení k vytvořenému Proxy serveru pomocí IP adresy a portu, což nám umožní monitorovat a dešifrovat veškerou příchozí a odchozí síťovou komunikaci s iCloud servery. Toto řešení nám umožní monitorovat komunikaci při vytváření záloh, získávání informací o iCloud účtu či zálohách a komunikaci při získávání dalších dat. Pokud bychom chtěli navíc zachytit komunikaci i při obnově zařízení z iCloud zálohy, tak je nutná další konfigurace na zařízení. Obnova zařízení totiž probíhá v době, kdy zařízení neobsahuje Root certifikát našeho Proxy serveru, a tak není možné HTTPS komunikaci dešifrovat. Keychain je možné nalézt na zařízení v úložišti /var/Keychains ve formě souboru, a to pod názvem keychain-2.db. Tento soubor je nutné zkopírovat ze zařízení tak, aby ho bylo možné využít těsně před tím, něž je zařízení obnovováno z iCloud zálohy. Následně je nutné smazaní iOS zařízení, reset všech nastavení v něm a restart zařízení. Zařízení, které je prvně spuštěno po smazání všech dat vyžaduje jeho nastavení v několika standardních krocích. Než je zařízení plně nastaveno, je nutné zařízení přepnout do DFU módu. V DFU módu je možné aplikovat Boot ROM exploity, aplikovatelné pro iOS zařízení využívající čip A4 či dřívější verzi tohoto čipu, za účelem nahrání upraveného systému Ramdisku. Po úspěšném nahrání Ramdisku je možné přistoupení k souborovému systému zařízení a následnému nahrazení souboru keychain-2.db v zařízení. Pokud byl Keychain soubor úspěšně nahrazen, je nutné opustit DFU mód a znovu restartovat zařízení. Na závěr je nutné se vrátit zpět k prvotnímu nastavení zařízení a nastavit Proxy Wi-Fi připojení k vytvořenému Proxy serveru pomocí IP adresy a portu, a obnovit zařízení z iCloud zálohy. Při obnově zařízení z iCloud zálohy už je možné znovu monitorovat a dešifrovat veškerou příchozí a odchozí síťovou komunikaci s iCloud servery.
42
6.3.3.
Komunikační protokoly služby iCloud
Komunikační protokoly služby iCloud jsou plně závislé na Apple ID a heslu, které jsou nutné k získání hlavičky HTTP protokolu k následné autentizaci. Tyto protokoly převážně využívají technologii Google Protocol Buffers, která slouží k serializaci strukturovaných dat přenášených v rámci HTTP protokolu. Soubory iCloud zálohy jsou rozdělené do několika částí, které jsou uchovávány v úložištích třetích stran, jako jsou Amazon a Microsoft. Naproti tomu informace o jednotlivých částech a jejich umístění v úložištích, šifrovací klíče a požadavky na tyto části jsou získávány prostřednictvím serverů Apple. [1]
Obrázek 20: Struktura souboru ze zálohy iCloud [1] 43
6.3.3.1.
Inicializace
Prvotní komunikace iOS zařízení se službou iCloud zahrnuje inicializaci za pomocí GET požadavku s URL http://setup.icloud.com/configuration/init?context=settings tak, jak můžeme vidět na ukázce kódu níže.
GET https://setup.icloud.com/configurations/init?context=settings HTTP/1.1 Host: setup.icloud.com Proxy-Connection: keep-alive Accept: */* Accept-Encoding: gzip, deflate Cookie: NSC_q06-tfuvqtfswjdf=ffffffff12a46fe645525d5f4f58455e445a4a422971 Accept-Language: en-us X-MMe-Country: GB X-MMe-Client-Info:
OS;6.1.6;10B500>
Connection: keep-alive User-Agent: Settings/1.0 CFNetwork/609.1.4 Darwin/13.0.0
V případě, že je požadavek validní a vše proběhlo v pořádku, služba iCloud vrací jako odpověď HTTP 200 s obsahem ve formátu Plist, který obsahuje všechny validní požadavky, které můžeme na službu zaslat. Mezi tyto možné požadavky patří vytvoření nového iCloud účtu, autentizace, přihlášení, aktivace a mnohé další. V ukázce kódu níže je možné vidět pár vybraných položek z tohoto Plistu a v příloze C této práce je možné zhlédnout plnou verzi tohoto Plistu.
urls newAccountUI <string>https://setup.icloud.com/setup/create_account_ui loginOrCreateAccount <string>https://setup.icloud.com/setup/login_or_create_account ... authenticate <string>https://setup.icloud.com/setup/authenticate/$APPLE_ID$
44
6.3.3.2.
Autentizace
V rámci komunikace s iCloud servery je nutná nejprve autentizace, a to za pomocí Apple ID a hesla. S využitím těchto údajů je možné vytvořit textový řetězec, který je vstupem pro funkci Base64, jejímž výstupem je část autorizační hlavičky HTTP protokolu ve formátu Basic Base64(AppleID:password). HTTP požadavek je typu GET a využívá URL https://setup.icloud.com/setup/authenticate/AppleID. V případě úspěšné autentizace je vrácena odpověď z iCloud serveru obsahující data ve formátu Plist. Tato data obsahují položky dsPrsID a mmeAuthToken, které slouží pro další komunikaci s iCloud serverem. Alternativní
možnost
je
využít
HTTP
požadavek
typu
POST
a
URL
https://setup.icloud.com/setup/login_or_create_account s využitím stejné hlavičky jako v předchozím případu. V případě neúspěšné autorizace je vrácena v obou případech odpověď HTTP 401.
6.3.3.3.
Uživatelské nastavení
Při úspěšné autentizaci je možné získat podrobné informace o uživatelském účtu a nastavením
prostřednictvím
požadavku
https://setup.icloud.com/setup/get_authentication_settings
POST
na
adresu
s autorizačním
hlavičkou
využívající položky dsPrsID a mmeAuthToken, získané v rámci autentizace.
Finální
formát autorizační hlavičky pak využívá formát Basic Base64 (dsPrsID:mmeAuthToken). V rámci odpovědi je opět zaslán obsah ve formátu Plist, který je možné podrobněji prozkoumat v příloze D této práce. V příloze je možné vidět informace o iCloud účtu a jeho nastavení, datové třídy a jejich odkazy. V neposlední řadě je nutné zmínit, že obsahem je i nový autentizační token mmeAuthToken, který je nutné využít při tvorbě autorizační hlavičky v rámci další komunikace s iCloud serverem.
6.3.3.4.
Zálohy iOS zařízení
V odpovědi získané v rámci požadavku na uživatelské nastavení byl zaslán obsah ve formátu
Plist.
Z tohoto
com.apple.Dataclass.Backup,
obsahu
je
která
nutné obsahuje
získat
položku
URL
s klíčem
https://p25-
mobilebackup.icloud.com:443. Tuto URL můžeme dále využít k získání informací o zálohách iOS zařízeních na službě iCloud. Výsledný formát adresy GET požadavku je 45
následující: https://p25-mobilebackup.icloud.com:443/mbs/$dsPrsID$. Zároveň je také nutné zaslat novou autorizační hlavičku v novém formátu, a to s využitím nově zaslaného autentizačního tokenu mmeAuthToken, získaného v odpovědi na požadavek uživatelského nastavení. Výsledný formát této hlavičky je následující: X-MobileMeAuthToken Base64(dsPrsID:mmeAuthToken). V rámci odpovědi je zaslán list všech unikátních identifikátorů záloh v binárním formátu Google Protocol Buffers. [1, 7]
Obrázek 21: HTTP odpověď obsahující informace o zálohách na službě iCloud
Jak je možné vidět na obrázku výše, data nejsou na první pohled čitelná, a tak je nutné tato data nejprve dekódovat. Bohužel, k dekódování těchto dat je nutné využít soubor obsahující formát těchto dat. Tento soubor je obvykle uložen s příponou .proto. V tomto případě ale tyto soubory nevlastníme, jelikož se snažíme tuto komunikaci odhalit s pomocí reverzního inženýrství. Jedinou možností je tak manuální snaha o odvození tohoto souboru přímo z binárních dat s využitím dokumentace o kódování dat Google Protocol Buffers. 46
Data začínají hexadecimální hodnotou 0x0A reprezentované v binární podobě jako 0000 1010. Nejvýznamnější bit, označován jako „most significant bit“ (MSB), je v tomto případě ten první a je možné ho nyní ignorovat. Poslední tři bity reprezentují typ dat tzv. WIRE_TYPE. V našem případě je hodnota tohoto typu 010, tedy 2. Hodnota 2 reprezentuje typ dat označovaný jako „Length-delimited“ využívaný pro textové, bajtové a některé další typy dat, tak jak je možné vidět na obrázku níže.
Obrázek 22: Typy dat využívané při kódování
Pokud provedeme bitový posun vpravo o tři bity, tak je možné získat hodnotu určující pořadí aktuálně zpracovávané položky v rámci souboru .proto. Tato hodnota je také označované jako „Field number“ nebo „Tag”. V tomto případě je tato hodnota rovna jedné, což určuje, že se jedná o první položku. Následující bajt 0x0A udává délku 10 bajtů, které v tomto případě uchovávají textovou hodnotu 8289572381, reprezentující již dříve získaný identifikátor dsPrsID. Dva bajty následující ihned za dsPrsID identifikátorem mají hodnoty 0x12 a 0x14. S využitím stejného postupu je možné zjistit, že další položka je také typu 2 s pořadím 2 v souboru .proto a její celková délka je 20 bajtů. Pokud se podíváme na těchto 20 bajtů, tak je možné zjistit, že data se nejeví jako textová data, ale spíše jako bajtová reprezentace dat. Podrobnějším zkoumáním je možné zjistit, že tyto jednotlivé bajty udávají identifikátor (E55953E2C69B4D26C11467C42C18E0F35978E4AF) naší zálohy uložené v iCloud úložišti.
47
V rámci techniky reverzního inženýrství je možné odvodit datové typy, hodnoty a předpokládaný význam dat získaný v odpovědi z iCloud serveru. V ukázce kódu níže je vidět odvozený formát souboru .proto, který obsahuje dsPrsID a identifikátor zálohy.
package icloud; message Device { required string dsPrsID = 1; repeated bytes udids = 2; optional bool unknown = 3; }
Získané identifikátory (udids) záloh je možné využít k získání podrobnějších informací
za
pomocí
GET
požadavku
ve
formátu
https://p25-
mobilebackup.icloud.com:443 /mbs/$dsPrsID$/$BackupUDID$. Odpověď serveru opět využívá Google Protocol Buffers a výsledný odvozený formát obsahuje identifikátor zálohy spolu s detailními informacemi, které je možné vidět níže.
message Device { required bytes udid = 1; required int64 fullSize = 2; repeated Backup backup = 3; required DeviceInfo device = 4; required int64 time = 5; } message DeviceInfo { required string deviceClass = 1; required string productType = 2; required string serialNumber = 3; required string deviceColor = 4; required string hardwareModel = 5; required string marketingName = 6; optional string idk = 7; }
48
message Backup { optional uint32 snapshotID = 1; optional uint64 size = 2; optional uint64 lastModified = 3; optional BackupInfo backupInfo = 5; optional uint64 committed = 6; } message BackupInfo { optional string DeviceName = 1; optional string ProductVersion = 2; optional string BuildVersion = 3; optional uint32 KeybagID = 4; optional bytes KeybagUUID = 5; optional int32 BackupReason = 6; optional int32 BackupType = 7; }
Informace o záloze poskytují informace o datu poslední modifikace a nahrání na úložiště, typ zálohy, celkovou velikost, název a typ zařízení, model, verzi iOS, sériové číslo a další. S využitím získaného identifikátoru snapshotID je možné získat list všech souborů uložených ve vybrané záloze. Tento list je možné získat za pomocí GET požadavku
s URL
https://p25-mobilebackup.icloud.com:443
/mbs/$dsPrsID$/$BackupUDID$/listFiles?offset={$offset$}&limit={$limit$}.
Výslednou
odpověď je nutné dekódovat z binární podoby s využitím odvozeného formátu, který je možné vidět v ukázce níže.
message File { required bytes fileName = 1; required string domain = 2; required string path = 3; optional bytes altFileName = 4; required int32 fileSize = 5; optional FileInfo info = 6; required int64 date = 7; optional bool bool = 9; }
49
Získaná data o každém souboru ze zálohy obsahují informace o názvu souboru a jeho doméně, umístění v iOS, alternativní název, celkovou velikost, datum vytvoření a další informace. S využitím těchto informací je možné filtrovat a limitovat data, která je nutné stáhnout z úložiště. Pro každý soubor, který chceme stáhnout z úložiště, je nejprve nutné získat autentizační klíč. Tento klíč je možné získat zasláním POST požadavku s URL https://p25-mobilebackup.icloud.com:443 /mbs/$dsPrsID$/$BackupUDID$/$snapshotID$/getFiles
na
server.
V těle
tohoto
požadavku je nutné uvést list názvů souborů, a to v binární podobě za pomocí Google Protocol Buffers. Odpovědí serveru je list autentizačních klíčů spolu s informací o kontrolním součtu. Tyto klíče jsou dále využívané k získání povolení ke stáhnutí souboru z úložiště spolu s adresou odkazující na tento soubor v datovém uložišti. Soubor stažený z úložiště je šifrovaný a k jeho dešifrování je nutné získat klíč prostřednictvím
GET
požadavku
s URL
https://p25-mobilebackup.icloud.com:443
/mbs/$dsPrsID$/$BackupUDID$/getKeys. V rámci odpovědi je vrácen list klíčů obsahující Keybag a passcode. Klíč, označovaný jako Keybag, je možné dešifrovat s využitím klíče passcode a využít k dešifrování stažených souborů zálohy iCloud.
50
7. Obnova dat z SQLite databáze 7.1. Specifikace Obnova smazaných dat z SQLite databází se stává často využívanou technikou extrakce důležitých dat z iOS zařízení, a to zejména kvůli hojnému využívání tohoto typu databáze v nativních i externích aplikacích na platformách iOS či Android, ale i mimo ně. Tato smazaná data mají velkou hodnotu pro forenzní specialisty i uživatele samotné. Abychom získali smazaná data z této databáze, je nutné porozumět interní struktuře SQLite databáze a jejím mechanizmům.
7.2. Struktura a nastavení SQLite databáze Každá SQLite databáze je rozdělena do několika stránek o stejné velikosti, které tvoří strukturu binárního stromu využívanou k uložení dat ve formě indexů či tabulek. Stránky v databázi mají velikost mezi 519 a 65536 bajty, přičemž velikost je vždy druhou mocninou a je uložená ve formátu big endian. Indexy jsou uložené v příslušných indexových stránkách binárního stromu, tak jako je obsah tabulek uložen v tabulkových stránkách binárního stromu. Každá tabulka a index v databázovém schématu má přiřazenou právě jednu tabulkovou a indexovou stránku z binárního stromu. Binární strom je obecně rozdělen na jednu kořenovou stránku, několik vnitřních a listových stránek tak, jak můžeme vidět na obrázku Obrázek 23: Struktura binárního strom SQLite databáze. Vnitřní stránky uchovávají klíče a reference na své potomky v binárním stromu. Stránky, označované jako listy, uchovávají klíče a data. Díky této struktuře je možné efektivně vyhledávat data s využitím předem specifikovaného klíče a s využitím definovaných referencí. Klíče, uchovávané ve stránkách označovaných jako tabulkové, reprezentují jednoznačné identifikátory pro řádky tabulky, uložené v dané stránce binárního stromu. Klíče a ukazatelé vnitřních stránek, klíče a data tabulkových listových stránek jsou uchovávány v umístěních stránky označovaných jako buňky. [8, 15]
51
Obrázek 23: Struktura binárního strom SQLite databáze [15]
Databáze může obsahovat i několik dalších typů stránek podle využití. Mezi tyto typy patří stránky označované jako overflow, freelist, pointer map a locking, které mohou, ale nemusí být obsaženy v databázi. První stránka každé SQLite databáze obsahuje hlavičku databáze o velikosti 100 bajtů. Každá databázová hlavička začíná sekvencí bajtů reprezentujících textový řetězec „SQLite format 3“ ukončený 0x00 bajtem. Hlavička dále obsahuje velikost jedné stránky reprezentovanou dvěma bajty ve vzdálenosti 16 bajtů od počátku. Počet stránek v databázi, číslo první stránky označované jako freelist, počet stránek označovaných jako freelist a číslo poslední kořenové stránky je stanoveno čtyřmi bajty ve vzdálenostech 28, 32, 36 a 52 bajtů od počátku. Pokud je číslo poslední kořenové stránky větší než nula, tak se jedná o databázi s nastavení auto-vacuum, jinak se jedná o non-auto-vacuum. Toto nastavení představuje velmi důležitou informaci s ohledem na obnovu smazaných dat z SQLite databáze. Pokud je databáze nastavena jako nonauto-vacuum, tak velikost databáze zůstává neměnná, i když dojde ke smazání dat v databázi. Nepoužívané stránky jsou tak označeny jako freelist, což umožňuje jejich použití pro nově přidávaná data. Naproti tomu při nastavení auto-vacuum, může dojít ke změně velikosti databáze. Smazání dat v takto nastavené databázi může způsobit zavolání interní příkazu (označován jako VACUUM příkaz) k optimalizaci databázového 52
prostoru. Během této optimalizace může být celá databáze přestavěna či zmenšena a v důsledku toho mohou být smazaná data permanentně odstraněna z databázového souboru. Nastavení auto-vacuum je dále členěné na mód úplný (označovaný jako „full“) či postupný (označovaný jako „incremental“). Při úplném módu jsou stránky označované jako freelist přesunuté na úplný konec databázového souboru, který je následně zkrácen při každém transakčním komitu, což má za následek odstranění stránek. Pokud je nastaven mód postupný, tak databáze využívá další informace k tomu, kdy provést optimalizace, které se již neprovádí při každém transakčním komitu.
7.2.1.
Formát stránky binárního stromu
Formát interní či listové stránky binárního stromu obsahuje důležité informace, jako jsou databázová hlavička, hlavička stránky binárního stromu, pole ukazatelů na buňky ve stránce, nepřiřazenou oblast, oblast k uchování buněk a rezervovaný region obsahující obvykle nulové hodnoty. Pole ukazatelů na buňky obsahuje číselné ukazatele o délce dvou bajtů, které udávají vzdálenost prvního bajtu buňky od počátku stránky binárního stromu. Oblast k uchování buněk obsahuje jednotlivé buňky ukládané směrem od konce stránky tak, aby se pole ukazatelů mohlo co nejvíce rozšiřovat. Oblast mezi posledním ukazatelem na buňku a první buňkou je označován jako nepřiřazená oblast.
Obrázek 24: Struktura stránky binárního stromu [15]
53
7.2.2.
Hlavička stránky binárního stromu
Hlavička stránky binárního stromu obsahuje důležité informace o stránce, jako jsou typ stránky (bajt 0), vzdálenost od počátku stránky k oblasti označované jako freeblock (bajt 1 až 2), počet buněk na stránce (bajt 3 až 4), vzdálenost od počátku stránky k prvnímu bajtu oblasti buněk (bajt 5 až 6), počet fragmentovaných volných bajtů v oblasti buněk (bajt 7) a ukazatel na poslední buňku s nejvyšší hodnotou klíče (bajt 8 až 11). Typ stránky je specifikován speciální jednobajtovou hodnotou reprezentující vnitřní stránku obsahující indexy (0x02), vnitřní stránku obsahující tabulku (0x05), listovou stránku obsahující indexy (0x0A) nebo listovou stránku obsahující tabulku (0x0D). Oblast označovaná jako freeblock reprezentuje nepřiřazenou oblast uvnitř oblasti k uchování buněk v rámci stránky binárního stromu o minimální velikosti čtyř bajtů. Více oblastí tohoto typu je pospojováno pomocí dvoubajtové číselné hodnoty na začátku každé z těchto stránek, která udává vzdálenost k další oblasti typu freeblock v rámci stránky binárního stromu. Tato hodnota může být i nulová v případě posledního výskytu oblasti v rámci sledované stránky. Další dva bajty na pozici 3 až 4 udávají číselnou hodnotu reprezentující celkovou velikost (včetně čtyřbajtové hlavičky) oblasti freeblock. Volné fragmentované bajty v oblasti buněk patří do speciální kategorie nepřiřazené oblasti o maximální velikosti tří bajtů.
7.2.3.
Stránka typu list binárního stromu
Důležitá data SQLite databáze jsou obvykle uložená ve stránce typu list binárního stromu. Obsah této stránky je definován její hlavičkou, tak jako v případě každé stránky, obsahující informaci o typu, počtu bajtů k oblasti prvního freebloku, počtu buněk, počtu bajtů k oblasti buněk a celkový počet volných bajtů. Oblast bezprostředně umístěná za hlavičkou stránky obsahuje pole ukazatelů na buňky ve stránce. Každá z buněk ve stránce obsahuje právě jeden záznam z SQLite tabulky. Formát buňky obsahuje nejprve informaci o celkovém počtu bajtů reprezentujících tzv. payload, a to včetně bajtů označovaných jako overflow. Tato hodnota je uložená za ve formátu Varint. Druhá položka v buňce reprezentuje číslo řádku, označované jako „row id“, ve formátu varint. Posledními dvěmi položkami v buňce jsou samotný payload a čtyřbajtová číselná 54
hodnota reprezentující číslo první stránky označované jako overflow. Grafickou reprezentaci formátu buňky je možné vidět v tabulce níže.
Celkový
počet
reprezentující
bajtů
payload
ve
formátu Varint
Číslo ve
řádku formátu
Číslo Payload
první
stránky
označované jako overflow (4 bajty)
Varint
Tabulka 3: Formát buňky na stránce typu list binárního stromu
7.2.4.
Formát Varint
Formát Varint reprezentuje číselnou hodnotu o variabilní délce využívající k uložení dat v binární podobě statické Huffmanovo kódování 64 bitových čísel v dvojkovém zobrazení (two´s complement). Výhodou tohoto kódovaní je, že potřeba adresového prostoru je mnohem menší při ukládání malých celých čísel. Formát Varint využívá k uložení čísel mezi jedním až devíti bajty. K určení bajtů, které jsou součástí uloženého čísla, a které již nejsou jeho součástí, slouží nejvíce významný bit, označovaný jako most significant bit (MSB). Bajty, které jsou stále součástí uloženého čísla, mají MSB nastavený, a to s výjimkou posledního bajtu. K rekonstrukci čísla se využívá pouze sedm bitů z prvních 8 bajtů a 8 bitů z devátého bajtu, které jsou sloučeny za účelem vytvoření finální podoby čísla v binární podobě. V ukázce kódu níže je možné vidět úplnou implementaci funkce v jazyce C#, která využívá pole bajtů a index v něm jako vstupní parametry. Index udává vzdálenost, od které funkce začíná rekonstruovat číselnou hodnotu ve formát Varint. Výsledkem této funkce je dvourozměrné pole typu Int64 (nebo long), uchovávající vypočítanou hodnotu čísla uloženého ve formátu Varint na indexu nula a celkový počet bajtů využívaných touto hodnotou na indexu jedna.
55
public static Int64[] ParseVarInt(byte[] varIntArray, long offset) { bool complete = false; long pos = offset; long result = 0; while (pos < (offset + 9) && !complete) { //MSB set = 1 if (GetBit(varIntArray[pos], 0) && pos < (offset + 8)) { long value = varIntArray[pos] & 127; result <<= 7; result += value; } else if (GetBit(varIntArray[pos], 0) && pos == (offset + 8)) { result <<= 8; result += varIntArray[pos]; complete = true; } else { long value = varIntArray[pos] & 127; result <<= 7; result += value; complete = true; } pos++; } if (!complete) { throw new Exception("VarInt parsing error ..."); } return new long[] { result, (long)(pos - offset) }; }
56
7.2.5.
Datový obsah buňky
Datový obsah buňky binárního stromu, označovaný jako payload, je vždy umístěn uvnitř samotné buňky ve formátu záznamu, je rozdělen na hlavičku a samotný obsah. Hlavička definuje posloupnost dat shodných se sloupci z SQLite tabulky. Jednotlivé sloupce jsou definovány s využitím tzv. sériových typů, které slouží k identifikaci typu dat. Hlavička záznamu Sériový Velikost
typ pro
hlavičky
první
ve formát
sloupec
Varint
ve formát Varint
Obsah záznamu Sériový
…
typ pro N
Hodnota
sloupec
pro první
ve formát
sloupec
Hodnota …
pro N sloupec
Varint Tabulka 4: Formát záznamu
Hlavička záznamu je složena z informace o celkové velikosti a výše zmíněného sériového typu pro každý sloupec tabulky ve formátu Varint. Sériové typy jsou definovány jako čísla od nuly a výše a jejich výčet je možně vidět v tabulce 5. Hodnota NULL je reprezentována typem nula, číselné hodnoty jsou reprezentovány typem jedna až 6 v závislosti na velikosti a hodnoty s desetinou čárkou jsou definovány typem 7. Speciální booleanovské hodnoty nula a jedna využívají typ 8 a 9. Poslední dva speciální typy slouží k definování hodnot BLOB a textových řetězců. Aby hodnota mohla být určena jako BLOB typ, tak musí být sudá a větší než dvanáct. Naproti tomu pro hodnotu typu textového řetězce platí, že musí být lichá, větší než třináct. Zbývající typy 10 a 11 nejsou využívány.
57
Serial Type
Content Size
Meaning
0
0
Value is a NULL.
1
1
Value is an 8-bit twos-complement integer.
2
2
Value is a big-endian 16-bit twoscomplement integer.
3
3
Value is a big-endian 24-bit twoscomplement integer.
4
4
Value is a big-endian 32-bit twoscomplement integer.
5
6
Value is a big-endian 48-bit twoscomplement integer.
6
8
Value is a big-endian 64-bit twoscomplement integer.
7
8
Value is a big-endian IEEE 754-2008 64-bit floating point number.
8
0
Value is the integer 0. (Only available for schema format 4 and higher.)
9
0
Value is the integer 1. (Only available for schema format 4 and higher.)
10,11 N≥12 and even
Not used. Reserved for expansion. (N-12)/2
Value is a BLOB that is (N-12)/2 bytes in length.
N≥13 and odd
(N-13)/2
Value
is
a
encoding and
string
in
(N-13)/2
the text bytes
in
length. The nul terminator is not stored. Tabulka 5: Sériové typy ve formátu záznamu [29, 33]
58
7.3. Implementace algoritmů pro extrakci smazaných záznamů V rámci této práce byly naimplementovány dvě verze algoritmů zabývajících se problematikou extrakce smazaných záznamů z SQLite databáze. První algoritmus je napsán v jazyce C a umožňuje získání informací o SQLite databázi, a to včetně definování nepřiřazeného prostoru, označovaného jako „unallocated space“, ve kterém jsou uchovávány smazané záznamy.
Obrázek 25: Výstup z prvního algoritmu
Na obrázku výše můžeme vidět výstup z programu využívající první algoritmus. Výstupem tohoto programu jsou nejprve informace o databázi, které byly získány na základě analýzy hlavičky SQLite databáze. Dále jsou zobrazeny informace o analýze jednotlivých stránek databáze. Nejprve je zobrazena informace o prvním a posledním bajtu stránky v rámci celé databáze, které jsou v ukázkovém případě 8192 a 12287. Dále je zobrazena informace o typu stránky, která je typu list (0x0D). Offset k prvnímu bajtu struktury bajtů označované jako freeblock je nula, což nás informuje, že v dané stránce se nenachází žádný freeblock. Na ukázkové stránce bylo také nalezeno devět buněk 59
a nula fragmentovaných volných bajtů v poli buněk. První buňka se nachází ve vzdálenosti 3821 bajtů od počátku stránky, což můžeme také vyhodnotit jako pozici 12013 od počátku databáze. Nepřiřazený prostor o celkové velikosti 3795 bajtů, označovaný jako „unallocated space“, je možné nalézt ve vzdálenosti 26 bajtů od počátku. S využitím těchto informací je možné využít k otevření SQLite databáze prakticky jakýkoliv hexadecimální editor a lokalizovat všechny nepřiřazené prostory. V těchto prostorech je možné nalézt často i zcela neporušené záznamy, které byly v minulosti smazány. Druhý algoritmus je napsán v jazyce C# a je již mnohem složitější. Tento algoritmus je implementován za účelem extrakce smazaných SMS zpráv z SQLite databáze, které jsou hojně využívané na všech iOS zařízeních. Algoritmus je možné nakonfigurovat, tak aby byl kompatibilní s různými verzemi SMS databází na iOS zařízeních. Konfigurace je implementovaná v podobě XML souboru s názvem RecoverySignature.xml, který je kompletně načten ze stejného umístění, jako aplikace samotná. Tento XML soubor obsahuje klíčový element s názvem signature, který obsahuje atributy pro name, database a table. Atribut name slouží pro identifikaci domény na iOS zařízení, ve které se obvykle nachází daná databáze. Název databázového souboru je specifikován v rámci atributu database. Poslední atribut s názvem table identifikuje tabulku z definovaného databázového souboru. V rámci elementu signature je možné nalézt jednotlivé vzory pro smazané záznamy. Tyto vzory jsou definovány v rámci elementu header, který se nachází uvnitř elementu pattern. Každý z vzorů navíc obsahuje element version sloužící k identifikaci iOS verze, ke které vzor patří. Všechny tyto elementy je možné přehledně vidět v ukázce kódu níže.
60
<signatures> <signature name="HomeDomain" database="sms.db" table="MESSAGE"> <pattern> [0];[85];[-2];[1,8,9];[0,-2];[1,2,3,4,5,6,8,9];[0,-2] … <pattern> [0];[85];[-2];[1,8,9];[0,-2];[1,2,3,4,5,6,8,9];[0,-2] …
Obrázek 26: Konfigurační soubor algoritmu pro extrakci smazaných SMS zpráv
Element header obsahuje pole sériových typů SQLite databáze, které je vytvořeno na základě sloupců tabulky. V ukázkovém případě je možné jako první položku vzoru vidět sériový typ 0, definující primární klíč tabulky, který je databází při smazání nulován. Dalším sériovým typem v poli je hodnota 85 reprezentující sloupec s názvem guid, jehož délka je vždy 36 bajtů. Sériový typ s hodnotou -2 slouží k reprezentaci textového řetězce o libovolné délce. V tomto případě je textovým řetězcem hodnota ze sloupce se jménem text, obsahující samotný obsah SMS zprávy. Další sériové typy, použité v ukázce, jsou přehledně vysvětleny v tabulce níže. 61
Sériový typ
Význam
0
NULL hodnota
1, 2, 3, 4, 5, 6
Číselná hodnota využívající od jednoho až po osm bajtů
-1
BLOB
-2
Textový řetězec o libovolné délce
7
Desetinná číselná hodnota
8
Číselná hodnota 0 nebo FALSE
9
Číselná hodnota 1 nebo TRUE
85
Textový řetězec o délce 36 znaků (85-13)/2 = 36 Tabulka 6: Seznam sériových typů použitých v ukázce XML konfiguračního souboru
SQLite databáze může smazat některé zprávy samovolně, a to například i při přesunu dat z jednoho místa databáze na jiné v rámci optimalizačních technik. Často se stane, že v nepřiřazeném prostoru je možné nalézt i zprávy, které jsou zároveň prezentovány i jako nesmazané. Z tohoto důvodu algoritmus provádí na závěr své činnosti i optimalizační část, která slouží pro porovnání všech získaných záznamů z nepřiřazeného prostoru s nesmazanými záznamy. Výstupem tohoto algoritmu jsou pouze SMS zprávy, které není možné zobrazit standardním postupem. Na obrázku níže je možné vidět uživatelské rozhraní implementovaného programu využívající výše popsaný algoritmus pro extrakci smazaných SMS zpráv. Získání smazaných dat v rámci programu je možné pomocí dvou jednoduchých kroků nakonfigurovat a spustit. Nejprve je nutné vybrat databázový soubor prostřednictvím tlačítka s názvem „Open file…”, které následně zobrazí dialogové okno pro výběr databázového souboru SQLite databáze. Program umožní vybrat pouze soubory se standartní koncovkou pro soubor typu SQLite databáze (.db nebo .sqlite). Dalším krokem je již spuštění algoritmu za pomocí tlačítka s názvem „Extract deleted SMS“. Po dokončení práce algoritmu jsou zobrazeny všechny smazané SMS zprávy a jejich datum v centrálním textovém panelu tak, jak je ilustrováno na obrázku níže.
62
Obrázek 27: Obnova smazaných SMS zpráv
63
8. Shrnutí výsledků a závěr V prvních kapitolách této práce byla nejprve souhrnně popsána platforma operačního systému iOS za účelem definice a návrhu různých možností extrakce dat. Data, která je možné z iOS operačního systému extrahovat, byla následně podrobně popsána v další kapitole této práce. Hlavní část této práce se zabývá samotnou extrakcí dat z iOS zařízení, která je podle použitých metod rozdělena na logickou extrakci dat, fyzickou extrakci dat a extrakci dat za pomocí datového úložiště iCloud. V rámci logické extrakce dat je přehledně popsána problematika záloh aplikace iTunes, které uchovávají velké množství uživatelských dat. Zálohy aplikace iTunes jsou automaticky vytvářeny na počítačích, ke kterým bylo připojeno iOS zařízení, a často na těchto počítačích zůstávají po dlouhou dobu bez povšimnutí. Formát těchto záloh je povětšinou nečitelný pro běžné uživatele, jelikož je využíván hašovací algoritmus pro názvy souborů ze zálohy. Aby bylo možné získat data z těchto záloh, je nutné využít buďto komerčních produktů nebo mít detailní znalost formátů a postupů, které tyto zálohy využívají. V práci jsou dále navrhnuty a analyzovány produkty, které je možné využít ke čtení iTunes záloh, a to i v případě šifrovaných záloh. Jedním z těchto produktů je i komerční program SmartPhone Data Recovery, který byl vytvořen autorem práce s využitím znalostí získaných při tvorbě této práce. Fyzická extrakce dat zahrnuje proces získání dat s využitím služeb běžících na pozadí spuštěného systému iOS. Tyto služby byly v nedávné době zveřejněny, ale nejsou společností
Apple
úmyslně
dokumentovány
S využitím
externí
knihovny
libimobiledevice je možné získat ze zařízení velké množství dat, a to i bez znalosti hesla k zařízení, což bylo demonstrováno v rámci ukázek kódu pro některé z popisovaných služeb. Poslední metodou pro extrakci dat, která je popsána a navrhována v této práci, je metoda extrakce dat ze záloh uložených na úložišti iCloud. Úložiště iCloud nabylo na nevídané popularitě a počet aktivních uživatelů se od prvního uvedení rapidně navýšil. Komunikace mezi zařízením a službou iCloud není úmyslně nikde dokumentována společností Apple, a proto je nutné využít komplexního útoku a reverzního inženýrství za účelem odhalení šifrované komunikace této služby. Během tohoto útoku jsou komunikační protokoly této služby úspěšně dešifrovány. Dešifrovaná 64
komunikace poskytla informace o tom, že služba iCloud je z velké míry založena na technologii Google Protocol Buffers. Tato technologie zajišťuje kódování dat, a tak bylo nutné nejprve dekódovat datové formáty. Poslední část této práce se zabývá obnovou smazaných záznamů z SQLite databází, které uchovávají velké množství dat a mají velkou forenzní hodnotu. Formát SQLite databáze na nejnižší úrovni je v této práci podrobně popsán. V rámci této části práce jsou také představeny dva naimplementované algoritmy zabývající se problematickou obnovy dat z SQLite databází. První algoritmus umožňuje identifikaci nepřiřazených prostorů uchovávajících smazané záznamy v jakékoliv SQLite databázi. Druhý algoritmus je představen v podobě Windows aplikace umožňující načtení a analýzu souboru SQLite databáze uchovávající SMS zprávy na všech iOS zařízeních. Hlavním výstupem této aplikace je seznam všech smazaných zpráv, vyskytujících se stále v části databázového souboru, která není dostupná standartní cestou. Vypracování této práce mi umožnilo hlubší porozumění operačního systému iOS a bezpečnosti dat uložených na zařízeních využívajících tento operační systém. Získané zkušenosti z této práce jsou aktivně využívány při realizaci různých softwarových řešení v komerční oblasti i mimo ni.
65
9. Seznam obrázků Obrázek 1: iPhone 3GS [21] ..................................................................................................................... 10 Obrázek 2: SMS SQLite databáze otevřená v programu SQLite Manager .............................. 18 Obrázek 3: Datové typy z aplikačního frameworku Core Foundation a jejich XML ekvivalenty [4] .............................................................................................................................................. 19 Obrázek 4: Umístění iTunes záloh [2] .................................................................................................. 21 Obrázek 5: Složky záloh různých iOS zařízení .................................................................................. 22 Obrázek 6: Hierarchie bezpečnostních klíčů použitých v Data Protection API (iOS4) [31, 32] ...................................................................................................................................................................... 24 Obrázek 7: Správa souborů v rámci iOS aplikace s využitím programu iTunes .................. 26 Obrázek 8: Správa souborů v rámci iOS aplikace s využitím programu iFunBox ............... 26 Obrázek 9: Umístění multimediálních dat na iOS zařízení .......................................................... 31 Obrázek 10: Umístění souboru en_GB-dynamic-text.dat uchovávající slovní výrazy ....... 32 Obrázek 11: Umístění souboru keychain-2.db ................................................................................. 33 Obrázek 12: Umístění souboru notes.sqlite uchovávající poznámky ...................................... 34 Obrázek 13: Umístění souborů uchovávajících data o textových zprávách .......................... 34 Obrázek 14: Umístění souboru History.plist ..................................................................................... 35 Obrázek 15: Práce se soubory uchovávající data o kontaktech ................................................. 36 Obrázek 16: Umístění souboru AddressBookImages.sqlitedb ................................................... 37 Obrázek 17: Umístění souboru call_history.db ................................................................................ 37 Obrázek 18: Konfigurace připojení jiných zařízení k Proxy serveru ....................................... 40 Obrázek 19: Konfigurace monitorování HTTPS komunikace a její dešifrování .................. 41 Obrázek 20: Struktura souboru ze zálohy iCloud [1] ..................................................................... 43 Obrázek 21: HTTP odpověď obsahující informace o zálohách na službě iCloud ................ 46 Obrázek 22: Typy dat využívané při kódování ................................................................................. 47 Obrázek 23: Struktura binárního strom SQLite databáze [15] .................................................. 52 Obrázek 24: Struktura stránky binárního stromu [15] ................................................................. 53 Obrázek 25: Výstup z prvního algoritmu ............................................................................................ 59 Obrázek 26: Konfigurační soubor algoritmu pro extrakci smazaných SMS zpráv ............. 61 Obrázek 27: Obnova smazaných SMS zpráv ...................................................................................... 63
66
10. Seznam tabulek Tabulka 1: Zdroj dat služby File Relay v iOS 2. x ............................................................................. 28 Tabulka 3: Zdroj dat služby File Relay v iOS 7 .................................................................................. 28 Tabulka 4: Formát buňky na stránce typu list binárního stromu ............................................. 55 Tabulka 5: Formát záznamu .................................................................................................................... 57 Tabulka 6: Sériové typy ve formátu záznamu [29, 33] .................................................................. 58 Tabulka 7: Seznam sériových typů použitých v ukázce XML konfiguračního souboru .... 62
67
Reference [1]
Afonin, O.: Cracking and Analysing Apple iCloud backups, Find My iPhone, Document Storage
[online].
2013,
[cit.
2015-04-17],
Dostupné
z
WWW:
http://www.elcomsoft.co.uk/PR/recon_2013.pdf [2]
Apple: About backups in iCloud and iTunes [online]. 2015, [cit. 2015-04-17]. Dostupné z WWW: https://support.apple.com/en-us/HT204136
[3]
Apple: iOS Developer Library [online]. 2015, [cit. 2015-04-17], Dostupné z WWW: https://developer.apple.com/library/prerelease/ios/releasenotes/General/RNiOSSDK-8.2/index.html
[4]
Apple: Property List Programming Topics for Core Foundation [online]. 2015, [cit. 2015-04-17],
Dostupné
z
WWW:
https://developer.apple.com/library/mac/documentation/CoreFoundation/Conc eptual/CFPropertyLists/CFPropertyLists.pdf [5]
Belenko, A.: iOS Forensics – Overcoming iPhone Data Protection [online]. 2011, [cit.
2015-04-17],
Dostupné
z
WWW:
http://www.slideshare.net/andrey.belenko/ios-forensics-overcoming-iphonedata-protection [6]
Belenko, A.: iOS Forensics with Open–Source Tools [online]. 2014, [cit. 2015-0417],
Dostupné
z
WWW:
http://2014.zeronights.org/assets/files/slides/belenko.pdf [7]
Belenko, A.; Sklyarov, D.: Dark and Brick Sides of the iCloud Security [online]. 2012,
[cit.
2015-04-17],
Dostupné
z
WWW:
http://2012.zeronights.org/includes/docs/Belenko%20Sklyarov.pdf [8]
Drinkwater, R.: Carving SQLite databases from unallocated clusters [online]. 2011, [cit.
2015-04-17],
Dostupné 68
z
WWW:
http://forensicsfromthesausagefactory.blogspot.co.uk/2011/04/carving-sqlitedatabases-from.html [9]
Google: Protocol Buffers - Encoding [online]. 2014, [cit. 2015-04-17]. Dostupné z WWW: https://developers.google.com/protocol-buffers/docs/encoding
[10] Hill, J.: SHAttered Dreams – Adventures in BootROM Land [online]. 2013, [cit. 2015-04-17],
Dostupné
z
WWW:
http://conference.hitb.org/hitbsecconf2013kul/materials/D2T1%20%20Joshua%20%27p0sixninja%27%20Hill%20-%20SHAttered%20Dreams.pdf [11] Katalov, V.: Apple iCloud inside out [online]. 2013, [cit. 2015-04-17], Dostupné z WWW: https://deepsec.net/docs/Slides/2013/DeepSec_2013_Vladimir_Katalov__Cracking_And_Analyzing_Apple_iCloud_Protocols.pdf [12] Levin, J.: Mac OS X and iOS Internals To the Apple´s Core. John Wiley & Sons, Inc. Indianapolis, USA, 2013, ISBN 978-1-11805765-0 [13] Miller, Ch.; Blazakis, D.; Zovi, D. D.; aj.: iOS Hacker´s Handbook. John Wiley & Sons, Inc. Indianapolis, USA, 2013, ISBN 978-1-118-204112-2 [14] Oliver, S.: iOS Developer Library [online]. 2012, [cit. 2015-04-17]. Dostupné z WWW: http://appleinsider.com/articles/12/09/17/apple_on_pace_to_sell_1_billion_ios_d evices_by_2015 [15] Pooters, I.; Arends, P.; Moorrees, S.: Extracting SQLite records – Carving, parsing and
matching
[online].
2011,
[cit.
2015-04-17],
Dostupné
z
WWW:
http://sandbox.dfrws.org/2011/foxit/DFRWS2011_results/Report/Sqlite_carving_extractAndroidData.pdf [16] Proffitt, T.: Forensic Analysis on iOS Devices [online]. 2012, [cit. 2015-04-17]. Dostupné
z
WWW:
http://www.sans.org/reading-
room/whitepapers/forensics/forensic-analysis-ios-devices-34092 69
[17] Puscek, D.: Reverse Engineering The iOS Boot Mechanism [online]. 2014, [cit. 2015-04-17],
Dostupné
z
WWW:
http://blog.lightbulbone.com/reverse-
engineering-the-ios-boot-mechanism-part-1/ [18] Přispěvatelé iPhone Wiki, UDID [online]. Media Wiki, 2011-09-04, 2014-10-07 [cit. 2015-04-17], Dostupné z WWW: https://theiphonewiki.com/wiki/UDID [19] Přispěvatelé iPhone Wiki, DFU Mode [online]. Media Wiki, 2009-08-08, 2014-1019 [cit. 2015-04-17], Dostupné z WWW: https://theiphonewiki.com/wiki/UDID [20] Přispěvatelé Wikipedie, IOS [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2008-03-07, 2015-04-17 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/IOS. [21] Přispěvatelé Wikipedie, IPhone 3G [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2008-06-09, 2015-04-17 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/IPhone_3G. [22] Přispěvatelé Wikipedie, IPhone [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2006-05-17, 2015-04-18 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/IPhone. [23] Přispěvatelé Wikipedie, IPod Touch [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2007-09-05, 2015-04-18 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/IPod_Touch. [24] Přispěvatelé Wikipedie, IPad [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2009-12-30, 2015-04-17 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/IPad. [25] Přispěvatelé Wikipedie, Apple Watch [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2015-09-09, 2015-04-16 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/Apple_Watch. 70
[26] Přispěvatelé Wikipedie, Property List [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2006-02-13, 2015-05-29 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/Property_List. [27] Přispěvatelé Wikipedie, Hierarchical File System [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2005-11-01, 2015-02-07 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/Hierarchical_File_System. [28] Přispěvatelé Wikipedie, ICloud [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2011-06-06, 2015-04-14 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/ICloud. [29] Přispěvatelé Wikipedie, SQLite [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2005-09-14, 2015-04-08 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/SQLite. [30] Přispěvatelé Wikipedie, ICloud [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2011-06-06, 2015-04-15 [cit. 2015-04-17], Dostupné z WWW: http://en.wikipedia.org/wiki/ICloud. [31] Sigwald, J.: iPhone Data Protection – Encryption Keys [online]. 2015, [cit. 2015-0417],
Dostupné
z
WWW:
https://code.google.com/p/iphone-
dataprotection/wiki/EncryptionKeys [32] Sigwald, J.; Bédrune, J.: iPhone Data Protection in depth [online]. 2011, [cit. 201504-17],
Dostupné
z
WWW:
http://reverse.put.as/wp-
content/uploads/2011/06/D2T2-Jean-Baptiste-Be%CC%81drune-Jean-SigwaldiPhone-Data-Protection-in-Depth.pdf [33] SQLite: The SQLite Database File Format [online]. 2014, [cit. 2015-04-17]. Dostupné z WWW: http://www.sqlite.org/fileformat.html
71
[34] SQLite:
About
[online].
2014,
[cit.
2015-04-17].
Dostupné
z
WWW:
http://www.sqlite.org/about.html [35] Zdziarski, J.: Apple Confirms Backdoors – Downplays Their Severity [online]. 2014, [cit. 2015-04-17], Dostupné z WWW: http://www.zdziarski.com/blog/?p=3466 [36] Zdziarski, J.: Hacking and Securing iOS Applications – Stealing Data, Hijacking Software, and How to Prevent It. O´Reilly Media, Inc. Sebastopol, CA, USA, 2012, ISBN 978-1-449-31874-1 [37] Zdziarski, J.: Identifying Back Doors, Attack Points, and Surveillance Mechanisms in iOS Devices [online]. 2014, [cit. 2015-04-17], Dostupné z WWW: https://pentest.com/ios_backdoors_attack_points_surveillance_mechanisms.pdf [38] Zdziarski, J.: iOS Forensic Investigative Methods [online]. 2013, [cit. 2015-04-17], Dostupné
z
WWW:
http://www.zdziarski.com/blog/wp-
content/uploads/2013/05/iOS-Forensic-Investigative-Methods.pdf [39] Zdziarski, J.: Running Invisible in the Background in iOS 8 [online]. 2015, [cit. 2015-04-17], Dostupné z WWW: http://www.zdziarski.com/blog/?p=5072
72
Příloha A Práce se službou File Relay a knihovnou libimobiledevice extern "C" __declspec(dllexport) int32_t GetDataFromDevice(char* dumpTmpFolder) { int res = -1; idevice_t dev = NULL; lockdownd_client_t client = NULL; lockdownd_service_descriptor_t service = NULL; file_relay_client_t frc = NULL; idevice_connection_t dump = NULL; const char **sources; //const
char
*default_sources[]
=
{"AppleSupport",
"Network",
"VPN",
"WiFi",
"UserDatabases", "CrashReporter", "tmp", "SystemConfiguration", "Photos", "Caches", "CoreLocation", NULL}; const char *default_sources[] = {"UserDatabases", NULL}; int i = 0; if (idevice_new(&dev, NULL) != IDEVICE_E_SUCCESS) { printf("no device connected?!\n"); goto leave_cleanup; } printf("connecting...\n"); if
(lockdownd_client_new_with_handshake(dev,
&client,
NULL)
!=
&service)
!=
LOCKDOWN_E_SUCCESS) { printf("could not connect to lockdownd!\n"); goto leave_cleanup; } //lockdownd_start_service_with_escrow_bag //if
(lockdownd_start_service(client,
FILE_RELAY_SERVICE_NAME,
LOCKDOWN_E_SUCCESS) { if
(lockdownd_start_service_with_escrow_bag(client,
FILE_RELAY_SERVICE_NAME,
&service) != LOCKDOWN_E_SUCCESS) { printf("could not start file_relay service!\n"); goto leave_cleanup; } if (client) { lockdownd_client_free(client); client = NULL; } if (file_relay_client_new(dev, service, &frc) != FILE_RELAY_E_SUCCESS) {
73
printf("could not connect to file_relay service!\n"); goto leave_cleanup; } if (service) { lockdownd_service_descriptor_free(service); service = NULL; } sources = default_sources;
printf("Requesting"); i = 0; while (sources[i]) { printf(" %s", sources[i]); i++; } printf("\n"); if (file_relay_request_sources(frc, sources, &dump) != FILE_RELAY_E_SUCCESS) { printf("could not get sources\n"); goto leave_cleanup; } if (!dump) { printf("did not get connection!\n"); goto leave_cleanup; } uint32_t cnt = 0; uint32_t len = 0; char buf[4096]; char* dumpTmpFilePath = "dump.cpio.gz";
char* path = addString(dumpTmpFilePath, dumpTmpFolder); FILE *f = fopen(path, "wb"); setbuf(stdout, NULL); printf("receiving "); while
(idevice_connection_receive(dump,
IDEVICE_E_SUCCESS) { fwrite(buf, 1, len, f);
74
buf,
4096,
&len)
==
cnt += len; printf("."); len = 0; } printf("\n"); fclose(f); printf("total size received: %d\n", cnt); res = extract_file(dumpTmpFilePath, dumpTmpFolder);
leave_cleanup: if (frc) { file_relay_client_free(frc); } if (client) { lockdownd_client_free(client); } if (dev) { idevice_free(dev); } return res; }
75
Příloha B Práce se službou House Arrest a knihovnou libimobiledevice extern "C" __declspec(dllexport) int32_t CreateAppFolder(char* folder, char* udid, char* appid) { int result = -1; idevice_t dev = NULL; lockdownd_client_t client = NULL; house_arrest_client_t hac = NULL; house_arrest_error_t res; int i; //DEBUG NO idevice_set_debug_level(0); if (idevice_new(&dev, udid) != IDEVICE_E_SUCCESS) { printf("no device connected?!\n"); goto leave_cleanup; } if
(lockdownd_client_new_with_handshake(dev,
&client,
NULL)
!=
LOCKDOWN_E_SUCCESS) { printf("could not connect to lockdownd!\n"); goto leave_cleanup; } lockdownd_service_descriptor_t service = NULL; if (lockdownd_start_service(client, "com.apple.mobile.house_arrest", &service) != LOCKDOWN_E_SUCCESS) { printf("could not start house_arrest service!\n"); goto leave_cleanup; } if (client) { lockdownd_client_free(client); client = NULL; } if (house_arrest_client_new(dev, service, &hac) != HOUSE_ARREST_E_SUCCESS) { printf("could not connect to house_arrest service!\n"); goto leave_cleanup; } if (service) { lockdownd_service_descriptor_free(service);
76
service = NULL; } res = house_arrest_send_command(hac, "VendDocuments", appid); if (res != HOUSE_ARREST_E_SUCCESS) { printf("error %d when trying to get VendDocuments\n", res); goto leave_cleanup; } plist_t dict = NULL; if (house_arrest_get_result(hac, &dict) != HOUSE_ARREST_E_SUCCESS) { if (house_arrest_get_result(hac, &dict) != HOUSE_ARREST_E_SUCCESS) { printf("hmmm....\n"); goto leave_cleanup; } } plist_t node = plist_dict_get_item(dict, "Error"); if (node) { char *str = NULL; plist_get_string_val(node, &str); printf("Error: %s\n", str); if (str) free(str); plist_free(dict); dict = NULL; goto leave_cleanup; } node = plist_dict_get_item(dict, "Status"); if (node) { char *str = NULL; plist_get_string_val(node, &str); if (str && (strcmp(str, "Complete") != 0)) { printf("Warning: Status is not 'Complete' but '%s'\n", str); } if (str) free(str); plist_free(dict); dict = NULL; } if (dict) { plist_free(dict); } afc_client_t afc = NULL; afc_error_t ae = afc_client_new_from_house_arrest_client(hac, &afc); if (ae != AFC_E_SUCCESS) {
77
printf("afc error %d\n", ae); } if (ae == AFC_E_SUCCESS) { char **list = NULL; afc_read_directory(afc, "/", &list); printf("Directory %s contents:\n", list); if (list) { while (list[0]) { if (strcmp(list[0], ".") && strcmp(list[0], "..")) { puts(list[0]); } list++; } } if (afc_make_directory(afc, folder) == AFC_E_SUCCESS) { printf("OK - folder created\n"); result = 0; } else { printf("ERROR - folder not created\n"); } afc_client_free(afc); goto leave_cleanup; } else { printf("failed to connect to afc service, error %d\n", ae); } leave_cleanup: if (hac) { house_arrest_client_free(hac); } if (client) { lockdownd_client_free(client); } if (dev) { idevice_free(dev); } return result; }
78
Příloha C iCloud API urls newAccountUI <string>https://setup.icloud.com/setup/create_account_ui fmipauthenticate <string>https://setup.icloud.com/setup/fmipauthenticate/$APPLE_ID$ genericTermsUI <string>https://setup.icloud.com/setup/iosbuddy/ui/genericTermsUI loginOrCreateAccount <string>https://setup.icloud.com/setup/login_or_create_account nqRegister <string>https://setup.icloud.com/setup/nq_register/$APPLE_ID$/$UDID$ qualifyDevice <string>https://setup.icloud.com/setup/qualify/qualifyDevice registerWebToken <string>https://setup.icloud.com/setup/web/basic/token_auth_update_account qualifySession <string>https://setup.icloud.com/setup/qualify/session emailTosUrl <string>https://setup.icloud.com/setup/web/mailtos/
79
about <string>https://setup.icloud.com/setup/iosbuddy/ui/about?page= addEmailUI <string>https://setup.icloud.com/setup/add_free_email_ui qualifyCert <string>https://setup.icloud.com/setup/qualify/cert?ver=P1.10.1 updateAccountUI <string>https://setup.icloud.com/setup/update_account_ui authenticate <string>https://setup.icloud.com/setup/authenticate/$APPLE_ID$ validate <string>https://setup.icloud.com/setup/validate/$DS_PRS_ID$/$UDID$ initiateVetting <string>https://setup.icloud.com/setup/initiate_vetting/$APPLE_ID$ createAppleID <string>https://setup.icloud.com/setup/iosbuddy/createAppleID completeVetting <string>https://setup.icloud.com/setup/complete_vetting/$APPLE_ID$ createAndRegisterAppleIdBaseUrl <string>https://setup.icloud.com/setup/web/create_apple_id_and_account/ iForgot <string>https://iforgot.apple.com/cgi-bin/iforgot.cgi
80
register <string>https://setup.icloud.com/setup/register/$APPLE_ID$/$UDID$ updateAccount <string>https://setup.icloud.com/setup/update/$APPLE_ID$/$UDID$ loginDelegates <string>https://setup.icloud.com/setup/iosbuddy/loginDelegates validateEmail <string>https://setup.icloud.com/setup/initiate_vetting/$APPLE_ID$ checkAppleIdAvailabilityUrl <string>https://setup.icloud.com/setup/web/check_availability/ rampAlert <string>https://setup.icloud.com/setup/ramp_alert updateAppleID <string>https://setup.icloud.com/setup/iosbuddy/updateAppleID newAccount <string>https://setup.icloud.com/setup/create/$UDID$ existingAppleIdTermsUI <string>https://setup.icloud.com/setup/iosbuddy/ui/existingAppleIdTermsUI createDelegateAccounts <string>https://setup.icloud.com/setup/iosbuddy/createDelegateAccounts emailLookup <string>https://setup.icloud.com/setup/lookup_email loadUI
81
<string>https://setup.icloud.com/setup/iosbuddy/ui/loadUI checkMeEmailAvailabilityUrl <string>https://setup.icloud.com/setup/web/check_availability/ getAccountSettings <string>https://setup.icloud.com/setup/get_account_settings registerWebBasic <string>https://setup.icloud.com/setup/web/basic_auth_update_account activateMeEmailUrl <string>https://setup.icloud.com/setup/web/activate_email
82
Příloha D iCloud API protocolVersion <string>3 tokens mmeAuthToken <string>AQAAAABVKDJ2DteMmJhwf/dWeIZIeneV5s6dkx0= mmeFMIPToken <string>AQAAAABVKWcE2uwl7SIL8ecAYYbBsI1G6dMRfbc~ appleAccountInfo primaryEmailVerified <true/> iCloudAppleIdAlias <string> lastName <string>Cloud appleIdAlias <string> appleId <string>[email protected] primaryEmail <string>[email protected] statusCode 2 brMigrated aDsID <string>001120-08-778e937a-ca0a-42ff-a29b-efed46e8f446
83
dsPrsID <string>8289572381 fullName <string>Mike Cloud locked firstName <string>Mike appleIdAliases <array> com.apple.mobileme availableFeatures <array> <string>com.apple.Dataclass.Reminders <string>com.apple.Dataclass.DeviceLocator <string>com.apple.Dataclass.Content <string>com.apple.Dataclass.Mail <string>com.apple.Dataclass.KeyValue <string>com.apple.Dataclass.Ubiquity <string>com.apple.Dataclass.Notes <string>com.apple.Dataclass.MediaStream <string>com.apple.Dataclass.Bookmarks <string>com.apple.Dataclass.Contacts <string>com.apple.Dataclass.Calendars <string>com.apple.Dataclass.Backup <string>com.apple.Dataclass.SharedStreams com.apple.Dataclass.Reminders com.apple.Dataclass.MediaStream beta
84
authMechanism <string>token apsEnv <string>production url <string>https://p25-streams.icloud.com:443 com.apple.Dataclass.Account iCloudEnv <string>PROD apsEnv <string>production accountStatusCode 2 beta url <string>https://p25-setup.icloud.com:443 com.apple.Dataclass.Contacts beta authMechanism <string>token protocol <string>dav url <string>https://p25-contacts.icloud.com:443
85
com.apple.Dataclass.Bookmarks protocol <string>dav apsEnv <string>production url <string>https://p25-bookmarks.icloud.com:443 authMechanism <string>token beta com.apple.Dataclass.Calendars beta authMechanism <string>token protocol <string>dav url <string>https://p25-caldav.icloud.com:443 com.apple.Dataclass.DeviceLocator authMechanism <string>token hostname <string>p25-fmip.icloud.com
86
apsEnv <string>Production url <string>https://p25-fmip.icloud.com:443 com.apple.Dataclass.Backup authMechanism <string>token url <string>https://p25-mobilebackup.icloud.com:443 com.apple.Dataclass.SharedStreams beta authMechanism <string>token apsEnv <string>production url <string>https://p25sharedstreams.icloud.com:443 com.apple.Dataclass.Quota quotaInfoURL <string>https://p25quota.icloud.com:443/quotaservice/external/ios/8289572381/getQuotaInfo quotaUpdateURL <string>https://p25quota.icloud.com:443/quotaclient/
87
storageInfoURL <string>https://p25quota.icloud.com:443/quotaservice/external/ios/8289572381/storageUsageInfo com.apple.Dataclass.Content url <string>https://p25-content.icloud.com:443 com.apple.Dataclass.Mail mailAliasLookupXMLURL <string>https://p25mailws.icloud.com:443/wm/alias.xml FullUserName <string>Mike Cloud imapHostname <string>p25-imap.mail.me.com smtpRequiresSSL <true/> smtpHostname <string>p25-smtp.mail.me.com imapRequiresSSL <true/> Username <string>mike.cloud88 mailAliasEditingURL <string>https://www.icloud.com/#mail/prefsaddresses dotMacMailSupported
88
mailSupportURL <string>http://www.apple.com/support/icloud imapPort 993 sendFromAddressJSONURL <string>https://p25mailws.icloud.com:443/wm/ext/sendfrom smtpPort 587 EmailAddress <string>[email protected] mailAliasLookupJSONURL <string>https://p25mailws.icloud.com:443/wm/alias.json com.apple.Dataclass.KeyValue beta authMechanism <string>token apsEnv <string>production configURL <string>https://keyvalueservice.icloud.com:443/config url <string>https://p25keyvalueservice.icloud.com:443 com.apple.Dataclass.Ubiquity
89
authMechanism <string>token wsUrl <string>https://p25-ubiquityws.icloud.com:443 apsEnv <string>production url <string>https://p25-ubiquity.icloud.com:443 com.apple.Dataclass.Notes mailAliasLookupXMLURL <string>https://p25mailws.icloud.com:443/wm/alias.xml FullUserName <string>Mike Cloud imapHostname <string>p25-imap.mail.me.com smtpRequiresSSL <true/> smtpHostname <string>p25-smtp.mail.me.com imapRequiresSSL <true/> Username <string>mike.cloud88 mailAliasEditingURL <string>https://www.icloud.com/#mail/prefsaddresses dotMacMailSupported
90
mailSupportURL <string>http://www.apple.com/support/icloud imapPort 993 sendFromAddressJSONURL <string>https://p25mailws.icloud.com:443/wm/ext/sendfrom smtpPort 587 EmailAddress <string>[email protected] mailAliasLookupJSONURL <string>https://p25mailws.icloud.com:443/wm/alias.json
91
Příloha E Časová osa modelů iPhone
92
