Dekryptera låsta Apple-anteckningar på iOS 16

Inledning

När jag analyserade en testenhet med ett populärt kommersiellt mobilt kriminaltekniskt verktyg stötte jag på något spännande - en låst Apple Note som bara syntes som "dold". Verktyget visade anteckningens sammanfattning (märkt "Lance"), men det faktiska innehållet saknades. Det fanns ingen aning om vad som fanns under låset och jag ställde mig en brännande fråga: kunde jag avslöja hemligheten på insidan? Jag behövde ett arbetsflöde som skulle hjälpa mig att dekryptera Apple Notes på iOS 16.

Enheten var igång iOS 16.7.10och efter att ha grävt i databasen NoteStore.sqlite insåg jag att alla krypteringsledtrådar fanns där - i väntan på att avkodas. Med hjälp av verktyg med öppen källkod började jag återskapa lösenordet och dekryptera anteckningens innehåll.

Detta inlägg går igenom hur du komplett kriminaltekniskt arbetsflöde om hur man dekryptera Apple Notes på iOS 16:

🔓 Hashcat för att knäcka lösenord
🗄️ DB Browser för SQLite för att utforska och extrahera krypteringsparametrar
🐍 Python-skript för härledning av nycklar och uppackning av AES-nycklar
🔍 CyberChef för att dekryptera, dekomprimera och analysera den slutliga protobuf-nyttolasten

⚠️ Viktig anmärkning: Detta arbetsflöde gäller specifikt för Apple Notes som är låsta på iOS 16.x. Från och med iOS 17 ändrade Apple hur krypterade anteckningar lagras - och iOS 18 innebär ännu fler förändringar.

Låt oss dyka in och avslöja det dolda meddelandet i den låsta Apple Note.

Gräva sig in i NoteStore.sqlite

Vid denna tidpunkt visste jag att innehållet i den krypterade noten lagrades i NoteStore.sqlite, särskilt i tabellen ZICNOTEDATA. Apple brukar ofta gzips anteckningens protobuf-data, men när det gäller låsta anteckningar är hela BLOB först krypterad-vilket innebär att ett direkt dekomprimeringsförsök inte ger läsbar text. Du kommer att behöva rätt dekrypteringsnyckel innan någon form av uppackning eller protobuf-parsning kan ske.

I skärmdumpen kan du se de råa hexadecimala värdena för ZDATA. Dessa data är effektivt krypterade av AES-kryptering, med kritiska metadata - som salter och iterationsantal - sparade i andra delar av databasen. Från en rättsmedicinsk undersökare När du inser att noten är helt krypterad är det dags att gräva djupare i tabellen ZICCLOUDSYNCINGOBJECT för att hitta de parametrar som behövs för att spricka lösenkoden och låsa upp anteckningen 🔓.

Varför är låsta Apple-anteckningar krypterade på iOS 16?

Apple Notes säkrar låsta anteckningar med hjälp av en kombination av PBKDF2 (härledning av nycklar) och AES (kryptering). När ett lösenord aktiveras på en anteckning lagrar Apple viktiga kryptografiska metadata i databasen, t.ex:

ZCRYPTOITERATIONSANTAL
ZCRYPTOSALT
ZCRYPTOWRAPPEDKEY

Dessa värden säkerställer att endast den som har rätt lösenord kan dekryptera innehållet i anteckningen.

Forensiskt tillvägagångssätt

Från en kriminalteknisk synvinkel inkluderar dina steg vanligtvis:

Identifiera de relevanta låsta anteckningsposterna i ZICNOTEDATA och ZICCLOUDSYNCINGOBJECT.
Extrakt de kryptografiska detaljerna - som antal iterationer, salt och den inkapslade nyckeln.
Spricka användarens lösenord med Hashcat (eller ett annat verktyg för återställning av lösenord som John the Ripper eller Passware).
Härleda de sista nycklarna i Python eller CyberChef och dekryptera anteckningens BLOB.
Dekomprimera den olåsta protobuf-datan (med CyberChef eller Python) för att avslöja den slutliga klartexten.

Knäcka lösenordet till den låsta Apple Note med Hashcat

Mitt mål var att simulera ett realistiskt kriminaltekniskt scenario: Jag hade en låst Apple Note och behövde återställa lösenkoden för att dekryptera innehållet. Det är där Hashcat kommer in i bilden. Genom att utnyttja hash-läget för Apple Secure Notes (ID 16200) testade Hashcat systematiskt olika lösenord tills det hittade det rätta.

Extrahera de nödvändiga kolumnerna

Jag började med att öppna NoteStore.sqlite i DB Browser och riktade in sig på rader med ZISPASSWORDPROTECTED = 1 i tabellen ZICCLOUDSYNCINGOBJECT. Jag frågade sedan följande kolumner:

Z_PK - anteckningens unika identifierare.
ZCRYPTOSALT - saltvärdet för PBKDF2.
ZCRYPTOWRAPPEDKEY - den inplastade nyckeln som senare kommer att packas upp.

Hashcat-ingångsfilen genererades av ett litet Python-skript anteckningar_till_hashcat.pysom formaterade dessa värden till en enda rad som Hashcat kunde analysera, inklusive iterationsantalet (från ZCRYPTOITERATIONCOUNT).

Kör Hashcat för att dekryptera det låsta Apple Note-lösenordet

Med min Hashcat-ingångsfil klar och en ordbok till hands körde jag följande kommando:

hashcat -m 16200 -a 0
Här:

-m 16200 anger Apple Secure Notes-läge.
-a 0 sätter Hashcat i attackläge Straight (ordbok).
Ordlistan kan vara något i stil med rockyou.txt eller en anpassad lista som härrör från enhetens artefakter.

Hashcat identifierade framgångsrikt det korrekta lösenordet: royalewithcheese. I en verklig undersökning kan din ordlista vara mycket större, men det här resultatet bekräftade att Hashcat kunde hantera de tunga lyften.

Härleda nyckelkrypteringsnyckeln (KEK) för att dekryptera Apple Notes

Med lösenordet i handen var nästa steg att härleda Nyckelkrypteringsnyckel (KEK), som används för att omsluta den slutliga AES-nyckeln som krypterar anteckningens innehåll. För att härleda KEK behövde jag följande värden från tabellen ZICCLOUDSYNCINGOBJECT:

Lösenord (det knäckta lösenordet)
Antal iterationer (ZCRYPTOITERATIONCOUNT)
Salt (ZCRYPTOSALT)

Till exempel, med hjälp av DB Browser, frågade jag:

SELECT ZCRYPTOITERATIONCOUNT, ZCRYPTOSALT FROM ZICCLOUDSYNCINGOBJECT WHERE Z_PK = ;

Därefter öppnade jag CyberChef - ett av mina favoritverktyg 🛠️ - och drog in operationen "Derive PBKDF2 key". Ställa in hashingfunktionen till SHA-256 och matade in lösenordet, saltet och iterationsantalet producerade CyberChef 16-byte KEK:

För att automatisera denna process skapade jag ett Python-skript som heter get_key.pysom tar emot databassökvägen, not PK och lösenord som argument. Om den körs returneras KEK i hex.

python get_kek.py NoteStore.sqlite

Resultat:

Anmärkning PK=16: KEK (hex) = a1dac1516302e1d3d73ad4fd4b6f8fef

Avslöja AES-nyckeln för att dekryptera låsta Apple-anteckningar på iOS 16

Nästa steg var att packa upp nyckeln som används för att kryptera anteckningens innehåll. Den omslutna nyckeln lagras i kolumnen ZCRYPTOWRAPPEDKEY i ZICCLOUDSYNCINGOBJECT. Till exempel frågade jag::

SELECT ZCRYPTOWRAPPEDKEY FROM ZICCLOUDSYNCINGOBJECT WHERE Z_PK = 16;

Alternativ för uppackning

Alternativ 1: Unwrapping AES-nyckeln för dekryptering av låsta Apple-anteckningar på iOS 16 med CyberChef

Jag inaktiverade alla tidigare operationer, sökte efter "AES Key Unwrap" och drog den in i receptfönstret. Genom att klistra in KEK och den inslagna nyckeln matade CyberChef ut den uppslagna AES-nyckeln.

Alternativ 2: Automatisera uppackning av AES-nycklar med unwrap.py

Jag har också utvecklat ett Python-skript som heter unwrap.py som tar databassökvägen och KEK (i hex) som argument. När skriptet kördes packades nyckeln upp och skrevs ut i hex-format. I mitt fall var den uppackade nyckeln:

python unwrap.py NoteStore.sqlite

Detta är den slutliga AES-nyckeln som kommer att användas för att dekryptera innehållet i den låsta Apple-noten.

Dekryptering av Apple Notes BLOBs med AES-GCM på iOS 16

Nu när jag hade den uppackade nyckeln var det dags att dekryptera Apple Notes BLOB som lagras i ZICNOTEDATA bord. Apple använder AES i GCM-läge för att skydda innehållet i låsta anteckningar, vilket innebär att jag behövde fyra viktiga komponenter för att gå vidare:

🔑 Oförpackad AES-nyckel
🔁 Initialiseringsvektor (IV) från ZCRYPTOINITIALISERINGSVEKTOR
🏷 Tagg för autentisering av GCM från ZCRYPTOTAG
💾 Krypterad BLOB från ZDATA

📤 Extrahera IV- och GCM-taggen från NoteStore.sqlite

För att lokalisera IV och GCM-taggöppnade jag ZICNOTEDATA tabell i DB Browser för SQLite. Dessa fält lagras som binära värden och kan hittas i antingen ZICNOTEDATA eller ZICCLOUDSYNCINGOBJECT tabeller. Båda lagrar data under samma kolumnnamn.

IV: 5c0c0bde9b6801747ddad1115a422d05
GCM-tagg: b9087ba19e3c7deff2cb4b9b51e6aafa

Den krypterade BLOB:en i sig var också synlig i ZDATA kolumn. Jag kopierade alla tre värdena i hexadecimalt format och förberedde mig för det sista dekrypteringssteget.

🧪 Avkryptering av anteckningen med CyberChef

Med allt i handen vände jag mig till CyberChef. Det här verktyget gjorde det enkelt att kombinera alla parametrar och avslöja det ursprungliga innehållet. Här är vad jag gjorde:

Jag lade till "AES-dekryptering" operation.
Jag klistrade in Oförpackad AES-nyckel i fältet Nyckel.
Jag ställde in läge till GCM.
Jag satte in IV och GCM Tag inom sina respektive områden.
Slutligen kopierade jag krypterad BLOB i inmatningsfönstret.

När jag träffade Bakadekrypterade CyberChef BLOB:en och visade en komprimerad fil - precis som jag förväntade mig. Detta innebar att krypteringslagret nu var helt borttaget och jag kunde gå vidare till att dekomprimera data.

Packa upp och analysera den slutliga anteckningen (dekrypterad Protobuf från Apple Notes)

Efter att ha dekrypterat den AES-krypterade BLOB sparade jag utdata i en fil med namnet dekrypterad_blob.bin och öppnade den i HxD. Filens signatur 0x1F8B08 bekräftade att det var en GZIP-komprimerad fil - Apple använder detta för att komprimera protobuf-data.

För att extrahera klartexten öppnade jag CyberChef igen och lade till Gunzip operation till arbetsflödet. Omedelbart började bekanta strängar dyka upp i utdata.

När jag väl var okomprimerad använde jag Protobuf Avkodning i CyberChef. Resultatet blev en strukturerad vy som liknade JSON, med nycklar och värden som representerade innehållet i den låsta Apple Note.

För att underlätta läsningen använde jag också ett Python-skript som utnyttjade backboxprotobuf modulen för att analysera protobuf-filen och skriva ut resultatet i ett rent, läsbart format.

Detta matchar vad användaren skrev i sin låsta Apple Note. Du har gått från en dold, lösenordsskyddad post till det faktiska meddelandet i klartext - en ovärderlig upptäckt i alla kriminaltekniska fall.

🔚 Avslutning

Grattis 🎉 - du har just slutfört ett fullständigt kriminaltekniskt arbetsflöde för att dekryptera låsta Apple-anteckningar på iOS 16. Du extraherade krypteringsparametrar från SQLite-databasen, knäckte lösenordet med Hashcathärledde och packade upp AES-nyckeln med hjälp av Pythonoch slutligen dekrypterade och analyserade protobuf med CyberChef. Varje steg förde dig närmare en avslöjande av anteckningens dolda innehåll.

Denna praktiska genomgång visar hur kraftfullt verktyg med öppen källkod kan vara inom digital kriminalteknik. De hjälper utredare att hitta krypterade Apple Notes som kommersiella verktyg kanske missar - särskilt på enheter som kör iOS 16 eller tidigare.

🕵️ Bonus: Lösenordshint

Här är en extra twist - jag hittade en lösenordshint i ZICCLOUDSYNCINGOBJECT bord:

Quarter Pounder

Eftersom enheten tillhörde någon som hette "Vincent" var det inte svårt att gissa lösenordet: royalewithcheese - en nick till Pulp Fiction. I verkliga fall kan lösenordstips som detta påskynda arbetsflödet när de kombineras med en strategisk knäckningsprocess.

📱 En sak till ... om iOS 17 och iOS 18

Denna guide gäller specifikt för hur man dekrypterar Apple Notes på iOS 16 och tidigare. Börjar med iOS 17Apple införde betydande ändringar i Notes-krypteringsprocessen. Du kan stöta på saknade nyckelavledningsfält, olika kryptografiska strukturer eller anteckningar som inte längre dekrypteras med samma metoder.

Om du funderar på hur du kan dekryptera Apple Notes på iOS 17 eller iOS 18Jag skulle gärna vilja samarbeta. Dela med dig av dina resultat - låt oss bryta ner den nya krypteringen tillsammans.

Tack för att du läste! Har du frågor eller insikter? Skriv dem i kommentarerna nedan eller kontakta oss direkt. Låt oss fortsätta att flytta fram gränserna för rättsmedicinsk upptäckt. 🔍