Vad en Full File System-extraktion faktiskt innehåller, och varför det mesta av den aldrig granskas

Fråga någon utanför området vad som finns på en beslagtagen telefon och de säger meddelanden, foton och kontakter. Fråga en analytiker och de stannar upp, eftersom det ärliga svaret är att ingen helt vet, och att ta reda på det är arbetet.

En Full File System-extraktion är en kopia av enhetens filsystem så som operativsystemet ser det. Inte en kuraterad export, inte den delmängd som en applikation går med på att lämna ifrån sig genom ett säkerhetskopieringsgränssnitt. Hela trädet.

Det är värt att gå igenom vad som faktiskt finns där, eftersom datans form förklarar nästan allt om vart undersökningstiden tar vägen.

Fyra lager, i fallande ordning efter uppmärksamhet

Lagret som alla tänker på. Meddelanden, samtalsloggar, kontakter, kamerarullen. Det är genuint viktigt, det är vad ärendet vanligen vänder på, och det är en liten del av extraktionen mätt i volym. Det är också den del som varje verktyg avkodar väl, eftersom det är den del som varje verktyg byggdes för först.

Applikationslagring. Varje installerad applikation håller sitt eget tillstånd: databaser med meddelanden och deras metadata, cache av profilbilder, utkast, aviseringshistorik, sökhistorik, platsspår, synkroniseringsläge. En telefon med sextio applikationer på sig har sextio sådana, i sextio layouter, i flera format, en del av dem versionshanterade och en del inte.

Det här lagret är där de intressanta bevisen i allt högre grad finns, och det är där täckningen är mest ojämn. En analytikers verktyg avkodar lagringen hos de applikationer som leverantören implementerade, och resten är en kataloglistning.

Systemspår. Operativsystemet registrerar en anmärkningsvärd mängd om sig självt i det vanliga arbetet: vilka applikationer som kördes och när, vilka nät enheten anslöt till, när den sattes på, vilka konton som är konfigurerade, vad som nyligen öppnades. Inget av det utformades som bevis. Mycket av det är mycket bra bevis, eftersom det är svårt att kuratera och det styrker eller motsäger den mänskliga berättelsen.

Sediment. Miniatyrcache, tillfälliga filer, write-ahead-loggar som fortfarande håller rader som raderats från huvuddatabasen, oallokerat utrymme med resterna av poster som togs bort. Det här är lagret där raderat innehåll återvinns, och det är också där analytikern måste vara mest försiktig, eftersom en återvunnen rad och en aktiv rad har olika bevisvärde och aldrig får presenteras som om de vore samma.

Volymproblemet är egentligen inte ett volymproblem

En modern flaggskeppstelefon ger en extraktion på tiotals eller låga hundratals gigabyte. Men lagring är billig och läsning är snabb, så den råa storleken är inte begränsningen.

Begränsningen är att det användbara innehållet är utspritt över ett stort antal format, av vilka de flesta är odokumenterade, flera ändras mellan versioner av applikationen som skrev dem, och inget utformades för att läsas av någon annan än applikationen själv.

Det är därför den meningsfulla frågan inte är hur stor en extraktion är. Det är hur stor andel av den som något verktyg har en uppfattning om. Allt annat finns, är läsbart i princip och oanvändbart i praktiken.

Vart timmarna tar vägen

Se en erfaren analytiker arbeta sig igenom en extraktion, och tidsfördelningen är inte vad en utomstående förväntar sig.

Mycket lite av den är att läsa meddelanden. En stor del är att reda ut vilka delar av extraktionen som alls är värda att läsa, och sedan få de delarna till ett tillstånd där det är möjligt att läsa dem. Att öppna en obekant databas, reda ut vad dess tabeller betyder, upptäcka att tidsstämplar lagras i en ovanlig epok, inse att meddelandetexten finns i en tabell och deltagaren i en annan utan någon uppenbar sammanfogning. Det är arbetet.

Det är också kvalificerat arbete som inte producerar något varaktigt. Den förståelse som en analytiker bygger om en applikations lagringslayout på tisdagen lever i deras huvud, eller i bästa fall i en personlig anteckningsfil, och den måste byggas upp igen av nästa person som möter samma applikation i en annan tjänst sex månader senare.

Den del som aldrig blir undersökt

Varje laboratorium har en informell regel om hur långt man ska gå. Den är sällan nedskriven och den är vanligen förnuftig: undersök det som verktyget avkodade, undersök allt som utredaren särskilt frågade om, och anteckna resten som inte analyserad.

Resultatet är en konsekvent, osynlig minskning av omfånget. Inte ett misslyckande i noggrannhet, och inte något som en ärendegranskning skulle flagga, eftersom rapporten korrekt beskriver vad som undersöktes. Men effekten över en ärendebelastning är att en stor andel av beslagtagna data aldrig tittas på av någon, och andelen är störst just i de applikationer som en leverantör fann kommersiellt ointressanta.

Vad som skulle förändra bilden

Tre saker skulle flytta det här, i ordning efter hur stor skillnad de gör.

Den första är täckning som inte beror på någon annans versionsschema. Om en obekant applikation kan struktureras den dag ärendet behöver det slutar den informella omfångsregeln att ta bort samma kategorier av bevis varje gång.

Den andra är sökning som arbetar på betydelse snarare än bara på strängar. Det mesta av en extraktion är oläsbart eftersom ingen har ett skäl att öppna det. En fråga ställd över hela sigillet på en gång hittar skälet.

Den tredje är verifiering som är billig nog att faktiskt utföra. En analytiker som måste ägna en eftermiddag åt att bekräfta var ett fynd kom ifrån kommer att bekräfta färre fynd. En som kan göra det med ett klick kommer att bekräfta alla, vilket är vad rättssalen har rätt att förvänta sig.

Den sista betyder mer än det låter. Att göra bevisgranskning snabbare är bara användbart om det inte samtidigt gör den grundare, och det enda försvaret mot det är att göra kontrollen så billig att det inte sparar någonting att hoppa över den.