Iesniegtais Apple Fusion Drive sastāvēja no diviem datu nesējiem - 128 GB SSD un 3 TB HDD. SSD bija fiziski bojāts, un aptuveni 41,9 GB tā satura nebija nolasāmi.
Fusion Drive gadījumā tas radīja īpaši sarežģītu situāciju. Apple File System (APFS) konteinera kritiski svarīgie metadati atradās SSD. Tā bojājuma dēļ operētājsistēma vairs nespēja korekti atrast un interpretēt visu failu sistēmu, lai gan liela daļa pašu datu joprojām bija saglabāta HDD.
Kas bija zaudēts un kas saglabājās
Lietotāja sējuma ieraksts bija zudis. FileVault šifrētais lietotāja sējums vairs neparādījās sistēmas sējumu sarakstā. Tā nebija šifrēšanas kļūme - bojātajā SSD apgabalā bija zaudēta informācija, kas bija nepieciešama šī sējuma atrašanai un piesaistei APFS struktūrai.
Bija bojātas arī sistēmas un datu struktūras. macOS sistēmas sējuma indekss bija pilnībā zudis, savukārt daļai lietotāja datu mezgliem trūka norāžu uz nākamajiem struktūras elementiem.
Tomēr SSD bija saglabājies pats galvenais APFS konteinera superbloks ar derīgu kontrolsummu. Tas saturēja būtisku informāciju par konteinera struktūru, bloku izmēriem, datu nesēju izkārtojumu un šifrēšanas atslēgu struktūru (keybag). Šī informācija deva iespēju sākt failu sistēmas rekonstrukciju.
APFS kā grāmata bez lapu numuriem
Lai saprastu, kas notika ar failu sistēmu, APFS struktūru var iztēloties kā grāmatu, kurai izplēstas lapas un izmētātas pa istabu, daļa no satura rādītāja ir zudusi, dažas lapas ir šifrētas, dažām lapām trūkst numuri.
Titullapa - superbloks.
Grāmatas sākumā ir informācija, kas palīdz saprast, kā tā ir uzbūvēta. Līdzīgu lomu APFS konteinera līmenī pilda superbloks (NXSB). Tas satur informāciju, kas nepieciešama pārējās konteinera struktūras atrašanai un interpretēšanai.
Satura rādītājs - B-tree.
Grāmatā nav nepieciešams meklēt katru lapu pēc kārtas - satura rādītājs norāda, kur atrodas konkrētās nodaļas. APFS izmanto B-tree struktūras, lai organizētu informāciju par failiem, mapēm un to atrašanās vietām. Ja šī struktūra ir bojāta, faili var joprojām atrasties diskā, bet sistēma vairs nezina, kā pie tiem nokļūt.
Izmaiņas netiek pārrakstītas uz vietas - Copy-on-Write.
APFS izmanto Copy-on-Write principu: mainot datus, jaunā versija tiek ierakstīta citā vietā, bet iepriekšējie dati netiek uzreiz pārrakstīti. Tas nozīmē, ka diskā var saglabāties vairākas failu sistēmas struktūras versijas. APFS šādas failu sistēmas stāvokļa versijas glabā kā checkpoints.
Kontrolsumma.
Katram APFS metadatu blokam ir sava unikāla kontrolsumma (fletcher64), kas ļauj uzreiz pārbaudīt bloka integritāti un apstiprināt, ka tā saturs nav sabojāts. Datu atjaunošanā šī īpašība ir izšķiroša: pat ja centrālais indekss ir iznīcināts, katrs atsevišķais bloks spēj pats "pierādīt" savu autentiskumu un sniegt pietiekami daudz informācijas, lai no fragmentiem pakāpeniski pārbūvētu visu failu sistēmu.
Dati ir šifrēti ar FileVault.
Šifrētie lietotāja dati paši par sevi nav lasāmi bez atbilstošajām atslēgām. Tāpēc šajā gadījumā bija nepieciešams ne tikai rekonstruēt APFS struktūru, bet arī atjaunot piekļuvi šifrēšanas atslēgai.
Kā tika atgūti dati
1. Atslēga vispirms, sējuma meklēšana pēc tam
Vispirms tika atjaunota piekļuve šifrēšanas atslēgu struktūrai, kas bija saglabājusies APFS konteinera keybag. Izmantojot lietotāja paroli, bija iespējams atšifrēt nepieciešamo atslēgu.
Tas bija būtisks moments, jo izmantojot atslēgu varēja atrast sējumu, ko tā atslēdz.
2. Vēsturisko versiju meklēšana
Tālāk tika analizēta diska sākuma daļa un meklētas iepriekšējās APFS struktūras versijas. Kopumā izdevās atrast 23 dažādas sējuma superbloka/checkpoint versijas.
Bet, kura versija ir pareizā?
3. Katras versijas stingra pārbaude
Jaunākā atrastā versija ne vienmēr ir īstā. Tā var saturēt norādes uz blokiem, kas jau ir bojāti vai nav pilnībā nolasāmi.
Tāpēc katra no 23 versijām tika pārbaudīta pa visu atjaunošanas ķēdi:
superbloks → failu sistēmas struktūra → atšifrēšana → kontrolsummas → gala dati
Pilnu pārbaudi izturēja divas versijas, kur viena no tām nodrošināja vispilnīgāko pieejamo failu struktūru. Šajā posmā tika atgūta lielākā daļa klientu datu, kas bija strukturēti.
4. Datu analīze
Kad failu struktūra ir sabojāta, ir svarīgi atrast failus, kas atvienojušies no kataloga, taču joprojām glabā vērtīgus klienta datus. Galvenais izaicinājums šādā analīzē - datu masīvā vienlaikus blakus pastāv gan nešifrētas sistēmas struktūras, gan šifrēti lietotāja dati.
Lai to atrisinātu, diska analīzē katrs bloks tika vērtēts divos skatos vienlaikus: kā nešifrēts failu sistēmas elements un kā atšifrēts lietotāja datu bloks. Pielāgotais skenēšanas algoritms spēja atšķirt derīgas struktūras no nejaušiem trokšņiem, ļaujot pakāpeniski rekonstruēt organisku failu koku pat no visvairāk cietušajiem apgabaliem. Rezultātā bez strukturētiem (direktoriju koks un failu nosaukumi) datiem tika atgūti arī RAW dati, kurus sagrupēja pa failu tipiem (.pdf, .ai, .jpeg, u.c.).
Šajā MI ģenerētajā diagrammā vienkāršoti attēlots viss atjaunošanas process.
Rezultāts
Lai gan SSD fiziskais bojājums bija pārtraucis pieeju Fusion Drive APFS failu sistēmai un macOS vairs nespēja uzrādīt lietotāja sējumu, būtiska daļa nepieciešamās informācijas bija saglabājusies.
Izmantojot saglabājušos APFS metadatus, vēsturiskos checkpoints, kontrolsummas un FileVault atslēgu struktūru, bija iespējams rekonstruēt failu sistēmu un atjaunot piekļuvi lietotāja datiem.