KANDIDATUPPSATS
IT-forensik och Informationssäkerhet, 180 hp
Carving och innehållssökning av komplexa dokument
En jämförelse av verktyg
Robin Kadar Rosengren, Michael Wendt
Datateknik, 15 hp
Halmstad 2016-08-29
Carving och innehållssökning av komplexa dokument
- En jämförelse av verktyg
Kandidatuppsats Vårterminen 2016
Författare: Robin Kadar Rosengren & Michael Wendt Handledare: Filosofie Doktor Eric Järpe
Högskolan i Halmstad Box 823, 301 18 HALMSTAD
Copyright Robin Kadar Rosengren, Michael Wendt, 2016. All rights reserved.c Kandidatuppsats
Sektionen för informationsvetenskap, data- och elektroteknik.
Högskolan i Halmstad
Förord
Tre års studier i IT-forensik och informationssäkerhet vid Högskolan i Halmstad är nu till ända. Det har varit tre år fyllda av intressanta föreläsningar, seminarier och laborationer. Under tiden på högskolan har vi fått studera ett brett område.
IT-forensik omfattar allt från juridik och kriminologi till nätverk och kryptologi.
Men det som vi fann vara mest intressant var konsten att återskapa bevis från filer som blivit borttagna på ett eller annat sätt. Detta ledde oss in på vårt ämne för den avslutande C-uppsatsen: file carving. – Konsten att återskapa raderade filer utan hjälp av filsystemsinformation. Vi valde att inrikta oss på file carving av just komplexa textdokument då vi, trots ett idogt sökande inte kunnat finna några små, snabba verktyg som klarar av att söka efter specifika textsträngar i raderade filer av denna typ. Ett verktyg med dessa egenskaper kan vara till stor nytta i flera olika scenario: till exempel vid brottsutredningar som ligger under stor tidspress, eller under pågående förhör med en misstänkt gärningsperson för att bekräfta eller förkasta dennes utsago.
Vi vill tacka vänner och familj som stöttat oss under tiden som vi har studerat, men framför allt under perioden som vi skrivit vår C-uppsats. Det har varit både kul och lärorikt, men samtidigt stressigt och påfrestande. Martin Lööf vid polisen i Borås har ställt upp på en intervju som vi använt oss av i denna rapport och vi är väldigt tacksamma för detta. Vi vill också tacka Mattias Wecksten, programansvarig för IT-forensik och informationssäkerhet vid Högskolan i Halmstad. Mattias var den som först introducerade begreppet file carving för oss för snart 2,5 år sedan.
Avslutningsvis vill vi rikta ett stort tack till vår handledare Eric Järpe som har lämnat ovärderlig hjälp under hela processen med uppsatsskrivandet. Uppsatsen är skriven i märkspråket LATEX via http://www.sharelatex.com.
Sammanfattning
File carvingär konsten att återskapa raderade filer utan hjälp av filsystemsinformation.
Speciellt viktigt skulle detta kunna vara vid utredning av ekonomisk brottslighet som utgör en vital del inom bekämpning av prioriterade områden som organiserad brottslighet och terrorism. I detta arbete presenteras ett nytt verktyg för att utföra file carvingsom även jämförs mot andra verktyg på marknaden med tyngdpunkt på processtid och minnesanvändning. Dessutom riktas fokus på egenskapen att snabbt kunna söka efter nyckelord i de framtagna filerna. Detta är något som kan vara mycket användbart när det finns behov av att snabbt hitta relevant information i en brottsutredning. Då filformaten .docx samt .pdf hör till de vanligaste typerna av textfiler har testerna valts att göras på dessa. I arbetet har det även undersökts hur polisen arbetar med file carving och sökning i textdokument idag.
EnCase är det absolut mest använda programmet hos polisen, men testerna visade att det är både långsamt och resurskrävande. Verktyget Autopsy visade sig vara ett snabbare alternativ, men det nykomna verktyget Alice var mindre, snabbare och resurssnålare än båda alternativ. EnCase kunde inte heller visa resultaten av en textsökning på ett lika överskådligt sätt som Autopsy och Alice.
Innehåll
1 Introduktion 1
1.1 Introduktion . . . . 1
1.2 Bakgrund . . . . 2
1.3 Syfte . . . . 3
1.4 Scenario . . . . 3
1.5 Frågeställning . . . . 3
1.6 Avgränsningar . . . . 4
1.7 Tidigare arbeten . . . . 5
1.8 Metod . . . . 5
1.8.1 Metodkritik och problematisering . . . . 6
2 Teori 9 2.1 Microsoft Word 2007 XML Format (.docx) . . . . 9
2.1.1 Bakgrund . . . . 9
2.1.2 Filformat i Microsoft Word . . . . 9
2.1.3 Filstruktur i .docx-filer . . . . 11
2.1.4 Dokumentdelar . . . . 12
2.2 Portable Document Format . . . . 13
2.2.1 Bakgrund . . . . 13
2.2.2 Filstruktur . . . . 14
2.3 File carving . . . . 17
2.3.1 Hårddiskar och filsystemet FAT . . . . 17
2.3.2 NTFS och radering av filer . . . . 18
2.4 Återskapande av raderade filer - File carving . . . . 20
2.5 Matematisk grund . . . . 21
2.5.1 ANOVA . . . . 21
2.5.2 Post hoc-test . . . . 21
3 Genomförande 23 3.1 Förberedelse . . . . 23
3.1.1 Data-set . . . . 23
3.1.2 Hårdvara . . . . 24
3.1.3 Egenskaper hos verktyg . . . . 24
3.2 Utveckling av nytt verktyg . . . . 25
3.2.1 Vad ska verktyget göra? . . . . 26
3.2.2 Planering . . . . 26
3.2.3 Programmering . . . . 27
3.2.4 Utökning av funktioner (PDF-implementering) . . . . 28
3.2.5 Carving-metod . . . . 29
3.2.6 Slutgiltiga verktyget: Alice . . . . 29
3.2.7 Svagheter . . . . 31
3.3 Test av verktyg . . . . 31
3.3.1 EnCase . . . . 33
3.3.2 QPhotoRec . . . . 34
3.3.3 Autopsy . . . . 34
3.3.4 Alice . . . . 35
3.4 Efterarbete - PhotoRec . . . . 35
3.5 Polisens arbete idag – en kort intervju . . . . 36
3.6 SPSS . . . . 37
4 Resultat 41 4.1 Uppmätta värden – verktygstest . . . . 41
4.2 Oberoende av dataset . . . . 41
4.3 Beroende av dataset . . . . 43
4.4 Mer om resultaten . . . . 48
4.4.1 EnCase . . . . 48
4.4.2 QPhotoRec . . . . 48
4.4.3 Autopsy . . . . 48
4.4.4 Alice . . . . 49
4.5 ANOVA och post hoc . . . . 49
5 Analys 51
6 Diskussion 53
6.1 Hur kan resultaten tolkas? . . . . 53
6.2 Resultatens konsekvenser . . . . 54
6.3 Förklaring till resultaten . . . . 54
6.4 Har metoden inverkat på resultaten? . . . . 54
6.5 Tidigare arbeten . . . . 55
6.6 Avslutande diskussion . . . . 55
7 Slutsats 57 7.1 Polisens arbete idag . . . . 57
7.2 Verktyg . . . . 58
Litteraturförteckning 59
A Källkod - Alice 63
B Loggar från avbildning 77
C Resultat från ANOVA/Post hoc Tid 85
D Resultat från ANOVA/Post hoc Minnesanvändning 89
Figurer
2.1 En .docx-fil när den öppnas genom ett program som kan hantera .zip-filer. 11
2.2 Innehållet i word-mappen i en .docx-fil. . . . 13
2.3 Filstruktur i .pdf-filer. . . . 14
2.4 Exempel på cross reference table i en .pdf-fil. . . . 15
2.5 Trailerns struktur i en pdf-fil. . . . 17
2.6 Konventionell trädstruktur jämfört med b-träd. . . . 19
3.1 Ordningen verktyget utför uppgifterna i verktygets huvudfunktion. . . . 30
3.2 Den ifyllda datan i verktyget IBM SPSS Statistics 20, där värdet 1 är EnCase, värdet 2 är Autopsy och värdet 3 är Alice i raden ”Mjukvara”. . 38
4.1 Diagram över uppmätt processtid. . . . . 47
4.2 Diagram över uppmätt minnesmängd. . . . 47
Kapitel 1
Introduktion
1.1 Introduktion
Finns det någonting i modern tid som påverkat vår vardag så mycket som den digitala tekniken? Idag finns den överallt och digitala produkter har ständigt blivit en större del av vår vardag de senaste 20 åren. Detta märks tydligt när många av oss idag har en telefon i fickan som är mycket mer kraftfull än familjens dator var för 15 år sedan. I en webbartikel kan vi läsa att 7 av 10 säger ”jag kan inte leva utan min telefon” [37]. Idag lagrar människor så pass mycket viktig information och har ett så pass stort behov av tjänsterna som de kommer åt via sina digitala maskiner att utan dem blir de rådlösa. Men det är inte bara mobiltelefonen som är viktig. GPS’er, datorer, smart-watches och mycket annat kan innehålla en stor del information som kan vara till hjälp för att kartlägga en persons liv och på så sätt vara behjälplig vid brottsutredning samt huvudförhandling. Ett annat scenario kan vara att en person som bevittnat ett brott har varit snabb med att ta ett foto med hjälp av sin digitalkamera eller mobiltelefon. Den digitala bilden kan då bli värdefullt bevismaterial i den fortsatta hanteringen.
På grund av denna ökning av användandet av digitalteknik i samhället har också ett nytt problem uppstått: vad ska man göra om viktig data medvetet eller av misstag har raderats? Det är ett problem som både privatpersoner, företag och myndigheter kan råka ut för. På det privata planet kan det vara till exempel semesterbilderna som av någon anledning inte lägre finns kvar på minneskortet i kameran. Ett sätt att återskapa dessa är att lämna in minneskortet till en fotobutik. De har oftast kompetensen att återställa raderade filer från kamerors minneskort. Detta är dock både dyrt och ger inte alltid önskat resultat, och oftast är det någonting som man kan åstadkomma själv med hjälp av lite kunskap och rätt verktyg.
Att polisen många gånger måste återskapa raderade filer vid tekniska brottsun- dersökningar är inte svårt att tänka sig. Detta av samma anledning som tagits upp tidigare: mer digitalteknik används i vårt vardagliga liv, och följaktligen även i de kriminellas liv.
Denna uppsats inriktas främst på det forensiska arbetet hos polisen, men kan även vara av nytta för företag och privatpersoner. Målgruppen för framställningen är verksamma IT-forensiker och personer med motsvarande kunskaper.
1.2 Bakgrund
En av många verktyg i en IT-forensikers verktygslåda är så kallad file carving. Då det i ett filsystem finns gömd information som till exempel om filers placering i form av metadata är det enkelt att återskapa filer som blivit markerade som borttagna när det finns tillgång till denna information. File carving är en teknik som syftar till att återskapa data från filer utan hjälp av ett filsystems metadata [2]. Det som finns till förfogande är alltså bara rådata i form av hexadecimala värden. I sin enklaste form kan ett dataprogram som läser av dessa värden från ett filsystem användas och däref- ter visa motsvarande symbol från ASCII-tabellen. Ett exempel är det hexadecimala värdet
“48454C4C4F20574F524C4421”
som motsvarar textsträngen
“HELLO WORLD!”
Om detta står skrivet i en .txt-fil är det väldigt enkelt att hitta i en hexadecimal- redigerare/läsare då de ofta direktöversätter hexadecimala värden till ASCII-formaterad text. Men hur är det om texten är skriven i ett mer avancerat program, som till exempel Microsoft Office Word?
Ett sådant program kan utöver bara text innehålla en mängd annan data så som tabeller, bilder och diagram. Utöver detta så har det också väldigt stora möjligheter att formatera dokumentet till det utseende som författaren önskar. Detta innebär att ett sådant dokument innehåller mycket mer data än vad en enkel .txt-fil gör, och de är formaterade helt annorlunda [13]. Öppnas en Microsoft Office Word (.docx)-fil i samma program som vid det förra tillfället är det inte alls säkert att det klarar av att skriva ut den faktiska text som dokumentet innehåller. Samma sak gäller vid undersökning av Portable Document Format (.pdf)-filer. Dock finns det verktyg som klarar av uppgiften.
1.3 Syfte
Syftet med denna uppsats är att driva metodiken för att utföra file carving vid specifika scenarion framåt genom att en granskning görs på polisens tillvägagångssätt idag, samt att ett verktyg som på ett effektivt sätt utför utvinning utvecklas. Detta verktyg måste klara de uppgifter som ställs när en polisutredning sker under extrem tidsbrist.
I detta arbete jämförs det nya verktyget med de som redan finns idag för att undersöka om effektivisering av metodik kan ske genom val av annat verktyg.
1.4 Scenario
Genom att konstruera ett scenario, utifrån vilket experimentet utförs, ges testerna ytterligare verklighetsanknytning. Syftet med detta är att ge experimentet en praktisk inriktning och simulera en verklig situation. Scenariot är som följer:
1. Du är en av de första som anländer vid ett tillslag.
2. Där hittar du en extern hårddisk i en byrålåda som troligtvis tillhör en vapen- smugglare. Alla filer är raderade.
3. Polisen har tidigare fått starka indicier på att den misstänkta personen sålt en stor mängd vapen av modell Walther PPK.
4. Personen sitter just nu häktad för brottet men kommer troligtvis att släppas imorgon eftersom huvudförhandling ska hållas och bevisningen är svag. Därför finns det inte tid till att skicka den externa hårddisken till ett labb, utan du måste undersöka hårddisken på plats och försöka utvinna vad som utvinnas kan. Du måste hitta bevis snabbt och det är viktigt att resultaten är korrekta!
1.5 Frågeställning
I detta arbete undersöks hur polisen idag utför file carving och sökning i filer av typen .docx samt .pdf. I samband med en ökad förståelse i hur arbetet praktiskt utförs undersöks också vilka alternativ av verktyg som kan utföra samma uppgift som de som polisen idag använder. Utöver detta görs även en undersökning av hur pass effektivt, mätt i bland annat i tid, utnyttjad datorkraft och antal interaktioner som krävs, polisens mest använda verktyg ställer sig mot andra alternativ på marknaden.
I arbetet med denna uppsats önskas det kunna utvecklas ett verktyg som bättre
hanterar de önskade egenskaper som olika situationer kan kräva, och därefter även jämföra detta mot de olika alternativ som idag står till IT-forensikerns förfogande vid utvinning av komplexa textdokument. Detta för att leda effektiviteten av denna typ av arbete framåt bland såväl verksamma IT-forensiker som privatpersoner och företag. De frågor som besvaras är:
• Hur ser rutinerna ut för file carving av .docx- och .pdf-filer hos polisen idag?
• Vilka verktyg finns för närvarande som klarar av uppgiften att hitta och åter- skapa raderade textfiler av typen .docx och .pdf?
• Vilka av dessa verktyg kan söka i dessa raderade filer och visa resultatet av sökningen i form av det eftersökta ordet och text tillhörande detta ord?
• Vilket av dessa verktyg ger snabbast och med minst krävda resurser ett resultat?
• Hur skulle man kunna konstruera ett eget bidrag för att lösa dessa uppgifter?
Tidigare arbeten har fokuserats på att file carvingverktyg mättes på ett mer brett användningsområde. Då inget fall är det andra likt inriktas detta arbete på en specifik typ av scenario där det snabbt behövs få reda på om en viss textsträng eller ett visst ord förekommer i dessa två väldigt vanliga filformat. Duff Johnson, konsult i Strategy och Communications, publicerade en studie på sin blogg [21] där han förutom .html listar .pdf och .docx som de två vanligaste filtyperna som skickas på internet. Även online-convert.com listar .docx och .pdf bland de 7 mest populära filformaten för textdokument [1].
1.6 Avgränsningar
Endast file carving av filtyperna .docx och .pdf undersöks i detta arbete. Däremot skapas dataseten även med filer av andra filformat så att scenariot görs mer verk- lighetstroget, då lagrigsmedier ofta innehåller mängder av olika filformat. I arbetet testas verktyg enbart på ett operativsystem: Microsoft Windows 7. Då arbetet utförs under en begränsad tid sattes en avgränsning att endast testa tre verktyg, samt ett nyutvecklat verktyg. Valet föll på just dessa tre då det funnits tidigare erfarenhet av dessa verktyg. Det finns med stor säkerhet fler verktyg för att utföra file carving men för att att arbetet ska hållas till rimlig storlek tas detta beslut.
1.7 Tidigare arbeten
År 2012 skrev B.Sc. Kovac en kandidatuppsats där han jämförde olika file car- vingverktyg[24]. Kovac valde att fokusera på vilka verktyg som hade bäst resultat gällandes file carving av fragmenterade bildfiler. En skillnad mot detta arbete är valet av filtyper att testa mot. Kovac valde bildfiler, men i nuvarande undersökning valdes att fokusera på textfiler. Både bildfiler och textfiler är informationsbärare som kan ha stor betydelse för en brottsutredning. För att en utredning ska anses vara komplett och korrekt måste båda undersökas. Men för enskilda specialfall där information måste sökas upp snabbt är det inte praktiskt när det görs på bildfiler. Med textfiler ges en möjlighet att söka efter innehåll med hjälp av nyckelord, något som inte är möjligt med bildfiler.
Svårare är det när det är komplexa filer som .docx och .pdf som ska undersökas, men då dessa är bland de vanligaste textfilerna är det mycket viktigt att de hanteras.
Det finns gott om arbeten där file carvingverktyg mäts mot varandra [29], men efter en undersökning hittades inte något som fokuserade, i första hand, på vanliga textfiler, så som det valdes att göras i detta arbete.
1.8 Metod
Genom att studera hur .docx-filer samt .pdf-filer är uppbyggda fås den grundläggande kunskapen som krävs för att kunna ta arbetet vidare. En rad olika metoder för att utföra file carving av de aktuella filtyperna beaktas härvid. För att göra detta avgörs först vilka verktyg som finns idag samt hur de fungerar. Efter att detta är gjort jämförs dessa verktyg efter vissa kriterier, så som till exempel tidsåtgång och resultat, men även speciellt valda sådana för det skapade scenariot (se 1.4 Scenario), och därigenom avgörs vilken metod som är mest effektiv. Dessa verktyg används för att försöka återskapa .docx- och .pdf-filer från tio olika dataset som skapas på en dator med operativsystem Microsoft Windows 10. Dessa dataset består av .docx- och .pdf-filer, samt av andra filformat, så som (men inte uteslutande) .jpeg och .png.
Dessa filer förs sedan in på en bärbar hårddisk för att därefter raderas med hjälp av en dator som har operativsystem Microsoft Windows 7. Med hjälp av verktyget FTK Imager görs sedan en avbild på hårddisken och det är denna avbild som file carvingverktygenska testas på.
De verktyg som undersöks är:
• EnCase v7
• QPhotoRec
• Autopsy
Genom att det hålls en kortare intervju med en yrkesutövande IT-forensiker vid polisen i Borås, erhålls den information om rutiner för hur file carving av dessa filtyper görs hos polisen idag. För att inte för stor tid ska tas i anspråk från intervjupersonen skickas frågorna via e-post. På så sätt låts den intervjuade besvara frågorna när tid finns för detta.
Därutöver utvecklas ett nytt verktyg som ska kunna hitta .docx-filer och .pdf- filer ur rå hexadecimal data samt söka efter specifika ord. Verktyget ska sedan extrahera all text som finns lagrad i dessa dokument och därefter visa meningen där nyckelordet förekommer i en programruta. Verktyget mäts enligt samma metod som de övriga file carvingverktygen mäts med, för att se om detta nya verktyg producerar bättre resultat än de som redan finns. För att ge en förståelse till hur detta verktyg fungerar ges en bakgrund till hur .docx-filer samt .pdf-filer är uppbyggda, men även en kort redogörelse för hur lagring samt borttagning av information går till på moderna datorer.
Av de metoder som tas upp av Pal och Memon [30] – med hjälp av filsystemets metadata, eller utan, används i detta arbete den andra metoden, som helt förlitar sig på utseendet av rådata och header-information. Denna teknik kallas för file carving.
1.8.1 Metodkritik och problematisering
Viktigt är dock att poängtera att det med stor sannolikhet finns andra verktyg som klarar av att utföra file carving. Det är tyvärr inte praktiskt möjligt att undersöka alla verktyg som finns i ett projekt av den här storleken. Därför valdes att enbart undersöka de verktyg som enligt tidigare kunskap ska klara av att utföra file carving.
Autopsy bygger sin carving-funktion till viss del på PhotoRec, det verktyg som också QPhotoRec bygger på, med skillnaden att Autopsy utöver att läsa rådata även använder sig av filsystemsinformation om denna lämnats intakt [6].
En svårighet som kan uppstå för verktyg som utför file carving på .docx- och .pdf-filer är när försök till återskapande på fragmenterade filer görs. Det är ett vanligt problem vid file carving att filerna är uppdelade på olika platser på lagringsmediet.
Detta försvårar identifieringen av filer avsevärt då det inte på något enkelt sätt kan av- göras vilka delar av filerna som hör till vilken fil utan hjälp av filsystemsinformation.
I arbetet mäts inte hur fragmenterade filer påverkar resultaten då detta ligger utanför ramarna för projektet. Ett sätt att återskapa fragmenterade filer är att använda sig av filsystemsinformation. Det kan således ses som en svaghet i metoden att utesluta denna, men det är ett val som gjordes då denna information inte alltid finns att tillgå, och utan denna hade verktyget troligtvis inte kunnat återskapa några filer alls. Enligt Pal och Memon utvecklades file carving då den traditionella återskapningsmetoden med filsystemsinformation inte kunde användas i alla situationer [30]. Men som diskuterats kan inte heller den moderna varianten klara av detta kriterium. Ett säkrare angreppssätt hade kunnat vara att använda sig av båda metoder samtidigt och på så sätt få ett mer omfattande resultat – Fragmenterade och ofragmenterade filer (om filsystemsinformationen är intakt) eller enbart ofragmenterade filer (om denna information inte är intakt).
Det välkomnas att i framtida undersökningar använda sig av det nya verktyget och den metod som används i detta arbete för att mäta detta. Koden för det nya verktyget bifogas i denna uppsats Bilaga A. Var och en får fritt använda sig av och utveckla verktyget i den inriktning de känner att det behövs, till exempel genom att inkludera stöd för fragmenterade filer. (Licens: GNU GPL)
Hur rutinerna ser ut hos Polisen idag är en svår fråga att besvara då det kan se olika ut för olika distrikt och kontor. Till detta arbete valdes att genomföra en intervju med en verksam IT-forensiker vid Polisen i Borås. Det kan antas att det finns välplanerade metoder för hur arbetet bör gå till väga, och att arbetet utförs på liknande sätt på alla polisstationer. Det kan därför även antas att intervjun som utförs ger en rättvis och generellt övergripande bild av polisens arbete med file carving.
Detta stärks också i en rapport skriven vid Högskolan i Halmstad 2010[3] samt i en intervju i tidningen Datormagazin från samma år[22].
Det finns troligtvis en stor mängd verktyg som klarar av de uppgifter som arbetet önskar att dessa ska ha. Men det är inte praktiskt möjligt att undersöka alla verktyg som finns. Därför är detta arbete begränsat till tre stycken som enligt tidigare erfarenhet ska kunna utföra dessa funktioner. I arbetet testas dessa funktioner ånyo för att verifiera att dessa finns tillgängliga i verktyget. De aktuella funktionerna är:
Möjlighet till att återskapa raderade .docx och .pdf-filer. Att enbart file carving av .pdf- och .docx-filer undersöks kan ses som smalt, men då dessa är bland de vanligaste typerna av textfiler täcker det en stor del av den textbaserade informationen som lagras på moderna datorer [1] [21]. Huruvida resultatet av en file carving presenteras
i form av det eftersökta ordet samt dess närmaste tillhörande text eller inte avgörs enkelt vid en okulär undersökning av dessa och presenteras i rapporten.
Resultatet av tids- och minnesmätning kan variera beroende på vilket system dessa utförs på, men även på vilket dataset som testet behandlar. Vissa verktyg kan vara mer optimerat för en viss datatyp. Detta tas inte hänsyn till i detta arbete.
Dock utförs samtliga tester på samma system och detta medför att testresultaten blir rättvisa i förhållande till varandra i avseende på den aktuella filtypen.
Det finns en stor mängd olika sätt att konstruera och utveckla ett verktyg som kan lösa dessa uppgifter. Detta arbete tar endast upp ett av dessa. Metoden som valts är vattenfallsmodellen[33], där man efter en initial kravundersökning bygger funktioner efterhand som sedan slås samman till ett verktyg som kan driftsättas.
Det bedöms att denna modell passar projektet bäst utifrån satta kriterier och då det innehåller flera funktioner som är oberoende av varandra.
Kapitel 2 Teori
2.1 Microsoft Word 2007 XML Format (.docx)
2.1.1 Bakgrund
Filformatet .docx introducerades i Microsoft Office 2007 som ersättning till det tidigare filformatet .doc som standard [10] [13]. Filformatet .docx använder sig av .xml-filer som introducerades i mjukvaran Microsoft Office Excel 2002.
2.1.2 Filformat i Microsoft Word
Filformatet .doc används i mjukvarorna Microsoft Office Word 2003, Microsoft Office Word 2002, Microsoft Office Word 2000 och Microsoft Office Word 97 [10].
Även de senare versionerna av Microsoft Office Word har stöd för .doc-filer. Filfor- matet .doc har en struktur där all data, förutom tabelldatan som finns i 1Table stream eller 0Table stream, finns i huvudströmmen1vid namn Word Document stream. Detta är en av de viktiga komponenterna för .doc-filer. I början av Word Document stream ligger en struktur vid namn FIB2 som innehåller pekare till all data som finns i dokumentet. Även Clx-strukturen finns i Word Document stream och innehåller information om egenskaper i dokumentet. En Clx-struktur är konstruerad på följande vis:
• Noll eller flera Prc-strukturer
• En Pcdt-struktur som i sin tur innehåller en PlcPcd-struktur
1Main Stream
2File Information Block
Informationen om dokumentets egenskaper finns i Prc-strukturen, som är en typ av lista. PlcPcd-strukturen är en av de viktiga komponenterna i .doc-filer. Den är en struktur som kartlägger en lista av CPs3 till Pcd-strukturer. Detta betyder att den binder positioner till tecken i dataströmmen till tecken i dokumenttexten.
Nästa komponent i .doc-filer är texten i dokumentet. Denna viktiga komponent är det nämnda CP. CP innehåller själva positionen för varje tecken som finns i texten, samt en Pcd-struktur som innehåller information om både placering och egenskaper av text i dokumentet.
Plc-strukturen är den tredje och sista av de viktiga komponenterna av en .doc- fil. Plc är en lista av CPer uppföljda med fält av dataelement. Det finns olika Plc-strukturer, varav två exempel är Plcbkf-strukturen, och den nämnda PlcPcd- strukturen. Plcbkf-strukturen innehåller bokmärken och pekare till dessa bokmärken.
Strukturen redovisas nedan:
• .doc – Filformatet .doc
– Word document stream – Huvudströmmen
∗ File information block – Innehåller pekare till data i dokumentet
∗ Clx – Innehåller information om egenskaper i dokumentet
· Prc – Innehåller information om egenskaper i dokumentet
· Pcdt – Innehåller länkar mellan text i dokumentet och egenska- per i Prc *- PlcPcd – Innehåller länkar mellan text i dokumentet och egenskaper i Pcd
∗ 0Table stream – Innehåller tabelldata
∗ 1Table stream – Innehåller tabelldata
– Character – Innehåller information om tecken i dokumentet
∗ CP – Markörer som berättar var tecken ska befinna sig i dokumentet
∗ Pcd – Innehåller information om både placering och egenskaper hos text i dokumentet
– Plc – Innehåller en lista av CPer uppföljda med fält av dataelement
∗ Plcbkf – Innehåller bokmärken och pekare till dessa bokmärken
∗ PlcPcd – Innehåller länkar mellan text i dokumentet och egenskaper i Pcd
3Character position, teckenposition
2.1.3 Filstruktur i .docx-filer
Filformatet .docx är baserat på en teknologi utvecklad av Microsoft som heter Open Packaging Conventions. Filer av typen .docx är egentligen komprimerade .zip-filer, som kallas för paket. Detta paket innehåller all information som finns i dokumentet, så som all text och eventuella bilder. Att använda sig av detta paketformat gör att filerna inte tar lika mycket hårddiskutrymme jämfört med det äldre filformatet .doc. Filformatet .docx är också mer robust om det skulle hända något fel under filöverföring eller hanteringen av filer [13]. En annan punkt att notera med detta paket är att det är lätt att manipulera innehållet i det, då det enbart behövs verktyg för att öppna .zip-filer och en text-redigerare. Det finns tre viktiga föremål i .docx-filer:
• Delföremål4
• Innehållstypsföremål5
• Sambandsföremål6
Figur 2.1: En .docx-fil när den öppnas genom ett program som kan hantera .zip-filer.
Varje fil i ett paket är ett delföremål, till exempel filen [Content_Types].xml som visas i Figur 2.1 genom att filen Test.docx öppnats i mjukvara som kan hantera
4Part items
5Content type items
.zip-filer. Förutom den nämnda filen syns även mapparna _rels, docProps och word.
Innehållstypsföremålen innehåller information om vilka filformat som finns i paketet.
Om ett paket innehåller en fil av typ .jpg hanterar innehållstypsföremålen detta och gör att dokumentet öppnas rätt av Microsoft Word samt tredjepartsmjukvaror.
Sambandsföremålen är de föremål som gör att alla filer i paketet tillsammans blir ett dokument. De filer i paketet som gör detta är de som är av filtypen .rels.
2.1.4 Dokumentdelar
Alla dokumentdelar innehåller en del av det som visas i dokumentet när det öppnas i Microsoft Office Word eller annan tredjepartsmjukvara. Till exempel, om ett do- kument innehåller fotnoter så kommer det att finnas en fil vid namn footnotes.xml i dokumentet, när det öppnas med ett program som kan hantera .zip-filer. Denna fil innehåller information om fotnoterna samt all text som återfinns i dem i dokumentet.
Figur 2.2 visar ett exempel på vad ett dokument kan innehålla:
• document.xml - All text som återfinns i huvuddelen av dokumentet, det vill säga alla rubriker och brödtexter.
• endnotes.xml - Information om slutnoteringar och all slutnoteringstext.
• fontTable.xml - Information om de teckensnitt som används i dokumentet finns i denna fil.
• footnotes.xml - Information om sidfötter och all sidfotstext i dokumentet.
• settings.xml - Diverse inställningar kan hittas här, bland annat inställningar om skrivskydd av dokumentet, om dokumentet är skrivskyddat.
• styles.xml - Dokumentets stilar finns i denna fil.
• stylesWithEffects.xml - Även i denna fil finns dokumentets stilar men med ett annat syfte. Office Word 2007 och Office Word 2010 har några skillnader när det gäller stilar, där den sistnämnda har fler alternativ för att ändra hur text ser ut. När en fil skapas i Office Word 2010 och använder nya stilar, för att sedan öppnas i Office Word 2007 så kommer inte de nya stilarna att vara synliga i dokumentet. Sparas även dokumentet i 2007 versionen av mjukvaran så kommer det se likadant ut i 2010 versionen av mjukvaran när den öppnas där, utan de nya stilarna. Det som finns att göra då är att konvertera filen till det senaste filformatet med en funktion i Microsoft Office Word 2010, för att
den på så sätt ska bli kompatibel med denna mjukvara. Då syns de nya stilarna igen. stylesWithEffects.xml är alltså en fil som innehåller de stilar som inte finns i äldre versioner av Office Word mjukvaran.
• webSettings.xml - Inställningar för kompatibilitet med webbläsare.
Figur 2.2: Innehållet i word-mappen i en .docx-fil.
2.2 Portable Document Format
2.2.1 Bakgrund
På 1980-talet utvecklade Adobe Systems Incorporated ett scriptspråk vars huvudsak- liga ändamål var att rita upp dokument på skärmar eller för en skrivare som sedan skulle skriva ut dokumentet på papper. Det kunde alltså förklara för en extern skrivare exakt hur den skulle placera och formatera text, bilder, former och mycket annat.
Detta scriptspråk kallas PostScript [19] och används än idag. PostScript la grunden till vad som senare skulle bli PDF-formatet, eller Portable Document Format som det egentligen heter. Adobe valde att utgå från sitt gamla scriptspråk när de ställdes inför utmaningen att utveckla ett nytt filformat. Ett filformat som skulle kunna användas för att rita upp dokument så att de såg likadana ut oavsett vilken mjukvara de kom ifrån, på vilken mjukvara eller skrivare de skulle visas eller skrivas ut ifrån, samt vilket operativsystem som skulle användas. Men PDF är inte bara en vidareutveck-
är anpassat och optimerat för att snabbt kunna visa ett dokument exakt så som det var tänkt av skaparen. Utöver den information som visas ifrån dokumentet kan det även innehålla interaktiva element så som till exempel hyperlänkar och noteringar – något som kan underlätta för läsaren. Utöver de egenskaper som redan nämnts kan det också tilläggas att PDF-formatet kan använda sig av digitala signaturer för att säkerställa att det är äkta [20].
2.2.2 Filstruktur
En fil av typen PDF är uppbyggd av rader med hexadecimala värden som berättar för PDF-tolken (mjukvara som visar upp innehållet i filen för användaren) vad den ska göra och visa. Varje kommando avslutas med en EOL-markör (End-of-line), som till exempel CARRIAGE RETURN (0D) eller LINE FEED (0A). En PDF-fils struktur visas i Figur 2.3 [20] [27] – Först en header, därefter en body och avslutningsvis en cross reference table och en trailer.
Header Body
Cross Reference Table Trailer
Figur 2.3: Filstruktur i .pdf-filer.
Header
Headern som kommer först i dokumentet talar om vilken version som används.
Typiskt kan en första rad i en PDF-fil se ut så här:
0000000: 2550 4446 2d31 2e34 0a25 c4e5 f2e5 eba7
De åtta första nollorna är inte en del av filen, utan är en del av mjukvaran som tolkar datat som berättar att det är den absolut första raden med hexadecimala värden.
Efter detta kan själva innehållet ses. Dessa hexadecimala värden motsvarar ASCII- bokstäverna
%PDF-1.4*%******
Där % betyder att raden är en kommentar och inte ska synas när dokumentet väl öppnas upp i en mjukvara som ska presentera innehållet för användaren, och där
* motsvarar ett icke skrivbart tecken, eller tecken som har en specialfunktion. Till exempel är första * efter “1.4” en radbrytning och därmed också en “EOL”. Då nästa tecken därför påbörjar en ny rad märks den ut med en ny kommentarindikering. De sista tecknen berättar för PDF-tolken att filen innehåller binär data. Till och med version 1.3 kan mjukvara med hjälp av detta utläsa och anpassa sig efter filens version.
I senare utgåvor har dock denna funktion flyttats till version-raden i trailern och kommer att användas istället för informationen i headern om denna finns tillgänglig.
Body
Bodyn är den del som innehåller allt material som ska visas för användaren när denne öppnar upp filen i sin PDF-läsare. Vanligaste objekten är text och bilder, men även typsnitt och sidor specificeras här.
Cross Reference Table (“xref Table”)
Denna tabell innehåller pekare till olika objekt i filen. Ett exempel på innehållet i nämnda tabell kan ses i Figur 2.4.
xref 0 1
0000000020 65535 f 2 1
0000025274 00000 n 16 4
0000025316 00002 n 0000025432 00000 n 0000000016 00001 f 0000000000 00001 f 20 1
0000026849 00000 n
Figur 2.4: Exempel på cross reference table i en .pdf-fil.
Detta tillåter random access till objekten och således behövs inte hela filen sökas igenom när ett objekt skall kallas. Formateringen är utformad så att tabellen är uppdelad i flera undergrupper. I undergrupperna finns objekt som listas en och en per rad i tabellen.
Tabellen börjar alltid med kodordet xref. Här ses sedan hur undergrupperna delas upp av de rader som innehåller endast två tal. Första talet är en indikator på det första objektet i undergruppens nummer. Objektnummer efter det första i undergruppen följer alltid i stigande form om 1 (ett). Undergrupp 3 (16 4) Innehåller alltså objekt 16, 17, 18 och 19. Den andra siffran säger hur många objekt som finns i undergruppen. Själva objektsreferensen (pekaren) är alltid 20 bytes lång (inklusive EOL) och uppbyggd enligt följande:
nnnnnnnnnn ggggg q eol
där “n” är en 10 tecken lång offset som berättar var i dokumentet objektet befinner sig,
“g” är generationssiffra, “q” kan ha värdet “f” eller “n” där “f” står för om objektet är
“free” d.v.s. inte används, eller “n” som då står för att det används. Generationssiffran ökas med ett steg när ett objekt går från använd till oanvänd. Undantaget är objekt 0 som alltid har generationssiffran 65535. EOL syns inte i tabellen som nämns ovan då det är ett icke-skrivbart tecken.
Trailer
Trailern i ett PDF-dokument ligger allra sist och ser ut som visas i Figur 2.5. En PDF-tolk börjar läsa filen bakifrån. Det första den kommer att stöta på är raden
“%%EOF” (End Of File) vilket indikerar slutet på filen. Därefter hittar den två linjer som börjar med “startxref” vilket indikerar att följande linje innehåller offset för var cross reference table (xref) börjar. Nästa del har nyckelordet ”trailer” och håller sin information mellan två punkter som börjar med “«” och slutar med “»”. ”keyn”
substitueras med namnet på egenskapen som kontrolleras och ”valuen” med värdet på denna.
Några exempel på Key’er som kan eller måste förekomma är: Size: Totala antalet objekt i Cross Reference tabellen, Root: Pekar på ett specialobjekt som innehåller en rad pekare till andra specialobjekt, Encrypt: Filens krypteringsordbok, ID: Fil-identifierare.
trailer
«
key1 value1 key2 value2 . . .
keyn valuen
»
startxref
Byte_offset_of_last_cross-reference_section
%%EOF
Figur 2.5: Trailerns struktur i en pdf-fil.
2.3 File carving
2.3.1 Hårddiskar och filsystemet FAT
För att förstå filsystemet NTFS börjar vi med att titta på dess föregångare: FAT. Detta filsystem har funnits i många versioner under åren, men i modern tid har det fått ge plats åt det nyare filsystemet NTFS när det gäller hårddiskar. Det är fortfarande vanligt i minneskort.
Data lagras på lagringsmedium. Ett sådant media är en hårddisk. En hård- disk består av flera block där data lagras. Dessa block kallas sektorer och clustrar.
Sektorer är den minsta enheten och flera av dessa utgör tillsammans ett cluster.
Clusterstorleken avgörs dels på hur många sektorer det går på clustret, men även hur stor sektorstorleken är. Diskstorleken i sin tur beror på clusterstorleken samt antalet clustrar. En hårddisk kan enbart skriva till en ensam sektor om clustret bara innehåller denna sektor. Det är alltså clustret som är den minsta skrivbara delen av en hårddisk. Är clusterstorleken 2 KB och det skrivs en fil på 4,1 KB så kommer alltså totalt tre stycken cluster (eller 6 KB) av hårddisken att tas i bruk på grund av detta. Att en fil måste delas upp på detta sätt är inte ovanligt. Det beror på att den förinställda clusterstorleken på moderna lagringsmedier (16-32 GB) ligger på 16 KB när filsystemet FAT32 används [11], och större clusterstorlek leder till mer förlust i lagringskapacitet [15].
Om hårddisken har flera intilliggande clustrar som är lediga så kommer datan
att skrivas efter varandra på dessa. Men om intilliggande cluster #3, som skulle användas till den 4,1 KB stora filen, skulle vara upptagen med annan data kommer hårddisken att istället titta på nästa cluster om den är ledig. Är den det så skrivs de sista 0,1 KB till cluster #4. Detta kallas filfragementering [17]. Fragmentering blir vanligare när hårddisken börjar närma sig fyllt läge. Detta beror på att hårddisken när den börjar närma sig slutet, börjar leta efter oallokerade clustrar över hela disken för att fylla med den data som inte får plats mot slutet. Operativsystemet arbetar aktivt med att försöka undvika fragmentering, men det är inte alltid möjligt. Anledningen till att operativsystemet ser det som ej önskvärt är att tiden att läsa in filerna kommer att öka när datorn tvingas läsa av ett större område på hårddisken för att läsa in hela filen. Fragmentering kan också innebära problem för den som försöker återskapa raderade filer, då verktyg ibland kan ha svårt för att hitta de delar som inte ligger i anslutning till de första [14].
Information om filers namn samt placering sparas i filtabellen (FAT). När data sedan ska läsas letar datorn upp vilket cluster filen börjar på i denna tabell. När den har hämtat första clustret kan den i slutet av detta utläsa var nästa cluster börjar så att den kan läsa in även den delen. Så fortsätter processen tills den når markören FF (ett hexadecimalt värde) i slutet av sista clustret som är dess EOF [30].
2.3.2 NTFS och radering av filer
NTFS har ingen filtabell i samma bemärkelse, men något liknande: först och främst har den en MFT (Master File Table) [18] Detta är konceptuellt likt en FAT, men kan förutom namn och pekare även hålla hela mindre filer. Detta gör att åtkomst till dessa filer blir väldigt snabb, då MFT är den första platsen som datorn letar på. Hade den använt FAT hade den istället först få gå till tabellen för att ta reda på vilket cluster den skulle gå till, för att sedan börja läsa filen. För stora filer används det pekare. Är det mindre mappinlägg (mappinläggen visar vilka clustrar som filerna befinner sig på) kan dessa, precis som för de mindre filerna, sparas direkt i MFT för snabb åtkomst.
Större inlägg måste sparas utanför. Pekare till dessa lagras i så kallade b-träd [4] [32]
som är en teknik som används för att lagra och läsa information från databaser.
B-träd är en struktur som möjliggör mycket snabb sökning tack vare dess uppbyggnad med flerdelade grenar i varje nod, i motsats till konventionella binära trädstrukturer som bara kan ha två grenar på varje nod (se Figur 2.6 för en visuell jämförelse av dessa två typer av trädstrukturer). Detta gör stegen färre från nod 1 till slutnod och minskar därmed processtiden. Noderna är också sorterade i sådan
ordning att datorn direkt matematiskt kan räkna ut vilken väg den ska gå och behöver således inte söka igenom hela trädet, utan kan direkt följa vägen till korrekt nod.
Programmet som sköter uträkningen lagras i RAM-minnet vilket ytterligare påverkar processtiden positivt.
Figur 2.6: Konventionell trädstruktur jämfört med b-träd.
När korrekt nod har hittats utläses vilket cluster den aktuella filen med mappin- lägg befinner sig på och datorn kan börja läsa in filen. När det är gjort vet datorn var den önskade filen finns och kan börja läsa in denna. Varje cluster får också ett existensvärde i $bitmap-filen som sätts till 1 om filen existerar och 0 om den är borttagen. Om filen är borttagen finns alltså själva datan kvar på samma fysiska plats som tidigare, men utrymmet som den är sparad på är nu markerad som oallokerat (tomt) i filsystemet. Filen syns således inte längre i datorns operativsystem. Däremot blir utrymmet öppet för överskrivning när andra data behöver platsen. Det är därför viktigt att utföra så kallad file carving (mer om detta i nästa stycke) tidigt då det ökar chanserna att få ett positivt resultat [2]. Ju mer hårddisken används efter att filen har
“raderats” desto större risk är det att området där den låg blir överskrivet av annan data och det kan resultera i att filen inte går att återskapa alls, eller enbart delvis. Ett mer tidkrävande sätt att radera filer (men också mycket säkrare) är att utföra en så kallad wipe [8] av hårddisken. Då skrivs allt innehåll över med nollor (0). På detta sätt försvåras arbetet med att försöka återskapa någon data.
2.4 Återskapande av raderade filer - File carving
En raderad fil behöver inte vara borta för evigt. Idag består en stor del av det polisiära forensiska arbetet av att försöka återskapa filer som någon har försökt dölja eller som har blivit raderade av annat skäl [7]. Så här förklarar Rohit Shaw, INFOSEC [34]
vad definitionen av file carving är:
“File carving is a process used in computer forensics to extract data from a disk drive or other storage device without the assistance of the file system that originality [sic] created the file.”
Det finns två metoder att återskapa borttagen data på, enligt Anandabrata Pal och Nasir Memon [30]. Den enklare metoden är den traditionella dataåterskapningsme- toden som använder sig av filsystemsstrukturen (som till exempel filtabeller) samt filsystemets metadata för att återskapa filer som blivit borttagna. Metoden utnyttjar filsystem som inte raderar data på det fysiska lagringsmediet. Filsystemet markerar enbart utrymmet som den “raderade” datan var placerat på som ledig för ny data, dock ligger information om filen kvar i filtabellen. Om det utrymmet inte blivit överskrivet med annan data ska det vara enkelt, enligt Pal och Memon, att återskapa denna.
Den andra metoden använder sig av filstrukturer och innehåll av filer för att återskapa filer, och är den nyare och mer avancerade metoden. Detta kan förklaras med att istället för att titta i ett register över var “raderade” filer finns, så tittas det direkt på disken och den data som finns där. Det går med hjälp av olika program att läsa in dessa ettor och nollor och få dem tolkade i så kallade hexadecimala värden.
Med dessa värden kan man se mönster som indikerar vad det är för typ av fil. Dessa mönster återfinns i början av filer, i den så kallade headern och kallas filsignatur. När vilken typ av fil är under kännedom kan arbetet påbörjas med att försöka tolka den rådata som följer. Det är denna metod som det nya verktyget kommer att grundas på. Eftersom metoden inte använder sig av filsystemsstrukturen kan återskapande av data göras på oallokerat utrymme. Denna metod blev introducerad då den traditio- nella dataåterskapningsmetoden misslyckats på dataset vars filsystemsinformation saknades eller var skadad.
2.5 Matematisk grund
För att läsaren av detta arbete lättare ska förstå de påstående som återfinns i resultat- delen förklaras de matematiska metoder som använts.
2.5.1 ANOVA
ANOVA står för Analysis of Variance [25] och är ett matematiskt test av skillnader i väntevärden mellan flera grupper. De används för att avgöra med en viss säkerhet om skillnad i medelvärde mellan grupperna inte bara beror på slumpen utan är bevis för en skillnad i väntevärdena, vilket kallas ett signifikant resultat. Det finns olika varianter av ANOVA, så som envägs-ANOVA och tvåvägs-ANOVA. En viktig poäng med ANOVA är att ett sådant test enbart bestämmer om det finns en skillnad mellan grupperna som det utförs på, men visar inte vilka grupper vars väntevärden skiljer sig åt. För att undersöka vilka grupper det är som skiljer sig åt, vid ett resultat där ANOVA-testet visar sig vara signifikant, kan det utföras ett post hoc-test utöver ANOVA-testet.
Grupperna i en ANOVA kan till exempel vara personer av olika kön, olika sorters TV-apparater eller, som i detta projekt, olika verktyg. Grupperna kallas också för de oberoende variablerna. När grupperna är valda väljs egenskaper som mäts mellan dessa grupper, till exempel längd eller vikt. Längden och vikten hade i exemplet kallats för de beroende variablerna.
2.5.2 Post hoc-test
Är de oberoende och beroende variablerna valda kan ANOVA-tester utföras, och eventuellt post hoc-testas vid signifikant resultat av ANOVA-test. Ett post hoc-test används, som nämndes i sektionen ovan, när det är viktigt att se vilka grupper det är som skiljer sig från varandra [28]. När ett post hoc-test visar ett signifikant resultat mellan de diverse grupperna bevisar det att grupperna inte har en skillnad som är slumpmässig. Det finns ett flertal olika sorters post hoc-test, dock valdes enbart Tukey’s test i detta projekt. Detta på grund av att Tukey’s test jämför alla gruppers medelvärden mot varandra samt att Tukey’s test är ett lämpligt val då grupperna är homoskedastiska, det vill säga, har samma varians, enligt Lehmann och Shaffer [26].
Kapitel 3
Genomförande
3.1 Förberedelse
3.1.1 Data-set
För att testerna ska kunna utföras med verktygen behövs dataset. I detta arbete skapas det 10 olika dataset i varierande storlek, och med olika antal filer i sig. De 10 datasetens egenskaper är:
1. 5.65 MB, 111 filer.
2. 12.8 MB, 224 filer.
3. 13.1 MB, 41 filer.
4. 9.66 MB, 494 filer.
5. 108 MB, 236 filer.
6. 364 MB, 338 filer.
7. 453 MB, 21 filer.
8. 247 MB 145 filer.
9. 2.76 MB, 6016 filer.
10. 390 MB, 37 filer.
Experimentet utförs på ett dataset åt gången, där en wipe (se 2.3.2 NTFS och radering av filer) utförs på partitionen mellan varje dataset. Varje dataset består av fem .docx-filer samt fem .pdf-filer. I dataseten innefattas det även filer av andra
3.1.2 Hårdvara
Partitionen som dataseten förs in på befinner sig på en extern mekanisk hårddisk med följande specifikation:
Märke: Western Digital Modell: WD My Passport 0730
Storlek: 500 GB Partitionsstorlek: 512 MB
Filsystem: NTFS
Anslutningstyp: USB 3.0 med kompabilitet för USB 2.0
Testerna utförs på ett datorsystem med följande specifikation:
Märke: Dell Modell: Optiplex 990
Operativsystem: Windows 7 Enterprise 64-bit Sp1 Processor: Intel core i5-2400 3.10Ghz
RAM-minne: 16 GB Anslutning till hårddisk: USB 2.0
Valet att begränsa partitionsstorleken till 512MB kom till då det tidigare be- stämts att dataseten inte skulle vara större än så. Detta för att hålla den totala mängd bearbetade datan under en nivå som var lämplig. Större mängd data resulterar na- turligt i längre utvinnings- och sökprocesser och då laborationstiden var begränsad valdes det att även begränsa mängden data. Huruvida detta påverkar resultaten mellan de olika verktygen eller inte undersöks inte.
3.1.3 Egenskaper hos verktyg
Under experimentet undersöks det som följer:
Fas 1 (innan utvinning)
Har verktygen följande önskvärda egenskaper?
• Verktyget är under 100 MB stort.
• Verktyget behöver inte installeras på systemet för att kunna köras.
• Det krävs färre än fem stycken musklick och textinmatningar för inställningar innan utvinning och sökning kan påbörjas.
• Verktyget har hjälptext som vägleder användaren genom inmatning av inställ- ningar.
Mindre mjukvaror som inte behöver installeras, med ett lågt antal behövda inter- aktioner innan processen kan börja kan vara fördelaktigt i till exempel situationer där utvinningar och sökningar måste ske ”live” [31] på systemet. Det vill säga där man inte först gör en avbild av hårddisken för att sedan analysera i ett labb. Detta är fördelaktigt om resultatet måste presenteras direkt.
Fas 2 (utvinning)
• Processtid: Hur lång tid tar utvinnings- och sökprocessen?
• Minnesanvändning: Hur mycket arbetsminne utnyttjar processen? (Använt minne under processen minus använt minne före processen mätt i MB) Fas 3 (efter utvinning)
Har verktygen följande önskvärda egenskaper?
• Verktyget visar alla filer som innehåller det eftersökta ordet.
• Verktyget visar inte filer som inte innehåller det eftersökta ordet.
• Verktyget visar resultat både i form av filnamn och en förhandsvisning av den rad i dokumentet där ordet förkommer.
• Verktyget visar sökväg till dokumentets plats.
• Verktyget kan exportera resultaten.
• Verktyget kontaminerar inte.
3.2 Utveckling av nytt verktyg
Förutom att sedan tidigare existerande verktyg testas, utvecklas även ett nytt verktyg med syfte att lösa det scenario som angetts ovan i Sektion 1.4 Scenario på bästa möjliga sätt. En skillnad mellan det nyutvecklade verktyget och verktygen som
sådant sätt som det aktuella scenariot kräver. Dessutom är det nyutvecklade verktyget kostnadsfritt samt framtaget för att vara lättanvänt, lättdrivet och för att producera lika bra, om inte bättre, resultat än de andra verktygen.
3.2.1 Vad ska verktyget göra?
Tanken är att raderade .docx-filer, det vill säga rådata från dessa filer som är markerad som borttagen på ett lagringsmedium, ska kunna hittas och utvinnas med hjälp av verktyget. Därefter ska verktyget extrahera de filer som finns i .docx-filen till en mapp med ett relevant namn för filen. Verktyget ska sedan hämta all text från .docx- filen genom att regular expressions på de filer som blivit extraherade ur .docx-filen används för att hitta text som följer ett specifikt mönster. Ett exempel på det nämnda är följande. All text som finns i body-delen av .docx-filen finns i filen document.xml i en mapp vid namn word. När all text från .docx-filen sparats i en .txt-fil så kommer verktyget att fråga efter ett nyckelord. Verktyget kommer sedan att söka genom .txt-filen efter detta nyckelord och om det hittas så kommer verktyget att visa den mening som nyckelordet finns med i.
3.2.2 Planering
Verktyget kommer att skapas del för del, det vill säga flera olika verktyg kommer att utvecklas för att sedan slås ihop till ett. Dessa verktyg kommer att ha alla de basfunktioner som ska vara implementerade i den slutliga versionen av verktyget.
Till att börja med skapas ett verktyg som kan extrahera filer från zip-arkiv, för att kunna extrahera de filer som finns inuti .docx-filen. Innehållet i filen behövs för fortsatt bearbetning av informationen. Det andra verktyget som kommer att utvecklas ska extrahera all text som finns i .docx-filerna till en .txt-fil genom att använda sig av de extraherade filerna som det första verktyget hämtat. Steg tre är att det utvecklas ett verktyg som kan söka efter ord som användaren skriver in i programmet. All text som finns i de textfiler som verktyg nummer två extraherat söks igenom och om verktyget hittar en matchning så visas den mening i verktyget som nyckelordet matchades till. Slutligen kommer det att utvecklas ett fjärde verktyg för att carva ut .docx-filer från rådata. När de fyra verktygen är utvecklade kommer de att sättas ihop till ett enda verktyg, som sedan finslipas och förbättras. Verktygets olika delar och egenskaper är sammanfattningsvis följande:
1. En del där filer extraheras ur zip-arkiv, vid namn extrZData.
