Forensically Sound Data Acquisitionin the Age of Anti-Forensic Innocence

Forensisch korrekte Datensicherungim Zeitalter anti-forensischer Arglosigkeit

Der Technischen Fakultät derFriedrich-Alexander-Universität

Erlangen-Nürnbergzur

Erlangung des Doktorgrades Dr.-Ing.vorgelegt von

Michael Gruhn

aus Bad Windsheim

Als Dissertation genehmigt vonder Technischen Fakultät derFriedrich-Alexander-Universität Erlangen-NürnbergTag der mündlichen Prüfung: 2016-11-24

Vorsitzender des Promotionsorgans: Prof. Dr.-Ing. Reinhard Lerch

Gutachter: Prof. Dr.-Ing. Felix FreilingProf. Dr. Zeno Geradts

Abstract

In this thesis, we tackle anti-forensic and rootkit problems in digital forensics. An anti-forensictechnique is any measure that prevents a forensic analysis or reduces its quality.First, we investigate the anti-forensic threat of hard drive firmware rootkits, which can prevent aforensic analyst from acquiring data from the hard drive, thus jeopardizing the forensic analysis. Tothis end, we first outline the threat of hard drive firmware rootkits. We then provide a procedureto detect and subvert already published hard disk drive firmware bootkits. We further outlinepotential avenues to detect hard drive firmware rootkits nested deeper within the hard disk drive’sso-called Service Area, a special storage on the magnetic platter reserved for use by the firmware.After addressing the acquisition of persistent data storage in form of hard disk drives, we shifttowards acquisition and later analysis of volatile storage, in the form of RAM. To this end, we firstevaluate the atomicity and integrity as well as anti-forensic resistance of different memory acquisitiontechniques with our novel black-box analysis technique. This black-box analysis technique in whichmemory contents are constantly changed via our payload application with a traceable accesspattern, allows us to measure to which extent current memory acquisition methods satisfy atomicityand integrity when dumping the memory of processes. We also discuss their resistance againstanti-forensics. As a result, we show that cold boot attacks belong to the most favorable memoryacquisition techniques.We then investigate cold boot attacks in more detail. First, we experimentally confirm that coolingthe RAM modules prolongs the remanence effect considerably. We then prove also experimentallythat transplanting RAM modules from one system to another is possible. We further address theissue scrambling in modern DDR3 technology as well as other proposed countermeasures, suchas BIOS passwords and temperature detection. We also show that once a system is cold-booted,malicious anti-forensic code running on the system stops running immediately and can thus nolonger interfere with the memory acquisition. Therefore, we show the practical feasibility of coldboot attacks as anti-forensic resistant memory acquisition method.After outlining the anti-forensic resistant acquisition of evidence we address the analysis. To thisend, we first revisited the theory of data analysis, especially the concept of essential data in forensicanalysis as coined by Carrier in his seminal work “File System Forensic Analysis”. We first extendCarrier’s concept by differentiating different levels of essentiality. We introduce the notion of strictlyessential data, which refers to data that is always required to be correct and non-manipulated byall systems to provide a specific functionality, and partially essential, which is only required tobe correct and non-manipulated for some systems. We then practically verify both the originaltheories and our extensions in experiments. Eventually, we argue that essential data can helpto build a trust hierarchy of data encountered during forensic analysis, from which we concludethat anti-forensic resistant analysis methods must only rely on what we call strictly essential, i.e.,trusted, data, otherwise, the analysis is potentially impaired by anti-forensic measures becausenon-essential data can be freely manipulated without impacting the correct working of a system.Last but not least, we tackle a long unsolved problem in forensic memory analysis: Currently, allstate-of-the-art digital forensic virtual memory analysis tools ignore unmapped memory pages, i.e.,pages swapped out onto persistent storage. This can result in blind spots in which data and thuspotential evidence is not analyzed. We fix this by analyzing the Windows NT virtual memory pagingvia a novel gray-box analysis method. To this end, we place traceable data into virtual memory andforce it into both the physical RAM as well as the pagefile stored on persistent storage. We are thusable to reverse engineer the complete virtual address mapping, including the non-mapped pagefile.We evaluate our analysis results against real world data from Windows 7, 8, and 10 systems in boththe 32 and 64-bit variants. By shedding light on this last blind spot of virtual memory analysiswe increase its anti-forensic resistance, because we can now for the first time analyze the virtualaddress space in its entirety.

Zusammenfassung

Diese Arbeit befasst sich mit der Anti-Forensik und Rootkit Problematik in der digitalen Forensik.Eine anti-forensische Technik ist jede Maßnahme die eine forensische Analyse verhindert oder IhreQualität mindert.Zuerst wird die anti-forensische Bedrohung durch Festplatten Firmware Rootkits untersucht, welcheeinen forensischen Analysten davon abhalten können Daten zu sichern, und dadurch die Analysegefährden. Hierzu skizzieren wir zunächst die Bedrohung durch Festplatten Rootkits. Dann stellenwir eine Prozedur vor mit der bereits veröffentlichte Rootkits erkannt und unterbunden werdenkönnen. Wir zeigen potenzielle Wege zur Auffindung von Rootkits, die tiefer in der FestplattenFirmware, in der sogenannten Service Area, einem speziellen Speicherbereich reserviert für dieBenutzung durch die Firmware, verankert sind.Nach dem Problem der Datensicherung von Festplatten widmen wir uns der Sicherung und späterenAnalyse von flüchtigen Daten in Form von RAM. Hierzu evaluieren wir zuerst die Atomarität undIntegrität, aber auch die anti-forensische Resistenz verschiedener Techniken zur Hauptspeichersi-cherung mit unserer neuartigen Black-Box Analyse Methode. Diese Analyse Methode, in der dieSpeicherinhalte durch unsere Anwendung permanent durch ein verfolgbares Zugriffsmuster verändertwerden, erlaubt es uns zu messen zu welchem Grad aktuelle Methoden zur Hauptspeichersicherungatomar und integer sind beim Auslesen des Speichers von Prozessen. Wir erörtern des weiterenderen Resistenz gegen Anti-Forensik. Das Resultat zeigt, dass der Cold Boot Angriff eine bevorzugteTechnik zur Hauptspeichersicherung ist.Wir haben deshalb den Cold Boot Angriff im Detail betrachtet. Zuerst haben wir experimentellbestätigt, dass das kühlen des RAMs den Remanenz Effekt beachtlich verlängert. Wir zeigen,ebenfalls experimentell, dass das Transplantieren von RAM Modulen von einem System zum anderenmöglich ist. Des weiteren befassen wir uns mit dem Problem des Scramblings der modernen DDR3Technologie und weiteren Gegenmaßnahmen wie BIOS Passwörtern und Temperatur-Überwachung.Wir zeigen ebenso, dass durch das kalte Neustarten Anti-Forensik Code der auf dem Systemausgeführt wird sofort in seiner Ausführung unterbrochen wird und daher nicht weiter bei derHauptspeichersicherung interferieren kann. Dadurch zeigen wir sowohl die praktische Anwendbarkeitalso auch die Anti-Forensische Resistenz des Cold Boot Angriffes.Nach dem Aufzeigen anti-forensisch resistenter Sicherung von Beweisen wenden wir uns der Analysezu. Hierzu erweitern wir zunächst das Konzept von essentiellen Daten wie es von Carrier in seinerwegweisend Arbeit “File System Forensic Analysis” vorgestellt wurde. Wir erweitern CarriersKonzept durch die Unterscheidung zwischen strikt essentiellen Daten, die immer korrekt undnicht manipuliert seien müssen damit alle Systeme eine spezifische Funktion zur Verfügung stellenkönnen und partiell essentiellen Daten, die nur für manche System korrekt und nicht manipuliertseien müssen. Danach verifizieren wir die originale Theorie und unsere Erweiterung in praktischenExperimenten. Zum Ende argumentieren wir, dass essentielle Daten helfen eine Vertrauens Hierarchieder Daten die in einer forensischen Analyse vorgefunden werden zu erstellen, aus welcher wirschließen können, dass anti-forensisch Resistente Analyse Methoden nur solche Daten verwendendürfen die strikt essentiell sind, da sonst die Analyse potenziell durch anti-forensische Maßnahmenbeeinträchtigt wird, weil nicht essentielle Daten frei manipulierbar sind ohne die Funktionalitäteines Systems einzuschränken.Zuletzt widmen wir uns einem lange ungelösten Problem in der forensischen Hauptspeicheranalyse.Zur Zeit ignorieren alle gängigen forensischen Methoden zur Hauptspeicheranalyse ausgelagerteSpeicherseiten, d. h. virtuelle Speicherseiten die auf persistenten Speicher ausgelagert wurden.Dies resultiert in durch die Analyse nicht einsehbare Speicherbereiche in denen sich potenziellBeweise befinden können. Wir treten dem entgegen indem wir die virtuelle Speicherverwaltungvon Windows NT mit einem Gray-Box Analyse Ansatz untersuchen. Hierzu plazieren wir rückverfolgbare Daten sowohl in den physischen RAM als auch die Auslagerungsdatei. Dadurch könnenwir den kompletten virtuellen Adressraum mitsamt der Auslagerungsdatei rekonstruieren. Wirevaluieren unseren Ansatz gegen Windows 7, 8 und 10, in den 32 und 64-bit Varianten. Indemwir diese zuvor nicht einsehbaren Speicherbereiche der Hauptspeicheranalyse zuführen stärken wirderen anti-forensische Resistenz, da man nun den kompletten Adressraum analysieren kann.

Acknowledgments

First and foremost, I would like to thank my doctoral advisor Felix Freiling for giving me theopportunity to work with him at his Security Research Group at the Department of ComputerScience at the Friedrich-Alexander University Erlangen-Nürnberg, his continuous advice, andsupport. Without him, this thesis would not exist. I would also like to thank Zeno Geradts, foragreeing to be the second reviewer to this thesis, and for the stimulating discussions we had whilemeeting at conferences — I’m looking forward to the next. I also thank my colleagues at theSecurity Research Group, for a cheerful and friendly working atmosphere.

In addition, I want to thank (in alphabetical order): Johannes Bauer for proof-reading parts of thisthesis, recommending the Grammarly grammar checker and, last but not least, collaborating on theDDR3 descrambling attack; Andreas Dewald for helpful input to the formalization of the essentialdata theory, proof-reading publications this thesis is based on, and being my group-leader for myfirst 1.5 years of research; Christian Moch for interesting discussions, sharing ideas, the deathmochexploit and proof-reading this thesis; Tilo Müller for the LATEX template this dissertation started outto be based on, proof-reading, advising and collaborating on publications this thesis is based on, andbeing my group-leader for the last year of research for this thesis (even though he is not a forensicguy himself); Andreas for proof-reading parts of this thesis; Johannes Stüttgen for the hint to theAcademic-Writing-Check project; the anonymous reviewers of the publications this thesis is based on.

Corporate acknowledgments:This work was supported by the online study program Master Digitale Forensik, the GermanFederal Ministry of Education and Research (BMBF) via the project Open Competence Center forCyber Security (Open C3S), the German Research Foundation (DFG) as part of the TransregionalCollaborative Research Centre “Invasive Computing” (SFB/TR 89) and the German FederalMinistry of Education and Research (BMBF) via the project Parallelized Application Detection inOverlays for Firewalls (Padiofire).

Contents

1 Introduction 11.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Background 82.1 Forensics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Anti-forensics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Rootkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Persistent data acquisition (from hard drives) 153.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 HDD anatomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.2 HDD firmware analysis software . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Hard disk firmware bootkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.1 Compromising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.2 Interfering with data acquisition . . . . . . . . . . . . . . . . . . . . . . . . 203.2.3 Detection (in EEPROM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.4 Subverting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.5 Investigating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Overlay/module-based hard disk firmware rootkit . . . . . . . . . . . . . . . . . . . 283.3.1 Verifying overlays/modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.2 Memory analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.1 Compromise in EEPROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.2 Compromise in Service Area . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.3 Compromised controller hardware . . . . . . . . . . . . . . . . . . . . . . . . 313.4.4 SSDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5 Conclusion and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

i

Contents

4 Memory acquisition evaluation 354.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Background: Criteria for forensically sound memory snapshots . . . . . . . . . . . 374.2.1 Atomicity of a snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.2 Integrity of a snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Black-box measurement methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.2 Estimating atomicity and integrity . . . . . . . . . . . . . . . . . . . . . . . 384.3.3 Intuitive examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.4 Practical constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4.2 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4.3 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4.4 Analyzed methods and tools . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5.1 Measurement accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5.2 Individual results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5.3 Atomicity and integrity comparison . . . . . . . . . . . . . . . . . . . . . . 484.5.4 Anti-forensic resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.6 Conclusions and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 Memory acquisition (via cold boot attacks) 515.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.1.2 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2.2 Test data placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2.4 Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.3.1 Ground state patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.3.2 Cached data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.4.1 Remanence effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.4.2 Temperature and RAM remanence . . . . . . . . . . . . . . . . . . . . . . . . 615.4.3 RAM transplantation attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.5 Bypassing countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.5.1 Descrambling DDR3 memory . . . . . . . . . . . . . . . . . . . . . . . . . . 655.5.2 RAM reset on boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.5.3 Locking the boot process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.5.4 Temperature detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.5.5 0x7c00 defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.6.1 CPU-bound encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.6.2 RAM encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.7 Conclusion and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

ii

Contents

6 Essential data and anti-forensics 716.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.1.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.1.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2 Definition of essential data by Carrier and its problems . . . . . . . . . . . . . . . . 736.2.1 Problem 1: Definition depends on assumed basic functionality . . . . . . . . 746.2.2 Problem 2: Definition depends on application . . . . . . . . . . . . . . . . . 756.2.3 Problem 3: Definition cannot deal with redundant information . . . . . . . 75

6.3 What is essential data? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.4.1 DOS/MBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.4.2 GPT header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.5.1 Usefulness of new definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.5.2 Trust hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.5.3 Evidence hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.6 Conclusions and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7 Virtual memory analysis (on Windows NT) 857.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.1.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.2 Grey-box virtual address translation analysis . . . . . . . . . . . . . . . . . . . . . 867.2.1 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.2.2 Test data generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.2.3 Inferring the virtual address translation . . . . . . . . . . . . . . . . . . . . 88

7.3 Windows NT x86 and x64 virtual memory overview . . . . . . . . . . . . . . . . . 897.3.1 Pagefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.3.2 Page table entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.3.3 Virtual address translation . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.4 Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957.4.1 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957.4.2 Pagefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.5 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.5.1 Finding DirectoryTableBase . . . . . . . . . . . . . . . . . . . . . . . . . . 967.5.2 Reconstructing the virtual address space . . . . . . . . . . . . . . . . . . . . 977.5.3 Analyzing the virtual address space . . . . . . . . . . . . . . . . . . . . . . 97

7.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.6.1 Problem cases of virtual memory analysis . . . . . . . . . . . . . . . . . . . 987.6.2 Synthetic data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.6.3 Real life data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.7 Conclusion and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

8 Conclusion and future work 105

Bibliography 109

iii

List of Figures

3.1 HDD anatomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Identifying the EEPROM of a Western Digital WD3200AAKX HDD . . . . . . . . . 213.3 Reading an EEPROM with an in-circuit programming clamp without desoldering . 223.4 Reading the EEPROM after it has been desoldered from the HDD’s PCB . . . . . 223.5 Holding a board in reset by pulling the processor’s reset pin . . . . . . . . . . . . . 233.6 Reset and ground pins to be connected for in-circuit reading from an ST31000340NS 233.7 Cross-comparisons of the EEPROM contents of different WD3200AAKXs . . . . . 243.8 Cross-comparisons of the EEPROM contents of a bootkit infected WD3200AAKXs 263.9 JTAG pin layout of the WD3200AAKX . . . . . . . . . . . . . . . . . . . . . . . 293.10 Wires soldered to the JTAG pins of a WD32000AAKX . . . . . . . . . . . . . . . . 293.11 A MICTOR 38 pin connector soldered to the JTAG test pads of a WD32000AAKX 293.12 UART pin layout of Seagate HDDs . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Space-time diagram of an imaging procedure creating a non-atomic snapshot . . . 374.2 Integrity of a snapshot with respect to a specific point in time t . . . . . . . . . . . 384.3 Atomicity and integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4 Acquisition plot of pmdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5 Memory acquisition technique comparison (acquisition plot) . . . . . . . . . . . . . 474.6 Memory acquisition technique comparison (acquisition density plot) . . . . . . . . 484.7 Each acquisition position inside an atomicity/integrity matrix . . . . . . . . . . . . 48

5.1 Abstract setup of our experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2 RAM module covered in cooling agent . . . . . . . . . . . . . . . . . . . . . . . . . 555.3 Illustration of different ground state patterns . . . . . . . . . . . . . . . . . . . . . 575.4 Observed cache effects due to missing cache write back . . . . . . . . . . . . . . . . 585.5 Scrambling patterns in DDR3 systems after a cold reboot . . . . . . . . . . . . . . 605.6 Mona Lisa picture series as recovered after a cold boot attack . . . . . . . . . . . . 605.7 RAM remanence of systems A to G and system J . . . . . . . . . . . . . . . . . . . . 615.8 RAM remanence of systems A, B, F, G and J over time and at different temperatures 625.9 Beginning of “Alice’s Adventures in Wonderland” recovered from a cold boot attack 645.10 Scrambled storage of data and image acquisition . . . . . . . . . . . . . . . . . . . 65

6.1 Typical partition entry in partition table . . . . . . . . . . . . . . . . . . . . . . . . . 716.2 Example of essential and non-essential data . . . . . . . . . . . . . . . . . . . . . . 73

7.1 Grey-box virtual address translation analysis scheme . . . . . . . . . . . . . . . . . 877.2 32-bit Paging PTE structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.3 Windows NT 32-bit Paging structures . . . . . . . . . . . . . . . . . . . . . . . . . 907.4 x86 PAE Paging structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917.5 x64 IA32e Paging structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927.6 Windows NT x64 paging structures . . . . . . . . . . . . . . . . . . . . . . . . . . . 937.7 Windows NT Demand Zero PTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937.8 Windows NT Pagefile PTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947.9 Windows NT Transition PTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947.10 Windows NT Prototype PTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

iv

List of Tables

3.1 Analyzed HDDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Comparison of worst case atomicity and integrity deltas . . . . . . . . . . . . . . . 49

5.1 List of tested computer systems and their corresponding RAM type and model . . 535.2 Ground state and bit decay relationship . . . . . . . . . . . . . . . . . . . . . . . . 575.3 List of observable RAM remanence in our test systems . . . . . . . . . . . . . . . . 595.4 Temperatures and bit errors for cold boot attacks with RAM transplantation . . . 635.5 BIOS password circumvention methods for the various systems tested . . . . . . . 675.6 Temperatures and bit errors for several transplantations without cooling . . . . . . 68

6.1 MBR partition table entry data fields and their type . . . . . . . . . . . . . . . . . 786.2 MBR data fields and their type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.3 GPT header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.1 Size value for signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977.2 Problem cases of virtual memory analysis . . . . . . . . . . . . . . . . . . . . . . . 997.3 Results of reconstructing synthetic data . . . . . . . . . . . . . . . . . . . . . . . . . 1017.4 Results of reconstructing real life data . . . . . . . . . . . . . . . . . . . . . . . . . 102

v

Listings

2.1 Partition table of extended partition loop exploit as displayed by fdisk . . . . . . . 112.2 Comment in foremost 1.5.7 source code file engine.c outlining an unfixed problem 12

3.1 OpenOCD command to dump memory sections of a WD3200AAKX HDD . . . . . 303.2 Boot message on UART from Seagate ST2000DM001 . . . . . . . . . . . . . . . . . 303.3 Displaying the available commands over the ST2000DM001’s UART . . . . . . . . . 31

4.1 Command to dump the lowest 2GiB of memory from QEMU into the file qemu.mem 434.2 Command to dump the memory from a VirtualBox virtual machine . . . . . . . . 434.3 inception indicating initialization of the IEEE1394 bus . . . . . . . . . . . . . . . 444.4 Commandline used to invoke ProcDump . . . . . . . . . . . . . . . . . . . . . . . . . 454.5 Invoking ProcDump leveraging process cloning for acquisition . . . . . . . . . . . . . 45

5.1 Program to replace any character outside the ASCII printable range with a star . . 64

7.1 Pagefile registry entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.2 Pagefile registry entry format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.3 WinDbg displaying memory layout of _MMPAGING_FILE structure . . . . . . . . . . 897.4 Extracting the pagefile.sys with the Sleuthkit . . . . . . . . . . . . . . . . . . . 967.5 _EPROCESS layout as per WinDbg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.6 _EPROCESS signature constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977.7 Obtaining offset information for siganture via WinDbg . . . . . . . . . . . . . . . . 97

vi

1 IntroductionTo new researchers in the field, digital forensics often appears to be a relatively new area of researchwith many unsolved problems. While the latter may be true, the former is not: As early as 1984,the FBI established its Computer Analysis and Response Team [39, p. 3], and already eight yearslater Collier and Spaul [24] introduced the then unknown field of computer forensics to academia.Like many areas of information technology, the area of digital forensics has developed quickly whichhas caused many problems with standardization and training. Today, however, the area has a solidscientific foundation as laid out by standard works such as Casey’s book “Digital Evidence andComputer Crime” [20] from 2004 or Carrier’s book “File System Forensic Analysis” [18] from 2005.A worldwide active community gathers at annual conferences such as the Digital Forensics ResearchConference (DFRWS) and the problem of training has been addressed by various academic degreeprograms [4], one being the German Master of Science Digitale Forensik [16], for which the authorof this thesis has been providing tutoring during the time of preparing this work. Hence today,digital forensics can be considered a well established scientific research field.

Looking at the present groundwork in the area, the standard pattern for performing forensicresearch on some hardware or software is the following: The first goal is to understand the system byperforming experiments or “tactical reverse engineering” [53]. The next step then is to characterizethe traces left within the system to allow investigators to draw conclusions upon discovery of suchtraces. The standard assumption mostly is that the system operates in “normal” circumstances,meaning that the technology is off-the-shelf and the opponent is a standard computer user. Bothassumptions are totally sound in the majority of scenarios of forensic practice. However, theestablishment of digital forensic science and the growing awareness of vendors, programmers, andcriminals of the field is slowly changing the rules of the game. We have entered a time whereopponents and technologies are increasingly clever, meaning that they are aware of the strengthsand especially the shortcomings of digital forensic techniques.Interestingly, the field of classical forensic science has undergone a similar evolution. For example,100 years ago it was possible, say for an axe murderer, to cover his tracks by wiping away the victim’sblood at the crime scene. If this was done well, it was very easy for the police to overlook traces ofblood, and thus the case would not be investigated further due to lack of evidence. However, in 1937,Walter Specht, a German forensic scientist, established the use of luminol to detect blood [136].The procedure uses the fact that luminol reacting with hydrogen peroxide becomes luminescent if acatalyst, in this case the hemoglobin in blood, is present [8]. Therefore, blood stains could now bedetected even after they had been cleaned [27]. Investigative procedures, therefore, became muchmore robust against “clever” opponents.The example clearly shows the effects of ignoring the clever opponent. Ignoring the abilities of anadversary can be characterized by a state of naïve innocence. Today, classical forensic sciences arewell-prepared against adversarial manipulative procedures, i.e., they have grown up from a stateof innocence to a state of self-reflected maturity. Failing to leave the literary “age of innocence”[166] can have catastrophic consequences. We, therefore, believe that it is now necessary for digitalforensic science to establish the “clever” opponent as the normal investigative case.

In this thesis, we address several anti-forensics methods against digital forensic procedures. Anti-forensics is becoming the established term for the techniques used by “clever” adversaries today. Aswith manipulations in classical forensics, it is very simple to manipulate a digital system in orderto hide evidence from an investigator. And it is again rather difficult to detect even some of thesimplest manipulations. For example, on the Microsoft Windows operating system to hide a processvia direct kernel object manipulation (DKOM) [17] from the Task Manager requires only a kerneldriver consisting of a mere 100 lines of C code. However, its detection is vastly more complicatedand has even led to a multi-million dollar business branch of anti-virus software. Like in classical

1

1 Introduction

forensics, the deeper the investigator’s analysis goes the harder it becomes to hide evidence. Ina sense, this thesis attempts to find the digital equivalent of luminol. For example, for a rootkitto run, its code must be present on the system. This leaves “residue” on the system. Now givenan untampered view of the system an investigator can when provided with an analysis techniquethat is complete, detect the rootkit’s code “residue”. This detection procedure can be seen as thedigital equivalent of applying luminol to detect blood residue. In this thesis, we present theories,techniques, and methods that extend the field of digital forensics in this regard with the focus onproviding untamperable acquisition and complete analysis methods, so all evidence “residue” canbe detected even though a “clever” opponent tried to hide it from the forensic analyst.

1.1 ContributionsThe contributions of this doctoral thesis to the field of rootkit and anti-forensic resistant computerforensic procedures concern different areas, such as persistent data acquisition, memory acquisition,and virtual memory analysis.

In the field of hard drive firmware rootkit resistant persistent data acquisition (Chapter 3) ourcontributions are as follows:

• We provide, to our knowledge, the first forensic discussion regarding the acquisition of datafrom hard disks with manipulated firmware.

• We provide an analysis of an already published hard disk bootkit. To this end, we outlinemethods for detection and subversion of the bootkit located in the hard disks EEPROM. Asa practical evaluation, we provide a procedure to verify the legitimacy of firmware containedin the EEPROM of the Western Digital HDDs model WD3200AAKX. To this end, wecross-compared the firmware of 16 WD3200AAKX HDDs.

• We provide a theoretical discussion on how hard disk rootkits residing in the firmware overlaysand/or modules stored in the so-called Service Area can be detected.

• To facilitate the transferability of our contributions we investigate 20 different hard drivemodels from different vendors. Of these 20 hard drive models, 16 are HDDs while 4 are SSDs.

In the field of rootkit and anti-forensic memory acquisition procedures (Chapter 4 and 5) ourcontributions are as follows:

• We develop a novel black-box analysis method to practically evaluate forensic memoryacquisition tools with regard to atomicity and integrity as defined by Vömel and Freiling[163]. Thus, we extend the insights of Vömel and Stüttgen [164].

• We evaluate 12 memory forensic acquisition tools and methods according to our method withregard to their atomicity and integrity.

• We further provide a discussion concerning the anti-forensic risks involved with each memoryforensic acquisition technique and method.

• Based on the results of our evaluation, we analyzed the most favorable memory acquisitionmethod, the cold boot attack in more detail. To this end, we provide an independent studybased on 12 computer systems with different hardware configurations and thus verify theempirical practicability of cold boot attacks against DDR1 and DDR2.

• We provide empirical measurements showing the correlation between temperature and RAMremanence. The results of these measurements demonstrate that already cooling the surfacetemperature of a DDR1 or DDR2 module by just 10 ℃ can prolong the remanence effectnotably.

• We further enable the cold boot attacks against scrambled DDR3 memory.

2

1.2 Related work

• Last, we argue that all software-based countermeasures to the cold boot problem publishedsince 2008 can be circumvented by transplanting the RAM modules from the victim’s runningcomputer to another computer controlled by the attacker. We further provide an overview ofcircumvention methods against BIOS-based cold boot countermeasures.

Besides the above contributions to the field of anti-forensic evidence acquisition we also contributeto the field of forensic data analysis theory (Chapter 6) with the following contributions:

• First, we revisit Carrier’s definition of essential data [18] and show that there are two typesof essential data: strictly and partially. While strictly essential corresponds to Carrier’sdefinition, partially essential refers to application specific interpretations.

• We use our new extended definitions to build a trust hierarchy with regard to anti-forensicresistance.

• We empirically show the amount of strictly and partially essential data in DOS/MBR andGPT partition systems, thereby complementing, extending and verifying Carrier’s findings.We, therefore, also empirically show which data within the DOS/MBR and GPT partitiontables is more resistant against anti-forensic manipulations given a specific system.

Last but not least, we make contributions to the field of virtual memory analysis (Chapter 7).These contributions can be summarized as follows:

• We eradicate a forensic blind spot from virtual memory analysis of the Windows NT operatingsystem. Namely, we integrate the swapped out pages stored on persistent storage in thepagefile.sys into the virtual memory analysis.

• To this end, we provide a gray-box analysis method to verify virtual address translationimplementations. This method can be used to verify the correctness of virtual memoryanalysis software as well as analyze virtual address translation mappings of unknown systems.We evaluate the practicability of our method by analyzing the partially known Windows NTpaging behavior, with a distinct focus on the pagefile.

• Our prototype tools work for virtual address space reconstruction of Windows NT versions 7,8.1 and 10 for both x86 systems, with 32-bit or PAE paging, as well as x64 systems, withIA32e paging.

• With this work, we, last but not least, provide a reference for Windows NT virtual addresstranslation, by summarizing our verification of previous research updated with our ownfindings.

Combining all our contributions we hope to further the field of rootkit and anti-forensic resistantdigital forensic procedures to a point where it becomes at least unfeasible for an opponent tohide digital evidence from forensic analysis and, therefore, take the first steps to leave the age ofanti-forensic innocence.

1.2 Related workProbably the first mention of anti-forensics was in 2002 by “the grugq” with his work “DefeatingForensic Analysis on Unix” in the hacker magazine Phrack [152]. However, the first mention of aproblem with such attacks on digital forensic procedures from within the forensic community wasprobably not until Geiger’s “Evaluating Commercial Counter-Forensic Tools” [55] in 2005. Backthen the term anti-forensics has not been established yet. Other works by Geiger et al. referring tocounter-forensics followed in 2006 [56, 57]. Already in the same year, “Arriving at an anti-forensicsconsensus: Examining how to define and control the anti-forensics problem” by Harris [74] attemptedto standardize methods of addressing the anti-forensic problem by defining the term, categorizingthe anti-forensic techniques and outlining general guidelines to protect forensic integrity. Also, in2006, Sartin [126] published “ANTI-Forensics–distorting the evidence”. It, like the other worksat that time, outlines the anti-forensic problem. “Anti-forensics and the digital investigator” by

3

1 Introduction

Kessler [86] extends previous definitions of anti-forensics with the notion of time-based anti-forensics,the methods of which simply try to delay the forensic process to the point where the informationgathered from it are too late, thus lose their evidentiary value or stop being usable at all, e.g.,the statute of limitations running out on a crime. In 2007 “Anti-forensics: Techniques, detectionand countermeasures” by Garfinkel [52] was published. It outlined anti-forensic techniques, mostnotably the 42.zip bomb, a decompression exploit. The 42.zip is a 42KiB sized ZIP archive, whichextracts to almost 4PiB of data. This is achieved by recursively compressing identical ZIP archivesinto another ZIP archive. The resulting large amount of data expansion will cause the investigatorto run out of storage space, especially when the analysis is automated. Most of the current systemsare aware of such ZIP bombs and limit their level of recursive unpacking. More such exploitsagainst forensic tools are outlined in “Anti-forensics with a small army of exploits” by Hilley [77].It focuses on the Metasploit Anti-Forensic Investigation Arsenal (MAFIA). In the same year also“Can we trust digital image forensics?” by Gloe et al. [59] was published. It raised the problem ofanti-forensics with regard to digital image forensics, which today is known as the field of multimediaforensics. Many works about the anti-forensics problem followed [12, 49, 119, 142, 117, 28, 48, 47].Several even exist that formalize on the problem [120, 142]. Other works include various exploitsused to impact forensic investigations in one way or the other [153, 168]. Works that specificallyfocus on anti-forensic measures on the Android smartphones [33, 1, 84] or other smartphones[6, 38] also exist. A field that really thrived with anti-forensics research was multimedia forensics.Beginning in 2010 many works, first developing methods to hide data within multimedia files, thendetecting the developed methods, have been released [60, 140, 137, 138, 139, 141, 158, 157, 149, 91].This research continued throughout the years 2012 to 2013 [9, 143, 15, 159, 42, 167, 41, 116]. Thehype seems to have ceased after 2014 with only a few publications in this area per year [174, 43, 44].Closely related to multimedia forensics is steganography, which is used as an anti-forensic measureby steganographically hiding evidence [147, 23].

In 2013 Stüttgen and Cohen presented “Anti-forensic resilient memory acquisition” [145] in whichthey detailed a software driven memory acquisition method that can still be reliable even against acompromised system. However, such highly publications specifically focusing on the development ofanti-forensic resistant acquisition methods are unfortunately still rare.

While not directly related to the anti-forensic problem, we would like to argue that Kerckhoffsprinciple [85] should also be applicable to forensics, i.e., the fact that the enemy knows the systemshould not impact its security. Applying this to digital forensics, it means that forensic methodsshould be anti-forensic resistant to the point where evading them becomes impracticable — even ifthe adversary knows the method. This may not always be possible, however, it should still be a goalto strive for. As can be seen from the classic forensic example, it is very simple for an adversarythat knows the forensic system to sabotage it, e.g., wiping blood away. While it is often difficultto remedy the problem, e.g., inventing use of luminol for detecting blood residue, in the end, theeffort is well worth it as the forensic procedure, therefore, becomes much more robust against anadversary, e.g., cleaning blood stains so they are not detectable anymore is a lengthy procedure[27]. To this end, forensic research should not be satisfied by being able to analyze the web browserhistory and then hoping an adversary will not figure out how to delete or disable the web browser’shistory. But forensic research must rather always investigate new avenues for forensic evidence, e.g.,analyzing the web browser’s cache, cookies, and temporary files.

This year, in 2016, there have been two anti-forensic papers presented at the Digital ForensicsResearch Conference (DFRWS). The first [94] outlines how memory analysis, i.e., identification andanalysis of process structures, can be bootstrapped in an anti-forensic resistant way. In the second[25] the authors survey various anti-forensic tools and provide an extended taxonomy.These two very current works at the leading conference in the field of digital forensics clearly showthe actuality and importance of this thesis’ topic.

In this section, we listed related works that deal with the digital anti-forensic problem in variousfields. More specific related work, including a delimitation to work presented in this thesis, is citedand discussed separately in each chapter.

4

1.3 Publications

1.3 Publications

During the preparation of this work partial results and other related works have been publishedat peer-reviewed conferences and workshops as well as peer-reviewed journals. The previouspublications by the author, who is marked via underlining, are:

[67] Michael Gruhn and Tilo Müller. On the practicability of cold boot attacks. 2013 InternationalConference on Availability, Reliability and Security, ARES 2013, Regensburg, Germany,September 2-6, 2013, pages 390–397, 2013. doi: 10.1109/ARES.2013.52. URL http://dx.doi.org/10.1109/ARES.2013.52.

[65] Michael Gruhn. Windows NT pagefile.sys virtual memory analysis. In Ninth InternationalConference on IT Security Incident Management & IT Forensics, IMF 2015, Magdeburg,Germany, May 18-20, 2015, pages 3–18, 2015. doi: 10.1109/IMF.2015.10. URL http://dx.doi.org/10.1109/IMF.2015.10.

[50] Felix Freiling and Michael Gruhn. What is essential data in digital forensic analysis? InNinth International Conference on IT Security Incident Management & IT Forensics, IMF2015, Magdeburg, Germany, May 18-20, 2015, pages 40–48, 2015. doi: 10.1109/IMF.2015.20.URL http://dx.doi.org/10.1109/IMF.2015.20.

[131] Maximilian Seitzer, Michael Gruhn, and Tilo Müller. A bytecode interpreter for secureprogram execution in untrusted main memory. In Computer Security - ESORICS 2015 - 20thEuropean Symposium on Research in Computer Security, Vienna, Austria, September 21-25,2015, Proceedings, Part II, pages 376–395, 2015. doi: 10.1007/978-3-319-24177-7_19. URLhttp://dx.doi.org/10.1007/978-3-319-24177-7_19.

[165] Philipp Wachter and Michael Gruhn. Practicability study of android volatile memory forensicresearch. In 2015 IEEE International Workshop on Information Forensics and Security, WIFS2015, Roma, Italy, November 16-19, 2015, pages 1–6, 2015. doi: 10.1109/WIFS.2015.7368601.URL http://dx.doi.org/10.1109/WIFS.2015.7368601.

[51] Felix Freiling, Jan Schuhr, and Michael Gruhn. What is essential data in digital forensicanalysis? it - Information Technology, 57(6):376–383, 2015. URL http://www.degruyter.com/view/j/itit.2015.57.issue-6/itit-2015-0016/itit-2015-0016.xml.

[32] Andreas Dewald, Felix Freiling, Michael Gruhn, and Christian Riess. Forensische Informatik.Books on Demand, Norderstedt, 2nd edition, 2015. ISBN 978-3-8423-7947-3.

[66] Michael Gruhn and Felix Freiling. Evaluating atomicity, and integrity of correct memoryacquisition methods. Digital Investigation, 16, Supplement:S1 – S10, 2016. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2016.01.003. URL http://www.sciencedirect.com/science/article/pii/S1742287616000049. Proceedings of the Third Annual DFRWSEurope.

[10] Johannes Bauer, Michael Gruhn, and Felix Freiling. Lest we forget: Cold-boot attacks onscrambled DDR3 memory. Digital Investigation, 16, Supplement:S65–S74, 2016. ISSN 1742-2876. doi: 10.1016/j.diin.2016.01.009. URL http://dx.doi.org/10.1016/j.diin.2016.01.009. Proceedings of the Third Annual DFRWS Europe.

5

1 Introduction

These publications are incorporated in this thesis as follows:

Chapter 3 on page 15 is based on yet unpublished work authored solely by the author of this thesis.

Chapter 4 on page 35 is based on “Evaluating Atomicity, and Integrity of Correct Memory Ac-quisition Methods” [66], which is a joint work with Felix Freiling. The idea, implementation, andevaluation, however, was an individual work by the author of this thesis. This previous publicationwas amended with a discussion of anti-forensic resilience in addition to atomicity and integrity.Chapter 4 further uses parts with general explanations about memory acquisition techniques from“Windows NT pagefile.sys Virtual Memory Analysis” [65], which have been merged into this chapterto avoid needless repetition in this thesis.

Chapter 5 on page 51 is based around “On the Practicability of Cold Boot Attacks” [67] withSection 5.5.1 on page 65 being based on “Lest We Forget: Cold-Boot Attacks on Scrambled DDR3Memory” [10]. The 2013 work “On the Practicability of Cold Boot Attacks” [67] revisited cold bootattacks and how all the published software based cold boot attack mitigations can be circumvented.It further identified a problem with the cold boot attack memory acquisition procedure againstmodern DDR3 memory. Research on the attack against DDR3 continued until 2015 when eventuallyin joint work we were able to formulate an attack against DDR3 memory. The results were publishedas a joint work [10] in 2016. Because the final solution was obtained by a joint work effort, Chapter 5focuses mainly on the results obtained in “On the Practicability of Cold Boot Attacks” [67] and onlycontains a condensed write-up of the joint work “Lest We Forget: Cold-Boot Attacks on ScrambledDDR3 Memory” [10] in Section 5.5.1 on page 65.Section 5.6.2 on page 70 further contains a reference to “A Bytecode Interpreter for Secure ProgramExecution in Untrusted Main Memory” [131]. Even though the implementation has been done byMaximilian Seitzer as part of his master’s thesis, the idea was solely by the author of this thesis.But because the resulting publication was also based on Maximilian Seitzer’s master’s thesis, it isonly referenced as an example of RAM encryption systems preventing cold boot attacks and notused in its entirety.

Chapter 6 on page 71 is based on the two publications both named “What is essential data indigital forensic analysis?” [50, 51] one by Freiling and Gruhn and the other one by Freiling et al.While the main idea of the work, i.e., refining Carrier’s definition of essential data in digital forensicanalysis [18], was stipulated by Felix Freiling, the technical evaluation of the work can be attributedto the author of this thesis. The work was further extend with a discussion of the relationship ofessential data and anti-forensics. Because the work with Schuhr [51] is itself based on the earlierwork by Freiling and Gruhn, but focusing on the legal aspects of essential data in digital forensicanalysis without any technical evaluation, it was not used in this thesis. The author’s contributionto the second edition of the book “Forensische Informatik” [32] is also based on “What is essentialdata in digital forensic analysis?” Additional material contributed to “Forensische Informatik”have not been used in this thesis.

Chapter 7 on page 85 is based on “Windows NT pagefile.sys Virtual Memory Analysis” [65], whichhas been an individual work by the author.

6

1.4 Overview

1.4 OverviewIn Chapter 2 on the following page, the background chapter, we first give an overview of forensicsand anti-forensics, both in the classical physical realm as well as the digital realm. We define themain goal of anti-forensics. We further, motivate and illustrate the main objective of this thesiswith practical examples. After this introductory background chapter, this thesis is devoted to stateof the art anti-forensic and rootkit problems.

In Chapter 3 on page 15, we investigate how data can best be acquired from hard drives that arepotentially compromised by a firmware rootkit. To this end, we first outline the threat of harddrive firmware rootkits to forensic analysis. We then provide a procedure to detect and subverthard disk drive firmware bootkits, as published. We further outline potential avenues to detecthard drive firmware rootkits nested deeper within the hard disk drive’s so-called Service Area, aspecial storage on the magnetic platter reserved for use by the firmware.

In Chapter 4 on page 35, we shift towards the acquisition of volatile storage, i.e., RAM. To thisend, we evaluate the quality, both with regard to atomicity and integrity, as well as anti-forensicresistance, of different memory acquisition techniques with our newly developed black-box analysistechnique. This resulted in the cold boot attack proving to be the most favorable anti-forensicresistant memory acquisition techniques.

In Chapter 5 on page 51, we outline the cold boot attack in detail. First, we experimentallyconfirm that cooling the RAM modules prolongs the remanence effect considerably. Then we prove,experimentally, that transplanting RAM modules from one system to another is possible. Wefurther address the issue of modern DDR3 technology being scrambled as well as other proposedcountermeasures, such as BIOS passwords and temperature detection.

In Chapter 6 on page 71, we start addressing the analysis of evidence. To this end, we first revisitthe theory of data analysis, namely the concept of essential data in forensic analysis as coined by[18]. After extending Carrier’s theories, we practically verifying both the original theories and ourextensions in experiments. We further argue that the essential data concept can be used to build atrust hierarchy, from which we concluded that anti-forensic resistant analysis methods must onlyuse what we call strictly essential, i.e., trusted, data.

In Chapter 7 on page 85, we tackle a long unsolved problem in forensic memory analysis. To thisend, we analyze the Windows NT virtual memory paging via a newly conceived gray-box analysismethod, in which we place traceable data into virtual memory and force the data into both thephysical RAM as well as being swapped out to the pagefile.sys stored on persistent storage. Weare thus able to reverse engineer the complete virtual address mapping, including the non-mappedpagefile. We present our results of this reverse engineering as well as practical evaluations to provethe correctness of our findings.

In Chapter 8 on page 105, we finally conclude this thesis.

7

2 BackgroundIn this chapter, we give a brief introduction and motivation into forensics and anti-forensics. Weillustrate them with examples that motivate our work. We also give a brief outline of rootkits andan introduction to firmware rootkits, which we address later in this thesis.

2.1 ForensicsIn general, forensic science is the application of scientific methods in the persuade of answeringquestions of law [20]. In forensic investigations, evidence is discovered, collected, preserved, analyzedand eventually presented in a court of law. Forensic scientists should only provide objective evidence.They should not be biased. They do not decide whether a suspect is guilty or innocent. They onlyprovide facts on which a judge or other entity can base their verdict on.

There are different forensic science fields. They usually are based on well established scientificresearch fields.

• Forensic anthropology uses anthropology, e.g., to analyze skeletonized human remains incriminal cases.

• Forensic botany uses botany to answer questions such as: “From where are leafs and/or pollensfound at a crime scene from?” This could reveal information regarding the whereabouts ofeither the victim or the suspect before a crime.

• Forensic chemistry uses chemistry to answer questions such as: “Is gunshot residue at thehand of a suspect?” This can determine whether the suspect has fired a weapon. “Is thereresidues of accelerants in the ashes of a fire?” If there is it would indicate arson instead of anaccidental fire.

• Forensic dactyloscopy uses dactyloscopy, which is the field of fingerprint identification, tomatch up two sets of fingerprints, by comparing their minutiae, and determining whetherthey are equal or not.

• Forensic engineering uses engineering to answer questions such as: “Did the car’s break linerupture before the crash?”, “Why did a building collapse?”

• Digital forensics, also known as digital forensics or forensic computing, uses research methodsfrom computer science to answer questions based on digital evidence, such as: “Is a specificfile stored on a specific computer system?”, “How did the file get onto the computer system?”,“Which user account is responsible for the download of the file?”

As can be seen from the above list all forensic field names are a combination of the word “forensic”and the name of the field. The term forensic computing is a term proposed in 2014 by Dewaldand Freiling [31]. It was not only introduced to bring the name into line with the naming of otherforensic fields, but also to distinguish between so-called digital forensic tasks usually performedby “ordinary” criminal investigators, such as copying hard disks, from the computer science tasksbehind complex digital forensic tasks. This can be compared to a police officer taking a DNA swabfrom a suspect and the forensic scientist actually performing the DNA analysis in a laboratory.In this case, the police officer is usually not considered to do forensic biology, while the latterdefinitively is. In this work the terms forensic computing and digital forensics are, however, usedinterchangeably.

8

2.2 Anti-forensics

In every forensic field, certain steps such as discovery, acquisition (also known as collection),preservation, analysis, and presentation exist. In this work, we only deal with acquisition andanalysis, because these are the most relevant targets for anti-forensic measures. In the next twosections, we outline the important aspects of acquisition and analysis.

2.1.1 Acquisition

Before evidence can be analyzed it must first be acquired. In a classical physical forensic discipline,this means collecting fingerprints, hair, fiber particles, etc. from the crime scene. Here special caremust be taken to not destroy the evidence during acquisition, i.e., if a fingerprint is not acquiredcorrectly, e.g., it is smeared during the acquisition process, it could be lost forever. In physicalforensics the acquisition process is closely related to preserving the evidence, i.e., making sureit retains its authenticity during the investigation. This is a task that is trivial during digitalinvestigations, because 1:1 copies of digital data are possible. This means in digital forensicsacquiring the evidence means making such a 1:1 copy of the data to be acquired. While this mayseem trivial for hard drives, which can simply be cloned, either via software or special hardware,we show throughout this thesis that this is not always the case. For example, to read a hard drive,the forensic investigator, according to the current state of the art, uses firmware running on thehard drive to do so. However, as we show, such firmware can be manipulated and interfere with theacquisition process. Such interference is called anti-forensics and we further discuss it in Section 2.2.

2.1.2 Analysis

Next, after the evidence has been acquired it needs to be analyzed. One classic example would befingerprint matching. A fingerprint acquired at a crime scene is compared to the fingerprints ofsuspects. If there is a match the suspect can be connected to the crime scene. Sometimes the actualevidence, or at least a part of it, gets destroyed during analysis, e.g., during chemical analysis, inwhich particles acquired at the crime scene must be dissolved in order to analyze them further.In digital forensics, such destruction of evidence is generally not needed, again, because of thepossibility of a 1:1 copy. The analysis process, in digital forensics, consists of interpreting theacquired data, e.g., a 512-byte block, could either be a boot sector, a network packet, or any otherdigital data. Is the data not interpreted correctly, the analysis is faulty. As before, such analysiserrors can be provoked via anti-forensic methods, which we discuss in the following section.

2.2 Anti-forensicsDefinition 1. Anti-forensics is any measure that prevents a forensic analysis or reduces its quality.

Any measure that prevents a forensic analysis can, according to Definition 1, be considered ananti-forensic measure. This means that any measures taken to prevent the forensic acquisition mustalso be considered an anti-forensic measure, because, as outlined earlier, if there is no evidenceacquired, it cannot be analyzed. A classic example of anti-forensic measures are gloves. A personwearing gloves generally does not leave fingerprints. Hence, a criminal wearing gloves at the crimescene prevents the analysis of his fingerprints by simply not leaving any in the first place.However, Definition 1 also specifies a reduction in quality to be sufficient for a measure to qualifyas an anti-forensic measure. One example would be to shred documents before they are acquiredby a forensic accountant. While ultimately the forensic accountant will be able to puzzle thedocuments back together, the time it takes to do so impacts the quality of the forensic analysisseverely. Because time spent during a forensic investigation always costs money, the quality of theforensic analysis is further impacted. Depending on the severity of the case, such time investmentsmay often not be justifiable. Also, if too much time passes during analysis gathered evidence maylose its evidentiary value or stop being usable at all, e.g., statute of limitation running out on acrime.

9

2 Background

It is important to note, that not only measures destroying and/or preventing evidence should beconsidered anti-forensic measures, but really all measures that as per Definition 1 prevent or reducethe quality of a forensic analysis. An example would be to manipulate a crime scene after a crime,i.e., leave and/or even plant more evidence than was originally present after the crime. To this end,a criminal could scatter the contents of a public ash-tray at a crime scene, rendering analysis ratherdifficult. Another example would be to outright frame somebody else for the crime by stealingpersonal items from the to be framed person and leaving them at the crime scene.In the next two sections, we will outline anti-forensics during acquisition as well as analysis in thecontext of digital forensics.

2.2.1 Acquisition

The most efficient and safest way to impact a forensic analysis is to interfere already with theacquisition process. If there is no acquisition there can be no analysis. The acquisition is anespecially crucial step in the digital forensic process, because unlike the analysis we show later, itcan often not be repeated. Once digital evidence is gone, it is gone. This is especially true forvolatile data, such as RAM contents, which we, therefore, mainly focus in this thesis.

2.2.1.1 Technical/practical impossibility

One way to prevent the acquisition of evidence is by making it technically impossible to acquire theevidence in the first place. To this end, hardware can be used to prevent a forensic analyst fromgaining access to the data. One such instance that comes to mind are Smartcards, more specificallySIM (subscriber identification module) cards. These cards can be protected by a PIN. The dataon them, such as stored phone numbers, can only be accessed when the correct PIN was entered.The card has also the possibility to lock itself, once the PIN was entered wrongly too many times,effectively preventing brute force attacks.

Another example is storing data in processor registers, which, unlike RAM can, at least accordingto current consensus [108], not be acquired via physical attacks. The most prominent example ofthis anti-forensic technique is TRESOR [108], which stores disk encryption keys in CPU registersso they can not be acquired via physical attacks.

Here it could be argued whether or not encryption can be considered a measure that preventsacquisition. We would like to argue that it does not, but rather prevents analysis. Because thedata itself can be acquired, and at least in theory the key can be brute forced eventually. However,we will not go into this semantic debate.

2.2.1.2 Manipulations

Another way to facilitate anti-forensics is via manipulations to the system that should be acquired.In 2013, Stüttgen and Cohen presented their work “Anti-forensic resilient memory acquisition”[145], in which they showed a simple one-byte manipulation that breaks many memory acquisitionsoftware for Linux. To this end, the memory layout information presented to the Linux user spacewas manipulation via direct kernel object manipulation (DKOM). More specifically, under Linux/proc/iomem exposes the memory resource tree to the user space. Only memory regions titled“SYSTEM RAM” are guaranteed to be backed by RAM and hence accessible. Changing this to “SYSTEMROM” does not cause any problems to the system. However, many memory acquisition tools willnot acquire those memory sections anymore, assuming those sections are actually ROM and notRAM. By preventing the forensic analyst from acquiring the memory logically also prevents memoryanalysis.

10

2.2 Anti-forensics

2.2.1.3 Tool errors

Another possibility for anti-forensics during acquisition are tool errors. While it is debatable thatvirtually all anti-forensic problems can be attributed to tool problems, i.e., most tools are, at thecurrent time, unfortunately not anti-forensic resistant, we will not enter a debate nor discussionwhat should and what should not be considered a tool error. We will rather give one clear exampleof anti-forensic attacks, to illustrate how errors in the tools used by the forensic analyst can beattacked with anti-forensic measures. To this end, we outline an error that allowed us to manipulatethe partition table of a storage medium in such a way that it could not be acquired by Linux.The error was first described by Wundram et al. [168] as an anti-forensic attack against the tool mmlsfrom Brian Carrier’s Sleuthkit. However, the described extended partition loop in the DOS/MBRpartition table also works to attack a Linux system, as is documented by CVE-2016-5011. Basically,the attack works as follows: A DOS/MBR partition table is created with one regular partition.Then an extended partition is created. This extended partition then points to the DOS/MBR itself,thus, creating a loop. The partition table as parsed by Linux’s fdisk tool is shown in Listing 2.1.Note that fdisk does not recursively parse extended partitions. However, Linux’s libblkdev wouldrecursively parse the loop until it ran out of memory, causing a denial of service (DoS) against thesystem.

$ f d i s k −l deathmoch_active . ddBad o f f s e t i n primary extended p a r t i t i o n

Disk deathmoch_active . dd : 0 MB, 1536 bytes , 3 s e c t o r sU n i t s = s e c t o r s o f 1 ∗ 512 = 512 b y t e sS e c t o r s i z e ( l o g i c a l / p h y s i c a l ) : 512 b y t e s / 512 b y t e sI /O s i z e ( minimum/ o p t i m a l ) : 512 b y t e s / 512 b y t e sDisk l a b e l type : dosDisk i d e n t i f i e r : 0 xc5952e09

Device Boot S t a r t End B l o c k s Id Systemdeathmoch_active . dd1 1 1 0+ 83 Linuxdeathmoch_active . dd2 0 0 0+ 5 Extended

P a r t i t i o n t a b l e e n t r i e s a r e not i n d i s k o r d e r

Listing 2.1: Partition table of extended partition loop exploit as displayed by fdisk

We were also able to find a similar anti-forensic attack against Windows 7 by setting the number ofpartition table entries to zero within the GPT header of a GPT partitioned storage medium. Oncesuch a prepared device was connected to a system running Windows 7, it caused the system tocrash with the so-called Blue Screen of Death, caused by a division by zero within the kernel.

While both outlined attacks can be trivially prevented by updating the tools, when first confrontedwith them while using a vulnerable tool, the forensic investigator must waste time analyzing theproblems caused by such manipulated partition tables instead of actually analyzing the storagemedium’s contents.

2.2.2 Analysis

In case the acquisition cannot be prevented the analysis must be attacked instead. However,because, at least, in theory, the analysis can be repeated an infinite amount of times it can oftennot be prevented completely. This is due to the ability to construct 1:1 copies of digital evidence,hence, granting the analyst theoretically infinite attempts. This means should an attack be ableto compromise an analysis, i.e., should the analysis fail, the analyst can restore the evidencefrom the 1:1 copy and try again and again until an analysis approach succeeds. Because thismakes anti-forensic measures during acquisition more powerful, this thesis focuses primarily on theacquisition and not analysis. Nonetheless, we now outline several anti-forensic schemes preventinganalysis.

11

2 Background

2.2.2.1 Technical/practical impossibilities

As already mentioned before, encryption could be considered rendering analysis technically impossi-ble, because, given a sufficient key space size brute force attack can be physically impracticable.Beside encryption, there is technically nothing that can make analysis impossible. However, it maybecome impracticable. Because even though an analyst can potentially try an infinite amount ofanalysis attempts, this is not practical. At one point either time or money will run out.

2.2.2.2 Manipulations

Even though manipulation, either of the acquired data or the system used by the forensic an-alyst, should not be possible, it has been shown that JavaScript code could be injected intoHTML reports produced by forensic tools [168]. Once those manipulated reports are viewed in abrowser supporting JavaScript the injected code is executed — on the analyst’s computer. Again, itcan be argued that such manipulation possibilities are errors in the tool producing the HTML report.

Another possibility for disturbing the forensic analysis are manipulations which, even though theyhave already been performed to the evidence before the acquisition, manifest during the analysisprocess. One such example are timestamps in digital audio recordings. Obviously, those can befaked. However, a more anti-forensic resistant method can be used to determine when a recordingwas actually made rather than when its manipulatable time stamp says it was. Usually, a powernetwork provides electricity with its typical frequency, i.e., the Electric Network Frequency (ENF).However, due to fluctuations in the production and consumption of electricity this frequencyfluctuates over time. These fluctuations can be extracted from an audio recording and correlated tothe ENF fluctuations [78]. This technique is known as the ENF criterion.Another example is the identification of the source camera of a picture. The metadata, such asEXIF data, embedded inside the picture can, again, be easily forged. However, the unique camerafingerprint embedded inside the picture, caused by photo response non-uniformity (PRNU) noise,the shape of the lens, and other uncontrollable production inaccuracies, can be used to identify thesource of a picture [58] even if heavily compressed [3]. This method is also applicable to videos[161].

2.2.2.3 Tool errors

Another possibility for anti-forensics during analysis are, again, tool errors. As before many anti-forensic problems can be attributed to tool problems. One example for this is an error in the filecarving tool foremost. It does not detect files that span over a 100MiB chunk boundary, i.e., if afile starts at 199MiB and ends at 201MiB it will not be detected by foremost. This is becauseforemost processes its input in chunks of 100MiB size with each of those chunks being analyzedseparately. The authors of foremost are well aware of this fact as the comment seen in Listing 2.2in the source code proves.

598 / ∗ FIX ME∗ ∗ ∗599 ∗ We s h o u l d j u m p b a c k a n d make s u r e we d i d n ’ t m i s s a n y h e a d e r s t h a t a r e600 ∗ b r i d g e d b e t w e e n c h u n k s . What i s t h e b e s t way t o d o t h i s ? \601 ∗ /

Listing 2.2: Comment in foremost 1.5.7 source code file engine.c outlining an unfixed problem

An attacker could hide evidence from the foremost tool by placing it at said 100MiB boundaries.While this example is trivial, more complex examples exist [168]. But the foremost example shows,without having to explain too many details, what can be considered an anti-forensic measure thatis enabled by a tool error.

12

2.3 Rootkits

2.3 RootkitsA rootkit is a special kind of malware. Its main objective is to provide sustained access to acompromised system and/or computer resource and at the same time conceal the presence of suchaccess, its related activities and the rootkit itself. One simple example of a rootkit, would be theinstallation of an SSH server, i.e., a remote access, by an attacker after gaining access to a system.This way the attacker can login to the system via SSH at a later point in time, hence, achievingsustained access. However, the installation of an SSH server is very simple to detect, because it is,among many other places, listed in the list of running processes.To combat this, rootkits generally use anti-forensic techniques to hide their presence. One suchexample of such hiding mechanism is direct kernel object manipulation (DKOM) [17], a techniquethat directly manipulates kernel memory structures. In this specific instance, a rootkit would modifythe kernel’s process list. This list is typically a doubly linked list containing all processes on thesystem. Because a process is executed in smaller subunits, so-called threads, which are organized inseparate lists, the process list can be manipulated without affecting the thread execution of themalware. The rootkit can, thus, make itself invisible to the operating system by unlinking itselffrom the process list.Another flavor of rootkits are so-called bootkits. They are called bootkits because, unlike regularrootkits, they infect the boot process of a system. Due to the very early compromise in the bootprocess, i.e., long before the actual system is actually loaded, very deep manipulations to thesystem being booted can be performed. This results in bootkits being harder to detect than regularrootkits. However, their ultimate goal is identical.Because these regular kind of rootkits and bootkits are already well known, also in the forensiccommunity, and tools for their detection exist, we, in this thesis, tackle firmware rootkits. Firmwarerootkits are rootkits that manipulate device firmware, i.e., the software providing functionalityto hardware devices. Contrary to popular belief modern hardware does not consist of discretelogic burnt into a circuit but hardware usually contains embedded processor units, i.e., computers,itself. Already in 2009 researchers presented firmware rootkits. One of those early works by AnibalL. Sacco and Alfredo A. Ortega leverages a computer’s BIOS to achieve a persistent infection[122, 123]. In this work, we will address the special case of firmware rootkits on hard drives.

13

3 Persistent data acquisition(from hard drives)

The main objective of a rootkit is to provide sustained access to a compromised system and at thesame time conceal the presence of such access, its related activities and the rootkit itself. To thisend, rootkits use anti-forensic techniques to hide their presence. In this chapter, we investigatean anti-forensics technique which prevents forensic investigators from acquiring case-relevant datain the first place. Currently, the most efficient way to remain persistent but hidden are hard diskfirmware rootkits, for the detection and mitigation of which currently no forensic best practice exist.We, therefore, analyzed 20 different hard drive models, of which 4 are SSDs, from different vendors.We also analyzed one model, the Western Digital WD3200AAKX, more in depth to outline methodsfor detection and subversion of bootkits located in the hard disks EEPROM. To this end, weanalyzed 16 different WD3200AAKX HDDs. In this chapter, we furthermore provide a theoreticaldiscussion on how hard disk rootkits residing in the firmware overlays and/or modules stored inthe special storage area on a HDD called the Service Area can be detected. To our knowledge, weprovide the first forensic discussion regarding the acquisition of data from a hard disk compromisedwith a firmware boot- and/or rootkit.

3.1 Introduction

In digital forensics data is analyzed. In order to analyze data, it must, however, first be acquired.Because many times forensic investigations, of, e.g., industrial espionage, involve rootkit compromises,this chapter addresses persistent data acquisition from potentially rootkit subverted hard drives.This is a task that has not been addressed by the current state of the art in forensic hard driveforensics. Current literature on hard drive forensics always recommends making a copy of theoriginal source drive, while using a write blocker to prevent changes to the original source drive.The current state of the art also recommends the acquisition of the usually hidden HPA and DCOsections. For a non-compromised hard drive, those measures work fine. However, they are notenough to ensure that evidence is not destroyed, lost or never found when the analyzed hard drivehas been compromised by a firmware rootkit.Hence, in this chapter, we first give a short overview of what effect a firmware rootkit can haveon an investigation. We then demonstrate how firmware bootkits can be detected and we outlineseveral possibilities how even deep firmware rootkits can be detected. We will use a Western DigitalWD3200AAKX as running example throughout this chapter.

3.1.1 HDD anatomy

A modern HDD is not just a block device but rather a whole computer system in itself. Thesymbolic picture in Figure 3.1 on the following page shows the anatomy of a hard disk drive (HDD).It is loosely based on the Wester Digital WD3200AAKX drive. The picture shows the HDD andselected components in the middle. The components are: the disk, also known as the platter; theread and write head; and the PCB containing the processor, RAM, EEPROM, etc. The figurefurther points out three topics of interest: persistent storage areas, interfacing possibilities, andanti-forensic threats. These are detailed in the next two sections. The first section outlines thepersistent storage areas and their associated anti-forensic threats. The second section outlines theinterfacing and verification possibilities.

15

3 Persistent data acquisition (from hard drives)

win

bond

25

X2

0B

LNIG

12

27

88

i67

45

-TFJ

1YPM

A6

82

AE

07

41

B

1P

TW

C

12

5

SAMSUNG 237K4H511638J-LCCCH5116 E1H012GSS

Service Area

Boot Sector

Data Sectors

HPA/DCO

Mask ROM

EEPROM

Compromised Firmware Overlays/ModulesCompromised Partition TableGeneral Anti-Forensics Code Stored on DeviceHidden Data in

Malware Code in RAM

Compromised Controller Hardware

Compromised Firmware Boot Loader

PersistentStorage

Areas:Anti-ForensicThreats:

Magnetization

JTAG

X-Ray

SPI

SATAUART

Interfacing and

VerificationPossibilities:

HPA/DCO, Service Area, EEPROM or sectors marked as "bad"

Disk/Platter

Figure 3.1: HDD anatomy: storage areas, interfacing possibilities and anti-forensic threats

3.1.1.1 Persistent storage areas and anti-forensic threats

While the main purpose of a HDD is to provide persistent storage, the HDD itself has also storageareas it can use, which may not be accessible by a normal user of the HDD. The following areas arepointed out in Figure 3.1:

Mask ROM The mask ROM is integrated into the processor on the HDD’s PCB. Because it isprogrammed by the integrated circuit manufacturer during the manufacturing process directly viathe photomask in the photolithography process, it is read-only and can not be modified. It containscode that allows the processor to boot and load the firmware boot loader code from the EEPROMinto RAM.

EEPROM The EEPROM contains the boot loader of the firmware. The boot loader bootstrapsthe system to the point where it can read from the platter. At this point, it will start loading morefirmware from the platter. The EEPROM can also be read and written by software via the HDDsSATA connection. This way firmware code can be modified, e.g., to perform legitimate firmwareupgrades. This results in the anti-forensic threats associated with a compromised firmware bootloader, also known as a bootkit. It is important to note that this firmware bootkit does not interferewith the boot process of the operating system installed on the HDD, but rather the boot process ofthe HDD itself. Besides compromising the firmware, the EEPROM could be used as hidden datastorage.

Service Area The Service Area is a hidden area on the platter that, unlike the HPA or DCO, cannot be used by a normal user. This area is used to store further firmware components called overlaysor modules, which are loaded into RAM by the boot loader. On some HDD’s some overlays areonly loaded on demand and swap other overlays out of RAM. While this area is reserved for usageby the firmware, there are vendor specific commands (VSCs) with which this area can be accessedvia the SATA interface. This allows an attacker to modify firmware as well as hide data. After theService Area begins the regular storage area of the HDD platter — often known as the User Area.However, in Figure 3.1 we additionally point out different aspects of the User Area, because thesedifferent sections of the User Area can be used in different ways to facilitate anti-forensics. But tothe hard drive, the User Area is treated as one single storage area.

16

3.1 Introduction

Boot Sector The Boot Sector is the first thing loaded by a BIOS when booting from the HDD.Because a professional forensic investigator will not boot from the device, any malware infections,such as bootkits in the boot sector, will not immediately impact his work, unless, of course, themalware is the subject of his investigation.The Boot Sector usually also contains the partition table, which can be malicious. In CVE-2016-5011, we have shown that it is possible to cause a denial of service (DoS) against various Linuxsystems with a specially crafted DOS/MBR partition table, that uses an extend partition loop [168],i.e., an extended partition within the DOS/MBR partition table will point back to the DOS/MBRitself causing infinite recursion in the library libblkid when parsing the partition table. Anothersuch example uses GPT partitioning. It can cause a DoS against Windows 7 by setting the numberof partition table entries to zero in the GPT header, which will result in the so-called Blue Screenof Death due to an implementation error which causes a division by zero within the kernel. So evenby merely connecting a HDD with such a compromised partition table to a vulnerable system canimpact the forensic investigator’s work negatively.

Data Sectors The Data Sectors are all sectors that a regular user of the HDD has access to.This is where, e.g., the file system resides, the files within it, etc. Regular anti-forensic measures,typically, reside here, e.g., directory loop attacks [168] or XSS code injection into forensic reportsthat are generated as HTML files [168].

HPA/DCO Last but not least the HDD can contain the so-called Host Protected Area (HPA)and/or a Device Configuration Overlay (DCO). Both are hidden from the user. The HPA can beused to store installation files used for system recovery, while the DCO can be used to control over-provisioning of the HDD. Access to both the HPA and DCO can be acquired via ATA commands[69]. Both areas are well known to forensic investigators, hence, they lost their value as data hidingspot for criminals.

3.1.1.2 Interfacing and Verification Possibilities

Figure 3.1 on the preceding page also shows the various interfacing and verification possibilities wefound provided by the analyzed hard drives. We will outline most of them in more detail throughoutthis chapter. Hence, here we only give a brief outline of each.

Magnetization The first idea to verify the data on the HDD platter seems to be to read themagnetization directly from the platter. While this may have worked on older hard disk drives,newer disk drives typically have a very high integration density rendering this method nearlyimpossible.

SATA The usual way today to interface with a HDD is via its Serial AT Attachment (SATA)interface. This method uses the firmware stored on the device to read and write data from and tothe platter. In the case of a firmware compromise this interface can not be trusted.

SPI To interface with the EEPROM the Serial Peripheral Interface (SPI) can be used. Becausethis interface it very low level a software compromise is not possible.

X-Ray While x-raying the device is not actually interfacing with it, X-raying can be used to verifythe integrity of the PCB and attached microchips.

JTAG Some hard disks have a Joint Test Action Group (JTAG) interface. A JTAG interface canbe used to test and debug the processor on the PCB.

UART Some hard disks have a Universal Asynchronous Receiver Transmitter (UART) interface,which provides serial communication with the device.

17

3 Persistent data acquisition (from hard drives)

3.1.2 HDD firmware analysis software

PC-3000 is a commercially available hard and software combination,which can be used to repaircorrupted firmware. Unfortunately, we do not have access to a PC-3000, hence, we can only makeassumptions about it. Presumably, it could possibly be used to restore a proper firmware on aHDD. But it is a proprietary product, hence, little is known about its inner workings, makingit a less trustworthy solution than what we are about to present. Also, because the PC-3000’sinner workings are unknown, it can not be further developed and adapted to the needs of forensicexaminers, e.g., new hard drive support.

3.1.3 Related work

In 2009 Sutherland et al. [148] outlined an anti-forensic technique in which the ability of the harddisk to mark specific tracks on the hard drive platter as bad was used to hide data from a forensicinvestigation by marking its corresponding physical sectors as bad, i.e., unusable. At OHM in 2013Jeroen “Sprite_tm” Domburg’s demonstrated possibly the first publicly demonstrated hard diskfirmware rootkit [37]. Many other works followed [173, 61, 172]. In 2012 Knauer and Baier [88]demonstrated how the diagnostic UART interface of a Samsung HDD could be used to bypass ATApasswords. They further extended their work in 2014 [7] to anti-forensic data hiding. In 2013 Readet al. [118] used firmware modifications to hide partitions from a forensic investigator. To this end,they used the HDDHackr tool, which can manipulate firmware of ordinary Western Digital HDDsto be used with the Microsoft Xbox 360, instead of more expensive official OEM drives. In 2015Laan and Dijkhuizen [90] proposed a firewall for specific ATA commands. With their work in place,the proposed hard disk firmware rootkits would not be able to infect the device, because this isdone via specific ATA commands, which their so-called firmwall would block.Further the NSA’s IRATEMONK, UNITEDRAKE, STRAITBIZARRE, SLICKERVICAR, SAD-DLEBACK, ALTEREDCARBON, FAKEDOUBT, PLUCKHAGEN and EASYKRAKEN projectsare assumed to be in one way or the other involved with compromising the firmware of HDDs.But, even though the topic of firmware rootkits and malware has been demonstrated again andagain, there is no publication outlining the impacts on digital forensics and/or providing bestpractice recommendations on how to deal with such firmware anti-forensic malware infections.

3.1.4 Outline

The outline of this chapter is as follows:First, in Section 3.2, we examine hard disk firmware bootkits. Next, in Section 3.3 on page 28we outline overlay-based hard disk firmware rootkits. Followed by a discussion in Section 3.4 onpage 31 and last but not least a conclusion in Section 3.5 on page 32.

3.2 Hard disk firmware bootkitIn this section, we present a survey of hard disk firmware bootkit infections using the WesternDigital WD3200AAKX 320GB HDD as our primary example. In the first Section 3.2.1 on thefacing page, we show two ways how this HDD’s firmware can be compromised — only via runningsoftware with root privileges on the computer hosting the HDD. Next, we show how we can use onlyanti-forensic resistant hardware techniques to detect some of the possible firmware manipulations.We further detail how deeper firmware manipulations could be detected as well as briefly outlinehow those techniques can be applied to other hard drives besides the explanatory WD3200AAKX,namely 20 hard drives by different manufacturers. In Section 3.2.4 on page 27, we show howmanipulated firmware and also manipulated controller hardware can be subverted by a forensicanalyst to still access the data stored on the HDD’s platter in a forensically sound way. Eventuallyto conclude this section we give future prospects in Section 3.2.5 on page 27 into how firmwaremanipulations can be investigated further.

18

3.2 Hard disk firmware bootkit

3.2.1 Compromising

The firmware of the Western Digital WD3200AAKX is not digitally signed. Neither is the firmwareof any other hard drive, to our knowledge. It can be uploaded, i.e., replaced with a new firmwareimage, via vendor specific ATA commands. These commands are often simply called vendor specificcommands (VSCs). The Linux tool hdparm provides the argument “–fwdownload <firmware.bin>”which implements a convenient interface to these vendor specific commands. It can be used towrite the new firmware image <firmware.bin> to the EEPROM of the WD3200AAKX. Malware,such as a rootkit, can also issue those vendor specific commands, given sufficient privileges to do so,i.e., it needs administrative privileges. Given this ability the possibilities of firmware manipulationare endless.

3.2.1.1 Providing persistent root access

In 2013 Jeroen “sprite_tm” Domburg demonstrated a firmware rootkit against a 500GB WesternDigital HDD that allowed for covert root access on UNIX systems persisting even system reinstallsand complete HDD erasure [37]. To this end, he hooked the interrupt table of the Marvel FeroceonARM processor responsible for the SATA DMA transfers. The hooked interrupt is triggeredonce the requested data was loaded from platter into the cache of the HDD by the secondFeroceon ARM processor on the main controller chip. Instead of instantly issuing the SATA DMAtransfer, the hook code would first search the newly loaded data in cache for an ASCII stringthat indicates the /etc/shadow file of a UNIX system was read, i.e., a string having the form“root:*:*:*:*:*:*:*:*\n”, with * representing a wildcard character for any ASCII character notcontaining : or no character, and \n representing a newline character. Here root represents theusername, in this case, the root user, and : is a separator separating the individual fields. The firstfield is the username and the second field the password hash. The other fields are additional fields,that are irrelevant for this scenario. The rootkit then exchanges the password hash for a knownpassword hash. This way the attacker injects a known root password into any UNIX system, orany other system employing the /etc/shadow password file for that matter, installed on such acompromised HDD — even if the system is reinstalled.

3.2.1.2 Activating and deactivating the rootkit (from remote)

Further hooks can be added to the firmware to enable and disable this root password overwrite, e.g.,a second hook in the interrupt table for the interrupt triggered once data in the cache is supposed tobe written to platter can be used to search for commands. These commands can then be triggeredsimply by writing them to disk. This way the regular root user can use the system with his or herpassword, but once the attacker wants to access the system all he or she needs to do is to write asecret command string to disk to activate the root password overwrite. sprite_tm used the strings“HD, live” to activate and “HD, dead” to deactivate his rootkit. An attacker can then inject sucha command string, e.g., within the User-Agent string of a HTTP request to a server which is thensubsequently written into the HTTP access logs of that server. Another example would be a SSHlogin attempt with a specially crafted username which would then be written to the security logsand thus trigger the command. An attacker may need to trigger multiple data writes to ensurethat the commands are actually committed to the HDD and not reside in the kernel’s file systemcache, though. To this end, an attacker can simply flood the logs by issuing bogus requests. Anysuch actions needed to get the command to be committed to disk can then be deleted afterwardsonce the attacker has gained root access. In fact, the firmware rootkit could replace the commandsfound in the cache with innocent looking data, e.g., if the command to start the rootkit was“3e91923511ce3ad01dc6ae56d3874dc6a7bef7aec532d365a4d83037eca4f20a13374211” it couldbe replaced with the valid user agent string “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0)Gecko/20100101 Firefox/40.1” before actually being written to disk.

19

3 Persistent data acquisition (from hard drives)

3.2.1.3 Other HDD firmware rootkit examples

Zaddach et al. demonstrated a similar exploit to sprite_tm’s work in their work “Implementationand implications of a stealth hard-drive backdoor” [173]. They further detailed optimizations tocontrol the rootkit in a way which makes the attack more feasible than sprite_tm’s prototype. Also,according to talks by the co-authors Goodspeed at 0x07 Sec-T Conference in 2014 [61], Kaminsky1at DEF CON in 2014 [83], and Zaddach himself at REcon in 2014 [172], they used a 500GB SeagateBarracuda HDD, showing that such firmware rootkits are not just affecting Western Digital drives.

In the following years more and more researchers recreated these HDD firmware bootkits andreported their results online. These examples of security researchers recreating sprite_tm’s workfurther show not only the feasibility, especially with regard to implementing their own firmwarerootkits, but also the relevance in the field of anti-forensics. Given that multiple independentresearchers have been able to recreate the rootkit and even openly posting about it online provesthat criminals have access to this kind of information. Forensic scientists should, therefore, expectsuch firmware compromises when investigating high profile cases of industrial espionage, etc.

Last but not least, the crucial part about this type of compromise is that there will be no evidenceon the regular data storage areas of the HDD. And any attempt to clean the drive will be futilebecause the changed root password hash is modified on the fly and never actually written to theplatter.

3.2.2 Interfering with data acquisitionBesides the above-mentioned scenario of persistent root access, trivial but yet efficient anti-forensicmeasures can be employed. E.g. the partitions of the HDD can be formatted in a way that afterthe partition table — irrelevant whether DOS/MBR or GPT — one sector is left unallocated,so it is never accessed by the system during regular operation. This sector can then be used bymanipulated firmware as a digital trap [61, https://youtu.be/8Zpb34Qf0NY?t=1095] and triggerany combination of — but not limited to — the following anti-forensic measures:

• only return zeros when reading specific sectors of the HDD (i.e., sectors containing evidence)

• only return zeros on all reads from the device

• return zeros on all read request and overwriting the requested data with zero on the HDD

All the above measures impact the quality of the forensic results obtained from the device. Whilethe first two are very subtle, they should, in general, be enough to stop forensic expert workingaccording to the current state of the art from discovering evidence. But they still leave the evidenceon the device. While measure three is not subtle, it will destroy the evidence. Given that imaginga drive is often automated and takes time, it is unlikely a forensic analyst realizes that the data hasbeen overwritten after the drive was imaged.In any case, the current state of the art does not consider such attacks and hence does not protectfrom them. Special equipment such as a write blocker will not prevent the drive itself, but only theinvestigator, from (accidentally) writing to the disk. Other practices, such as hashing the image,will also not help, because the data was already manipulated on the device. Imaging the devicetwice (or even three times), first without HPA, then with HPA (and then DCO) enabled, could,depending on the type of anti-forensic trap used, yield discrepancies between each imaging result.For example, the first time the partition table is read the data is read correctly. Then, once thesector after the partition table functioning as the trap is read the partition table will suddenlybe zeroed out. However, in case the data was erased during the first imaging process, noticingdiscrepancies at the second imaging process is too late.

1Even though not named on the publication, he admitted to being an “unindicted co-conspirator” [83, https://youtu.be/xneBjc8z0DE?t=550].

20

3.2 Hard disk firmware bootkit

3.2.3 Detection (in EEPROM)

Detecting manipulated firmware must be done via hardware, i.e., physical access. This is becausecompromised firmware could simply acknowledge requests that new — non-compromised — firmwarehas been written successfully when the investigator tries to upload such non-compromised firmwareto the device. The compromised firmware could use the Service Area to store a shadow firmware,which is returned on read requests and overwritten on write requests. All, of course, withoutactually touching the real firmware on the controller.One possibility to verify firmware with software only access would be to upload firmware with acharacteristic behavior, e.g., returning a magic value when reading a specific sector. This way onecould make sure that at least this functionality of the firmware is executed and then assume therest of the uploaded firmware is also executed. However, this gives no 100% assurance, becausecompromised firmware could only temporarily load the newly uploaded firmware and at a laterpoint switch back to the compromised firmware, e.g., via a command string written to disk asdetailed in Section 3.2.1.2 on page 19. This is possible because the Service Area provides enoughstorage for multiple versions of the firmware.Here it is critical to acknowledge the fact that the Service Area can only reasonably be read throughthe controller itself and hence the firmware. This means without physical acquisition of the firmwarebinary no 100% assurance can be given. However, in this section we only look at the currentlyeasily available HDD firmware compromise methods, i.e., a bootkit residing within the EEPROM.A deeper HDD compromise down into the system and overlay modules within the Service Area isoutlined in Section 3.3 on page 28.To detect a bootkit as that follows the scheme outlined by sprite_tm [37], the firmware loaderresiding in the EEPROM must be verified. For this three steps are needed: identifying the EEPROMchip, reading the EEPROM chip and last but not least verifying its contents.

3.2.3.1 Identifying the EEPROM

Figure 3.2: Identifying the EEPROM of a Western Digital WD3200AAKX HDD

The EEPROM can be identified by reading the part number on the chip. Because the marking isoften very small it is advised to read the part number from a picture. Figure 3.2 shows a picture ofthe Western Digital WD3200AAKX EEPROM, taken with an inexpensive of the shelf consumersmartphone (LG L70). The direction of light is important to maximize the readability of themarkings. As can be seen from the picture the EEPROM of this Western Digital WD3200AAKXis a Programmable Microelectronics Corporation Pm25LD020 chip. A list of chips used withindifferent HDDs can be seen later in Table 3.1 on page 33.

21

3 Persistent data acquisition (from hard drives)

3.2.3.2 Reading the EEPROM

The process of reading the firmware on our Western Digital WD3200AAKX example HDD isstraightforward and can be done without desoldering the EEPROM chip. We used a commerciallyavailable SOIC-8 programming clamp and the Autoelectric MiniPRO TL866CS programmer. Oncethe controller PCB has been removed from the HDD the SOIC-8 programming clamp can simply beclipped to the EEPROM chip as can be seen in Figure 3.3. This process is referred to as in-circuitprogramming. Figure 3.4 depicts the reading of a desoldered EEPROM chip.

Figure 3.3: Reading an EEPROM with an in-circuitprogramming clamp without desoldering

Figure 3.4: Reading the EEPROM after it has beendesoldered from the HDD’s PCB

To increase transparency, we used the open source minipro software by Valentin Dudouyt instead ofthe official but proprietary software by Autoelectric. The MiniPRO programmer supports over 10 kdifferent EEPROM chips. It only supports 3.3V SPI EEPROM chips, however, some EEPROMchips are 1.8V. To read those 1.8V chips — or other chips unreadable by the MiniPRO — weused a Bus Pirate v4.0 by Dangerous Prototypes in combination with the open source flashromsoftware.Table 3.1 on page 33 shows all HDDs we tested for compatibility with this EEPROM acquisitionmethod. The table lists the HDD Vendor, HDD Model, the EEPROM chip used and whether ornot we were able to read the EEPROM in-circuit. We were able to acquire the firmware portionstored in the EEPROM of all the devices containing an EEPROM. However, only on about half,we could acquire the EEPROM in-circuit. Nevertheless, we demonstrate the practicability of ourproposal. Reading out the EEPROM in-circuit does not pose an unreasonable overhead in HDDdata acquisition. We, therefore, propose that this procedure should be best practice when imagingHDDs of systems under suspicion of malware and/or rootkit compromises. Because the potentialbenefits, as we will show in the next sections, outweighs the effort to read the EEPROM. In casethe EEPROM can not be read in-circuit, we, however, rather recommend imaging the drive withoutdesoldering it first — unless there are strong indications that the drive is actually compromised.

Even though in-circuit reading on the WD3200AAKX was straightforward, for other hard drives itwas sometimes challenging to read the EEPROM in-circuit, i.e., without desoldering. In certainboard layouts applying power to the EEPROM via the SPI interface would power-up the wholeboard, including the processor, causing the programmer to, either abort due to over-currentprotection, or return all ones on reading the chip ID or data. To remedy the problem, it sometimesis possible to hold the board in reset, i.e., pull down the system reset pin of the board, as canbe seen in Figure 3.5 on the facing page. Further Figure 3.6 on the next page shows what webelieve to be the reset pins and grounds of the HDDs listed in Table 3.1 on page 33 requiring thisprocedure for in-circuit reading. We are reasonably certain these are the respective correct resetpins. However, once connecting the marked contacts, we were able to read the EEPROM withoutany problems.

22

3.2 Hard disk firmware bootkit

Figure 3.5: Holding a board in reset by pulling theprocessor’s reset pin

Figure 3.6: Reset and ground pins to be connectedfor in-circuit reading from an ST31000340NS

Whether a board needs to be held in reset for in-circuit programming to work is indicated inTable 3.1 on page 33 with the rst footnote. On other occasions, when the error message fromthe minipro software is “IO error: expected 7 bytes but 5 bytes transferred”, we foundmultiple quick successive read attempts to cause the reading to work. In this case presumably,the applied voltage supplied to the EEPROM charged the decoupling capacitors which are spreadover the circuit board. Consequently, after these had been charged up, the EEPROM reached itsrequired minimum supply voltage and was able to operate correctly. In the big table, we indicatethis via the rep footnote.

To verify a successful read we always performed three readouts and checked for identical bit patterns.We found this to be very important, because even slightly defective or loose contacts in either theSPI cables or the probe cables which hold the board in reset can cause read errors, which can go byunnoticed unless checked for.

Not all EEPROMs could be read in-circuit. Interestingly we were only unable to read the EEPROMof HDDs by Toshiba and HGST. These HDD’s board layouts were basically identical. This ispresumably because as of 2012 the HGST’s 3.5” HDD division is owned by Toshiba. However, allthe EEPROMs of all the HDDs listed in Table 3.1 on page 33 can be read by desoldering them.Further in case a HDD is not listed as in-circuit-programmable in Table 3.1 on page 33 does notmean it is in general impossible to do so, but rather that we did not manage to do so with ourequipment.

3.2.3.3 Verifying EEPROM contents

In order to determine a procedure on how to verify different firmware obtained from the EEPROM,we used our example drive the Western Digital WD3200AAKX. More specifically we used 16 differentones. We extracted the EEPROM of each and then compared the retrieved contents. From this sam-ple set we concluded that the firmware retrieved from the EEPROM can not be compared directly,i.e., via a hash or bitwise comparison. This is because the EEPROM also stores information that isdifferent for each drive. The 16 analyzed HDDs had 4 different firmware revisions with each revisionbeing found on 8 and 5 drives respectively and 3 firmware revisions being found only on 1 drive each.

Figure 3.7 on the following page shows cross-comparisons, via hexcompare, of different firmwarebinaries from different WD3200AAKX HDDs. The blue and/or green parts are identical betweenthe two binaries. The red areas mark differences.

23

3 Persistent data acquisition (from hard drives)

(a) Same firmware revisions (b) Different firmware revisions (c) More drastically differentfirmware revisions

(d) Detailed view of Figure 3.7a showing the differences in more detail

Figure 3.7: Cross-comparisons via hexcompare of the EEPROM contents of different WD3200AAKXs(Blue and/or green output is identical in both, while red marks differences)

Figure 3.7a shows a comparison of the EEPROM contents of drives using the same firmware revision.Here we can observe that overall the contents is almost identical. Only some byte sequences atthe end of the EEPROM are different. These byte sequences are within so-called ROYL ROMmodules. ROYL refers to the drive and firmware architecture used by Western Digital for theWD3200AAKX hard disk. The ROM refers to the type of module, i.e., in this case, a moduleresiding in the EEPROM. And last the term module refers to a part of the firmware which isorganized modular in so-called modules. Here the difference is located in the modules with IDs0x0a, 0x0d, 0x30, and 0x47. Module 0x0d contains identity information. Module 0x30 is the ServiceArea translator, i.e., where on the platter is the Service Area. Module 0x47 is responsible forsurface adaptives, i.e., how far is the head away from the platter, etc. All these modules containdrive specific information, and hence, are different for each drive. We have also found module 0x0b(Module Directory) in the EEPROM as well. However, it was identical within each firmware revision.

24

3.2 Hard disk firmware bootkit

As is already clear at this point a bitwise comparison is, even between the same firmware revisions,not possible, as the EEPROM already contains data individual to that specific hard disk, namelythe surface adaptives and SA Translator modules. However, because the position of these modulesis the same for the same firmware revision, they can simply be excluded from the comparison. Usingthese modules to store a rootkit or other compromising code is not possible, because the variabledata is first too small to hold meaning full exploitation code and second not executed. Hence, if allother portions of the EEPROM contents are identical to known good EEPROM contents, it is safeto assess that the EEPROM can also be considered good and not compromised.

Figure 3.7b on the facing page depicts a comparison of two different firmware revisions. Herethe same modules as before contain differences, but also the actual firmware at the start of theEEPROM is different. Starting with the section header. It is different because some sectionschanged in size. Next, comes the bootstrap code, which is responsible for decompressing the otherfirmware sections. As can clearly be seen from the large blue section after the small initial redsection this bootstrap code did not change between these firmware revisions. The following sections,however, are all completely red. Here it is important to note that this does not mean that theentire firmware changed between these revisions. Because these sections are compressed even smallchanges lead to different compression tables and a bitwise completely different data stream. Theempty space after the sections containing the firmware is blue again, because they, for both revisionsare filled with 0xff indicating empty flash blocks.

Figure 3.7c on the preceding page depicts the comparison of two different firmware revisions. Unlikethe previous example, the changes between these firmware revisions can be characterized as major.First, the position of some ROYL modules changed. The modules are now located more closelyafter the last firmware section. The yellow frames and the arrow indicate from where to where themodules moved within the EEPROM.

Another noteworthy change is within the bootstrap code. Unlike before, the bootstrap code actuallychanged. Because the bootstrap code is not compressed, the unchanged sections remain identical.However, because adding and removing code changes the offset of all code following, the bootstrapcode eventually also differs in our non-offset compensated bitwise comparison and is marked asred. For further discussion, it should be remembered that there are still unchanged parts of thebootstrap code showing up as blue, though.

Last but not least, it is important to acknowledge that even though the header changed, as before,its length remained the same. This means no additional sections have been added, nor have sectionsbeen removed. This indicates that the number of sections seems to be a rather fixed entity of theWestern Digital ROYL firmware.

Figure 3.8 on the following page shows comparisons of clean EEPROM firmware contents withinfected EEPROM firmware contents. As before, a blue output indicates that there is no differencebetween the clean and infected EEPROM contents, while red indicates a difference. First, inFigure 3.8a on the next page we compare the same EEPROM contents but before and after beinginfected with the rootkit as per sprite_tm’s proof of concept rootkit code [36]. Unlike before almostthe entire bits of the EPROM contents changed, save the empty part and the ROYL modules.This is because sprite_tm’s bootkit adds itself as an additional section to the firmware. Thiscauses the header at the beginning of the EEPROM to be extended by 32 bytes. This causes thesections following the header to be shifted by that 32-byte offset, thus, changing the EEPROMcontent from the non-infected EEPROM. Further, because the sections are shifted, their beginningaddresses within the EEPROM change as well. This, in turn, causes the header fields containingthese addresses to also change, which causes the checksums for the header sections to also change.Hence, the EEPROM contents almost completely changed, compared to the contents before theinfection.

25

3 Persistent data acquisition (from hard drives)

(a) Firmware before and after bootkit infection as persprite_tm’s proof of concept rootkit code [36]

(b) Same firmware revision but one with bootkit in-fection as per sprite_tm [36]

Figure 3.8: Cross-comparisons via hexcompare of the EEPROM contents of a firmware bootkit infectedWD3200AAKXs (Blue output is identical in both, while red marks differences)

However, because a direct comparison of the EEPROM contents before and after infection isimpracticable, we compared the infected EEPROM contents with clean EEPROM contents withthe same firmware revision. The results can be seen in Figure 3.8b. We see the same changesas we saw in the case of comparing the same EEPROM contents with itself before and afterinfection. However, as demonstrated earlier in Figure 3.7a on page 24, the ROYL modules locatedwithin the EEPROM after the firmware differ for different HDDs, even when containing the samefirmware revision. Hence, we also see some changed byte sequences towards the end of the EEPROM.

We can now, with the above knowledge, formulate a procedure to verify EEPROM contents xagainst a set of known-good EEPROM contents G = {g1, g2, . . . , gn}:

• If x ∈ G the EEPROM x is good. In fact, it is one of the samples.

• For each g in G check– whether x ≈ g with only differences in the ROYL modules after the firmware sections.

If this is the case then the EEPROM x is good.– whether the section header in x contains more than one section with block code number

0x5a, i.e., main loader section. If this is the case the EEPROM x is definitively infectedwith a bootkit.

• Otherwise, the EEPROM x can not be verified as good.

Here it is important to understand that it is not enough to verify that the section header at thestart of the EEPROM does not contain a second main loader section, i.e., a second section withblock code number 0x5a. While this is enough to detect the prototype bootkit by sprite_tm, itis not enough to detect a more elaborate bootkit. In theory, a bootkit could hide in one of thecompressed sections. Hence, even an EEPROM comparison looking like the top part of Figure 3.7con page 24 with the bottom part looking like Figure 3.7b on page 24, does not indicate a cleanEEPROM. The clean state can only be assessed via the above procedure.

Because the firmware is not digitally signed it is hard to be 100% certain a firmware is notcompromised, making it hard to build a set of known good EEPROM firmware samples. There areseveral ways to verify an EEPROM as good:

• Extract the EEPROM from vendor updates.– This seems like the most convenient way. It can also be secure in case the vendor update

is digital signed. However, HDD firmware is usually not regularly updated via vendorupdates.

26

3.2 Hard disk firmware bootkit

• Reverse engineering the EEPROM contents and verify it does not contain any unintentionalfunctionality.– This is the safest. This ensures even against compromise via vendor-supplied firmware.

However, it is impracticable. Goodspeed acknowledged that it took the authors behindImplementation and implications of a stealth hard-drive backdoor [173] “ten man months”[61, https://youtu.be/8Zpb34Qf0NY?t=1396] to reverse engineer the firmware of aSeagate Barracuda HDD. He further stated that they “killed 15 hard disks” [61, https://youtu.be/8Zpb34Qf0NY?t=1442] during their research. And this was to develop a hook-based bootkit for the HDD. Verifying any and every functionality within the firmwarecould potentially take much longer. This makes it impracticable for a productive forensiccontext. It may be applicable within an audit for highest security environments.

• Determining good EEPROMs via clustering.– While this approach can not provide 100% assurance, it provides a reasonable trade-off

between practicability and certainty. The basic idea to build a set of good EEPROMsfor the WD3200AAKX is as follows:1. Collect EEPROM contents of as many WD3200AAKXs as possible into your test

set T .2. Add each EEPROM sample to its own cluster.3. Compare the EEPROM contents pairwise via hexcompare.4. If the comparison indicates the same firmware revision, i.e., the result looks similar

to Figure 3.7a on page 24, with only differences in the ROYL modules 0x0a, 0x0d,0x30, and 0x47 join the clusters of the two compared EEPROM samples.

5. Define a trust-threshold t.6. Add one EEPROM sample of each remaining cluster to your good WD3200AAKX

EEPROM sample set G if the number of EEPROM samples within the cluster isabove your trust-threshold t.

This scheme only works if no more than trust-threshold t many EEPROMs within thetest set T are compromised. Hence, it is advised to not included HDDs that are suspectedto be compromised in test set T . Ideally, test set T should only contain samples froma good source, e.g., bought directly from the vendor. Obviously, this does not protectagainst a bad vendor, unlike the reverse engineering method.

3.2.4 SubvertingA bootkit compromise as outlined previously can be subverted by replacing the compromisedEEPROM contents with legitimate EEPROM contents. This can be done by writing the EEPROMvia SPI. This is the inverse process of the EEPROM reading as outlined in Section 3.2.3.2 on page 22.The same rules regarding in-circuit programming as discussed for reading also apply to writing.Another possibility is to replace the EEPROM by desoldering it, or replacing the entire PCB of theHDD. This process is often done by data recovery specialist in case of a bad EEPROM or bad PCB.Here it is important to leave the drive specific data from the ROYL modules 0x0a, 0x0d, 0x30, and0x47 from the compromised EEPROM intact, because otherwise the correct functionality of thedrive can be impacted. In case the EEPROM or PCB is swapped, this data must be copied to thereplacement EEPROM.

3.2.5 InvestigatingTo investigate the actual firmware rootkit is a complex task. As noted earlier, Goodspeed acknowl-edged that it took ten man months to reverse engineer the firmware of a Seagate Barracuda HDD.This firmware is not obfuscated in any way. So if the task is to investigate a sophisticated firmwarerootkit this time could potentially be increased dramatically.

27

3 Persistent data acquisition (from hard drives)

3.3 Overlay/module-based hard disk firmware rootkitIn the previous section, we outlined how the boot loader code stored in the EEPROM can beverified to detect and combat firmware bootkits. However, as already suggested in the previoussection, the EEPROM is not the only place where the HDD stores its firmware and hence malwarecan hide. After the boot loader code loaded from the EEPROM initialized the HDD enough to readfrom the spinning platter, further firmware code is loaded from the Service Area. Western Digitalcalls these additional firmware blocks modules, while Seagate calls them overlays. A firmwarerootkit hiding in the Service Area is harder to detect than the previously discussed bootkit insidethe EEPROM.

3.3.1 Verifying overlays/modulesIn order to detect an infected overlay and/or module, the overlays and modules must be verified.The general ideas of Section 3.2.3.3 on page 24 can be reused to verify the overlays and modules.The challenging part is acquiring the overlays or modules without the risk of a rootkit interfering inthe acquisition process. As outlined before a compromised firmware could simply return the originalfirmware when it is read, and keep it in a shadow copy for write requests to it — all while continuingto run the compromised firmware. We now outline the possibilities to read the Service Areas onour WD3200AAKX example HDD. We also provide an alternative memory analysis procedure thatcan be used to analyze a hard disk.

3.3.1.1 Reading Service Area

To read the Service Area of the WD3200AAKX there exist two possibilities. While the first relieson the potentially compromised firmware, the second can deliver 100% trust, but requires a largeamount of engineering.

Vendor Specific Commands (VSC) The Service Area can be read via SATA by issuing vendorspecific commands (VSCs). Hiding Data in Hard-Drive’s Service Areas by Berkman [13] outlineshow the Service Area can be read from a Western Digital WD2500KS HDD. They also publishedtheir source code, which can be adapted to be used with the WD3200AAKX. The Service Areamodules can further be read with the commercial PC-3000 tool suit.

The problem with this method of reading the Service Area is that the vendor specific commandssend via SATA to the HDD, are interpreted by the very firmware running the HDD. If that firmwareis compromised, it can simply deny the read requests or return a clean copy of the original firmwaremodules, etc. Hence, this method is not anti-forensic resistant enough to withstand very deep andelaborated rootkit compromises.The problem is complicated by the fact that the parts of the firmware responsible for providing theSATA interface are located in modules stored in the Service Area. Meaning that this firmware codecan not be verified within the EEPROM. Hence a way to access the Service Area without using thefirmware located within it must be devised.

Custom Boot Loader The only way to read the Service Area without relying on the firmwarelocated within it is to use a custom boot loader. To this end, the EEPROM can be programmedvia physical access, again programming via software will invoke potentially compromised firmwareon the HDD. This is not a trivial task. However, because the HDD runs any code without anysignature checks whatsoever, it boils down to reverse engineering how the firmware accesses theService Area and reimplementing this functionality into a minimal boot loader, which dumps thecontents of the Service Area. Many HDDs have a UART interface which can be used to loadadditional code in case the EEPROM provides insufficient space, and to possibly dump the ServiceArea contents. Table 3.1 on page 33 provides an overview of which HDDs contain such a UARTinterface. Many HDDs also contain the testing and debugging interface JTAG, which can aid indeveloping such a custom boot loader. Whether a HDD has JTAG is also documented in Table 3.1on page 33. The documentation lists the IDCODE that should be expected to be found when

28

3.3 Overlay/module-based hard disk firmware rootkit

performing an IDCODE scan on the JTAG interface. Again, if Table 3.1 on page 33 does not listUART or JTAG on a specific HDD does not mean it does not have JTAG or UART. It simplymeans that during our investigations we have not found such interface or could not utilize it. Weoutline JTAG in more detail in Section 3.3.2.1.

3.3.2 Memory analysisBecause developing a custom boot loader to dump the Service Area without involving potentiallycompromised firmware, we propose a memory analysis as an alternative. This can be comparedwith doing a live analysis on a computer system — in this case the HDDs processor.

3.3.2.1 Dumping memory via JTAG

Figure 3.9: JTAG pin layout of the WD3200AAKX Figure 3.10: Wires soldered to the JTAG pins of aWD32000AAKX

Figure 3.11: A MICTOR 38 pin connector solderedto the JTAG test pads of a WD32000AAKX

Figure 3.12: UART pin layout of Seagate HDDs

As mentioned before, many hard disks contain the testing and debugging interface JTAG. We canuse the JTAGulator hardware to determine the JTAG pinout of suspected JTAG pins. Figure 3.9shows the JTAG pin layout of our example WD3200AAKX HDD. Figure 3.10 shows wires solderedto the JTAG pins, which are then connected to the BusBlaster v4 JTAG interface. In Figure 3.11, aMICTOR connector was soldered to the WD3200AAKX. This not only provides a more convenientaccess, but also is easier to solder to the pads than individual wires. This means that the solderingskills only need to be moderate to achieve a JTAG connection.

29

3 Persistent data acquisition (from hard drives)

With OpenOCD we can then dump the relevant firmware files. The used OpenOCD commands canbe seen in Listing 3.1. The mask ROM boot loader is mapped into memory at offset 0xffff0000. Itis dumped via the first command. Then the firmware sections of the EEPROM are dumped.dump_image bootrom .bin 0 xffff0000 0 x10000dump_image bootsection0 .bin 0 x1b000 0 x1aa0[...]

Listing 3.1: OpenOCD command to dump memory sections of a WD3200AAKX HDD

The addresses of the firmware sections in memory can be extracted from the header in the EEPROM.This can, e.g., be done with sprite_tm’s fwtool [36, http://spritesmods.com/hddhack/hddhack.tgz] via ./fwtool -i eeprom.bin. The “Block load vaddress” of each section in the output isthe memory address to which that section is loaded by the boot loader. Next, the same procedurecan be used to dump the entire address space and verify code integrity by reverse engineering.Because the firmware is capable of loading additional modules from the Service Area at any time,the memory should be dumped periodically and analyzed for changes.

Even though this can also not provide 100% assurance, it is more feasible, to begin with, thandeveloping a boot loader. But ultimately this form of memory analysis should be used to reverseengineer the hard disk under investigation to the point where developing custom boot loader codeis possible. This is especially true, since all HDD controller processors we tested via JTAG wereall MMU-less, i.e., not using a memory managing unit (MMU) to restrict memory accesses. Thismeans any process running on the controller can modify any and all code and data in RAM. Thismeans the only way to truly assess non-compromise is when each and every instruction executed bythe processor is verified before execution.

3.3.2.2 Dumping memory via UART

While not anti-forensic resistant because it involves the firmware of the HDD, is the possibility toleverage the debugging console provided by Seagate HDDs via their UART interface. Figure 3.12on the previous page shows the UART pin layout. Table 3.1 on page 33 lists the baud rates andstop bit configurations of the tested Seagate HDDs. Booting the HDD should output a messagesimilar to the one listed in Listing 3.2. Once this message is displayed commands can be entered.Listing 3.3 on the facing page displays an example session. First, Ctrl+Z is pressed to activate theASCII Diagnostic Serial Port Mode. This is acknowledged by the device by displaying the F3 T>prompt. From there further commands can be issued. In the example the Diagnostic CommandLevel is changed to Level C by entering /C. Then the ASCII Command Information is displayed via Q.

Boot 0x40MSpin Up

TCC -001C[0 x000065B4 ][0 x00006A20 ][0 x00006E8C ]Trans .

Rst 0x40MMC Internal LPC ProcessSpin Up

TCC -001C(P) SATA Reset

MCMainPOR : Start :Check MCMT Version : CurrentMCMainPOR : Non -Init Case

Reconstruction : MCMT Reconstruction StartMax number of MC segments 0A61

Nonvolatile MCMT sequence number 000161 C9[RSRS] 07 C8

Reconstruction : Completed 1:[ MCMTWS ]

MCMainPOR : MCTStateFlags 0000002 A MCStateFlags 00005141MCMainPOR : Feature Enabled ...

[SR] 0000PowerState = IDLE1

Listing 3.2: Boot message on UART from Seagate ST2000DM001

30

3.4 Discussion

F3 T >/C

F3 C>Q

Online CR: Rev 0011.0000 , Flash , Abort[...]Online ^C: Rev 0011.0000 , Flash , Firmware Reset[...]Online ^Z: Rev 0011.0000 , Flash , Enable ASCII Diagnostic Serial Port Mode[...]All Levels ’/’: Rev 0001.0000 , Flash , Change Diagnostic Command Level , /[ Level ]All Levels ’+’: Rev 0012.0000 , Flash , Peek Memory Byte , +[ AddrHi ],[ AddrLo ],[ NotUsed ],[ NumBytes ]All Levels ’-’: Rev 0012.0000 , Flash , Peek Memory Word , -[ AddrHi ],[ AddrLo ],[ NotUsed ],[ NumBytes ]All Levels ’=’: Rev 0011.0002 , Flash , Poke Memory Byte , =[ AddrHi ],[ AddrLo ],[ Data ],[ Opts][...]Level 1 ’S ’: Rev 0011.0001 , Flash , Edit Processor Memory Byte , S[ AddrHi ],[ AddrLo ],[ MemValue ],[ NumBytes ],[ Opts]Level 1 ’U ’: Rev 0011.0001 , Flash , Edit Buffer Memory Byte , U[ AddrHi ],[ AddrLo ],[ MemValue ],[ NumBytes ]Level 1 ’e ’: Rev 0011.0000 , Flash , Spin Down and Reset Drive , e[ MsecDelay ],[ Opts]Level 1 ’m ’: Rev 0011.0001 , Flash , Edit Processor Memory Word , m[ AddrHi ],[ AddrLo ],[ MemValue ],[ NumBytes ],[ Opts][...]Level C ’Q ’: Rev 0001.0000 , Overlay , Display ASCII Command Information , Q[ CmdLevel ],[ Cmd][...]Level T ’[’: Rev 0011.0000 , Overlay , ASCII Log Control , [[ LogFunction ],[ Log]

Listing 3.3: Displaying the available commands over the ST2000DM001’s UART

The interesting commands to peek and poke, i.e., read and write memory, are + to peek a byte and= to write a byte. Zaddach et al. [173] were able to use this simple interface to place a GDB stubinto the firmware and debug it further.Seaget is a project that uses this UART memory peeking interface to dump the memory and buffersof a Seagate HDD, hence also dumping the firmware as it resides in memory.

3.4 DiscussionBefore concluding this chapter we would like to discuss the various compromises and how eitherour work or already existing research can be used to detect the compromise.

3.4.1 Compromise in EEPROMA compromise located within the EEPROM, such as firmware bootkits, can be easily detected viathe methods outlined in Section 3.2.3 on page 21. Because currently, all publicly available sourcecode with regard to HDD rootkits use a bootkit within the EEPROM, verifying at least EEPROMintegrity during forensic investigations seems like a reasonable addition to HDD acquisition.

3.4.2 Compromise in Service AreaAs we have also outlined in this chapter more elaborate malware residing in the firmware overlays ormodules waiting to eventually be triggered is also possible. We propose the development of customboot loaders to dump potentially infected overlays and/or modules from the Service Area. However,due to the high complexity and unavailable documentation of the HDDs internal structures, sucha task is not trivial. Our proposed memory analysis method can, however, be used to search formalware during firmware execution. But this is no automated task and requires a large amount ofreverse engineering.

3.4.3 Compromised controller hardwareWhat has not been discussed in this chapter is a hardware compromise. This means that thecontroller chip itself is compromised. Either the chips mask ROM has been compromised duringmanufacturing or the chip itself has been replaced with an optical identical but functional differentchip. One example of such component replacement is the NSA’s FLUXBABBIT project. Com-promised hardware can either be detected via differential power analysis and related techniques[135] or depending on the type of compromise via X-Ray [45]. A destructive attestation methodwould be to “decap” the chip and successively remove each of the chip’s layers and use a scanningelectron microscope to verify the chip’s individual gates [112, 113, 128, 150].

31

3 Persistent data acquisition (from hard drives)

However, hardware compromise is very unlikely, as this would mean redeveloping the entire chipwith compromising enhancements. Hence a more likely scenario is the compromise of the bootROM stored within the controller chip. We were not able to verify the boot ROM directly. However,it can be verified via JTAG by reading it as mapped into memory at offset 0xffff0000. But thisassumes the JTAG hardware itself isn’t compromised. To rule out any hardware compromisein the controller the entire controller chip can be replaced with a controller chip of a knownnon-compromised hard-disk. In fact, for simplicity, the entire controller board can be replaced witha known non-compromised controller board. In such a case, the HDD specific calibration dataand references to the firmware overlays in the Service Area must, however, be copied from the oldEEPROM onto the new EEPROM, as already outlined in Section 3.2.4 on page 27.

3.4.4 SSDsWhile this chapter was demonstrated with a WD3200AAKX HDD, parts of this chapter are alsoapplicable to SSDs. To demonstrate this we also tested SSDs. These are listed in Table 3.1 on thenext page. While we were not able to find an SSD that contained firmware on an EEPROM, wewere able to find JTAG interfaces on most of them.

3.5 Conclusion and future workAfter presenting the state of the art in hard drive firmware rootkit compromise, outlining detectionand ramification measures for bootkits residing in the EEPROM and also a presentation of possibledetection methods for more sophisticated rootkits hiding within overlays or modules in the ServiceArea, we would like to conclude this chapter. While we do not completely solve the problem ofhard drive rootkits, it is the first work to investigate such hard drive compromises from a forensicperspective. It thereby offers the forensic community a first starting point for immediate measures,such as saving and potentially verifying the EEPROM contents when acquiring hard drives. Thisway EEPROM residing bootkits can be ruled out during investigations. This is important because,as has been shown in this chapter, the knowledge on how to implement these bootkits is publiclyavailable. Hence, this form of hard drive compromise may no longer be the reserved domain ofgovernment attackers, but may eventually end up being used by criminals.Future work in this area is the establishment of a known good firmware database. Maybe evensupport by VirusTotal (an online malware scanning service) to scan hard drive firmware samples.They already provide a possibility to scan BIOS firmware binaries.Another important future step is verifying the overlays and modules stored in the Service Areawithout relying on the firmware of the drive itself and also, for transparency sake, without relyingon proprietary software. Vendors are also responsible for ensuring their firmware can not be triviallymanipulated anymore. To this end, digital signing, as already proposed by Seagate in a technologypaper [130], must become common practice.However, to not be at the mercy of trusting the vendor, the outlined firmware verification, especiallyof the Service Area must still be pursued.

32

3.5Conclusion

andfuture

work

Type Vendor Model EEPROM Vdd IC Reader JTAG UARTHDD HGST HTS541010A9E680 MX25L4006E 3.3 no

HGST HUA722020ALA330 LE25FU206 3.3 noHGST HUA722020ALA330 PM25LD020 3.3 noHGST HUA723020ALA640 LE25FS406 1.8 noSamsung SP2504C - 57,600-8N1dbgSeagate ST10000DM003 LE25S81QE 1.8 no 38,400-8N1dbgSeagate ST10000DM003 W25Q80.W 3.3 yes Bus Pirate 38,400-8N1dbgSeagate ST2000DM001 EN25S40 1.8 yes Bus Pirate 38,400-8N1dbgSeagate ST31000340NS W25X40L 3.3 yesrst MiniPRO 38,400-8N1dbgSeagate ST3320620AS AT25F512AN 3.3 yesrep MiniPRO 9,600-8N1dbgToshiba DT01ACA100 PM25WD040 3.3 noToshiba DT01ACA300 PM25WD040 3.3 noWD WD3200AAKX W25X40 3.3 yes MiniPRO 0x121003d3 115,200-8N1xmod

WD WD3200AAKX PM25LD020 3.3 yes MiniPRO | Bus Pirate 0x121003d3 115,200-8N1xmod

WD WD5000AAKX W25X20BL 3.3 yes MiniPRO 0x121003d3 115,200-8N1xmod

WD WD800BEVS-08RS -SSD Intel SSDSA2CT040G3 W25X40C0x0 3.3 yes MiniPro

Micron MTFDDAC128MAM-1J1 - ?hdrSamsung MZ-75E500 - 0x4ba00477Super Talent STT_FTM32GX25H - 0x4f1f0f0f

rstController must be held in reset.repMultiple quick read attempts must be issued. Or an external 3v3 supply may be used to overcome the power issues.dbgFully fledged debugging console. Note: The baudrate can be changed.xmodXmodem protocol for downloading code. Must be enabled via shorting pins.0x0Did not contain any firmware. EEPROM was zeroed.hdrSSD has labeled JTAG header, but JTAGulator’s IDCODE scan fails.

Table 3.1: Analyzed HDDs: listing their EEPROMs with the corresponding voltages (Vdd); in-circuit programmability (IC); SPI reader used for in-circuit reading (ifpossible); IDCODE found via JTAG; baud rate and stop bit configuration for UART interfacing; (where applicable)

33

4 Memory acquisition evaluationWith increased use of forensic memory analysis, the soundness of memory acquisition becomes moreimportant. Because an unsound memory acquisition can reduce the quality of the memory analysis,sound memory acquisition is also important to prevent accidental self-inflicted anti-forensics. Inthis chapter, we, therefore, present a black-box analysis technique in which memory contentsare constantly changed via our payload application with a traceable access pattern. This way,given the correctness of a memory acquisition procedure, we can evaluate its atomicity and oneaspect of integrity as defined by Vömel and Freiling [163]. We evaluated our approach on severalmemory acquisition techniques represented by 12 memory acquisition tools using a Windows 764-bit operating system running on an i5-2400 with 2GiB RAM. We found user-mode memoryacquisition software (ProcDump, Windows Task Manager), which suspend the process during memoryacquisition, to provide perfect atomicity and integrity for snapshots of process memory. Cold bootattacks (memimage, msramdump), virtualization (VirtualBox) and emulation (QEMU) all deliverperfect atomicity and integrity of full physical system memory snapshots. Kernel level softwareacquisition tools (FTK Imager, DumpIt, win64dd, WinPMEM) exhibit memory smear from concurrentsystem activity reducing their atomicity. Their integrity is reduced by running within the imagedmemory space, hence overwriting part of the memory contents to be acquired. The least amountof atomicity is exhibited by a DMA attack (inception using IEEE 1394). Further, even if DMAis performed completely in hardware, integrity violations with respect to the point in time of theacquisition let this method appear inferior to all other methods. Our evaluation methodology isgeneralizable to examine further memory acquisition procedures on other operating systems andplatforms.

4.1 IntroductionVolatile memory (RAM) is an increasingly valuable source of digital evidence during a forensicinvestigation. Not only are cryptographic keys for full disk encryption kept in RAM, but alsomany other pieces of information like the list of running processes and the details of active networkconnections are kept in RAM and are lost, if the computer would be simply turned off duringevidence collection.There are many ways to acquire volatile memory on standard desktop and server systems today [162].The possibilities range from software-based methods with tools like DumpIt, WinPMEM, over DMAattacks [11], up to cold boot attacks [72]. All these methods have their advantages and disadvantages.On the one hand, while software-based methods are very convenient to use, they can be subvertedby malware [145]. On the other hand, DMA and cold boot attacks are often defeated by unfavorablesystem configurations (BIOS passwords or inactive DMA ports) or technology-immanent problems.Overall, these hindrances might produce memory images that are not forensically sound. To whatextent this happens, is still rather unclear.To address this point, Vömel und Freiling [163] integrated the many different notions of forensicsoundness in the literature into three criteria for snapshots of volatile memory: (1) correctness, (2)atomicity and (3) integrity. All three criteria focus on concrete requirements that are motivatedfrom practice:

• A memory snapshot is correct if the image contains exactly those values that were stored inmemory at the time the snapshot was taken. The degree of correctness is the percentage ofmemory cells that have been acquired correctly.

• The criterion of atomicity stipulates that the memory image should not be affected by signs ofconcurrent activity. It is well known that unatomic snapshots become “fuzzy” [96]. The degreeof atomicity is the percentage of memory regions that satisfy consistency in this respect.

35

4 Memory acquisition evaluation

• A snapshot satisfies a high degree of integrity if the impact of a given acquisition approachon a computer’s RAM is low. For instance, by loading a software-based imaging utilityinto memory, specific parts of memory are affected and the degree of system contaminationincreases (and consequently, integrity decreases).

All three criteria were formally defined and shown to be independent of each other.With these criteria, it was now possible to measure and not only estimate the forensic soundnessof snapshot acquisition techniques. This was then done by Vömel and Stüttgen [164] for threepopular memory acquisition utilities: win32dd, WinPMEM, and mdd. Their study exhibited somecorrectness flaws in these tools (which were later fixed), but also showed that their level of integrityand atomicity was all quite similar.The reason why Vömel and Stüttgen [164] only evaluated three software-based acquisition methodslies in their measurement approach: They used the open-source Intel IA-32 emulator Bochs runninga Windows XP SP3 on which the acquisition utilities ran. The utilities were instrumented suchthat every relevant event was recorded using a hypercall into the emulator, thus enabling themeasurement. Naturally, this white-box measurement approach was only possible for tools thatwere available to the authors with their source code, thus severely restricting the scope of theirmeasurement. It is clear that approaches such as DMA and cold boot attacks can only be measuredusing a black-box approach. Furthermore, these measurements were performed in a situation wherethe Windows system was basically idle, thus giving a lower-bound measurement. The impact ofsystem load on the quality of memory acquisition is not yet precisely known.

4.1.1 Related workVömel und Freiling [163] defined correctness, atomicity, and integrity as criteria for forensically-sound memory acquisition and provided a comparison matrix [162, Fig. 5] with regard to thedifferent acquisition methods. However, they also indicate that “the exact positioning of themethods within the fields of the matrix may certainly be subject to discussion” [162, p. 7]. The firstto evaluate these memory acquisition criteria were Vömel and Stüttgen [164]. As already statedthey relied on a white-box methodology restricting them to open source tools.Other works using the notion of atomicity are BodySnatcher [127], HyperSleuth [100] and Vis [171],all of which try to increase atomicity of forensic memory acquisition by suspending execution of theoperating system, hence reducing concurrency.

4.1.2 ContributionIn this chapter, we present the first black-box methodology for measuring the quality of memoryacquisition techniques. Extending the insights of Vömel and Stüttgen [164], we take correctness forgranted and focus on integrity and atomicity. Our approach allows comparing not only differentsoftware utilities with each other but also to compare them with totally different approaches likeDMA and cold boot attacks.The idea of our approach is to apply the memory acquisition method to memory content thatchanges in a predictable way: Briefly spoken, we use a program that writes logical timestampsinto memory in such a way that investigating the memory snapshot yields the precise time when acertain memory region was imaged. This allows inferring an upper bound in integrity and atomicitymeaning that these criteria will be at most as bad for the respective procedures.

4.1.3 OutlineThis chapter is structured as follows: First, in Section 4.2 on the facing page, we revisit themain definitions of Vömel and Freiling [163]. After this, we introduce our black-box measurementmethodology in Section 4.3 on page 38. In Section 4.4 on page 40 we give an overview of ourexperimental setup and in Section 4.5 on page 46 we outline our results. Finally in Section 4.6 onpage 50 we conclude our work.

36

4.2 Background: Criteria for forensically sound memory snapshots

4.2 Background: Criteria for forensically sound memorysnapshots

We briefly revisit the main definitions of Vömel and Freiling [163]. In their model, memory consistsof a set R of memory regions (pages, cells, or words) and a full snapshot covers all memory regionsof the system, i.e., it stores a value for every memory region in R. However, their definitionsalso hold for partial snapshots, i.e., snapshots that cover subsets R ⊂ R of all memory regions.Our evaluation methodology makes use of partial snapshots, therefore, we simplify the definitionstowards this case. Here we disregard correctness but rather focus on atomicity and integrity.

4.2.1 Atomicity of a snapshotIntuitively, an atomic snapshot should not show any signs of concurrent system activity. Vömeland Freiling [163] formalize this by reverting to the theory of distributed systems where concurrentactivities are depicted using space-time diagrams. Figure 4.1 shows an imaging procedure that runsin parallel to another activity on a machine using four memory regions R = {r1, r2, r3, r4}. Eachhorizontal line marks the evolution of each memory region over time, state changes are marked asevents. The imaging procedure is shown as four events (marked as squares) that read out eachmemory region sequentially. Concurrently, a separate activity updates memory regions (first r1,then r4, then r2, shown as black dots).

r1

r2

r3

r4

Figure 4.1: Space-time diagram of an imaging procedure creating a non-atomic snapshot

Definition 2 (Atomicity [163]). A snapshot is atomic with respect to a subset of memory regionsR ⊂ R if the corresponding cut through the [. . . ] space-time diagram is consistent.

The imaging process always corresponds to a cut through the space-time diagram since it necessarilyhas to access every memory region in R. The cut distinguishes a “past” (before the snapshot)from a “future” (after the snapshot). Intuitively, a cut is consistent if there are no activities fromthe future that influence the past [101, p. 123]. Given this intuition, it is clear that the snapshotcreated in Figure 4.1 is not atomic.

4.2.2 Integrity of a snapshotEven atomic snapshots are not taken instantaneously but require a certain time period to complete.The property of integrity refers to this aspect. Intuitively, integrity ties a snapshot to a specificpoint of time chosen by the investigator. A high level of integrity implies that the snapshot wastaken “very close” to that point in time.

Definition 3 (Integrity [163]). Let R ⊆ R be a set of memory regions and t be a point in time. Asnapshot s satisfies integrity with respect to R and t if the values of the respective memory regionsthat are retrieved and written out by an acquisition algorithm have not been modified after t.

37

4 Memory acquisition evaluation

t

r1

r2

r3

r4

Figure 4.2: Integrity of a snapshot with respect to a specific point in time t

In a certain sense, integrity refers to the “stability” of a memory region’s value over a certaintime period. Figure 4.2 illustrates the idea: The example consists again of four memory regions,i.e., R = {r1, r2, r3, r4}. We assume that at time t, the imaging operation is initiated and leadsto a change in the memory regions r3 and r4, as indicated by the black dots (e.g., by loading asoftware-based imaging solution into memory). Again, the snapshot events (when the respectivememory region is read out by the acquisition algorithm) are visualized as black squares. Regardingt, the snapshot satisfies integrity for memory regions r1 and r2 but not for r3 and r4.By t, we refer to the point of time when an investigator decides to take an image of a computer’smemory. Although being highly subjective, this point of time ideally defines the very last cohesivesystem state before being affected (in any way whatsoever) by the imaging operation; the value of tshould, therefore, mark a time very early in the investigation process.Vömel and Freiling [163, Lemma 1] show that under certain assumptions the integrity of a snapshotimplies its correctness and its atomicity.

4.3 Black-box measurement methodologyAs already suggested by Vömel and Stüttgen [164] we developed a black-box measurement method-ology allowing us to estimate atomicity and integrity. Our black-box methodology comprises aworst case analysis, in a high load scenario.

4.3.1 ImplementationOur technical implementation of the black-box methodology is as follows: First, we implementour payload application named RAMMANGL.EXE (the name refers to “RAM mangler”). This payloadapplication allocates memory regions. Each memory region is marked with a counter which isconstantly increased by the payload application like a timer.Second, we implement an analysis framework that reads the counter value back from each regionand runs statistics on them according to the estimation explained in the next section.

4.3.2 Estimating atomicity and integrityWe now devise two simple measures by which it is possible to estimate the atomicity and integrityof a memory snapshot. We call these measures the atomicity delta and integrity delta.Intuitively, atomicity is bounded by possibilities to write memory regions “from the past”. Hence,the faster all memory regions are acquired after the first region was “moved into the past”, i.e.,was acquired, the lesser regions can potentially be written to “from the past”. Atomicity can hencebe approximated by the atomicity delta, i.e., the interval from the acquisition of the first memoryregion to the acquisition of the last memory region as this is the area where inconsistencies within

38

4.3 Black-box measurement methodology

the image can be introduced. If no memory region has been acquired yet, all memory regions canstill be freely changed because no memory regions value has been “fixed” yet. The same is trueonce all memory regions have been “fixed”, i.e., acquired. Any changes to the memory regions thenwill not introduce any more inconsistencies. Good atomicity, therefore, corresponds to the speed oftaking the memory snapshot.In contrast, integrity implies that the memory snapshot is closely tied to the values that were presentin memory at the point in time the investigator initiated the acquisition. Obviously, software-basedmethods must, therefore, have a non-zero integrity since the acquisition tool changes memoryregions when loading itself into the address space of the system. Since we focus on process memoryand because forensic memory acquisition tools should strive for a neglectable footprint anyway, weconsider the amount of memory regions actually occupied and thereby changed by the acquisitiontool to be negligible. This assumption allows us to devise the integrity delta, i.e., the average overthe times required to acquire each memory region, given that imaging was initiated at acquisitionpoint in time t = 0.Formally, let C = (c0, · · · , cN ) be the vector of counters embedded in the N memory regions ofour payload application and t is the time the acquisition was started. We can now define our twomeasures that indicate atomicity and integrity as follows.

Definition 4 (atomicity delta). The atomicity delta is the time span between the acquisition ofthe first memory region and the last memory region, formally:

(maxi

ci) − (minj

cj).

Definition 5 (integrity delta). The integrity delta is the average time over all regions betweenstarting the acquisition and acquiring that memory region, formally:

N∑i=0

ci

N− t

Both measures are illustrated in Figure 4.3. The lower these values the better the atomicity and/orintegrity respectively.

t

Atomicity ∆

Integrity ∆

r1

r2

r3

r4

Figure 4.3: Atomicity and integrity

39

4 Memory acquisition evaluation

4.3.3 Intuitive examples

As an intuitive example, imagine the memory of a system to consist of four memory regions, eachmemory region containing one counter. Initially, the counters are all set to 0. Once the memoryacquisition starts the counters are atomically increased every timer tick. So the ideal memoryacquisition process should provide a memory image of C = (0, 0, 0, 0), that is all counters of all fourmemory regions still being in the exact state the acquisition was started.An example for an acquisition with high integrity but low atomicity would be the counter valuesC = (0, 0, 40, 0). This is indicated by a high atomicity delta of 40 and an integrity delta of 10.An example for an acquisition with high atomicity but low integrity, on the other hand, wouldhave counter values C = {1337, 1337, 1337, 1337}. In fact, an atomicity delta of 0 indicates perfectatomicity. While an integrity delta of 1337 indicates a poor point in time integrity, i.e., the snapshotwas acquired 1337 counter ticks after the investigator requested the memory snapshot to be acquired.

4.3.4 Practical constraints

However, because in practice it is not possible for an application to atomically update all counters,we have to introduce some constraints to our methodology. The reason why the counters can not beupdated atomically is the same reason why memory acquisition software can not acquire memoryatomically. This is due to modern computer systems distributing their computing and also memoryaccess resources in form of so-called threads. Each thread being allowed to use the system onlyfor a given amount of time then handing the system resources over to another thread. This waymultiple applications can run on the system quasi at the same time. While in reality they runsequentially, if the execution is handed over between threads fast enough, usually in the orderof milliseconds, interactivity, e.g., interactive graphical interfaces, can be achieved. Further cansystem tasks, such as processing interrupts, be run periodically. This is important to keep thesystem working correctly. Because most software memory acquisition software relies on parts of thesystem, e.g., file system or network drivers, to exfiltrate the memory to persistent storage, theycan not monopolize the systems resources in order to achieve atomic acquisition. One approacharound this is to subduct the operating system the control over the file system or network devicesand run the memory acquisition outside the real of the operating system, either as a different OSas demonstrated by BodySnatcher [127], or a hypervisor as demonstrated by HyperSleuth [100] orVis [171].

4.4 ExperimentsIn this section, we briefly outline our experiment. We start with the setup, then elaborate on issueswe encountered during the execution. We then describe our solution to the issues and our opinionin how far this affects our results and/or forensic memory acquisition in general.

4.4.1 Setup

We conducted our experiments on a 64-bit Windows 7 Enterprise operating system identifiable byits build number 7600.16385.amd64fre.win7_rtm.090713-1255. The hardware used was a FujitsuESPRIMO P900 E90+ with an Intel i5-2400 @ 3.10GHz and one 2GiB RAM module. Of these2GiB physical RAM, 102MiB were mapped above 4GiB (see PCI hole discussion in Section 4.4.3.1on page 42) and 10MiB were lost to the BIOS and PCI devices. Resulting in a total of 2038MiBphysical RAM usable by the operating system. The pagefile of the system was disabled to ensurethat all relevant data was residing in RAM.Due to issues of Volatility relying on kernel debugging data structures, namely the kernel debuggerdata block (_KDDEBUGGER_DATA64), which Volatility was unable to read in all our 64-bit RAMdumps (a known issue), we wrote our own tools, the concept behind which we will introduce inChapter 7 on page 85.

40

4.4 Experiments

The memory was acquired directly onto a removable storage device consisting of a 320GB WesternDigital WD3200AAKX-00ERMA0 hard disk inside a Inateck FD2002 hard disk docking stationconnected via USB 2.0. Even though the docking station supports USB 3.0 it was connectedvia USB 2.0 only. The disk was formatted with the Windows native file system NTFS. The diskconnected via USB could sustain 90MB/s write speeds. This was tested via dd. We copied (usingdd) 4GiB test files into the NTFS file system of the disk multiple times. In no memory acquisitiontest was this write speed reached, making us confident that disk I/O was not the determining factorof our evaluation. The memory acquisition tools were also started from this removable storagedevices, which was mounted by Windows as volume E. One exception to this was Windows TaskManager’s process dumping facility, which was invoked from the system’s Windows Task Manager.For the cold boot attacks with the memimage and msramdump tools we also used an WD3200AAKXdisk and the Inateck USB docking station. Inception was also invoked from a Lenovo X230t, theinternal hard disk of which could sustain 250MB/s write speeds again according to dd.

4.4.2 SequenceWe conducted our experiments as follows:

1. Startup computer.

2. Enter password to login user.

3. Wait approximately 1min for the system to settle.

4. Open cmd.exe via the Windows Start menu.

5. Enter E: to change the working directory to our removable storage.

6. Type “RAMMANGL.EXE 512 2048” but not start the payload yet.

7. Now the memory acquisition tool was started and prepared to the point where the leastamount of user interaction was needed to start the acquisition. In most cases this consistedof starting another cmd.exe as Administrator, changing the current working directory to E:and then invoking the tool. In other cases, we explain the procedure in Section 4.4.4 on thenext page.

8. Start the payload application RAMMANGL.EXE.

9. Start the memory acquisition tool immediately afterwards. The multitude of differentacquisition tools evaluated disallowed us from automating this step. We, therefore, tried ashard as we could to tie the start of the memory acquisition as close as possible to the point oftime of starting the payload application.

10. Start timing measurement with a stopwatch while not touching the system.

11. Stop time after the acquisition has completed, then close RAMMANGL.EXE (Ctrl+C).

12. Save the console output of RAMMANGL.EXE and the output of the acquisition tool to disk.

13. Note down the time on stopwatch to experiment log.

14. Restart the system.

Occasionally the hard disk was defragmented to ensure maximum write capabilities. This was doneat a maximum fragmentation rate of 3%, as reported by Windows. The defragmentation was alsodone by the Windows system.

41

4 Memory acquisition evaluation

4.4.3 IssuesIn this section, we will briefly list some issues that impacted our evaluation and how we haveovercome them.

4.4.3.1 PCI hole

The computer system used for our evaluation remapped all memory between 2GiB and 3.5GiB —the so-called PCI hole — to above 4GiB. This remapping happens on the physical address leveland not just the virtual address level. The remapping is usually performed by the BIOS.This remapping was no problem for user-mode, kernel-level and physical acquisition via cold bootattacks. It, however, posed a sometimes unresolvable problem for acquisition over DMA via IEEE1394. IEEE 1394 only provides DMA for the lower 4GiB of memory. In some occasions, importantmemory structures concerning our payload process, namely the process control block, were movedto memory above 4GiB making it impossible to reconstruct the virtual address space of the payloadprocess.All of the tested kernel level acquisition tools acquire the whole address space, “including” thePCI hole remapped addresses from 2GiB to 4GiB, filling this non-existing RAM with zero bytes.While this is not an issue preventing our experiments, it impacts some of the measured values.Because we only consider the memory contents of our payload application and these are scatteredthroughout the low 2GiB, the tools need half of their total runtime to acquire this memory anyway.For further analysis, we extract all timing information from the counters in the memory region ofour payload application.

4.4.3.2 Inconsistent page tables

In about every fifth memory dump acquired via kernel-level acquisition, we were confronted withinconsistent page tables. While almost the whole virtual address space of our payload applicationRAMMANGL.EXE could be reconstructed, a few pages were sporadically mismapped to virtual memoryof other processes, unused physical memory or kernel memory. The reason for this is yet unknown tous, however, because all tested kernel-level acquisition tools exhibited the same behavior, regardlessof the acquisition method (either using MmMapIoSpace(), the \Device\PhysicalMemory device orPTE remapping) we do not consider it to be a tool error. However, on the other hand, we alsodo not consider it to be an error of our framework, because we confirmed the correct assembly ofour virtual address space of our payload application with Volatility and the tools we developed anintroduce in this thesis in Chapter 7 on page 85. To resolve this open issue we simply repeatedmeasurements with inconsistent page tables until we acquired correct images for our analysis.

4.4.4 Analyzed methods and toolsIn this section, we introduce the tools and methods we evaluated with our methodology. Whileclassical memory acquisition techniques could be divided into hardware- and software-based solutionsthis no longer holds true because many acquisition techniques use both hard- and software [162, 3.Acquisition of volatile memory]. We hence divide the acquisition methods into: DMA attacks, coldboot attacks, software acquisition, and virtualization.

4.4.4.1 Cold boot attack

The physical memory of a system can be acquired via a cold boot attack, which were first popularizedby demonstrating them practically by Halderman et al. [72]. We will outline the cold boot attack ingreat detail in the next chapter. But briefly outlined, in a cold boot attack an attacker is leveragingthe RAM’s remanence effect. RAM does not lose its contents instantly but the charges of thestorage capacitors rather dissipate over time. Making it possible to read out the stored values of theRAM even after rebooting the system. To perform the attack an attacker reboots the hardware intoa small operating system capable of acquiring the RAM contents and writing them to persistentstorage [72]. Halderman et al. also made the tools, we refer to as the memimage, used for theiroriginal publication available online [71].

42

4.4 Experiments

Because the computer can be reset at any time, the point in time integrity is perfect. The same istrue for atomicity, because once rebooted all system activity stops perfectly conserving the RAMcontents. This makes the method 100% atomic. However, while the point in time of the acquisitioncan be chosen perfectly, the minimal operating system injected into the system inevitably overwritesmemory. Because the size of the memimage is only 9.9KiB, this RAM contents loss can, in general,be neglected when compared to the total 2GiB memory size of our test system. Making the integrityalso almost 100%. Another available tool to conduct cold boot attacks is msramdump by McGrewSecurity. It has a memory footprint of around 22.6KiB, i.e., it will overwrite 22.6KiB of RAMcontents.One problem with cold boot attacks are, however, bit errors that can be introduced during hardresets of the system or when trying to transplant the RAM from one system to another, seeSection 5.4.3 on page 63, in which case the correctness of the acquired image is considerablyimpacted.Even though the theory behind cold booting and/or resetting a machine at a specific point alreadyintuitively lets one assume perfect atomicity, we verified this with our experiments. Due to theintroduced bit errors during a hard reset or transplantation attack, which would have a negativeimpact on our evaluation methodology, we refrain from such complex attacks and only performed asimple reset attack, as outlined in Chapter 5 on page 51.

4.4.4.2 Emulation

QEMU is an open source computer emulator initially developed by Fabrice Bellard. It allowsoperating systems to be run within an emulated environment.We called QEMU from the command line with the -monitor stdio option. This allows convenientaccess to the QEMU monitor on the standard terminal of the host operating system. This way thememory of the emulator can be saved by invoking the command outlined in Listing 4.1. Duringmemory acquisition, the emulation is paused making the acquisition fully atomic. Even though thisis a known and clear-cut feature of the emulator we verified the perfect correctness, atomicity andintegrity of this memory acquisition method in our evaluation.

pmemsave 0 0 x80000000 qemu.mem

Listing 4.1: Command to dump the lowest 2GiB of memory from QEMU into the file qemu.mem

4.4.4.3 Virtualization

VirtualBox is an open source virtualization solution by Oracle. It employs Intel’s VT-x virtualizationtechnology allowing a guest operating system to be run within a host operating system without theperformance drawbacks incurred by pure emulation solutions. However, similar to emulation thememory can be acquired with perfect atomicity, correctness, and integrity. The command to savethe entire address space of a virtual machine into an image file can be seen in Listing 4.2.

vboxmanage debugvm ${ vmname } dumpguestcore --filename ram. elf64

Listing 4.2: Command to dump the memory from a VirtualBox virtual machine ${vmname} as an ELF64dump into file ram.elf64

4.4.4.4 Kernel-level acquisition

A very popular, because simple, area of memory acquisition tools are software tools, such asWinPMEM, DumpIt, win64dd, or FTK Imager, to name a few. They allow to conveniently dump thephysical memory to either a removable storage medium or transmitting it over the network.Especially popular are so-called kernel-level acquisition tools. Because in modern operating systemsapplications have no access to physical memory but only their own virtual address space, privilegedsystem access from within the kernel is necessary. This is often done in the form of a driver runningin kernel mode in conjunction with a user-level interface. Even though the kernel-level driver hasaccess to the full physical memory it is hard to write memory onto disk or transmit it via the

43

4 Memory acquisition evaluation

network from within the kernel. Hence, most acquisition solutions have a user-mode part usedto controlling the memory acquisition driver. The user-mode part is also in charge of writing theacquired memory to an image on disk or transmitting it over the network. This can then be donewith the regular APIs of the operating system.Because kernel-level acquisition tools are essentially a part of the same system they try to acquire aforensically sound memory image from, it is a very interesting aspect how their interaction withthe system impacts atomicity, integrity, and correctness.

FTK Imager Lite — we used version 3.1.1 — by AccessData is a graphical framework for liveforensics. It supports kernel-level memory acquisition. FTK Imager was one of the closed sourcetools mentioned by Vömel and Stüttgen as one candidate for a black-box analysis [164].

DumpIt — we used version 1.3.2.20110401 — by Matthieu Suiche and MoonSols is another kernel-level acquisition tool. Its main feature is its simple usage. The program has no options norconfiguration. The user starts it directly from a connected removable storage device. The startlocation is also the location to which the memory image is written. Due to this ease of use and thegeneral availability DumpIt is rather popular.

The tool win64dd — we used version 1.3.1.20100417 (Community Edition) — is another kernel-levelacquisition tool by Matthieu Suiche and MoonSols. We used the freely available CommunityEdition of the otherwise commercial product. Unlike DumpIt the tool win64dd offers severalconfiguration options, such as acquisition method (MmMapIoSpace(), \Device\PhysicalMemory,and PTE remapping as default) or acquisition speed (normal, fast, sonic, and hyper sonic as default).

WinPMEM — we used version 1.6.2 — by Michael Cohen is an open source kernel-level memoryacquisition tool. Like win64dd it offers an option to select between different acquisition modes(physical or iospace).

4.4.4.5 DMA

Memory can be acquired via a DMA attack. This attack uses a system bus such as PCI [19],PCIe [46] or IEEE1394 [11] to perform direct memory access (DMA) on a target machine. Asstated earlier IEEE1394 is restricted to the lower 4GiB of physical memory and requires a soft-ware driver on the target system to be present. PCI is not hot-pluggable, making it a solutionthat needs to be pre-installed, i.e., the target system must be made forensically ready beforememory can be acquired. Because DMA has to transfer individual memory pages while thesystem is running, which potentially changes the memory contents, the atomicity measure, asproposed by Vömel and Freiling [163], of this method, is considered to be only moderate [162, Fig. 5].

The toolset inception — we used version 0.4.0. — is a framework for DMA attacks developed byCarsten Maartmann-Moe and is available freely under the GPL license. It allows DMA attacks viaIEEE1394, also known as FireWire or i.LINK, and PCIe.

# ./ incept dump[...][\] Initializing bus and enabling SBP -2, please wait or

press Ctrl+C

Listing 4.3: inception indicating initialization of the IEEE1394 bus and waiting in order to enable theSBP-2

Initializing the IEEE1394 bus and enabling the Serial Bus Protocol 2 (SBP-2) can, according toour experiments, sometimes take up to 10 seconds, especially when the driver is not already loadedin the victim’s machine. This is indicated by, first, the output of the inception tool as can beseen in Listing 4.3, and second by various pop-ups within the Windows operating system indicatingnew hardware, the initialization of new drivers and eventually the message that the new hardwareis ready.

44

4.4 Experiments

4.4.4.6 User-mode

Memory can be also acquired from the virtual memory. In such case, the memory acquisition isrestricted to user-level processes.

The Windows Task Manager — we used the one supplied by our test system — can be used todump memory of processes. In such case, the Windows Task Manager writes the process dump toC:\Users\user\AppData\Local\Temp\RAMMANGL.DMP. To keep the results in line with the otherresults the system hard disk was also a 320GiB Western Digital WD3200AAKX hard disk. Theprocess is suspended while the Windows Task Manager dumps the memory, resulting in highatomicity. However, because the process must be selected within the process tab of WindowsTask Manager in order to initiate the dump, we exhibited a tiny lag between starting the payloadapplication and starting the memory acquisition, slightly decreasing integrity.

ProcDump — we used version 7.1 — from the Sysinternals tools is another tool that can acquirememory of a process. As can be seen from Listing 4.4 the process of which the memory should beacquired can be defined as the processes image name. Hence unlike previous user-mode dumpingtools the lag between starting the RAMMANGL.EXE, acquiring its process ID and eventually invokingthe dump tool is removed, helping greatly with the point in time integrity of dumps.

procdump .exe -ma RAMMANGL .EXE

Listing 4.4: Commandline used to invoke ProcDump

ProcDump further has various options used to trigger a dump, e.g., CPU load, memory usage orothers going above a certain threshold, or the process exhibiting an exception. This gives aninvestigator a very high degree of fine tuning the acquisition’s point in time, hence increasingintegrity. ProcDump offers a method called clone to dump the process memory using a conceptsimilar to copy-on-write at the operating systems level. With this, it was possible to obtain asurprisingly perfect memory image, something we only expected to obtain from virtualization oremulation. Listing 4.5 lists the parameters used to invoke ProcDump with process cloning andreflections keeping the downtime of the process being imaged to a minimum.

procdump .exe -ma -a -r RAMMANGL .EXE

Listing 4.5: Invoking ProcDump leveraging process cloning for acquisition with minimal process suspension

Another user-level dumping tool is pmdump — we used version 1.2 — by Arne Vidstrom. Unlikethe other tools it does not suspend the process. We mostly just used it to spread the spectrumof our evaluation by introducing yet another kind of memory acquisition technique. Because theprocess is not suspended, pmdump exhibits memory smear resulting in reduced atomicity. Obviously,in most scenarios ProcDump leveraging cloning should be the preferred tool for acquiring a singleprocess’ address space.

45

4 Memory acquisition evaluation

4.5 ResultsWe now present our results. We first outline our measurement accuracy. Then we give selectedexamples of our results. Eventually, we give an overview comparison among the acquisition methods.

4.5.1 Measurement accuracyWe repeated all measurements until the relative standard deviation of the mean value of all countervalues was below 10%. This ensures that 95% of all possible repeated measurements end up within20% of the mean value of our measurements. Given that our objective is not to evaluate differentkernel-level acquisition software with each other, as they are very close to each other as alreadyoutlined by Vömel and Stüttgen [164], but rather to evaluate the overall state of memory acquisitionthese figures are good enough as each comparison group is far enough apart to not fall within 20%of one another.

4.5.2 Individual resultsFirst, we give a brief insight into individual results.

4.5.2.1 pmdump

Because the resulting image seen in Figure 4.4 provides an expected visual, we start by introducingthe results of pmdump. This also helps to explain the way in which we visualize the measurements:As can be seen from Figure 4.4 it does take some time, i.e., counter increments (x-axis), until thetool starts to acquire some memory. This is first due to the fact that the tool needs the process IDof our payload application in order to dump its memory. Hence our payload application was runningfor some seconds during which its process ID was determined. Second, the pmdump tool seemedrather resource intensive slowing the overall system down, hence also slowing its own dumpingprocess down. It can also be seen from Figure 4.4 that the tool acquires the virtual address space,as the y-axis depicts the counters spread along the virtual addresses of the process.

Figure 4.4: Acquisition plot of pmdump

Table 4.1 on page 49 gives the worst case figures, i.e., the maximum figures obtained in all runs, forour atomicity and integrity delta.

46

4.5 Results

4.5.2.2 inception

Figure 4.5 is quite a different picture compared to pmdump’s Figure 4.4 on the preceding page.Figure 4.5 shows inception in comparison to other acquisition methods. The x-axis shows timewhile the y-axis shows the memory regions. Each dot indicates the point in time when a specificmemory region was acquired. From this, it can clearly be seen that inception is the least atomicacquisition — and also the overall slowest. Because inception acquires the physical memory itsacquisition plot looks rather scattered and not as orderly as the plot of pmdump. This is becauseWindows does not map sequential virtual addresses to sequential physical addresses. It rather keepsphysical memory in a heap and allocates individual pages. Due to the memory management unit(MMU) of the CPU this translation usually happens transparently without loss of performance.Again Table 4.1 on page 49 gives the worst case figures regarding atomicity and integrity delta forinception.

Figure 4.5: Memory acquisition technique comparison (acquisition plot)

4.5.2.3 DumpIt

As can be seen from Figure 4.5 DumpIt is less smeared than inception via IEEE1394. However, itis still behind super atomic methods such as cold boot attacks and virtualization, represented byVirtualBox, which are both indistinguishable vertical lines to the far left close to the 0 point on thex-axis. We selected DumpIt here as a representative of kernel-level acquisition methods as they allare very closely related and there is no point in illustrating virtually identical acquisition methodsnext to each other.

47

4 Memory acquisition evaluation

4.5.3 Atomicity and integrity comparison

In summary, it can be argued that there is quite a difference regarding atomicity and integrityconsidering different acquisition methods. However, as can clearly be seen from the acquisitiondensity plot in Figure 4.6 that the different methods seem to cluster. For example, the kernel-levelacquisition methods are all pretty identical with regard to atomicity and integrity, as well asacquisition speeds. One other group would be DMA acquisition, here represented by the inceptiontoolkit. Then user-mode dumping, which should be split into methods suspending process executionand methods that do not. Last but not least are the ultra high atomicity methods, which can noteven be distinguished anymore in Figure 4.6 because they all cluster along the y-axis. These arevirtualization and emulation methods and the physical cold boot RAM attacks.

Figure 4.6: Memory acquisition technique comparison (acquisition density plot)

0 1 2 3 4·104

0

0.5

1

1.5

2

·104

memimage

VirtualBox

ProcDump

Windows Task Manager

pmdump

WinPMEM

FTK Imager

win64ddDumpIt

inception

Atomicity Delta

Integrity

Delta

Figure 4.7: Each acquisition position inside an atomicity/integrity matrix

48

4.5 Results

Table 4.1 gives a listing of all evaluated methods worst case atomicity and integrity deltas as definedin the beginning of this chapter. The table is ordered according to the above-outlined groups aswell as ranked by the sum of atomicity and integrity delta within each group.

(Worst Case) (Worst Case)Atomicity Delta Integrity Delta

msramdump 1 43.84memimage 1 63.28

VirtualBox 1 26.64QEMU 1 35.24

ProcDump -r 0 39.75ProcDump 1 36.50

Windows Task Manager 1 728.54pmdump 37 136.62WinPMEM 13230 5682.24

FTK Imager 13151 5917.24win64dd 15039 8077.54

win64dd /m 1 15039 8172.28DumpIt 15711 8500.09

inception 43898 22056.77

Table 4.1: Comparison of worst case atomicity and integrity deltas

Figure 4.7 on the facing page is the representation of Table 4.1 as an atomicity/integrity matrix.Please note that the figures within Table 4.1 can only be compared with measurements performedwith the same parameters and same hardware because the counter increments are highly hardwaredependent. To compare other tools we make our framework available to the public.

4.5.4 Anti-forensic resilienceIn this section, we discuss the anti-forensic resilience of the investigated memory acquisitiontechniques.

4.5.4.1 Kernel-level acquisition

The problem of software tools is their trustworthiness with regard to anti-forensics [145], theirrequirement for target operating system administrative privileges, and their low atomicity [162,Fig. 5]. Even if special memory acquisition software such as lmap by Stüttgen and Cohen [146],which was especially crafted to resist anti-forensics, is used the software must still run on the system.The lack in atomicity gives greater risks to evidence being deleted during acquisition.

4.5.4.2 User-mode

User mode acquisition tools can not be considered anti-forensic resistant at all, because, a kernellevel rootkit can fully control the user-mode memory dumping program.

4.5.4.3 DMA

DMA attacks via FireWire, as outlined in this chapter, can be prevented by disabling the SBP-2protocol. This can be done by adding the line “blacklist firewire-sbp2” to any .conf filewithin /etc/modprobe.d/. Because the FireWire attack is already well known, modern operatingsystems will also disable FireWire DMA while in the lock screen. Adding to this the unfavorablelow atomicity, which means great potential for evidence to be deleted during acquisition, DMAattacks, at least the variant tested in this chapter, can not be considered very anti-forensic resistant.

49

4 Memory acquisition evaluation

4.5.4.4 Emulation and virtualization

Emulation and virtualization can be considered perfectly resistant against anti-forensics, because thesystem under analysis is already sandboxed within the virtual environment. However, a system thatis not already in a virtualized environment can not be analyzed this way, reducing the applicabilityof this method.

4.5.4.5 Cold boot attacks

Cold boot attacks provide a very high degree of atomicity and they do not depend on any targetoperating system administrative privileges to run. However, they may need hardware administrativeprivileges, if only a simple reset attack, instead of a full blown memory transplantation attack,as outlined in Section 5.4.3 on page 63, should be performed. However, as we will outline inSection 5.5.3 on page 67 we outline how such privileges can be obtained by a forensic analyst.Because, as soon as the system is rebooted, the RAM contents is out of reach of any anti-forensicsoftware running on the system. As the integrity of the cold boot attack is very high, i.e., thepoint in time the memory image should be acquired can be specified very accurately, any detectionattempts of the attack are too slow. The forensic analyst cuts the power to the system and acquiresthe RAM. There is no room for anti-forensic interference, such as deleting evidence, etc.

4.6 Conclusions and future workWe presented a practical approach to estimating atomicity and integrity of forensic memoryacquisition tools. This is the first time that this was done with a black-box approach. In this way,we could also test closed source software acquisition tools. We think that these evaluations areimportant because before conducting these experiments we had no intuition for how completelydifferent acquisition techniques, e.g., kernel-level acquisition and DMA attacks via IEEE1394,would compare.Currently, our results are highly tied into the hardware and RAM size. It would be worthwhile tohave an independent figure representing atomicity and integrity so different tools could be comparedmore easily.Because the impact of non-atomic memory acquisition on memory analysis is not well studied,no tools consider the issues during analysis. The impact of non-atomic, concurrent and smearedmemory snapshots on forensic memory analysis are yet unknown. However, misattribution seemsto be one possible issue, e.g., when a process ends while the memory of the system is captured andduring this time another process starts, it is possible that the memory contents belonging to thesetwo processes get mixed up. In the worst case, incriminating evidence might be attributed to adifferent process and hence possibly different user. In a less worse case, exculpatory evidence maybe missed, due to insufficient atomicity or integrity. Hence the impact of low atomicity and lowintegrity must be researched more thoroughly.In this chapter, we have shown that cold boot attacks compare favorably with the other memoryacquisition methods, not only in atomicity and integrity but also with regard to anti-forensicresilience. Hence, in the next chapter, we will outline the cold boot attack in more detail.

50

5 Memory acquisition(via cold boot attacks)

Even though a target machine uses full disk encryption, cold boot attacks can retrieve unencrypteddata from RAM. Cold boot attacks are based on the remanence effect of RAM which says thatmemory contents do not disappear immediately after power is cut, but that they fade gradually overtime. This effect can be exploited by rebooting a running machine, or by replugging its RAM chipsinto an analysis machine that reads out what is left in memory. In theory, this kind of attack isknown since the 1990s. However, only in 2008, Halderman et al. have shown that cold boot attackscan be well deployed in practical scenarios. In this chapter, we investigate the practicability of coldboot attacks. We verify the claims by Halderman et al. independently in a systematic fashion.For DDR1 and DDR2, we provide results from our experimental measurements that in large partagree with the original results. However, we further point out that a straightforward cold bootattack against DDR3 memory could not be reproduced. This is due to the fact that on newer Intelcomputer systems the RAM contents are scrambled to minimize undesirable parasitic effects ofsemiconductors. We, therefore, briefly outline a descrambling attack against DDR3 memory therebyenabling cold boot attacks on systems employing Intel’s memory scrambling technology. This isimportant, because, as was outlined in Chapter 4 on page 35, cold boot attacks are unparalleledwith regard to atomicity and integrity as well as anti-forensic resilience. Our test set comprises 17systems and system configurations, from which 5 are based on DDR3.

5.1 Introduction

Contrary to widespread belief, the contents of RAM are not instantly lost after power is cut butrather fade away gradually over time. Cold temperatures slow down the decay of bits in RAMfurther. This effect is called the remanence effect and was first described by Link and May [98]in 1979. Since then, the remanence effect has been subject to security research several times[170, 5, 70, 134]. Theoretic attacks based on it were first proposed in the 1990s by Anderson andKuhn [5], and were later described in detail by Gutmann [70] and Skorobogatov [134].RAM can be classified into dynamic and static RAM (DRAM and SRAM). RAM modules inwidespread PCs mostly use the DRAM technology because of its simplicity and low manufacturingcost. Gutmann explains in his work about data remanence in semiconductor devices [70] whyDRAM exhibits the remanence effect. According to Gutmann, a DRAM chip consists of multipleDRAM cells where one cell stores the information of exactly one bit. Each cell consists of a capacitor.Each capacitor’s voltage is compared to the load of a reference cell which stores a voltage half-waybetween fully charged and fully empty. If the voltage of a cell is higher than the reference voltagethe cell stores a one-bit; if it is lower it stores a zero-bit (or vice versa if the cell is an active lowdesign). As the voltage of capacitors does not vanish instantly but rather decays exponentially, thebits are preserved for a short amount of time without power.The memory controller refreshes each cell’s voltage before it decays to the point where the bitinformation gets lost. Normally, the refresh rate is so high that each cell gets refreshed severaltimes per second. However, the decay of capacitors is longer than the time between two refreshoperations of the memory controller. This can be observed as the remanence effect, which lastslong enough that data in memory survives a system reboot. This observation prompted so-calledcold boot attacks.

51

5 Memory acquisition (via cold boot attacks)

Cold boot attacks can make use of the property that the remanence effect is prolonged by coolingdown RAM chips [134, 72]. Hence RAM modules are often cooled down or even frozen before thoseattacks. In the easiest form of a cold boot attack, the attacker reboots the system from USB thumbdrive to start malicious system code that reads out what is left in memory. In a more advancedmethod, which becomes necessary when BIOS settings require a boot password or disallow to bootfrom USB, RAM modules can even be physically extracted in order to read them out in an analysismachine. In both cases, secret information, such as cryptographic keys for full disk encryption, canbe retrieved from a computer’s RAM that is running or suspended to RAM.Despite the fact that the data remanence effect has been known for years, and that it has constantlybeen warned about, it was not until 2008 that Halderman et al. published the first practical attackbased on the remanence effect in their work “Lest We Remember: Cold-Boot Attacks on EncryptionKeys” [72]. Even though Halderman et al. have been cited by further research publications on thesubject of cold boot attacks in subsequent years [21, 75, 22, 2], the practicability of this attack hasnever been verified independently, nor reconstructed by any of these publications, especially not forthe modern DDR3 technology.

5.1.1 Related workAs stated above, the first practical attack based on the remanence effect was described by Haldermanet al. [72, 73]. In their renowned paper from 2008, Halderman et al. have shown that cold bootattacks can be used to extract sensitive information, in particular, cryptographic keys, from RAM.From extracted RAM cryptographic keys were reconstructed using recovery algorithms and thenused to break the full disk encryption of BitLocker, TrueCrypt, and FileVault. After this, manypublications which focus on key recovery and reconstruction followed [121, 75, 155, 125, 99]. In 2013,Müller and Spreitzenbarth performed cold boot attacks against smartphones for the first time [106].To this end, they published a recovery tool called FROST which can be used to retrieve encryptionkeys from Android devices, thus proving that the ARM microarchitecture is also vulnerable to coldboot attacks. Taubmann et al. [151] later extended the idea of cold boot attacks against mobiledevices with lightweight tools. In 2015 Lindenlauf et al. evaluated the cold boot attack againstDDR2 and DDR3 memory [97]. In there specific test setup, which consisted only of one DDR3system, they were, unlike we, able to recreate the cold boot attack also against DDR3 memory.We contribute to this field by verifying the memory extraction process against laptops and desktopPCs. We further investigate the new DDR3 technology in depth uncovering and subsequentlysolving an inherent problem preventing straightforward cold boot attacks against DDR3 memory.

5.1.2 OutlineIn Section 5.2, we outline the test setup of our experiments, including the hardware and softwareconfigurations as well as the execution process of our experiments. In Section 5.4 on page 59, wepresent the results of our experiments, i.e., we present details about the temperature effects onRAM remanence. In Section 5.5 on page 64, we outline how pure software-based countermeasurescan be circumvented by different forms of the cold boot attack. And in Section 5.7 on page 70, wefinally conclude this chapter.

5.2 SetupIn this section, we give an overview on our setup. We describe the hardware we used, the softwarewe deployed, and our experimental setup.

5.2.1 HardwareFirst, we outline the hardware used during our experiments. This includes the computer systemswe tested, as well as the equipment utilized in our experiments.

52

5.2 Setup

5.2.1.1 Computer systems

We focused on mobile devices such as laptops because due to their greater exposure to physicalaccess by a forensic analyst they represent likely targets of the cold boot attack. Laptops, dueto their mobility and thus the associated risk of loss, are also more likely to be encrypted than,e.g., desktop or server systems, which are more focused on performance. Table 5.1 gives a list ofthe systems we tested. All RAM chips were non-ECC SDRAM modules. Identical RAM modelnumbers mean the same RAM module was used in the corresponding systems. From now on, werefer to each system configuration by its respective identifier denoted as A to Q.

ID System or Motherboard DDR Type RAM model Size [MiB]A Asus Eee PC 1010H 2 HYMP512S64BP8-Y5 1024B Asus Eee PC 1010H 2 NT512T64UH8A1FN-3C 512C Asus Eee PC 1010H 2 04G00161765D (GDDR2) 1024D Asus Eee PC 1010H 2 KVR667D2S5/1G 1024E Asus Eee PC 1010H 2 CF-WMBA601G 1024F HP Compaq NX6325 2 HYMP512S64BP8-Y5 1024G HP Compaq NX6325 2 NT512T64UH8A1FN-3C 512H Intel Classmate PC NL2 2 HYMP512S64BP8-Y5 1024I Toughbook CF-19FGJ87AG 2 HYMP512S64CP8-Y5 1024J ASRock K8NF4G-SATA2 1 HYS64D64320GU-6-B 512K Fujitsu SCENIC P300 i845E 1 HYS64D64320GU-6-B 512L Fujitsu SCENIC D i845G 1 KVR400X64C3A/512 512M ASRock H77M-ITX 3 CMX8GX3M2A1600C9 8192N Fujitsu ESPRIMO P900 E90+ 3 M378B5773CHO-CK0 2048O ASRock Z77 Pro4 3 HMT351U6BFR8C-H9 4096P Asus P8P67LE 3 M378B5773DHO-CH9 2048Q ASRock Z77 Pro3 3 KHX2133C8D3T1K2/4G 4096

Table 5.1: List of tested computer systems and their corresponding RAM type and model

5.2.1.2 Thermometer

Temperature measurements were performed with a Sinometer DT8380 contactless infrared thermome-ter with a laser pointer. Its measurement range is from -30℃ to 380℃. It has a distance-to-spotratio of 12:1, meaning measuring from a distance of 12cm the temperature within a spot of a 1cmdiameter is measured [133].

5.2.1.3 Cooling agent

Cooling was provided by multiple cans of “KÄLTE 75 SUPER” spray from CRC Kontakt Chemie,which is a professional cooling agent especially suited for use with electronic components. It isnon-burnable and provides a cooling power of 267J/ml and according to its specification the lowestattainable cooling temperature is -55℃ [26].

5.2.2 Test data placementThe test data consisted of a 2MiB chunk of random data generated by a pseudo-random numbergenerator (PRNG) [92] and a 687KiB 687× 1024 pixel Portable Graymap (PGM) formatted pictureof the Mona Lisa. The random data was used as machine comparable data for error analysis,while the pictures were used for visual inspection. The test data was written starting from thephysical address 8MiB. We, of course, verified for each tested system that this memory area wasnot overwritten during reboots. This was not the case for all tested systems.

53

5 Memory acquisition (via cold boot attacks)

5.2.3 SoftwareWe wrote two special-purpose boot loaders for our work, one for data placement and one for dataextraction. Writing our own boot loaders saved us to boot into full OSes that potentially falsifyour results. The data placement simulates content, such as full disk encryption keys that reside ina target’s RAM.Our software to place the test data was a minimal boot loader containing the PRNG for the machinecomparable data. It also contained the picture of the Mona Lisa in its static data. After the datawas copied to the desired memory location the WBINVD instruction [81] was issued to force the datato be written to RAM instead of potentially remaining in CPU caches. The extraction boot loaderextracts the remanence of the placed data, thus completing our cold boot attack. The extracteddata is eventually analyzed.The software we used for extraction is based on the memimage tool by Bill Paul [71], which was alsoused for the experiments in the original cold boot attack publication by Halderman et al. [72].The memimage tool provides a simple boot image — scraper.bin — that can be written to abootable device, such as a USB stick. When booted, this USB scraper copies the entire addressablememory contents of the system to the boot device. While this provides all functionality neededto perform cold boot attacks even against systems with several GiB of RAM, it was not verycomfortable to use for our repeated measurements because dumping the entire memory takes a longtime. Thus, the tool was modified to dump only the previous placed test data without wasting timeon extracting the rest of the memory that is not relevant to our measurements. We did, however,also perform a multitude of full RAM dumps to evaluate the overall feasibility, applicability, andpracticability of the cold boot attack.

5.2.4 ExperimentOur experiments follow the procedure outlined as follows.

5.2.4.1 Structure

The canonical procedure of our cold boot attack consists of the 8 steps illustrated in Figure 5.1on the next page. Step #1 is to boot the system into the placer tool. The placer then, in step#2, copies the test data into the system’s RAM. Step #3 is to cool the RAM module down to thedesired temperature c for the current measurement. Then, in step #4, the system is shutdownand in step #5, we wait t seconds. Depending on the kind of experiment, the RAM module mayalso be removed and transplanted into a different system during step #5. Afterwards, in step #6,the system containing the RAM is powered on again. In step #7, the booted extraction programdumps the remaining test data from RAM to disk. In the final step #8, the gathered remanence ofthe test data is compared with the clean undecayed test data, and the changed bits, i.e., bit errors,are counted.Figure 5.1 on the facing page contains pseudo code for the test data placement, the extraction, andthe analysis on how many bits have decayed. The pseudo code uses the following variables andterminology:

• TESTDATA: test data on boot medium

• DUMP: RAM dump stored on boot medium

• RAM: physical RAM region being analyzed

• BIT_ERROR_COUNT: number of bit errors

• POPCOUNT: hamming weight of a byte

• WRITE_BACK_CACHES: forces cached data to be written to RAM

• N: Number of bytes in test data

• C(c, t): cooling to c℃ and t seconds without power

54

5.2 Setup

Placement:for (i=0; i < N; i++) {

RAM[i] = TESTDATA [i];}WRITE_BACK_CACHES ();

Extraction:for (i=0; i < N; i++) {

DUMP[i] = RAM[i];}

Cooling:C(c, t)

Analysis:BIT_ERROR_COUNT = 0;for (i=0; i < N; i++) {

i f ( DUMP[i] != TESTDATA [i] ) {BIT_ERROR_COUNT += POPCOUNT (DUMP[i] ^ TESTDATA [i]);

}}

#8 Analyze Remanence

#7 Extract Remanence

#6 Power up/boot

#5 Wait t

#4 Shut down#3 Cool RAM to c ℃

#2 Place test data

#1 Power up/boot

Figure 5.1: Abstract setup of our experiments: Either a system is rebooted, or optionally its RAM modulesare removed and transplanted into another system during step #5.

5.2.4.2 Execution

We executed our experiments according to the following procedures:

Cooling In step #3, the cooling agent is sprayed evenly over the entire surface of the RAM moduleso that all RAM chips are covered equally, as can be seen in Figure 5.2. If possible, both sides ofthe RAM module are sprayed. In the case of the laptop systems A to I, this was not possible due tothe placement of RAM modules. After the initial cooling, no more cooling is applied so the RAMmodules slowly warm up again during step #5. While this lack of cooling during step #5 maycause distortion in the decay curves of our measurements, applying constant cooling to maintain aconstant temperature is practically not feasible. In real cold boot attacks, it is possible to reboot amachine to the point where the memory controller is refreshing the RAM modules again within 5to 10 seconds. It is also possible to transplant RAM modules in this time. Hence measurementsbeyond that time are purely illustrators of the RAM remanence but irrelevant to real practical coldboot attacks anyway.

Figure 5.2: RAM module covered in cooling agent (This is an Extreme over-exaggerated example. Duringour experiments we never had to use this much cooling agent.)

55

5 Memory acquisition (via cold boot attacks)

Temperature Measurements The temperature is measured right after step #3 and before step#4. Because we measure with a contactless infrared laser thermometer, all measurements reflectsurface temperatures. We measure from a distance of around 8 cm yielding a measuring spot7 mm in diameter. This spot is small enough to encompass exactly one RAM chip. For the chipto measure, we choose the hottest chip of the RAM module. This chip is on all tested systems,without exception, in the lower row of the RAM module near the socket. The upper chips awayfrom the socket are consistently several ℃ cooler.RAM chips are cooled down while the system is running, meaning while the RAM chips still produceheat. The plastic surface of the RAM chips gives higher temperature readings than a label on theRAM module or its metal circuit parts. Therefore, our measured temperatures do not reflect thereal core temperature of the RAM module but rather the upper bound of the surface temperature.Our measurement procedure is probably the reason why we have temperature down to only 0℃,even though the cooling agent can cool a disconnected RAM chip down to -30℃ (measured usingthe same procedure). However, to obtain more relevant results, the RAM is cooled in a normaloperational state.In case the temperature measurement indicates that cooling is insufficient for the current experiment,cooling is reapplied and the temperature is measured again.

Timing Measurements All timings mentioned are measured between step #4 and step #6. Asan indicator of the events for step #4 and step #5, pressing the system’s power button is used.While this does not reflect the true point where a RAM module is cut and reconnected to power, itis an established and reproducible point in time.

Analysis The extracted test data is analyzed as follows: We first calculate the number of bit errorsas outlined in the pseudo code of Figure 5.1 on the preceding page. We then divide the error countby the number of total bits, in our case 2Mi. This gives use the percentage of correct bits. Notethat, since we use random test data, it can happen with a statistical probability of 50% that abit of our random test data is exactly the ground state of the bit in RAM and hence “correct” bychance. That is, the minimum percentage of correct bits is 50%.

All measurements, especially the temperatures, are best efforts and not precisely accurate, as itis not possible to allocate the exact same amount of cooling agent every time. If for any of ourexperiments there was a deviation from the above-mentioned procedure, it is indicated as such.

5.3 ObservationsBefore presenting the results of the measurements, we want to discuss a few observations madeduring the experiments.

5.3.1 Ground state patternsAn important aspect of analyzing already partially decayed memory images is the patterns in theground state of the RAM. The ground state is the state the RAM decays to, i.e., the state theRAM will eventually take when not being refreshed anymore. The ground state of most RAM isnot uniformly zero or one, but rather forms a pattern of alternating areas of zeros and ones. Thepattern on test system A is formed from alternating stripes of ones followed by a stripe of zeroswith some intermittent odd stray zeros and ones in both stripes. Each stripe is exactly 64KiB,presumably the size of one memory subunit of the bigger 64MiB memory chips of which the entire1GiB RAM module is made of. Halderman et al. [72] also observed such patterns. Figure 5.3 onthe next page illustrates the different ground states of two different hardware configurations. Fromour understanding the ground state is dependent not only on the RAM module used, but also thesystem. The first is obvious, because a RAM module can interpret its contents any way it wants,i.e., decide autonomously about a bit being active high or active low. The second is not so obvious,however, also a system’s RAM controller can be at liberty to interpret bits differently. This isimportant for RAM transplantation, which we outline in Section 5.4.3 on page 63, in which we

56

5.3 Observations

(a) System C (b) System G

Figure 5.3: Illustration of different ground state patterns

could transplant the RAM of one system to another system only if the memory controllers arecompatible. This can be asserted by checking the ground pattern of two systems with the sameRAM module. If they are identical, the systems are compatible.

A snapshot of the pattern can be obtained by powering the computer down for a long time so anyremanence of previous RAM content is definitively gone, then taking a snapshot of the state ofRAM. With this snapshot it can be analyzed whether a bit has not decayed. For example if theground state of a bit is zero and a RAM dump from a cold boot attack finds the bit at that positionto be a one it can safely be assumed that this bit has not decayed, because bits will decay to theirground level. Contrary to observations by Halderman et al. we never exhibited bits that did notdecay to their ground state. However, even Halderman et al. acknowledge that the fraction of bitsflipping in the opposite direction is negligible small [72]. Hence, this assumption can be used duringanalysis.

Table 5.2 is showing the correlation between the ground state of bits, the observed state of bits andthe possibility of decay. To determine whether a bit has not been decayed one can XOR the groundstate with the observed state and whenever this XOR returns true the bit has not been decayed.

Ground state of bit Observed state of bit Has the bit decayed?0 0 Maybe0 1 No1 0 No1 1 Maybe

Table 5.2: Ground state and bit decay relationship

57

5 Memory acquisition (via cold boot attacks)

This information can be highly valuable when reconstructing the original memory state of acorrupted memory dump acquired via a cold boot attack. Hence for an attack, it is beneficialto also acquire the ground state pattern, just in case some bits are corrupted and reconstructiontechniques must be used. Key reconstruction techniques can use this ground state within theirreconstruct models [2, 72].

5.3.2 Cached data

During developing the data placer tool we purposely did not force a write back of the cached data.via the WBINVD instruction. This lead to the very obvious observation that data in the cache isnot vulnerable to this kind of cold boot attack. Figure 5.4 illustrates this cache effect with picturesof Mona Lisa that have been written to memory without a forced write back of the cached data. Itshould be noted that before writing the Mona Lisa’s pictures into RAM the RAM was empty, i.e.,it contained its natural ground state. In a real scenario, the black and white areas in the pictureswould contain previous RAM contents.

(a) Only top portion of picture writ-ten to RAM

(b) Bottom of picture still in cache (c) Single lines of picture still incache

Figure 5.4: Observed cache effects due to missing cache write back

This observation, while completely obvious, validates the idea behind the anti-forensic encryptionconcept behind FrozenCache [115], which tries to keep encryption keys entirely in the CPU’s cachesso they can not be extracted from RAM in a cold boot attack.

Cold boot attacks against CPU caches, which in itself are simply SRAM, could also be possible asSRAM also exhibits data remanence [134]. However, our observations have shown that, at least onthe tested hardware, the cache is invalidated on boot, thus, requiring additional tricks, possiblyhardware, and technical knowledge to attack the caches directly — if at all possible in practice.

58

5.4 Results

5.4 Results

We now present the results of our experiments. We first probe our test systems for RAM remanence.We then analyze the correlation between temperatures and RAM remanence. And last, we presentresults of our RAM transplantation experiments.

5.4.1 Remanence effect

Not all systems we tested exhibit RAM remanence. On some machines, RAM is reset even onwarm resets, and even though any POST procedures are disabled and all fast and/or quick bootfeatures are enabled in the system’s BIOS, as advised by Halderman et al. [72]. This fact was alsoobserved by Chan et al. [21]. Whether this memory reset is done as part of fulfilling the TCGPlatform Reset Attack Mitigation Specification [154] or, as suspected by Halderman et al., as aquirk of ECC-capable systems to always bring the RAM to a known state whether or not ECCRAM is actually installed or not, remains an open question. Table 5.3 provides an overview of thestate of observable RAM remanence in the various systems we tested with different types of coldboot attacks. Note the difference of the DDR3 systems M to Q, compared to the DDR1/DDR2systems A to L.

DDR RAM remanence observable after a

warm reset cold rebootwithout cooling with cooling

A 2 YesB 2 Yes No YesC 2 YesD 2 YesE 2 YesF 2 YesG 2 YesH 2 No (reset)I 2 No (reset)

J 1 YesK 1 No (reset)L 1 No (reset)

M 3 Yes No (scrambled with ”signature” every 256KiB)N 3 Yes No (scrambled)O 3 Yes No (scrambled)P 3 Yes No (scrambled)Q 3 Yes No (scrambled)

Table 5.3: List of observable RAM remanence in our test systems with different types of cold boot attacks.

Interestingly, all tested DDR3 systems maintain their entire RAM contents through warm resets,meaning that they are vulnerable to simple local warm reset attacks. However, after cold reboots,for all of them only noise patterns can be observed. These noise patterns are different each timeand unrelated to the placed test data. See Figure 5.5 on the following page for noise patternsacquired on different systems. There exists one exception, however: On system M, the first fourbytes of every 256KiB block always equal 0x5a on memory reset. This seemingly deliberatelyplaced “signature” suggests explicit scrubbing of the memory. But since the memory is preservedon a warm reset such deliberate scrubbing is unlikely.

59

5 Memory acquisition (via cold boot attacks)

(a) System M (b) System N (c) System O (d) System P (e) System Q

Figure 5.5: Scrambling patterns in DDR3 systems after a cold reboot

Further research indicated that DDR3 memory contents are scrambled to prevent parasitic semi-conductor effects. Because toggling a lot of bits in RAM from zero to one or vice versa, can causeelectromagnetic side effects Intel patented a technique [105, 40] in which the data is XORed witha random data stream before being written into RAM, and again XORed with the same randomstream when reading from RAM. This way the maximum number of zeros and/or ones in a streamis on average 50%, reducing electromagnetic side effects. In Section 5.5.1 on page 65, we brieflysummarize an attack against this scrambling deployed by Intel.

(a) 0 sec / 100% (b) 2 sec / 99.2% (c) 3 sec / 93.4% (d) 4 sec / 93.1% (e) 5 sec / 61.4% (f) 6 sec / 51.9%

Figure 5.6: Mona Lisa picture series as recovered from system C’s RAM after a cold boot attack at normaloperational temperature of 20 to 25℃ after different amounts of time. Each picture’s caption includes the

percentage of correct bits that were recovered.

Figure 5.6 is a representation of the RAM remanence in system C visualized as a sequence ofMona Lisa pictures. Figure 5.7 on the next page plots the time-related bit decays of the systemsA to G and J, exhibiting RAM remanence even after a cold reboot at their normal operationaltemperatures. The measurements at time t = 0 represent a warm reset. The first measurementabove t = 0 represents the fastest time a system could be power cycled, i.e., powered down andup again. Note that even though A uses the same RAM module as F, and B the same as G, theircurves differ. This can be explained by system F and G supplying the fan and thus presumably alsothe memory controller with power for about 0.5 seconds after the power button is pressed. Thus,the actual time without power is less than presented in the graph. This shows that a simple coldreboot attack, which is impossible on system A and B, is possible on system F and G, even thoughthose systems use the same RAM modules.

60

5.4 Results

5.4.2 Temperature and RAM remanence

50

60

70

80

90

100

0 2 4 6 8 10 12 14

Cor

rect

bits

(%

)

Time (s)

ABCDEFGJ

Figure 5.7: RAM remanence of systems A to G and system J

We can conclude that cold boot attacks are feasible on most machines with DDR1 and DDR2,although the longevity of the RAM remanence varies considerably, as can be seen in Figure 5.7.We now analyzed the correlation of RAM remanence with the RAM temperature in more detail.To this end, we performed several cold boot attacks according to the experiment structure outlinedin Section 5.2.4 on page 54, each with a different temperature c and a different time t. Again, themeasurements at time t = 0 represent a warm reset and the shortest measurement above t = 0represents the fastest time that systems can be power cycled.

Figure 5.8 on the following page shows plots about times and bit decays at different temperaturesfor systems A to E and H. These plots clearly show the correlation of lower temperatures and longerRAM remanence. Especially the legacy DDR1 system J shows a remarkable long RAM remanence.The remanence of systems A and B, which at normal operational temperature barely exists, canbe prolonged such that the systems can be power cycled and retain over 99% and 96% of theirbit information. As mentioned before, the differences between system A and F, and the differencebetween B and G, which use the same RAM, can be attributed to the fact that systems F and Gare supplying the memory controller with power for about 0.5 seconds beyond the power buttonbeing pushed, plus the fact that the RAM in systems F and G has a higher operational temperaturethan the RAM in systems A and B.

With these measurements, the temperature influence on RAM remanence can be clearly confirmedfor our DDR1 and DDR2 test systems. Even a modest surface temperature drop of only 10℃prolongs remanence.

61

5 Memory acquisition (via cold boot attacks)

50

60

70

80

90

100

0 5 10 15 20 25 30 35 40 45 50

Cor

rect

bits

(%

)

Time (s)

2 - 4˚C8 - 12˚C

22 - 25˚C

(a) System A

50

60

70

80

90

100

0 2 4 6 8 10 12 14

Cor

rect

bits

(%

)

Time (s)

0 - 4˚C8 - 11˚C

24 - 26˚C

(b) System B

50

60

70

80

90

100

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85

Cor

rect

bits

(%

)

Time (s)

0 - 5˚C10 - 12˚C20 - 25˚C

(c) System C

50

60

70

80

90

100

0 5 10 15 20 25 30 35 40 45 50

Cor

rect

bits

(%

)

Time (s)

-3 - 1˚C8 - 11˚C

27 - 29˚C

(d) System F

50

60

70

80

90

100

0 2 4 6 8 10 12

Cor

rect

bits

(%

)

Time (s)

-1 - 0˚C8 - 12˚C

26 - 34˚C

(e) System G

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800 900 1000

Cor

rect

bits

(%

)

Time (s)

10 - 12˚C32 - 37˚C

(f) System J

Figure 5.8: RAM remanence of systems A, B, F, G and J over time and at different temperatures. Notethe different time scales. The highest temperature of each system’s measurement is its normal operation

temperature.

62

5.4 Results

5.4.3 RAM transplantation attacks

As is evident from the previous section, RAM remanence is long enough, or can be prolonged longenough via cooling, that there is enough time for a RAM module to be transplanted from onesystem to another without losing the majority of its content. In practice, we were, able to transplantthe RAM from system A to system B. For this, we cooled the RAM module in system A, quicklyremoved the RAM module from the running system, and then inserted it into system B. SystemB was subsequently booted and the RAM remanence extracted. We could in various attemptsconsistently recover over 98% of all bits correctly. Our attempts became increasingly better andour last attempts even surpassed 99%. Table 5.4 gives a list with the figures for our attempts.

Even a seemingly failed attempt (the power button of system B was missed) resulted in 95%of all bits being transferred correctly. Considering the findings of Halderman et al. where theyreconstructed an AES key within seconds if 7% of the bits are decayed [72], or Heninger andShacham showing their ability to efficiently reconstruct an RSA private key with small publicexponent from only 27% of the bits [75], still renders our ”failed” attempt a success. Cold boot keyrecovery for other ciphers such as Serpent and Twofish, as published by Albrecht and Cid [2], canalso tolerate higher bit errors than what we exhibited. Hence RAM transplantation is a feasibleattack scenario.

In another experiment, we successfully transplanted the RAM from system H, which accordingto Table 5.3 on page 59 resets its entire memory upon boot, into system A. This way we couldefficiently circumvent whatever mechanism causes the memory into system H to be reset. This canalso be used to circumvent BIOS locks as we stress in the next section.

However, RAM transplantation is not always possible. It requires two systems with compatiblememory controllers, e.g., trying to transplant from system K to J, A to F, F to A, I to A, I to F,and H to F, all failed.

Temperature [℃] Errors [bits] Correct bits [%]5.9 77,645 99.5372005.4 136,120 99.1886623.5 157,994 99.0582825.4 216,734 98.7081655.2 268,176 98.401546

Table 5.4: Temperatures and errors for several cold boot attacks with RAM transplantation from systemA to system B. The temperature was measured after the RAM was transplanted.

5.4.3.1 Recovering ASCII text

Even though encryption keys can be recovered despite bit errors, the question remains whetherother RAM contents can be analyzed. To this end, we placed the text of Lewis Carroll’s “Alice’sAdventures in Wonderland” beside the Mona Lisa picture and the random data to give anotherexample of real life data that a forensic analyst might be interested in. This children’s novel canrepresent sensitive e-mails or other documents. The code outlined in Listing 5.1 on the next pagewas used to bring the text back into the range of printable ASCII characters, in case it containedbit errors.

63

5 Memory acquisition (via cold boot attacks)

#include <s td i o . h>int main (void ){

int c ;while ( c=getchar ( ) , c !=EOF) {

c &= 0x7f ; // s l i g h t error c o r r e c t i o n herei f ( ( c < ’ ’ | | c > ’ ~ ’ ) && ( c != ’ \n ’ && c != ’ \ r ’ && c != ’ \ t ’ ) )

c = ’ ∗ ’ ;putchar ( c ) ;

}return 0 ;

}

Listing 5.1: Program to replace any character outside the ASCII printable range with a star

Figure 5.9 shows the recovered text from a cold boot attack with temperature c ≈ 5.9 ℃ and timet ≈ 4 seconds resulting in an overall rate of 99.5% correct bits. While, even with such a lowerror rate, the text becomes quite mangled it is still legible in a way that the storyline can befollowed. The same way the storyline of a sensitive e-mail conversation could be followed or thescheme of embezzlement arrangements could be followed without any advanced technical effort inreconstructing and fixing the text at all. Of course finding the scattered pieces of texts in pagedmemory and piecing them together takes a little more effort it is still possible by using simple toolssuch a Unix’s strings utility to extract all printable characters from a RAM dump then lookingover them by hand.

CH*PTER I. Dmwn t‘e*Rabbip-Hole

Alice was Beginnin’ to get &ery tirad of sitting by*her siSter on Thebank, and o& having nothing to do: once or twice she had paeped into thebook her sister was reading,*but it had no p(ctures kr convErsations init, ’and what is the use of a book,’ thought Alice ’withoet pictureS*orcoNvdrsatIon?’

Figure 5.9: Beginning of “Alice’s Adventures in Wonderland” recovered from a cold boot attack. Allnon-printable characters have been replaced with a star.

Deeper analysis such as listing the processes running on a system or performing a signature searchfor malware code are, however, rather difficult, because they do not contain any redundancy.Further, every bit within them matters, e.g. a process within the process list is pointing to thenext entry via an address pointer, if this address is off only by one bit the list can not be followedanymore. We have stipulated research into fuzzy logic memory analysis, however, the results arestill pending.

5.5 Bypassing countermeasures

We now take a look at various countermeasures to the cold boot attack that have been proposedsince 2008 and discuss how those can be circumvented. Some of the outlined countermeasuresalready exist in practice, others have stayed theoretical proposals, which we show how to circumventregardless.

64

5.5 Bypassing countermeasures

5.5.1 Descrambling DDR3 memoryAs outlined earlier, modern DDR3 memory uses scrambling to prevent current spikes and elec-tromagnetic interference. To this end, Intel performs memory scrambling in its DDR3 memorycontrollers. It can be argued that this scrambling is a countermeasure against cold boot attacks,because they seem to stop at least the straightforward cold boot attack proposed by Haldermanet al. Hence, in this section we summarize the findings of Bauer et al. [10]. In this joint work,titled “Lest we forget: Cold-boot attacks on scrambled DDR3 memory”, we present an attack onscrambled DDR3 memory systems which requires 64 bytes of known plaintext per memory channel,i.e., at most 128 bytes for a dual-channel system, within the memory image in order to yieldcomplete descrambling of the image. The attack is further refined by exploiting the mathematicalrelationships present within the key stream to reduce the number of known plaintext bytes to only25, i.e., 50 bytes for a dual-channel system. In this section, we only shortly summarize the mainidea of our joint publication.

5.5.1.1 Scrambling

When transmitted and written to a RAM module, biased data streams, i.e., streams with anoverwhelming number of zeros or ones, can cause electromagnetic side effects, which can lead toproblems, e.g., when all bits are toggled simultaneously, the resulting power spikes could causeneighboring cells to toggle as well. Unbiased streams, i.e., streams with an equal amount of zerosand ones, help to mitigate such problematic behavior. A process known as scrambling can be usedto turn a biased stream into an unbiased stream. To this end, the data stream is XORed with apseudo-random number (PRN) sequence, before being transmitted. The PRN sequence will removethe bias from the stream, because the resulting stream will contain, on average, an equal amount ofzeroes and ones. The inverse process, descrambling, can be facilitated by XORing the data streamwith the same PRN sequence used for scrambling.

target

Pscramble

Key K0

RAM

M = P ⊕K0

I = M ⊕K1descramble

Key K1M

transplantacquisitionsystem

Figure 5.10: Scrambled storage of data and image acquisition [10]

Figure 5.10 shows the schematic of a cold boot attack with scrambling involved. On top is the targetsystem using key K0 to scramble the memory and on the bottom is the acquisition system usingkey K1 for descrambling. The problem is that if keys K0 and K1 are different, the descrambleddata I is different from the original plaintext data P . In case the target system and the acquisitionsystem are two different computers and the RAM module is actually transferred between them,then the keys are definitively different. In case the acquisition system and the target system arethe same system and the system uses a static key, i.e., the key is set randomly on reboots makingK0 = K1, the cold boot attacks can, despite the scrambling, be performed regularly. This specialcase was exhibited by the single test system used by Lindenlauf et al. [97]. However, even if theacquisition system and the target system is the same system, i.e., no RAM transplantation isperformed, the keys can be different. This is the case for a cold reboot, i.e., resetting the system bycutting the power. On the majority of systems, this causes the scrambling key to be reinitialized,thus leading to wrong descrambling. In fact, in such a case the data is first scrambled with one key,then descrambled with another key, in principle scrambling it twice. This is one of the reasons why,

65

5 Memory acquisition (via cold boot attacks)

even though Intel’s patents on their scrambler mechanism [105, 40] explains that a linear-feedbackshift register (LFSR) is used to generate the scrambler data stream, which seems simple to attack,it is a rather complex task in practice.

5.5.1.2 Descrambling via stencil attack

Because Intel’s scrambler is based on an LFSR its key stream is periodic. This means the keystream Ki is a repeated concatenation of some subkey stream ki with

Ki = kxi

and|ki| = π

with π being the periodicity, i.e., length, of the subkey stream ki.According to Figure 5.10 on the preceding page, plaintext memory contents P that was scrambledwith key K0, then during acquisition descrambled, i.e., again scrambled, with key K1, is acquiredas image I, with the following relationship between P , K0, K1 and I:

P = I ⊕K0 ⊕K1

Because both K0 and K1 are LFRS streams, they exhibit the above-mentioned periodicity, andhence can also be represented via a repeated concatenation of some subkey stream k01:

K0 ⊕K1 = kx01

also with|k01| = π

The above relationship can thus be expressed as:

P = I ⊕K0 ⊕K1 = I ⊕ kx01

The subkey stream k01 can then be recovered as follows, if a stream of length π is known within P :

kx01 = I ⊕ P

In case the known plaintext is a pattern of all zeros, i.e., 0x00, the subkey stream k01 is thus:

kx01 = I

Because the memory pattern 0x00 is the most likely pattern in RAM, the image I can be clusteredinto chunks of π length and searched for the most chunk with the most dominant contents. Thisis likely the subkey stream k01. To descramble the image I this subkey stream can be repeatedlyXORed with each π-length chunk of I, like a “stencil”. Hence this attack is referred to as the stencilattack.From all machines we investigated, we concluded a 64-byte periodicity, i.e., π = 64. Hence, toperform the above-described stencil attack we only need 64 bytes of known plaintext.

For a more in-depth description of the DDR3 memory descrambling attack, including details onhow to deal with bit errors during acquisition, dual channel memory systems, and an improvedattack leveraging mathematical properties in the key streams, we would like to refer to our jointpublication “Lest we forget: Cold-boot attacks on scrambled DDR3 memory” [10].

66

5.5 Bypassing countermeasures

5.5.2 RAM reset on bootClearing RAM on boot, as mandated in the TCG Platform Reset Attack Mitigation Specifi-cation [154], can stop a straightforward reboot attack. However, it cannot stop an advancedtransplantation attack as presented in the previous section. This technique is nonetheless adangerous mitigation technique because it indeed raises the difficulty of cold boot attacks.But even without transplantation, it can be possible to acquire the RAM contents. In 2013 Schramppresented his talk “RAM Memory acquisition using live-BIOS modification” [129] at the OHMconference. In his talk, he outlined how he was able to reflash the BIOS of a running system withCoreBoot and SerialICE This way it was possible to extract the RAM contents from the systemvia a serial interface after rebooting the system, without the original BIOS clearing the RAMcontents on reboot. This way also EEC memory, for which the BIOS zeroes the RAM to bring itinto a known state for error correction to work, can be attacked. To this end, the new BIOS beingflashed while the system is running must not initialize EEC memory on startup, but rather readthe memory contents without error correction.We were able to partially verify the research by Schramp [129], i.e. we were able to change the stockvendor BIOS of a Lenovo X230t, with CoreBoot and SeaBIOS, while the system was running, andhence could remove BIOS restrictions such as passwords, etc. We were unfortunately only able todo so against a prepared system, from which the BIOS chip was already removed and placed insidean SOP-8 socket, which was re-attached back to the motherboard via wires, and thus could easilybe swapped. However, we were not able to actually desolder the BIOS EEPROM from the runningX230t without causing the operating system to either crash1, presumably due to bus interference,or shutdown due to overheating, caused by excess heat from soldering. While the operating systemcrashing does, presumably, not interfere with the RAM modules being refreshed by the memorycontroller hub, the system resets shortly after the crash, which did not provide enough time tocomplete the desoldering of the old BIOS EEPROM and resoldering of the new prepared CoreBootBIOS EEPROM. Nonetheless, we consider this a valid option for forensic investigators.

5.5.3 Locking the boot processIn case the boot device is looked, i.e., the system will only boot from HDD, the forensic investigatorcan place the RAM dumper tool on a HDD. Locking the whole boot process, e.g., with a BIOSmaster password, does also not prevent the advanced transplantation attack, because a forensicanalyst can still transplant the RAM into a system with full control over the boot process. But likethe RAM reset on boot, this practice also complicates cold boot attacks.

System MethodA-E CMOS Battery RemovalF-G CMOS Battery Removal2H-L CMOS Battery RemovalM-Q Jumper

Table 5.5: BIOS password circumvention methods for the various systems tested

However, on most systems, BIOS passwords should not be considered a security mechanism.Table 5.5 outlines on which systems we were able to circumvent the BIOS password via one of thefollowing commonly known BIOS password circumvention techniques:

• Backdoor Password: BIOSes, especially on older desktop systems, often featured specialpasswords which could be used instead of the legitimately set BIOS password. Those backdoorpasswords could then be used by technicians to gain access to the BIOS for maintenance.Common BIOS passwords are, e.g., “_award”, “AWARD_PW”, “PHOENIX”, “CMOS”, “A.M.I.”,“589589”, etc., depending on the BIOS manufacturer [76].

1The X230t would output noise both through its speakers and the display.2This only works if the stringent security password option is disabled.

67

5 Memory acquisition (via cold boot attacks)

• CMOS Battery Removal: On some systems, the BIOS password is stored in the CMOS, whichis continuously powered via its own small coin cell battery. If the power to the system iscut and this coin cell removed, the CMOS contents and hence BIOS password is lost. Tothis end, a cold boot attack with a hard reboot, i.e., cutting the power must be performed,and in addition to that the coin cell battery must be removed as well. Due to residualpower, however, the system must be attempted to be booted while the power is still cut, thisensures the power to the CMOS is completely lost. While we were able to perform this BIOSpassword resetting cold boot attack, the results, with regard to bit loss, are comparable tothe advanced transplantation attack. In some instances we, however, had to repeat the resetprocess, rendering the results far inferior to the transplantation attack. Hence, this methoddoes not provide additional benefits beyond making a compatible system for transplantationunnecessary.

• Jumper: Many modern desktop systems feature a jumper to reset the CMOS and/or bypassthe BIOS password. To this end, the specific jumper on the motherboard of the system mustbe changed to the position used for CMOS reset and/or BIOS password bypass, as dictatedby the vendor. Then the cold boot attack can be performed as outlined previously.

The above outlined BIOS flashing attack will, of course, also work here too.

5.5.4 Temperature detectionA proposed countermeasure [102] is the usage of temperature sensors which in case a suddentemperature drop is detected initialize a memory wiping process. However, we found that thismethod again only makes the cold boot attack harder but does not prevent it. To Simulate anattack, we used system A as the victim and system B as the attacker. We powered system B upwithout RAM. This obviously causes the boot to fail and leaves the system in an unresponsivefailure state but the system’s memory controller is still fully functional and refreshes any RAMmodule inserted. The RAM module is very quickly, within under a second, removed from runningsystem A and inserted into system B. As this transfer is done without cooling no temperaturesensors are triggered. Once the RAM is in system B, it is refreshed by the memory controllerimmediately. To finish the attack we need to perform a normal cold boot attack on system B, bringit back to normal operational state and boot it into our extraction program. Since the RAM isalready out of control of the temperature triggering system this does not pose a problem.

Temperature [℃] Errors [bits] Correct bits [%]6.8 127,406 99.2406018.0 1,217,038 92.745888

10.7 1,749,820 89.5702609.9 4,408,509 73.723239

Table 5.6: Temperatures and bit errors for several transplantations from system A to system B withoutcooling. In the attempt with 73% correct bits the RAM socket of system B was accidentally missed causing

more loss.

Because the RAM transfer has to be performed without cooling it causes considerable RAM decay,even though it can be performed in under one second. Nevertheless, we were able to extract 90%of the bits correctly, even reaching 99% in one attempt. However, the attack is very fragile andthe slightest mishaps while performing the non-cooled transfer results in severe data loss. In onesuch instance, only 73% of the bits could be captured correctly. Table 5.6 gives an overview ofthe results of various attempts. As detailed in Section 5.4.3 on page 63, available research on keyreconstruct says that, despite these elevated error rates, encryption keys can be reconstructed.Even though we demonstrate how temperature sensors can be circumvented, they pose a furtherobstacle because they make a phase of uncooled decay mandatory.

68

5.6 Limitations

5.5.5 0x7c00 defenseThe 0x7c00 method is another proposed countermeasure [102]. On the x86 architecture, 0x7c00 isthe memory address to which an IBM-PC compatible BIOS loads the boot device’s master bootrecord (MBR), i.e., the first 512 bytes of a bootable device [144]. The theory behind the 0x7c00defense is to place sensitive data, such as encryption keys, into this 512 bytes at 0x7c00, so thatany reboot will overwrite them. However, the RAM module can be transplanted into a system withtwo memory slots with the slot holding the lower address space in which 0x7c00 resides being filledwith a dummy RAM module, and the upper slot with the victim’s RAM module. So again, thiscountermeasure complicates the attack, but it does not prevent it entirely. Besides that, it onlyoffers protection for 512 bytes.But also the above-mentioned BIOS reflashing attack will work. Eliminating the need to transplantat all.

5.6 LimitationsAs demonstrated, all proposed software solutions to the cold boot problem can be circumventedwith an adaption of the attack, because once RAM modules are removed from a system there is noway for the system to react upon the event of removal. Hence, although some solutions provide acertain level of mitigation, pure software solutions cannot be entirely effective. The only way toavoid cold boot attacks seems to be physical security or to build upon RAM chips that are lessaffected by remanence.When preventing an attacker, in this case, a forensic analyst, to access a running and/or suspendedsystem with sensitive data in RAM, or by preventing RAM transplantation, cold boot attacksbecome impossible. However, this requires some kind of physical protection. For example, the firstcan be achieved by always turning the system off and never just locking it or leaving it in suspend,and the latter can be achieved by soldering RAM directly onto the system’s motherboard, as donein smartphones, tablets and also some laptops today.However, if the countermeasures involve hardware or hardware features, such as using CPU registersto store encryption keys, they are often not circumventable. Even though we were able to circumventthe scrambling of DDR3, we could not have done so if, instead of a simple LFSR-based scramblingalgorithm, solid encryption, e.g., AES, was used. Therefore, we now outline the current limitingcountermeasures to the cold boot attack.

5.6.1 CPU-bound encryptionSome defenses treat RAM as the insecure data storage that it is. These measures keep the assetsthat need to be protected against an attack out of RAM. Researchers have found multiple differentways to store full disk encryption keys in a more secure place than RAM, e.g., AESSE [107] usesSSE registers, TRESOR [108] and TreVisor [110] use debug registers, LoopAmnesia [132] uses modelspecific registers, and FrozenCache [115] uses the CPU’s cache. PRIME [54] and Copker [68] aresolutions to store private keys within registers. For ARM, a cold boot resistant implementationnamed ARMORED [62] has been developed.Of course, all these methods have their own disadvantages, such as limited register space, or thefact that preventing data from being written from cache to RAM is a tedious and impracticableprocess. However, we were not able to extract any data from the locations used as key storage bythese systems. But note that, even these systems do not prevent a cold boot attack, they merelyprevent keys from entering RAM. All other information can at any time be extracted in a cold bootattack. This again renders these measures being far from a complete solution.In 2012 Blass and Robertson [14] were able to attack TRESOR by injecting code into the kernelvia a DMA attack. This code, eventually, gained access to the disk encryption key stored in thedebugging registers. Such attacks are, however, not possible if Intel’s IOMMU is used. The IOMMUallows restricting memory access of IO devices, such as PCI cards. The IOMMU, in this regard,acts like the classic MMU and protects the memory of the operating system’s kernel from suchDMA attacks.

69

5 Memory acquisition (via cold boot attacks)

5.6.2 RAM encryptionIn 2010 Cryptkeeper, the first system to encrypt RAM was published. However, it had one crucialflaw. The RAM encryption key resided in cleartext in RAM. We, therefore, extended the idea ofTRESOR [108] with our work “A Bytecode Interpreter for Secure Program Execution in UntrustedMain Memory” [131], which, like TRESOR, uses registers for cold boot resistant storage. In thiswork, we present a bytecode interpreter that uses the registers to store its internal state as wellas an AES encryption key. It will fetch encrypted instructions and data as needed from RAM.It will decrypt and execute them inside registers and when needed encrypt the data again beforewriting it from registers back to RAM. This way we are able to overcome the limits of CPU-boundencryption of only being able to protect a disk encryption key. With this bytecode interpreter, weare able to perform Turing complete calculations with full cold boot attack resistance.In 2016 RamCrypt [63] was published. It also uses registers to store the RAM encryption key.However, unlike our bytecode interpreter RamCrypt keeps a small set of memory in cleartext inRAM, hence, a carefully timed cold boot attack can still acquire the relevant data.Later the problem of RAM encryption was addressed by special hardware [169]. But ultimately thenew Intel Software Guard Extensions (SGX) [103], special hardware extensions, will allow code anddata to be placed into so-called enclaves, which are encrypted in memory and can only be accessedby code running in the same enclave. Unlike the before mentioned academic solutions, the wideavailability of SGX on Intel CPUs ultimately threatens cold boot attacks.

5.7 Conclusion and future workThis chapter provides an independent study on the practicability of cold boot attacks. We system-atically recreated the practical RAM extraction procedure as presented by Halderman et al. Ourempirical measurements on DDR1 and DDR2 showed the correlation between temperatures andRAM remanence, demonstrating that even minor cooling of the surface temperature of a RAMmodule by just 10℃ prolongs the remanence effect notably. By providing profound documentationon our experiments, a detail that is missing in the publication by Halderman et al., other researcherscan better match and compare their findings to ours. We further elevated the attack to currentlyused DDR3 RAM technology and further showed that cold boot attacks are also in 2016 a viableoption to acquire the RAM of systems without any anti-forensic interference. Even though, weoutlined limitations of the cold boot attack its availability, which far exceeds the availability ofother memory acquisition methods, such as kernel level acquisition methods, which require rootaccess to a system, combined with its resistance to anti-forensic interference, render it the mostfavorable acquisition method available.

Because technology is permanently evolving, DDR3 has been superseded by DDR4. These newDDR4 modules and also the memory controllers need to be investigated.We also see future work in the field of data recovery from decayed memory images containing biterrors introduced during cold boot attacks. While this has already been done for encryption keys,it is still an open research question for other data such as kernel structures, including, but notlimited to process lists, or other user data residing in RAM.

70

6 Essential data and anti-forensics

In his seminal work on file system forensic analysis, Brian Carrier defined the notion of essentialdata as “those that are needed to save and retrieve files.” He argues that essential data is, therefore,more trustworthy since it has to be correct in order for the user to use the file system. Because thisessential data is more trustworthy it also means it is more reliable and anti-forensic resistant.In many practical settings, however, it is unclear whether a specific piece of data is essential becauseeither file system specifications are ambiguous or the importance of a specific data field depends onthe operating system that processes the file system data. We, therefore, revisit Carrier’s definitionand show that there are two types of essential data: strictly and partially. While strictly essentialcorresponds to Carrier’s definition, partially essential refers to application specific interpretations.We empirically show the amount of strictly and partially essential data in DOS/MBR and GPTpartition systems, thereby complementing and extending Carrier’s findings. We thereby alsoempirically show which data is more anti-forensic resistant given a specific system.

6.1 Introduction

Analysis is the interpretation of digital evidence. This interpretation is non-trivial because (at leasttheoretically) digital data can be manipulated perfectly. But the mere fact that evidence is digitaldoes not mean that it cannot be trusted at all. Digital data can also be interpreted in differentways, e.g. data in memory can be interpreted as code or data.Consider for example a simplified partition table entry within the boot sector of a hard disk (seeFigure 6.1). It consists of a reference to the first sector of the partition and the length of thepartition in sectors. Furthermore, it provides an identifier for the “type” of the partition anda bootable flag to indicate whether the partition holds a bootable operating system. While itis possible to manipulate all parts of the entry using a disk editor, changes will have differentconsequences. For example, changing the bootable flag may only affect the behavior of the computerif it wants to boot from the partition and so changing the bootable flag from false to true maynot affect the behavior of the computer at all. However, if the reference to the first sector ofthe partition is changed, the boot loader/BIOS cannot locate the beginning of the partition. Inconsequence, this means that booting from that partition or mounting it will necessarily fail. Auser of that partition must set the field to its original value, which is rather cumbersome. It can,therefore, be argued that the value of the starting LBA field is more trustworthy than the bootableflag.

Start LBA Length Type Bootable

Figure 6.1: Typical partition entry in partition table

However, in case a system relies on the bootable flag to contain a specific value in order to use thepartition entry, then the starting LBA field and other fields can be used to store arbitrary data, aslong as the bootable flag is set to an invalid value. This knowledge is important, because it can beused to hide data from a forensic analysis.

71

6 Essential data and anti-forensics

The observation that some data fields can be trusted more than others was made by Carrier [18].Carrier [18, p. 176] defines the term “essential file system data” as follows (emphasis maintained):

Essential file system data are those that are needed to save and retrieve files. Examplesof this type of data include the addresses where the file content is stored, the name of afile, and the pointer from a name to a metadata structure. Non-essential file systemdata are those that are there for convenience but not needed for the basic functionalityof saving and retrieving files. Access times and permissions are examples of this type ofdata. [18, p. 176]

Carrier argues that it is important to differentiate between these two types of data because essentialdata is more trustworthy than non-essential data: essential data needs to be correct because

[. . . ] otherwise the person who used the system would not have been able to read thedata. [18, p. 12]

Consequently, Carrier classified every data field in file system data structures as being eitheressential or non-essential.

6.1.1 Problem statement

While the definition of essential data may be intuitively clear, there are many cases where themeaning of a field remains unclear despite the definition. One main problem is that it depends onthe operating system how the data is interpreted. While one operating system may respect thebootable flag and only boot into those that officially have their bootable flag set, another operatingsystem may offer to boot any one of all partitions from within the boot loader. Being this so, isthen the bootable flag essential or non-essential?In this chapter, we revisit Carrier’s notion of essential data and show how to fit application/operatingsystem specific data into Carrier’s terminology. We conducted a sequence of experiments regardingthe data fields stored in the standard DOS/MBR and GPT partition systems: We systematicallychanged the value of the field and observed the behavior of different operating systems thereafteron that data. The resulting behavior patterns were not always the same over different operatingsystems, confirming the fact that essential data depends on the operating system. We argue thatthere are two types of essential data: strict and partial. While strictly essential correspondsto Carrier’s definition, partially essential refers to application/OS specific interpretations. Weempirically show the amount of strictly and partially essential data in DOS/MBR and GPT partitionsystems, thereby complementing and extending Carrier’s findings.

6.1.2 Related work

In digital forensic science, there exist various classifications of evidence. Many of the categorizationsof digital forensics are borrowed from physical evidence. For example, Lee and Harris dividedevidence into two distinct groups, namely “transient evidence” and “pattern evidence” [93]. Theyfurther defined seven criteria by which evidence can be categorized: the kind of crime the evidenceindicates (murder, theft, etc.), the kind of material the evidence is made of (metal, plastic, etc.),the aggregation state of the evidence (solid, liquid, gaseous), the kind of forensic question answeredby the evidence (contact, event reconstruction, exculpatory of a defendant), how the evidence wasgenerated (blood drips vs. whipped blood), and the specific form of the evidence (fingerprint, color,dust, dirt, blood, etc.). Kirk and Thornton defined the class of microscopic evidence [87]. Gross andGeerdes were the first to mention the perishableness of evidence in 1985 [64]. These categorizationscan, with some modifications, also be applied to digital evidence as well.

72

6.2 Definition of essential data by Carrier and its problems

As has been mentioned sufficiently often before, Carrier 2005 defined essential and non-essentialdata, but he did this without recurring to traditional classifications. Dewald et al. later extendedthis definition to more general settings that include any type of digital evidence, even volatiledata in RAM. Like for Carrier, their definitions remain informal but correspond to Carrier’s termsmore or less directly. They distinguish two distinct groups: technically avoidable and technicallyunavoidable evidence [32]. They further suggest categorizing evidence by the distance from thecrime scene and volatility [32]. In this chapter, we further extend and refine the definition of Carrier.

6.1.3 Outline

In this chapter, we revisit Carrier’s definition of essential data (in Section 6.2) and define the twonew types of essential data in Section 6.3 on page 76. We evaluate our definition on DOS/MBR andGPT partition systems in Section 6.4 on page 77 and discuss the new terminology in Section 6.5 onpage 81. We conclude in Section 6.6 on page 83.

6.2 Definition of essential data by Carrier and its problems

Brian Carrier coined the term essential data in his seminal work on file system forensic analysis[18]. Intuitively, essential data is data that is “needed to save and retrieve files.” [18, p. 176]While Carrier does not provide a more formal definition, his text contains multiple examples andstatements that clarify the concept.The standard example for essential data is a pointer value from the metadata of a file to its content(see Figure 6.2): This pointer needs to be true, otherwise the user of the system would not be ableto read the file. As an example for non-essential data Carrier mentions the last-accessed timestampof the file. Carrier argues that

[. . . ] [i]f the time value is never updated, it will not affect the user when she tries toread from or write to the file. Therefore, we should trust the essential data more thanthe non-essential data because it is required and it is needed for the file system to saveand restore files. [18, p. 176]

Name:miracle.txt

Cluster:345

Size:40

Last Accessed:October 27, 2004

Today, the Yankeeswon the World Series.

Today, the Red Soxwon the World Series.

Cluster 344 Cluster 345

Figure 6.2: Example of essential and non-essential data [18, Fig. 1.4, p. 13]: the name of the file and thepointer to its content are essential, the last access time is non-essential.

73

6 Essential data and anti-forensics

6.2.1 Problem 1: Definition depends on assumed basic functionality

In a sense, essential data defines the “core” of the data structures necessary to use the “basicfunctionality” of a file system. The basic functionality due to Carrier apparently is to manage a setof files on a disk. The introductory quotation at the beginning of this article gives examples forwhat this basic functionality is [18, p. 176]:

• saving (i.e., writing) a file,

• retrieving (i.e., reading) a file, and

• identifying a file with a name.

In contrast, Carrier explicitly states which data fields are solely “for convenience” and are thusnon-essential data. For example, a timestamp or a user ID “is not essential because it does notneed to be true” [18, p. 176] to read or write the file since

[. . . ] the OS may not have enforced the access control settings on a file; therefore, aninvestigator cannot conclude that a user did or did not have read access to a file. [18,p. 186]

Other examples of non-essential data are file attributes such as read-only in FAT. They arenon-essential because

[. . . ] [t]he impact of these being set depends on how the OS wants to enforce them.The read only attribute should prevent a file from being written to, but I found thatdirectories in Windows XP and 98 can have new files created in them when they are setto read only. [18, p. 227]

In other words, if the operating system can ignore the data field and still provide “basic functionality”,then the data field is non-essential. If this functionality is merely reading and writing to files, thenwe are close to Carrier’s definition used throughout most parts of his book. However, if it comes topartition systems, basic functionality is different: Carrier states that the “purpose of a partitionsystem is to organize the layout of a volume” [18, p. 72]. This means that the only essential dataare those that identify the start and end of each partition:

A partition system cannot serve its purpose if those values are corrupt or non-existent.All other fields, such as a type and description, are nonessential and could be false. [18,p. 72]

Interestingly, Carrier at one point switches to a totally different “basic functionality” while analyzingdata from the Application category (such as file system journals):

In this section, we will refer to the data being essential if they are required for theapplication-level goal of the feature and not if they are required for storing data. [18,p. 339]

The application level goal is not simply reading and writing to files, but rather they “are essential forthe goal of providing a log of file changes” [18, p. 392]. In several other places, application-level fea-tures are used to vary the notion of essential data, e.g., in the context of the $STANDARD_INFORMATIONattribute in NTFS [18, p. 282, p. 316].So overall, Carrier’s definition is relative to what basic functionality one assumes.

74

6.2 Definition of essential data by Carrier and its problems

6.2.2 Problem 2: Definition depends on application

Carrier also observes that the basic functionality (and, therefore, the definition of essential data)may be dependent on the “application”. The term application refers to any software accessing thedata on disk, but most often it refers to an operating system (OS):

Some OSes may require a certain value to be set, but that does not mean it is essential.For example, a very strict (and fictitious) OS might not mount a file system that hasany files with a last access time that is set in the future. Another OS may not have aproblem with the times and will mount the file system and save data to it. MicrosoftWindows requires that all FAT file systems start with a certain set of values even thoughthey are used only when the file system is bootable. Linux, on the other hand, has norequirements for those values. [18, p.176]

So the fact that a specific value needs to be set for a particular operating system to boot the systemdoes not mean it is essential. Carrier argues as follows:

[. . . ] knowing the OS that wrote to the file system is just as important as knowing thetype of file system. When discussing file recovery, it is not enough to ask how to recovera file from a FAT file system. Instead, ask how to recover a file that was deleted inWindows 98 on a FAT file system. Many OSes implement FAT file systems, and eachcan delete a file using different techniques. For example, most OSes do the minimalamount of work needed to delete a file, but there could be others that erase all dataassociated with the file. In both cases, the end result is a valid FAT file system. [18,p. 240]

So a data field is essential only if all operating systems have to use it in order to provide basicfunctionality.

6.2.3 Problem 3: Definition cannot deal with redundant information

When analyzing the flags in the $STANDARD_INFORMATION attribute in NTFS, Carrier makes aninteresting observation that points to a third ambiguity of his notion of essential data:

Many of these flags [e.g., encrypted, hidden, read-only, etc.] are the same as were seenwith FAT, and a description of them can be found there. The flags for encrypted andsparse attributes are also given in the attribute headers, so I consider them to not beessential in this location. This is debatable, though, because another person could claimthat this flag is essential and the MFT entry header values are not essential. [18, p. 361]

In other words, if an important data field appears redundantly in multiple places and both fieldscan be used to provide basic functionality, then it is “debatable” which one is essential and whichone is non-essential.

75

6 Essential data and anti-forensics

6.3 What is essential data?Given the ambiguities of Carrier’s informal definition, we now revisit the concept of essential dataand try to approach its different meanings by using a simple formal notation.As observed in Section 6.2 on page 73, the notion of essential data depends on the “basic functionality”and the “application”. Different basic functionalities can be characterized as a set of operations thatare “basic” and assumed vital for the task at hand. For example, the “standard” basic functionalitythroughout most parts of Carrier’s book is the set

{store a file, retrieve a file}

but there may be different sets in different contexts. We define a set B of basic functionalities as

B = {b1, b2, b3, . . .}.

Next, to a basic functionality, the definition of essential data is relative to the set of applications Awhich we denote as

A = {a1, a2, a3, . . .}.

The applications can be operating systems, database systems, or in general every computer systemthat accesses a data structure on disk that makes up a partition table, a file system or a database.The data structure consists of several data fields. Examples for data fields have been mentionedabove, e.g., the file name, pointers from metadata to file content, access timestamps, the startaddress of a partition in a partition table, or a magic value in a file header. It is on the level ofdata fields that we want to determine essential data. For simplicity, we abstract from the semanticsof these data fields and simply denote by F the set of all data fields of interest.The combination of basic functionality and application uniquely defines the context in which we canprecisely decide whether a data field is essential or not. The idea of our definition is to constructgeneral notions of essential data from individual observations of how an application behaves whentrying to provide some basic functionality using a specific data field. More precisely, we define aboolean evaluation function E with the following signature

E : B ×A× F 7→ {true, false}

which for a given behavior b, application a and field f returns whether the field f is necessary by ato correctly provide b.It is important to note that E can be evaluated by experiment, i.e., by choosing a concreteapplication a and looking how it behaves after manipulating some data field f . So, for example, ifapplication a, e.g., Windows XP, can provide basic functionality b, e.g., access to file content, evenif field f , e.g., the pointer to file content, is not present or malformed, then E(b, a, f) = false. Inthis case, we say that a evaluates negatively on f , i.e., the field f is non-essential to a to provide b.If, however, the application a cannot correctly access the data, not access the data at all, or evenstops working or crashes, then E(b, a, f) = true. In this case, we say that a evaluates positively onf , meaning that the field f is essential for application a. to provide behavior b.We now define what it means for a data field to be essential data. We distinguish between applicationdependence and basic functionality dependence and define two different notions of essential data.Let us fix some basic functionality b ∈ B and some data field f ∈ F and consider a fixed set A ofapplications.

Definition 6. We say that f is strictly essential w.r.t. A and b iff all applications in A evaluatepositively on f , i.e., iff ∀a ∈ A : E(b, a, f).

The term strictly essential tries to precisely capture Carrier’s definition of essential data. Becauseall applications require the data field, it seems logical that this data field is absolutely necessary forthe data structure to function. However, it may also be the case that some application evaluatespositively on the data field and some negatively. This captures an application-dependent form ofessential data: Roughly spoken, the field is essential for some applications but not essential forothers. This results in the notion of partially essential data.

76

6.4 Evaluation

Definition 7. We say that f is partially essential w.r.t. A and b iff some applications in A evaluatepositively on f and some evaluate negatively. Formally, the following condition has to be satisfied:

∃a ∈ A : E(b, a, f) ∧ ∃a ∈ A : ¬E(b, a, f)

Intuitively, the term partially essential comprises data that only some applications require tocorrectly process the data structure. Often these are fields that are specified to be of a specific formby the data structure specification, but besides the specification stating so, there is no reason forthese fields to contain the specified data. Examples of such partially essential data only required bythe specification are checksums and informational fields.Finally, we define what it means for a data field to be neither strictly nor partially essential.

Definition 8. We say that f is non-essential w.r.t. A and b iff all applications in A evaluatenegatively on f , i.e., iff ∀a ∈ A : ¬E(b, a, f).

The term non-essential includes all data fields that no application requires to function correctly.Examples for this are metadata, file contents, slack space or padding. This is usually contentthat the user of the data structure is free to decide on (like file content), or parts which are notconsidered part of the data structure at all (such as slack space or padding).Note that a data field can either be strictly essential or partially essential but not both. Thiscorresponds to Carrier’s concept of essential data since in his view, data was either essential ornon-essential, only that we now allow to distinguish application-specific types of essential data.Also, note that our definition is relative to the basic functionality. We believe that this is a definingaspect of essential data: As long as two basic functionalities are incomparable, so must be thenotions of essential data for these functionalities. This is also reflected by Carrier’s statements.

6.4 Evaluation

We now evaluate our definitions of essential data by fixing basic functionality and a set of applicationsand then empirically running the application on a file system for which different data fields werechanged or manipulated. We, therefore, tried to systematically reproduce the findings of Carrier[18], which we were not always able to. The set of applications consisted of Windows XP, Windows7 and Ubuntu 12.04, and we systematically evaluated the data fields of the DOS/MBR and GPTpartition systems. For these parameters, we attempted to reliably reproduce the deterministicbehavior of operating systems when certain data fields were changed. In a sense, we tried to recreatethe evaluation function E upon which the general notion of strictly/partially essential data is based.The analysis was performed by 19 students taking part in a course on digital forensics for computingprofessionals.The set of basic functionality in our experiment was the ability to access or mount a partition (in orderto store and retrieve files). This is the default functionality B in the following. However, in somecases, we observed that the operating systems behaved differently regarding other functionalities.In this case we qualify our results with a footnote specifying the specific (non-default) functionalityin question.We present our results as tables listing the data fields in the MBR and GPT headers and partitionentries, with each data field being marked as essential or not for each tested operating system. Moreformally, the tables show the boolean values of the evaluation function for the specific combinationof functionality and application. For comparison, we also always note the classification by Carrier[18]. Based on the results of the evaluation, the last column denotes whether the data field isstrictly (SE), partially (PE) or non-essential (NE).

77

6 Essential data and anti-forensics

6.4.1 DOS/MBR

Table 6.2 on the facing page gives an overview of entries in the Master Boot Record (MBR) andtheir categorization. As can be seen, only the partition table entries are strictly essential, whilethe boot code is non-essential, unless the application is supposed to boot from the device. Buteven in that case, the boot code can be whatever the application decides and any other applicationshould not be hindered to access the partitions by different boot code. The same is true for thedisk signature and the “UEFI unknown value”, which are also user controllable.

The boot code is non-essential for accessing/mounting the partition, but for another basic function-ality, namely booting from the volume, it is even strictly essential. Since our default functionalityis accessing the partition, we refer to the field as non-essential.

The interesting field is the boot signature field. Indeed, an OS can access the partition table andfrom there the partitions without this value, as shown by Carrier. However, in our evaluation, allthree tested OSes required this value to be set. Otherwise, they refused to mount any partition,because they considered the MBR to be invalid, which according to the UEFI Specification [156] iscorrect. Windows XP and 7 even attempted to repair the volume. So given the evidence of Carrierand our own findings, we argue that it is partially essential.

Bytes Data Field f Essential [18] Essential Linux Essential Windows Type0 - 0 Boot-Indicator No Yes∗ No PE1 - 3 CHS Start-Address Yes§ No No PE4 - 4 Partition Type No Yes† Yes† PE5 - 7 CHS End-Address Yes§ No No PE8 - 11 LBA Start-Address Yes§ Yes Yes SE12 - 15 Size in LBA-Blocks Yes§ Yes Yes SE

∗Must be either 0x00 or 0x80, otherwise the entry is ignored§Either CHS Addresses or LBA Addresses must be provided.†Essential for automatically mounting the partition.

Table 6.1: MBR partition table entry data fields [156, Table 14. Legacy MBR Partition Record] and theirtype.

We now turn to the data fields of an MBR partition entry. As can be seen from Table 6.1 only theLBA Addresses are strictly essential, because the CHS Addresses are not used by the OSes. AsCarrier already indicated the CHS Addresses are non-essential if the OS uses the LBA Addressesand those are present and correct. With our new levels of essential, we are able to adequatelyrepresent those instances where it depends on the application whether a field is essential or not.

To provide backwards compatibility a storage medium partitioned via the GPT system contains aso-called protective MBR (PMBR) at LBA 0. This PMBR protects the GPT partitions in the sensethat legacy applications are prevented from accidentally accessing the disk areas containing theGPT Partitions as “used”. To this end, the PMBR contains one partition of type EFI (0xee). Therest of the partition entries is zeroed. GPT will work without this PMBR being present, in whichcase, however, GPT ignorant legacy systems may accidentally overwrite data in GPT partitions.The essential data of this PMBR with regard to the tested operating systems is the same as theclassical MBR, hence not explicitly listed.

78

6.4Evaluation

Bytes Data Field f Essential [18] Essential Linux Essential WindowsXP and 7 Type

0 - 424. . . 446 Boot Code No No No NE440 - 443 Unique MBR Disk Signature No§ No No NE444 - 445 UEFI Unknown No§ No No NE446 - 461 1st Partition Table Entry Yes Yes∗ Yes∗ SE462 - 477 2nd Partition Table Entry Yes Yes∗ Yes∗ SE478 - 494 3rd Partition Table Entry Yes Yes∗ Yes∗ SE494 - 461 4th Partition Table Entry Yes Yes∗ Yes∗ SE510 - 511 Boot Signature No Yes Yes† PE512 - Logical Blocksize Reserved No No No NE

§Part of boot code and not explicitly defined by Carrier.∗Otherwise, the partition is not recognized.†Otherwise, the Microsoft Windows wants to repair the drive containing the partition.

Table 6.2: MBR data fields [156, Table 13. Legacy MBR] and their type.

79

6Essentialdata

andanti-forensics

Bytes Data Field f Essential [18] Essential Linux EssentialWindows 7 Type

0 - 7 EFI Signature “EFI PART” No Yes∗ Yes∗ PE8 - 11 Revision Yes Yes Yes SE12 - 15 GPT Header Size in Bytes Yes Yes Yes SE16 - 19 Header CRC32-Checksum No Yes Yes PE20 - 23 Reserved (zeroed) No No No NE24 - 31 LBA of Header (self-reference) No No Yes PE32 - 39 LBA of GPT Backup Header No No No NE40 - 47 LBA of 1st Block of Partition Area Yes Yes Yes SE48 - 55 LBA of last Block of Partition Area No No No NE56 - 71 Disk GUID No No No NE72 - 79 LBA of 1st Block of Partition Table Entries Yes Yes Yes SE80 - 83 Number of Partition Table Entries Yes Yes† Yes†,‡ SE84 - 87 Size of Partition Table Entries Yes Yes Yes SE88 - 91 CRC32-Checksum of Partition Table Entries No Yes Yes PE92 - Blocksize Reserved (zeroed) No No No NE

∗Without the EFI Signature the PMBR is used.†Must be greater than the partition number to be used.‡Setting the Number of Partition Table Entries to zero leads to a Blue Screen of Death in Windows 7.

Table 6.3: GPT header [156, Table 17. GPT Header]

80

6.5 Discussion

6.4.2 GPT header

Table 6.3 on the facing page shows our empirical results for the GPT header. Because WindowsXP does not support EFI and GPT it was not tested and hence is not listed. As can be seen fromthe table, again all three types of essential data are present. The main reason for the amountof partially essential data is again due to a specification requiring a field but applications notnecessarily relying on it. According to the UEFI Specification [156, 5.3.2 GPT Header] the EFISignature, Header CRC32-Checksum, LBA of Header and CRC32-Checksum of partition tableentries must all be valid. But as Carrier already indicates, a GPT partitioned drive can be usedwithout these fields being valid.An interesting fact is that the LBA of GPT backup header is non-essential, even though the UEFISpecification [156, 5.3.2 GPT Header] clearly states that the GPT Backup Header must also bechecked for validity. Obviously, this is not done by any tested operating systems.

6.5 Discussion

We now discuss the benefits and shortcomings of our definition.

6.5.1 Usefulness of new definitions

Strictly essential data must be relied upon, because by definition it is the minimum amount of dataneeded to correctly access a data structure according to its specification. If less data is required toaccess the data structure this would violate our definition of strictly essential.In theory, with an infinite number of applications, this definition would exactly correspond toCarrier’s definition, because if a field is essential according to Carrier there cannot exist anapplication that is able to correctly interpret the data structure without this field. However, ifsuch an application aw would exist then the original premise of the field being absolutely necessaryto access the data structure could be dismissed because the aw would be a witness against thenecessity of the data field. Hence, strictly essential data w.r.t. the set of all (thinkable) applicationsis exactly the minimal data necessary for a data structure to function correctly (with respect to acertain basic functionality, or course).As stated earlier partially essential data, is often data that is required by the specification, butnot necessary at all to access the data structure. One example is the MBR Boot Signature. Eventhough in our tests all OSes required the signature, it is obviously possible to construct an OSthat does not require this signature. If partially essential data is encountered during an analysis,care must be taken to consider the circumstances correctly, e.g., as can be seen from Table 6.2 onpage 79 neither Windows nor the tested version of Linux recognized the partition table as valid,hence, this fact could be exculpatory.In theory, non-essential data should only comprise data fields that are by specification allowedto be completely controlled by the user of the data structure. If an application would exist thatimposes a restriction on the data field content, e.g., assumes a particular value to be present, thatapplication would violate the specification of the data structure and, therefore, would have to beconsidered broken. For Carrier too, the fact that data is fully user-controllable is a good indicatorof something being non-essential:

Technically, any file that an OS or an application creates could be designed as a featurein a file system. For example, Acme Software could decide that its OS would be fasterif an area of the file system were reserved for an address book. Instead of saving namesand addresses in a file, they would be saved to a special section of the volume. Thismight cause a performance improvement, but it is not essential for the file system. [18,p. 205]

81

6 Essential data and anti-forensics

6.5.2 Trust hierarchy

With our new notions of essential data, we are able to adequately represent those instances where itdepends on the application whether a field is essential or not, which allows us to define a hierarchyof trustworthiness:

• Strictly essential data must be trusted. They are generally not manipulatable withoutimpacting the correct functionality of the data structure.

• Partially essential data can be trusted for specific applications. Because not all applicationsrequire this data to be specifically formatted, it is possible that this data is manipulated.

• Non-essential data cannot be trusted. Non-essential data is in general either user content, thatis data which can be freely chosen by the user of the data structure, or “wasted” space within thedata structure, that serves no data storage purpose, such as slack space or padding. However,non-essential data can become essential if “higher level” basic functionalities (functionalityreferring to user applications like browsers or word processors) are considered.

This trust hierarchy can give an indication to how anti-forensic resistant a specific data field is,because a field that is strictly essential can not be manipulated without impacting the correctfunctionality of the application. So, in case, a partition table of a hard drive actively being usedby a system is analyzed, it can be assumed that the strictly essential fields could not have beenmanipulated by anti-forensic software. With this knowledge, anti-forensic resistant tools can bebuild, by making current tools only rely on strictly essential data, if possible. In case this is notpossible, the tool should warn the forensic analyst when partially essential data was used to interpretthe data.

6.5.3 Evidence hierarchy

Besides a hierarchy of trustworthiness of data, a hierarchy of where evidence is most likely storedcan be specified:

• While strictly essential data can be evidence in itself, it cannot “contain” evidence. This isbecause the strictly essential data’s content is completely defined by the data structure and isnot freely user influenceable.

• Partially essential data can be used to store user content, given it is not used by an appli-cation which evaluates positively on that data field. So for partially essential data the casecircumstances, i.e., the set of installed applications, must be considered in order to judgewhether a data field contains user data that can be used as evidence.

• Non-essential data can be used freely to store any data. Hence, this data must, in any case, beanalyzed. During a forensic investigation, even fields that the data structure specification doesnot explicitly tag as user storage must be analyzed for hidden data if the field is non-essential.Here it is also important to note that data fields can depend on other data fields, e.g., if forDOS/MBR the bootable flag in the partition table entry is not set to either 0x00 or 0x80 ona Linux, the entry is discarded. This means the CHS and/or LBA addresses within the entrybecome non-essential, even though they are strictly essential in a valid partition entry.

Because non-essential data can be freely manipulated, it can be used as anti-forensic hiddenstorage, i.e., non-essential data fields of data structures can be used to either hide evidence of storecomponents of a malware or rootkit. Hence, non-essential data must, in any case, be analyzed.

82

6.6 Conclusions and future work

6.6 Conclusions and future workCarrier’s notion of essential data is important to understand the trustworthiness and hence resilienceagainst anti-forensic manipulations of evidence found in file systems. In this chapter, we revisitedCarrier’s definition and distinguished a “pure” notion (consistent across all possible contexts) andan “application-dependent” notion of his term. With our evaluation, we, therefore, followed arecommendation by Carrier to verify and test specific behavior of applications as stated in his book:

[. . . ] it is important for an investigator to verify and test the application-specificbehavior in the context of a specific incident. [18, p. 176]

Because anti-forensic methods often use flaws within systems, these practical evaluations are veryimportant. Even given such a simple target as partition tables, we were able to uncover discrepanciesbetween system with regard to how essential data is to them. An anti-forensic attacker familiarwith a particular system could use those discrepancies to his advantage, e.g., storing evidence in adata field that is supposed to be strictly essential in theory, when on the particular system it isnon-essential and thus can be freely manipulated.In future work, we need to extend our analysis to other and also more complex data structures.Interesting structures are file systems, such as FAT, NTFS and EXT. However, also memorystructures such as kernel process structures could be evaluated. However, we would then need toalso take general notions like technically avoidable and technically unavoidable evidence [32] intoaccount.Further possible research needs to be done on data fields which have a logical dependency on eachother. One example for this would be the GPT Backup Header. It is not used if a valid GPTHeader is defined. This means that the GPT Backup Header could be considered non-essential. Ifno valid GPT Header exists the GPT Backup Header is used. This would make the GPT Headernon-essential. However, both cannot be non-essential at the same time. At least one of them needsto be defined, making at least one strictly essential, but not both. Ways to formalize this need tobe found.

83

7 Virtual memory analysis(on Windows NT)

Once the evidence has been acquired it needs to be analyzed. To this end, we in this chapter,address the analysis of virtual memory. This can be used to analyse the memory acquired via oneof the previously mentioned methods. We further identify one blind spot of current state-of-the-artmemory analysis methods, namely the swapped out memory pages. In order to provide more virtualmemory than is actually physical present on a system, an operating system may transfer frames ofmemory to a pagefile on persistent storage. Current memory analysis software does not incorporatesuch pagefiles and thus misses important information. We, therefore, present a detailed analysis ofWindows NT paging. We use dynamic gray-box analysis, in which we place known data into virtualmemory and examine where it is mapped to, in either the physical memory or the pagefile, andcross-reference these findings with the Windows NT Research Kernel source code. We demonstratehow to decode the non-present page table entries, and accurately reconstruct the complete virtualmemory space, including non-present memory pages on Windows NT systems using 32-bit, PAE orIA32e paging. Our analysis approach can be used to analyze other operating systems as well.

7.1 IntroductionWith the increased usage of hard disk encryption, the employment of RAM disks, and persistencedata avoidance technologies such as private browsing modes, memory analysis becomes more andmore important to the computer forensic process. In some cases, such as memory resident malware,or the already mentioned private browsing modes, the volatile memory can become the only sourceof information in an investigation.Because the physical memory of a computer system is limited and far smaller than the availablepersistent storage modern operating systems provide virtual memory. In a virtual memory envi-ronment, virtual memory addresses are translated to physical memory addresses via an addresstranslation process. To provide more virtual memory as is physically present in form of RAMmodules, an operating system may swap parts of the virtual memory out to persistent storage.Hence, data in the virtual address space may not always be present in the physical main memoryof a computer system, but only in the persistent storage of that system. The location of the virtualmemory on the persistent storage is known as the pagefile.

7.1.1 Motivation

Previous research has already found the pagefile to be of forensic value. Software such as browsers canleave evidence in the pagefile [114]. However, current analysis methods are not adequate. Currently,the pagefile is treated as a miscellaneous date file, without considering each non-paged memorypage’s position in the virtual address space. This approach can still yield valuable information, e.g.,by running a keyword search over all non-paged memory pages in the pagefile [124, 111]. Searchingthe pagefile via a file carver can also successfully discover files [95].However, without context, the forensic value of these findings is diminished. One example is amulti-user system. In which case, finding data of interest in the pagefile may not be enoughto be helpful to the case if it can not be attributed to a particular user or process within thecomplete system. Further, a lot of data of interest is simply lost because it can not be adequatelyreconstructed without putting the non-paged memory pages into context, e.g., process structures orpicture files.

85

7 Virtual memory analysis (on Windows NT)

In general, complex data structures spanning multiple memory pages require the paging relationto be reconstructed accurately and with certainty. Additionally, to reconstruct also non-pagedmemory data from the pagefile must be incorporated into the analysis. This is exactly what ourwork fixes. It provides the paging context of the non-paged memory pages within the pagefile ofWindows NT systems to current memory analysis methods.

7.1.2 Related workCurrently, memory analysis is already established and there exist a vast amount of works dealingwith the acquisition and analysis of paged memory [162]. However, only one [89] considers non-pagedvirtual memory. Related work exists for the extraction of the pagefile.sys [95]. Many worksmention extracting data from the pagefile.sys via crude methods [124]. However, such methodsare at the borderline of forensic sanity, because some rely on knowing specific keywords before handor extract data chunks without putting them into the context of the rest of the system processes.The incorporation of the pagefile into the memory analyzing process was proposed [82] andpreliminary information has been published regarding the connection between the pagefile andnon-present pages in the page table of Windows NT system [89]. This knowledge was furthersupplemented by information about mapped files [160] and the Windows Virtual Address Descriptor(VAD) tree [34].Volatility, the leading project in open source memory analysis, strives to add pagefile support as partof their project road map, but it is not implemented yet. Rekall, a project forked from the Volatility“scudette” branch known as the “Technology Preview” branch, currently developed by MichaelCohen for Google, has very recently, during the preparation of this work, added preliminary codeto their 1.2.1 release, in preparation for pagefile analysis. However, no publication nor informationabout this implementation, nor any evaluation with regard to its correctness existed during thepreparation of our work.

7.1.3 OutlineThis chapter is structured as follows: In Section 7.2 we present our gray-box analysis scheme andthe tools we used to conduct this analysis. In Section 7.3 on page 89, we provide an overview ofpaging on Windows NT systems, the content of which was ascertained and verified via our gray-boxanalysis scheme. In Section 7.4 on page 95, we give a brief overview of current memory and pagefileacquisition techniques for Windows NT. And in Section 7.5 on page 96, we give a brief overview ofmemory analysis that can be performed within the virtual address space as reconstructed by ourmethod. Finally in Section 7.6 on page 98 we evaluate the new combined virtual memory analysistechnique incorporating the pagefile. To this end, we compare it to current analysis methods. Lastbut not least, we conclude this chapter in Section 7.7 on page 103.

7.2 Grey-box virtual address translation analysisEven though, work related to pagefile incorporation into Windows NT virtual memory analysisexists, as already outlined in Section 7.1.2, we developed a gray-box virtual address translationanalysis method, which can be used to verify, disprove, and/or updated current knowledge. Thisgray-box scheme can further be used to analyse yet unknown systems.

7.2.1 SchemeThe virtual address translation analysis scheme targets address translation via paging. However,it can be adapted to other translation methods, such as segmentation. The basic scheme can beseen in Figure 7.1 on the next page. The components consist of the Virtual Memory, the PhysicalMemory, the Pagefile, and the Virtual Address Translation.The Virtual Address Translation component is the target of the analysis. The goal is to inferknowledge about it. To this end, the Virtual Memory is filled with known pages. We use sequentialnumbers to fill the pages. We call these known pages crib pages (cf. word usage of crib in cryptology).

86

7.2 Grey-box virtual address translation analysis

The number pattern within each page allows us to uniquely identify each page and to find thecorresponding physical frame in either the Physical Memory component or the Pagefile.The available knowledge about the basic workings of the Virtual Address Translation and theavailability of at least the binary code of the operating system, residing in physical memory, makesthis a gray-box analysis. The goal of this analysis is to provide for any given virtual page addressthe corresponding physical frame address or physical frame offset, if the physical frame is in thepagefile.

0x000000000x00000001

...0x00000ffe0x00000fff

0x000010000x00001001

...0x00001ffe0x00001fff

...

0xNNNNN0000xNNNNN001

...0xNNNNNffe0xNNNNNfff

0xNNNNN0000xNNNNN001

...0xNNNNNffe0xNNNNNfff

0x000010000x00001001

...0x00001ffe0x00001fff

0x000000000x00000001

...0x00000ffe0x00000fff

?VirtualAddress

Translation

Virtual Memory Physical Memory

Pagefile

CribPage

MemoryPage

CribFrame

MemoryFrame

PagefileFrame

Figure 7.1: Grey-box virtual address translation analysis scheme

7.2.2 Test data generationThe data needed for our gray-box analysis is created by our ramwrite tool. It is platform-independent, portable and only relies on ISO C89 features. ramwrite allocates a specific amount ofmemory via malloc(). It allocates one page more than is requested. This way the crib data canbe aligned to a page boundary. The memory space from the address returned by malloc to thenext page boundary is filled with 0xc001babe to distinguish it from the beginning of the crib dataand also potentially from any other data.The ramwrite process stays open until user input is provided. This way the memory allocation canpersist as long as needed. ramwrite supports different patterns it can write. The most useful are:

addr: Writes a sequence of 32-bit numbers into the allocated space, starting with 0 at the start ofthe allocation.

zero: Overwrites the allocation with zero bits; useful for “cleaning” the memory before tests.

one: Like zero, but writes all one bits.

deadbeef: Fills the allocation with the 32-bit value 0xdeadbeef; useful as a second distinguishablepattern.

87

7 Virtual memory analysis (on Windows NT)

ramwrite is duplicated and renamed swapforcer. swapforcer is used to force the memoryallocation of ramwrite out of physical memory into the pagefile by making a large allocation.swapforcer fills its memory allocation with 0xdeadbeef. Depending on how much of the ramwritememory content should be written to the pagefile, swapforcer can also allocate the completephysical memory.With these two programs the needed crib data can be placed into physical memory and the pagefileas follows:

• ramwrite is executed and fills its memory allocation with sequential 32-bit numbers (addrpattern).

• swapforcer is executed and fills its memory allocation with a distinguishable pattern(0xdeadbeef pattern).

• By varying the size of the memory allocation by the swapforcer, the crib data distributionbetween physical memory and pagefile can be controlled. The more memory swapforcerallocates, the more frames of the ramwrite process are swapped into the pagefile.

7.2.3 Inferring the virtual address translationOnce ramwrite and swapforcer are executed on a system, the physical memory and pagefile can beacquired. In Section 7.4 on page 95 we will go into detail how this is can be done on Windows NT.The analysis then consists of

1. figuring out the mapping of virtual crib page addresses to physical crib frame addresses andoffsets, and

2. inferring how the operating system “remembers” this mapping.

The first is trivial. A simple program find_addr <offset> <addr> was created that searches theinput at the specified offset <offset> for a crib page starting with the 32-bit value given by the<addr> parameter.The second step is more complicated and has, in some parts, to be done via manual reverseengineering:

1. The hardware dependent address translation must be interpreted.

2. The software dependent address translation must be interpreted.

The hardware dependent address translation is specified by the hardware manufacturer. Addresstranslation is done via paging tables. For this, the operating system has to store the base addressof the root table somewhere. In Section 7.5.1 on page 96, we will detail how this base address canbe found on Windows NT systems. Once this base address is extracted the paging table tree canbe traversed.After the hardware dependent address translation part is implemented in the memory analysisprocess, it is recommended to test it with memory dumps of the ramwrite program without anycrib data being forced into the pagefile. The memory analysis process should be able to perfectlyreconstruct the crib data, i.e., bring each crib frame into the correct order.For the software dependent part a trial-and-error process is used. We currently assume the correlationbetween virtual addresses and offset in the pagefile can be inferred from the page table entry itself.At least this is true for Windows NT and Linux (cf. swp_entry_t and pte_to_swp_entry() inthe Linux source code). If a different system does not use the page table entries to store thisinformation, the relevant data structure must be found within the operating system data structures.Here the location, i.e., addresses and offsets, of the crib pages and crib frames can be used to verifyfound data structures. Even though, theoretically an exhaustive search for crib frame addressesand offsets could be used the amount of possible candidates for operating system data structurescould be overwhelming. Our findings so far, however, indicate that the crib frame offset into thepagefile can be determined, by appropriately shifting and masking the page table entry value.

88

7.3 Windows NT x86 and x64 virtual memory overview

7.3 Windows NT x86 and x64 virtual memory overview

In this section, we give an overview of virtual memory translation for Windows NT x86 and x64 with32-bit, PAE and IA32e Paging. The information herein was derived via the techniques described inthe previous section and was further extended and verified via cross-referencing the Windows NTResearch Kernel source code [104].

7.3.1 Pagefile

Before the paging overview, we briefly explain the pagefile of Windows NT. The default pagefile onWindows NT systems is called pagefile.sys. On default it is stored in the root directory of thefile system the operating system is installed on, i.e., %SystemRoot%\pagefile.sys. However, upto 16 pagefiles can exist. Their name, location, minimum and maximum size in MiB are specifiedin the registry strings stored in the entry shown in Listing 7.1.

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management \ PagingFiles

Listing 7.1: Pagefile registry entry

With each string entry having the form outlined in Listing 7.2

<path to pagefile > <minimum size in MiB > <maximum size in MiB >

Listing 7.2: Pagefile registry entry format

The pagefiles are numbered, starting from 0 to 15 beginning with the first entry in the PagingFilesregistry entry. At runtime, the Windows NT kernel keeps a _MMPAGING_FILE structure for eachpagefile. The most relevant fields are outlined in Listing 7.3, with the offsets referring to a Windows 7x86 with the kernel build version 7600.

lkd > dt nt! _MMPAGING_FILE+0 x018 File : Ptr32 _FILE_OBJECT+0 x024 PageFileName : _UNICODE_STRING+0 x040 PageFileNumber : Pos 0, 4 Bits+0 x044 FileHandle : Ptr32 Void

Listing 7.3: WinDbg displaying memory layout of _MMPAGING_FILE structure

This way the pagefile number and corresponding path and name of the file can be derived from thephysical memory of a system. However, in order to be of any use, the corresponding pagefiles musthave been acquired alongside the physical memory, at which point the pagefile numbers, paths, andnames should already be known to the analyst who acquired the pagefiles in the first place. Inany case, multiple pagefiles are rare, because they must be explicitly configured and are, to ourknowledge, not generated by Windows NT on default settings.On a live system, the pagefile itself is locked by the kernel. However, in Section 7.4.2 on page 95 wewill detail how the file can still be acquired on a live system.The pagefile’s content is unstructured. Raw memory frames are stored in the file as if it was physicalmemory. Each frame is referenced by an offset. The next section explains the address translationbetween virtual memory page addresses and the pagefile frame offsets.

89

7 Virtual memory analysis (on Windows NT)

7.3.2 Page table entriesWindows NT systems running on x86 based hardware will use PAE Paging [80, 4.4. PAE PAGING]if available. If it is not available they will use 32-bit Paging [80, 4.3. 32 BIT PAGING]. Windows NTsystems running on x64 based hardware will use IA32e Paging [80, 4.5. IA32e PAGING].In the following sections, we will give an overview of the page table entries (PTEs). PTEs can bedivided into two categories: hardware PTEs and software PTEs. Hardware PTEs are all PTEswhich have the present bit set. If this bit is set the interpretation of the values within the PTEis strictly done by hardware. In case the PTEs are marked as invalid, they are software PTEs.Software PTEs are interpreted strictly by software. In this case the Windows NT kernel. Later wewill go into detail how Windows NT interprets the PTEs and translates the virtual addresses. Wewill now give an overview of the bit layout of possible PTEs.

7.3.2.1 32-bit Paging

Figure 7.2 lists the hardware PTEs that we encountered during our analysis of Windows NT runningon x86 based hardware without PAE Paging present. Their definition is given strictly as per theIntel specification [80, Figure 4-4.]. Ignored fields are grayed out. They are not interpreted by thehardware and can thus be considered software fields. The bits at offset 12 to 31 give the 4KiBaddress of either further tables or the start of the physical memory frame.

012345678910111213141516171819202122232425262728293031

Address of PD IgnoredP

CD

PW

TIgnored CR3

Address of PT Ignored 0

Ign

ored

Acc

esse

d

PC

D

PW

T

Ign

ored

1 PDE (PT)

Address of 4 KiB frame Ignored

Glo

bal

0

Ign

ored

Acc

esse

d

PC

D

PW

T

Ign

ored

1 PT (4KiB)

Figure 7.2: 32-bit Paging PTE structures

Windows NT does not seem to use 2MiB frames. We neither encountered such frames during ouranalysis nor makes the Windows Research Kernel source code any references to 2MiB frames for32-bit Paging [104, mi386.h].

012345678910111213141516171819202122232425262728293031

PageFrameNumber

rese

rved

Pro

toty

pe

Cop

yO

nWri

te

Glo

bal

Lar

geP

age

Dir

ty

Acc

esse

d

Cac

heD

isab

le

Wri

teT

hro

ugh

Ow

ner

Wri

te

Val

id MMPTE_HARDWARE

PageFileHigh

Tra

nsi

tion

Pro

toty

pe

Protection

Pa

ge

Fil

eL

ow

Val

id MMPTE_SOFTWARE

Figure 7.3: Windows NT 32-bit Paging structures

90

7.3 Windows NT x86 and x64 virtual memory overview

Figure 7.3 on the preceding page lists the software PTEs of Windows NT with regard to 32-bitPaging. The definition of the MMPTE_SOFTWARE PTE was taken from the Windows ResearchKernel source code [104, mi386.h:2446] as was the MMPTE_HARDWARE PTE definition [104,mi386.h:2508].The PageFileLow field gives the pagefile number. As discussed earlier there can be up to 16 pagefiles.The PageFileHigh field gives the offset into the pagefile. Like the hardware PTEs, this offset is a4KiB offset. Hence the byte offset can be obtained by simply masking the last 12 bits of the PTE.Not only memory frames can reside in the pagefile, but also PTEs themselves can reside in thepagefile. These findings are the same as presented in other research [89, Figure 3].

7.3.2.2 PAE Paging

Figure 7.4 lists the hardware PTEs that we encountered during our analysis of Windows NT runningon x86 based hardware with PAE Paging enabled. Their definition is given strictly as per the Intelspecification [80, Figure 4-7.]. Ignored fields are again grayed out and can be considered softwarefields. Further we also grayed out reserved fields, which according to Intel’s specification have to bezeroed [80, p. 4-18]. For all but the Page Directory Entry pointing to a 2MiB frame (PDE (2MiB))the bits at offset 12 to 62 give the 4KiB address of either a further table or the start of the physicalmemory frame. For the PDE (2MiB) bits 21 to 62 give the 2MiB address of the physical 2MiBframe.

01234567891011121314151617181920212223242526272829303132M-1M51526263

Ignored Address of PDPT Ignored CR3

Reserved Address of PD Ignored Reserved

PC

DP

WT

Res

erve

d

1 PDPTE (PD)

XD Reserved Address of PT Ignored 0

Ign

ored

Acc

esse

dP

CD

PW

TU

/SR

/W 1 PDE (PT)

XD Reserved Address of 2 MiB frame Reserved

PA

T Ignored G 1

Dir

tyA

cces

sed

PC

DP

WT

U/S

R/W 1 PDE (2MiB)

XD Reserved Address of 4 KiB frame Ignored G

PA

TD

irty

Acc

esse

dP

CD

PW

TU

/SR

/W 1 PTE (4KiB)

Figure 7.4: x86 PAE Paging structures

Again Windows NT does not seem to use 2MiB frames, at least we did not encounter such framesduring our analysis. However, the Windows Research Kernel source code references 2MiB framesfor PAE and IA32e Paging [104, miamd.h:2685]. The software PTEs for PAE Paging seem to bevirtually identical to the IA32e ones, which we detail in the next section.

91

7 Virtual memory analysis (on Windows NT)

7.3.2.3 IA32e Paging

Figure 7.5 lists the hardware PTEs that we encountered during our analysis of Windows NTrunning on x64 based hardware using IA32e Paging. Their definition is given strictly as per theIntel specification [80, Figure 4-11.]. The IA32e PTEs are virtually identical to the PAE PTEs.The only difference is that bits at offset 62 to 52 are ignored.

01234567891011121314151617181920212223242526272829303132M-1M51526263

Reserved Address of PML4 Ignored

PC

DP

WT

Ignored CR3

XD Ignored

Res

erve

d

Address of PDPT Ignored

Res

erve

dIg

nor

edA

PC

DP

WT

U/S

R/W 1 PML4E

XD Ignored

Res

erve

d

Address of PD Ignored 0

Ign

ored

AP

CD

PW

TU

/SR

/W 1 PDPTE (PD)

XD Ignored

Res

erve

d

Address of PT Ignored 0

Ign

ored

AP

CD

PW

TU

/SR

/W 1 PDE (PT)

XD Ignored

Res

erve

d

Address of 2 MiB frame Reserved

PA

T Ignored G 1 D AP

CD

PW

TU

/SR

/W 1 PDE (2MiB)

XD Ignored

Res

erve

d

Address of 4 KiB frame Ignored GP

AT

D AP

CD

PW

TU

/SR

/W 1 PTE (4KiB)

Figure 7.5: x64 IA32e Paging structures

Again Windows NT does not seem to utilize either the 1GiB nor the 2MiB frames. As statebefore, however, code for 2MiB frames is defined in the Windows Research Kernel as theMMPTE_HARDWARE_LARGEPAGE software PTE structure [104, miamd.h:2685].

Figure 7.6 on the facing page lists the software PTEs of Windows NT with regard to IA32e Pagingand, as already explained above, PAE Paging. The definition of the MMPTE_SOFTWARE,MMPTE_HARDWARE and MMPTE_HARDWARE_LARGEPAGE PTE was taken from theWindows Research Kernel source code [104, miamd.h].

As before the PageFileLow field gives the pagefile number. The PageFileHigh field gives the offsetinto the pagefile. Like the hardware PTEs this offset is a 4KiB offset. Hence the byte offset can beobtained by shifting the value of the PTE by 21 bits and then simply masking the last 12 bits. Asbefore not only memory frames can reside in the pagefile, but also PTEs themselves.

92

7.3 Windows NT x86 and x64 virtual memory overview

01234567891011121314151617181920212223242526272829303132M-1M51526263

reserved2 PageFrameNumber reserved1

PA

Tre

serv

ed0

Pro

toty

pe

Cop

yO

nWri

teG

lob

alL

arge

Pag

eD

irty

Acc

esse

dC

ach

eDis

able

Wri

teT

hro

ugh

Ow

ner

Wri

teV

alid MMPTE_HARDWARE. . .

. . . _LARGEPAGE

NoE

xec

ute

Sof

twar

eWsI

nd

ex

rese

rved

1

PageFrameNumber

rese

rved

0P

roto

typ

eC

opy

OnW

rite

Glo

bal

Lar

geP

age

Dir

tyA

cces

sed

Cac

heD

isab

leW

rite

Th

rou

ghO

wn

erW

rite

Val

id MMPTE_HARDWARE

PageFileHigh Reserved UsedPageTableEntries

Tra

nsi

tion

Pro

toty

pe

Protection

Pa

ge

Fil

eL

ow

Val

id MMPTE_SOFTWARE

Figure 7.6: Windows NT x64 paging structures

7.3.3 Virtual address translation

After the overview of available PTEs we now explain how they are used in Windows NT to translatevirtual to physical addresses.

7.3.3.1 Hardware

All hardware PTEs, i.e., PTEs that have the valid bit set, are interpreted by the hardware. For areference on how this is done, we recommend the Intel specification [80] which details the 32-bitPaging [80, Figure 4-2.], PAE Paging [80, Figure 4-5.] and IA32e Paging [80, Figure 4-8.] addresstranslation process. In any case, if the valid bit is set, the interpretation must strictly follow thehardware specification.

7.3.3.2 Software

The software PTEs can be divided into different types: Demand Zero, Pagefile, Transition, andPrototype PTEs. All Software PTEs are hardware and paging mode independent. Only theircorresponding fields, namely PageFileHigh, may reside at different bit offsets within the PTE.However, they are interpreted the same for every paging mode, as the memory management code ofthe NT kernel responsible for these software PTEs is already abstracted from the hardware PTEs[104, pagfault.c].

Demand Zero01234567891011

0 0 0 0 0 Demand Zero PTE

Figure 7.7: Windows NT Demand Zero PTE

A PTE with the Valid, Transition, Prototype, PageFileLow and PageFileHigh fields set to zero [104,miamd.h:2385 and mi386.h:2225] is a so-called Demand Zero PTE. It can be seen in Figure 7.7.Any request to this virtual address should be satisfied by a memory frame that is filled with zeros[104, MiResolveDemandZeroFault()].

93

7 Virtual memory analysis (on Windows NT)

Pagefile01234567891011

PageFileHigh 0 0

Pa

ge

Fil

eL

ow

0 Pagefile PTE

Figure 7.8: Windows NT Pagefile PTE

The Pagefile PTEs, as seen in Figure 7.8, or MMPTE_SOFTWARE PTEs, as they are referred toin the Windows Research Kernel source code, are the most interesting to this work. If the Valid,Prototype and Transition bits are zero and the PageFileHigh field is not zero the PTE referencesthe pagefile [104, MiResolvePageFileFault()] given by PageFileLow. The offset into the pagefileis given by PageFileHigh. Pagefile PTEs can also reference other PTEs, in which case the PTEthat is referenced is loaded from the pagefile. If a Pagefile PTE is encountered during analysis in aplace where a PDPTE (PDE), PDE (PT) or PTE (4KiB) page table is expected the PageFileHighfield gives the offset to the relevant paging table structure within the pagefile. The index in thispaging structure is taken from the virtual address bits the same way as for the hardware addresstranslation. Note that because Windows NT does not use 1GiB nor 2MiB paging structures the7th bit of the Pagefile PTE must be ignored. If bit 7 is one this does not indicate a large page. APTE loaded from the pagefile can then be interpreted like a PTE loaded from a physical memoryframe.

Transition01234567891011

1 0 0 Transistion PTE

Figure 7.9: Windows NT Transition PTE

A Transition PTE, as seen in Figure 7.9, is a PTE with the Valid and Prototype field set to zero,but the Transition field set to one [104, MiResolveTransitionFault()]. This PTE is used to marka page as being in transition, i.e., being in the process of being paged out to the pagefile. A PTEmarked as being in transition, hence, still resides at the physical memory frame it points to. Aswith Pagefile PTEs also Transition PTEs can also reference other PTEs, which can be interpretednormally.

Prototype01234567891011

1 0 Prototype PTE

Figure 7.10: Windows NT Prototype PTE

Prototype PTEs, as depicted in Figure 7.10, are used to facilitate shared memory and mapped files[104, MiResolveMappedFileFault()]. They have the Valid bit set to zero and the Prototype bitset to one [104, MiResolveProtoPteFault]. Even though these Prototype PTEs also constituteparts of the virtual address space we currently do not resolve them as we focus on reconstructingthe pagefile.

94

7.4 Acquisition

7.4 Acquisition

In this section, we provide a brief overview of the available acquisition methods with regard tophysical memory and pagefile. We will do so by summarizing existing research. We start withphysical memory acquisition.

7.4.1 Memory

Acquisition of the physical memory was already outlined in Section 4.4.4 on page 42. However, onemethod was not outlined before — Windows crash dumps.

7.4.1.1 Crash dumps

Crash dumps are a good way to obtain the system memory. They can be, appropriate systemconfiguration provided, triggered via keyboard input or by crashing the Windows NT kernel. Asof writing, a bug in Windows 7 allows the system to be crashed via a GPT partitioned storagemedium with the number of possible partition entries in the GPT header set to zero. This causes adivision by zero in the kernel and, on default system configuration, a core dump is written to disk.Because the operating system is stopped during the crash dump procedure the method has highatomicity [162, Fig. 5].The problem with this method, however, is the location on disk the core dump is written to. It iswritten to the pagefile, destroying it as a possible information source for virtual memory analysis.Another problem is caused by encryption. If the file system is encrypted the crash dump used to bedumped to disk in cleartext. However, starting from Windows Vista with Service Pack 1 (SP1) andWindows Server 2008, a disk encryption software can implement a Crash Dump Filter Driver whichallows encrypting the contents of crash dumps, as well as the hibernation file. Thus, rendering thismethod useless if software disk encryption is used.

7.4.2 Pagefile

In this section, we outline how the pagefile of Windows NT can be acquired either on a live systemor via dead analysis.

7.4.2.1 Dead acquisition

Acquiring the pagefile.sys via dead acquisition is trivial. If no disk encryption is used we cansimply shut down the computer or even just unplug the storage device the pagefile.sys is storedon from the target system. Next, we can mount the file system on the storage device and copy thepagefile.sys.In case disk encryption is used we must first obtain the encryption keys via either a cold boot,DMA attack or any other available means. Note that crash dumps can not be used for key recoveryas outlined in Section 7.4.1.1. Also, key recovery via software executed on the target system shouldbe avoided, because in such cases the pagefile.sys can be acquired live, as explained in the nextsection. The recovered encryption keys can be used to circumvent the disk encryption [72, 99]. Incase self-encrypting disks (SEDs) are used a warm-replug attack [109] can be used. In case, diskencryption is used, and a DMA attack is not available, or SEDs are used, care must be taken tonot lose the pagefile.sys, because neither the warm-replug attack on SEDs nor the cold bootattack are reversible. Hence, in such cases, a life acquisition is preferable, if available.

95

7 Virtual memory analysis (on Windows NT)

7.4.2.2 Live acquisition

Acquiring the pagefile on a live system is more complicated because, as already outlined inSection 7.3.1 on page 89, the Windwos NT pagefile is locked by the kernel against any ordinaryaccess during runtime. However, the pagefile can be acquired from the so-called Win32 DeviceNamespace, e.g., the extraction process of the pagefile.sys onto the removable drive mounted onvolume E using the Sleuthkit’s ifind and icat tools to access the C volume’s device namespace\\.\c: is outlined in Listing 7.4. In this example, 11163 is the $MFT entry number of thepagefile.sys.C:\> ifind .exe -n / pagefile .sys \\.\c:11163C:>icat.exe \\.\c: 11163 > E:\ pagefile .sys

Listing 7.4: Extracting the pagefile.sys with the Sleuthkit

Tools which are able to automatically copy the pagefile of a running system are: Disk Explorer,Forensic Toolkit, WinHex, Pagefile Collection Toolkit (PCT) [95], ntfscopy, icat, or FGET(Forenisc Get by HBGary Inc.), to name a few.

7.5 AnalysisOnce a physical memory dump and corresponding pagefile are acquired the process of reconstructioncan begin. In order to reconstruct a virtual address space of a process the process structures,namely the Directory Table Base, i.e., the pointer to the process’ page table root must be found.After this the virtual address space can be reconstructed by implementing the virtual addresstranslations as outlined in Section 7.3.3 on page 93. To this end, we implemented two kinds oftools. First, a tool that finds the _EPROCESS structures and extracting the DirectoryTableBasefrom them by carving the physical memory dump. Second, a tool that, given a physical memorydump, a pagefile copy, and a DirectoryTableBase value, reconstructs the virtual address spacedefined by the paging structure.

7.5.1 Finding DirectoryTableBase

The address of the root table of the paging structure governing the virtual address space of aprocess is stored in the processes _EPROCESS structure in a variable called DirectoryTableBase.To find this variable the _EPROCESS structures of the various Windows NT kernel versions can becarved from physical memory via a signature. _EPROCESS structures are, to our knowledge, notswapped out to the pagefile. Listing 7.5 shows the eight fields we found to be enough to build arobust signature by employing the constraints outlined in Listing 7.6 on the next page.lkd > dt nt! _EPROCESS

+0 x000 Pcb : _KPROCESS+0 x000 Header : _DISPATCHER_HEADER

+0 x000 Type : UChar+0 x002 Size : UChar+0 x003 Reserved2 : Pos 2, 4 Bits

+0 x028 DirectoryTableBase : Uint8B+0 x030 ThreadListHead : _LIST_ENTRY

+0 x000 Flink : Ptr64 _LIST_ENTRY+0 x008 Blink : Ptr64 _LIST_ENTRY

+0 x180 UniqueProcessId : Ptr64 Void+0 x2e0 ImageFileName : [15] UChar

Listing 7.5: _EPROCESS layout as per WinDbg

In Listing 7.6 on the facing page IS_PRINTABLE_ASCII_STRING() denotes a function that testswhether the string is composed of only printable ASCII characters. And with KERNEL_ADDRESSdenoting the start of the kernel space. This is 0x80000000 for 32-bit and 0x80000000000 for 64-bitsystems. Further DTB_ALIGNMENT is 0x1000, except for PAE systems, there it is 0x20. The valuefor SIZE is Windows NT version and build dependent. Size values for some systems are given inTable 7.1 on the next page.

96

7.5 Analysis

ThreadListHead . Flink >= KERNEL_ADDRESSThreadListHead . Blink >= KERNEL_ADDRESSDirectoryTableBase != 0DirectoryTableBase % DTB_ALIGMENT == 0Type == 0x03Size == SIZEFlags == 0x00Reserved2 == 0x00IS_PRINTABLE_ASCII_STRING ( ImageFileName )

Listing 7.6: _EPROCESS signature constraints

Windows NT Version SIZE

Windows 7 x86 7600 0x26Windows 7 x64 7600 0x58Windows 8.1 x86 9600 0x28Windows 8.1 x64 9600 0xb2Windows 10 x64 9841 0xb4

Table 7.1: Size value for signature.

The offsets of the quoted fields can be obtained via WinDbg by executing the commands outlinedin Listing 7.7.. sympath srv*. reloaddt nt! _EPROCESSdt nt! _KPROCESSdt nt! _DISPATCHER_HEADERdt nt! _LIST_ENTRY

Listing 7.7: Obtaining offset information for siganture via WinDbg

Please note that this signature may not be anti-forensic resistant, i.e., it may rely on values such asthe Size field, which is not used by the operating system and hence can be overwritten with othervalues by a rootkit or malware [35]. We used this signature for our evaluation only. We refer toDolan-Gavitt et al. [35] and Lee et al. [94] for anti-forensic resistant signature construction.

7.5.2 Reconstructing the virtual address spaceOnce the root of the paging table structure is found the virtual address space spanned by thatpaging structure can be reconstructed. To this end, the memory range from zero to the highestmemory address can be iterated and any present physical frame can be written out to a new file inorder to create a dump of the process’ virtual memory space. The address translation is performedas per Section 7.3.3 on page 93.

7.5.3 Analyzing the virtual address spaceOnce the virtual address space is reconstructed current methods to analyze the now flat processmemory space can be used. These methods include, but are not limited to, the following:

• File carving via foremost

• Keyword search in the process space via strings

• Encryption key search via aeskeyfind [71] or interrogate

• Disassemble the process’ code and data segments

While some of them may still not be very forensic savvy and accurate, such as file carving andstrings, they can now be used to extract full files and texts from editors, emails, messengers orvisited websites, even if such process memory was not paged or physically fragmented. Further, canany findings by these tools now be linked to the process they were found in, which can be linked tothe user owning the process. All of which was not possible previously.

97

7 Virtual memory analysis (on Windows NT)

7.6 EvaluationWe developed, tested and verified the correct working of our virtual address space extraction toolagainst the following versions of Windows NT:

• Windows 7 7600 x86 (with 32-bit Paging and/or PAE Paging)

• Windows 7 7600 x64 (with IA32e Paging)

• Windows 8.1 9600 x86 (with 32-bit Paging and/or PAE Paging)

• Windows 8.1 9600 x64 (with IA32e Paging)

• Windows 10 9841 x86 (with PAE Paging)

• Windows 10 9841 x64 (with IA32e Paging)

7.6.1 Problem cases of virtual memory analysisFor evaluation we consider four problem cases with regard to virtual memory analysis, as depictedin Figure 7.2 on the facing page:

1. Physical memory frames are fragmented but no frames are in the pagefile, as illustrated inFigure 7.2 on the next page:

• Naïve carving of the physical memory may not yield any results due to the fragmentation.• Memory analysis only considering physical memory can completely reconstruct the

virtual address space.• File carving applied to the pagefile can not yield any results, because no virtual page is

mapped to a pagefile frame.

2. All virtual memory pages are sequentially mapped into the pagefile, as shown in Figure 7.2on the facing page:

• Any physical memory analysis will not yield any results, because all virtual pages aremapped to pagefile frames.

• File carving applied to the pagefile will retrieve the content, because it is availablesequentially.

3. Physical memory frames only reside in the pagefile and are fragmented, as shown in Figure 7.2on the next page:

• Any physical memory analysis will not yield any results, because all virtual pages aremapped to pagefile frames.

• File carving applied to the pagefile may not yield any results due to the fragmentation.

4. Physical memory frames are scattered over physical memory and the pagefile. This isillustrated in Figure 7.2 on the facing page:

• Any method besides virtual memory analysis incorporating the pagefile may not yieldresults, with regard to an investigation, because neither the physical memory, nor thepagefile contain the complete mapping of the virtual pages. Hence, only a combinationof physical memory and pagefile analysis can provide a perfect reconstruction.

Only the presented virtual memory analysis approach incorporating the pagefile is able to perfectlyreconstruct the virtual address space in all of the four problem cases. In reality, we have foundproblem cases 1 and 4 to be most prevailing. We have only rarely encountered case 3. We havenever encountered case 2. However, close matches, where almost all virtual memory pages weresequentially mapped to pagefile frames, have been observed.

98

7.6Evaluation

Problem Case 1 Problem Case 2 Problem Case 3 Problem Case 4

Virtual Memory Physical Memory

Pagefile

Memory Carving

Pagefile Carving

Virtual MemoryAnalysis +Pagefile

?

Virtual MemoryAnalysis

Virtual Memory Physical Memory

Pagefile

Memory Carving

Pagefile Carving

Virtual MemoryAnalysis +Pagefile

Virtual MemoryAnalysis

Virtual Memory Physical Memory

Pagefile

Memory Carving

Pagefile Carving

Virtual MemoryAnalysis +Pagefile

Virtual MemoryAnalysis

?

Virtual Memory Physical Memory

Pagefile

Memory Carving

Pagefile Carving

Virtual MemoryAnalysis +Pagefile

Virtual MemoryAnalysis

?

?

?

Memory Carving Maybe No No MaybePagefile Carving No Yes Maybe MaybeVirtual Memory Yes No No MaybeVirtual Memory + Pagefile Yes Yes Yes Yes

Table 7.2: Problem cases of virtual memory analysis: Only one case can be perfectly solved by current memory analysis techniques.

99

7 Virtual memory analysis (on Windows NT)

7.6.2 Synthetic data

First, we evaluated our virtual address reconstruction with synthetic data. This data consistsof an allocation of crib pages, as outlined in Section 7.2.2 on page 87. After the ramwrite andswapforcer processes were started sync.exe from the Sysinternals Tools was started to increaseatomicity with regard to the pagefile written to disk. The physical RAM and pagefile were acquiredvia VirtualBox as outlined in Section 4.4.4.3 on page 43, i.e., the VM was first paused, then theRAM was acquired via the debugvm dumpguestcore command, after which the VM state wassaved, the hard disk cloned and the pagefile extracted via icat from the Sleuthkit.

Selected results can be seen in Table 7.3 on the next page. The table lists seven different datasetsobtained from different kernels with different paging. The different kernels and paging modesdemonstrate the correct functionality of our implementation for the various different Windows NTsystems. The table further lists the amount of crib data allocated. It then details how muchsequential crib data could be reconstructed with the four methods: physical memory carving,pagefile carving, classical memory analysis, i.e., reconstructing the virtual address space withoutincorporating the pagefile, and last but not least our proposed virtual memory analysis methodincorporating the pagefile. For each method, the length of reconstructable crib data at the start ofthe memory allocation and the longest overall crib data reconstructable was listed. An equal sign(“=”) before the longest reconstructable crib data listing denotes that the longest match was foundat the start of the memory allocation. This is important if file carving methods are considered,as these methods rely on file headers which are usually at the beginning of a file. For a perfectreconstruction both the reconstructable crib data at the start and the longest overall match shouldcoincide with the allocation size and the longest overall match must be at the start of the allocation.A dash (“-”) denotes that no specific crib frame could be found.

Dataset 1 was obtained from a system exhibiting problem case 1, i.e., all crib data was mappedinto physical memory. This can be seen from the fact that no crib frame was present in the pagefileat all. All crib data can be reconstructed only from physical memory.

Dataset 2 provides the transition state, where pages have started to be swapped out to the pagefile.However, because the pages were still in transition, refer Section 7.3.3.2 on page 94, their contentwas still present in physical memory and hence all crib data could be reconstructed using onlyphysical memory.

Datasets 3 to 6 provide problem cases of type 4, i.e., crib data is placed in both the physicalmemory and the pagefile. The various techniques yield unpredictable results depending on thecurrent fragmentation and scattering of the crib data. Only the proposed virtual memory analysisapproach is able to perfectly reconstruct the crib data for all datasets. Datasets 3 to 6 provide thetransition into problem cases 2 and 3, with the data that can be obtained via classical memoryanalysis not making use of the pagefile gradually declining from dataset 3 to 6.

Last, dataset 7 is the extreme problem case 2, in which classical memory analysis can not reconstructany data at all, because all crib pages have been swapped out to the pagefile. The fact that thenaïve memory carving method was still able to extract one 4KiB frame, can be attributed to thefact that one particular physical memory frame, which was already allocated to a different process,was not overwritten by the other process yet. We verified this hypothesis by tracing that particularmemory frame back to being part of the swapforcer process’ virtual address space. As statedearlier, we used the swapforcer process to swap as many crib pages as possible into the pagefile.This clearly shows the ill effects that incomplete analysis methods can have on the conclusions thata forensic analyst may draw. Here, the memory frame appeared to belong to the ramwrite process,while in reality it did not. Attributing evidence to a wrong process could mean attributing it to adifferent user. This ultimately could lead to wrong accusations against a person.

100

7.6Evaluation

Kernel Allocation Memory Carving [KiB] Pagefile Carving [KiB] Virtual Memory [KiB] Virtual Memory + Pagefile [KiB][Build (Paging)] [KiB] Start Longest Start Longest Start Longest Start Longest

1 7600 x64 (IA32e) 0x4000 0x8 = 0x8 - - 0x4000 = 0x4000 0x4000 = 0x40002 7600 x86 (PAE) 0x4000 0x4 0x8 - 0xd 0x4000 = 0x4000 0x4000 = 0x40003 9841 x64 (IA32e) 0x40000 - 0xc 0x10 0x28 - 0x3afbc 0x40000 = 0x400004 7600 x86 (32 Bit) 0x8000 - 0x8 0x18 0x38f8 - 0x2114 0x8000 = 0x80005 9600 x64 (IA32e) 0x10000 - 0x1c 0x1fe8 0x2800 - 0x8c 0x10000 = 0x100006 9600 x86 (PAE) 0x10000 - 0x4 0x74c 0x4000 - 0x24 0x10000 = 0x100007 7600 x64 (IA32e) 0x10000 - 0x4 0x13c 0x2c00 - - 0x10000 = 0x10000

Table 7.3: Results of reconstructing synthetic data

101

7Virtualm

emory

analysis(on

Window

sNT)

Physical Memory Pagefile Virtual Memory Pagefile and Virtual Memory Virtual Memory with PagefileFull Viewable Total Full Viewable Total Full Viewable Total Full Viewable Total Full Viewable Total0 0 269 0 ≈ 33 113 0 ≈ 135 454 0 ≈ 135 567 200 200 600

Table 7.4: Results of reconstructing synthetic data: Images carved out of the raw memory, pagefile or different memory address space reconstructions.

102

7.7 Conclusion and future work

7.6.3 Real life data

Besides the evaluation with synthetic data using crib pages, we also evaluated our approach againstreal life data. To this end, we acquired the memory and pagefile of a Windows 8.1 x64 systemwith 1024MiB RAM running on x64 based hardware, while an instance of Firefox in privatebrowsing mode was running. Firefox was used to open a prepared HTML web page with 200 JPEGimages embedded. The 200 JPEG images total over 1.2GiB. Each image was a high quality6000× 4000 pixel image from a DSLR. The data was acquired via WinPMEM and the Sleuthkit’s fcat.We then used our virtual memory analyzer to extract the virtual address space of the firefox.exeprocess. We then carved this address space with the Foremost file carver. We further repeated thecarving process on the raw physical memory image, the pagefile and the virtual memory addressspace only reconstructed from physical memory.The number of images each procedure could recover is listed in Table 7.4 on the preceding page.The “Full” column lists the image files that could be fully recovered, i.e., 6000× 4000 pixel imagesthat are not corrupted in any way. The “Viewable” column, on the other hand, lists distinct imagesthat were recognizable by visual inspection, these include corrupted and only partially recoveredimages, as well as embedded thumbnail images. Because the JPEGs used had two smaller thumbnailimages embedded the total number of JPEGs in the Firefox process is 600. Our method was ableto recover all of them. No broken images were recovered. Because no other JPEG files were openedby Firefox, no additional images were recovered as well. The other methods could only recover thesmaller embedded thumbnail images but no full 6000× 4000 pixel image.This evaluation using real life data underlines the practicability of our results. The fact that currentmemory analysis techniques were only able to retrieve viewable content for 135 of the 200 imagesand were unable to recover the full 6000 × 4000 pixel images, while we are able to reconstruct allimages, further punctuates the practical importance of our results.

7.7 Conclusion and future work

In all evaluated cases, we performed better or at least on par with current memory analysistechniques. Further has our gray-box analysis approach quickly exposed critical errors during thedevelopment of our tools. Hence we expect this technique to be able to successively improve currentand future memory analysis software with regard to correctness and completeness, as well.As with all research, this work only presents a small part of what can be done. Future research willbe needed on the following topics.While the Windows NT family of operating system is most prevailing, other operating systems needto be considered as well. Our analysis approach can, as already stated in Section 7.2.3 on page 88,be used on the Linux operating system as well, but also other operating systems such as Apple’sMac OS or the BSD family of operating systems should be evaluated.To develop correct reconstruction we used virtual machines to acquire the physical memory andcorresponding pagefiles of systems with ultimate atomicity. While this provides, without a doubt,the best results, it is not always possible. Hence, better acquisition methods acquiring both physicalmemory and the pagefile at the same time with high atomicity must be investigated. Also, theeffects of virtual address reconstruction using inconsistent physical memory and pagefile dumpsmust be researched. Our preliminary findings indicate that even though a virtual address spacecan be reconstructed from inconsistent physical memory and pagefile dumps, the reconstructedaddress space inevitably contains incorrect, i.e., outdated, memory pages. But the impact of thesereconstruction errors is not known yet.The virtual memory analysis needs to be extended beyond the pagefile. To this end, PrototypePTEs of shared memory and mapped files [160] should be considered. Relevant code can befound in the Windows NT Research Kernel source code [104]. The relevant parts are the codehandling software page faults due to the Prototype PTEs [104, MiResolveProtoPteFault() andMiResolveMappedFileFault()].

103

7 Virtual memory analysis (on Windows NT)

As shown in other research [79], pagefiles can be compressed and also encrypted. Hence, decom-pression and decryption procedures may need to be integrated into future virtual memory analysisprocedures that want to incorporate compressed and/or encrypted pagefiles.

Last but not least, best practice approaches with regard to combined pagefile and memory acqui-sition must be researched. For our tests, we always synced the disks of the system, because weassume it yields higher atomicity. However, we have not evaluated what consequences this couldhave, e.g. old data, which may contain relevant evidence, could be overwritten by the sync operation.

Summarizing this chapter it can be said that even though virtual memory analysis is an importantfield, it is, as outlined by our future work list, still an emerging field, that still has problems. Wesolved one blind spot, namely incorporating the pagefile. The generic research method we usedis expected to be deployed against other operating systems as well as being used to evaluate thecorrectness of other memory forensic tools.

104

8 Conclusion and future workIn this thesis, we first outlined forensics and anti-forensics, both in the classical physical realm aswell as the digital realm. We defined the main goal of anti-forensics, i.e., impairing the quality of aforensic analysis, and motivated it with practical examples. After this we tackled anti-forensic androotkit problems.First, we investigated how data can best be acquired from hard drives that are potentially com-promised by a firmware rootkit. To this end, we first outlined the threat of hard drive firmwarerootkits to forensic analysis. We then provided a procedure to detect and subvert hard disk drivefirmware bootkits, as publicly published. We further outlined potential avenues to detect harddrive firmware rootkits nested deeper within the hard disk drive’s so-called Service Area, a specialstorage on the magnetic platter reserved for use by the firmware. We, therefore, showed that it ispossible and feasible to counter anti-forensic measures manifested as compromised hard disk drivefirmware. Because those hard disk drive firmware rootkits are undetectable otherwise, we urgethe forensic community to adopt the techniques we outlined. We also advise that our introducedtechniques are developed further and extended to not just include SSDs but also devices such asnetwork cards and other peripherals that could harbor rootkits.After we addressed the acquisition of persistent data storage in form of hard disk drives, we shiftedtowards acquisition and later analysis of volatile storage, in form of RAM. To this end, we firstevaluated the quality, both with regard to atomicity and integrity as well as anti-forensic resistance,of different memory acquisition techniques with our newly developed black-box analysis technique.This resulted in the cold boot attack proving to be the most favorable memory acquisition techniques.Because we open sourced our black-box technique we urge other forensic scientists in the communityto use it to further test additional memory analysis tools to determine, for themselves, whichacquisition tool to use. Even though we determined that the cold boot attack is the most favorable,specific circumstances may make it inapplicable, e.g., the system must not be rebooted. Hence, itis important for forensic analysts to know their options as well as each option’s limits with regardto atomicity, integrity, and anti-forensic resilience.We, therefore, researched the cold boot attack in great detail. First, experimentally confirming thatcooling the RAM modules prolongs the remanence effect considerably. Then proving experimentallythat transplanting RAM modules from one system to another is possible. We further addressed theissue of scrambling in modern DDR3 technology as well as other proposed countermeasures, suchas BIOS passwords and temperature detection. With this we showed that cold boot attacks arean adequate anti-forensic resistant memory acquisition technique, because the are hard to defend,and once the system is cold-booted, i.e., rebooted, any anti-forensic code running on the system isstopped immediately and hence prevented from interfering with the memory acquisition. Whilewe showed the cold boot attack to be feasible and practical on current RAM technology we alsoshowed that memory encryption techniques may render it unusable, in which case we refer to ourevaluation of memory acquisition techniques, from which a different suitable acquisition techniquecan be selected by forensic analysts. It is also important for judges to understand the idea behindthe cold boot attack, because in some circumstances a system needs to be substantially altered, e.g.,RAM frozen and transplanted into a different system, which is contrary to the long-standing statusquo of digital forensics to not tamper with evidence. Here, the system is, however, not tamperedwith per se. The modifications are rather necessary to obtain the evidence. This can be comparedto an analysis in forensic chemistry in which evidence is often dissolved to obtain the in it containedinformation, such as its composition — but this dissolving inadvertently tampers and even destroysthe evidence in its material form. In classical forensic science this is acceptable, however, in digitalforensics, such practice is often still frowned upon. But we would like to argue that also in thedigital domain it can be necessary to modify the evidence in its material form in order to obtaininformation from it.

105

8 Conclusion and future work

After we outlined the acquisition of evidence, we addressed the analysis. To this end, we firstrevisited the theory of data analysis, namely the concept of essential data in forensic analysisas coined by [18]. After extending Carrier’s theories, we verified both the original theories andour extensions in practical experiments. We further argued that the essential data concept canbe used to build a trust hierarchy, from which we concluded that anti-forensic resistant analysismethods should only rely on what we call strictly essential, i.e., trusted, data. In case this can notbe done, the analysis tool should at least notify the investigator that the conclusion was drawnfrom potentially manipulated data. Here it is also important that judges understand the problemof anti-forensic manipulations and work needs to be done to clearly assess the likelihood of suchmanipulations.Last but not least, we tackled a problem in forensic memory analysis that had been unsolved fora long time. A blind spot where data and thus potential evidence in unmapped memory pages,i.e., pages swapped out onto persistent storage, were not examined by current state-of-the-artdigital forensic virtual memory analysis tools. We fixed this by analyzing the Windows NT virtualmemory paging via our conceived gray-box analysis method. To this end, we placed traceabledata into virtual memory and forced it into both the physical RAM as well as being swappedout to the pagefile.sys stored on persistent storage. We were thus able to reverse engineer thecomplete virtual address mapping, including the non-mapped pagefile. With our evaluation, wefurther showed that only the presented analysis method considers and finds all available evidence.Other analysis methods leave blind spots which could be used by anti-forensic tools to hide evidence.

Even though our contributions to the field of anti-forensic and rootkit resistant digital forensicprocedures are plenty, they are still not enough. Many anti-forensic threats may exist that havenot even been discovered yet. For example, to our knowledge we are the first within the forensiccommunity to raise concerns with regard to firmware rootkits on hard disk drives. However, theidea and feasibility of such firmware rootkits have been demonstrated since 2013. And its potentialexisted since the inception of hard disk drives with upgradeable firmware — which to our knowledgehas always been there on modern hard disk drives. Even before hard disks, firmware rootkitsfor network cards have been proposed by Delugré [29]. We would like to argue that our outlinedmethods for hard disk rootkits, especially verifying the EEPROM contents, is also applicable tonetwork cards. Another possibility for rootkits is within the so-called baseband processor [30], aspecial processor separate from the application processor on which the regular operating systemresides. Here, our introduced JTAG methods are applicable.

Another concern is that existing anti-forensic resistant methods are, apparently, not applied inpractice. For example, the fact that cold boot attacks against DDR3 memory are not possibleanymore due to memory scrambling did not seem to resonate in the forensic community eventhough we have already published our findings and made freely available online in 2013. In fact, in2015 results have been published asserting the opposite. Lindenlauf et al. [97] published a studyon the feasibility of cold boot attacks even against DDR3 memory [97], completely ignoring thefact that DDR3 memory is scrambled. Their results have only been possible because the particularsystem configuration tested used constant scrambling. Had the cold boot attack actually been usedin practice this fact would have spread more widely. We, therefore, urge forensic practitioners to atleast familiarize with such anti-forensic resistant acquisition and analysis methods, so they can, inselected cases, apply them. Of course, we would favor anti-forensic resistant forensic methods tobe applied always, but we do understand that without widespread tool support for such methodsit is an additional burden on the forensic investigator, which can often not be fulfilled because oftime or budget constraints. We, therefore, also urge tool developers to adopt and preferentiallyimplement anti-forensic resistant acquisition and analysis methods.

106

The answer to whether we found the digital equivalent of luminol, as proposed in the introductionof this thesis, can not be answered yet. However, what can be assured is that blood detectionvia luminol has and still is constantly improved [136, 8] and scientifically scrutinized [27]. Theuse of luminol has matured. The same constant improvements and scrutiny must be applied tothe methods introduced in this thesis. So they can mature. New technologies must be evaluatedfor their anti-forensic potential and new ways must be endeavored to undermine this anti-forensicpotential.

But possibly the biggest problem with rootkits and anti-forensic methods is that if they are notactively sought out, they pass undetected — like blood which was wiped from a crime scene. Afterall, this is their purpose — manipulate, hide evidence and presenting a false reality, without beingdetected. We must, therefore, not let ourselves be stopped by deceptions for otherwise we maybe trapped in undesirable circumstances [166]. Hence, it must be made best practice to expectanti-forensics and be prepared accordingly. With this thesis, we hope to help prepare forensicinvestigators around the world for the specific addressed anti-forensic threats and, therefore, takethe first step in leaving the age of anti-forensic innocence.

107

Bibliography[1] Pietro Albano, Aniello Castiglione, Giuseppe Cattaneo, and Alfredo De Santis. A novel

anti-forensics technique for the android OS. In 2011 International Conference on Broadband,Wireless Computing, Communication and Applications, BWCCA 2011, Barcelona, Spain,October 26-28, 2011, pages 380–385, 2011. doi: 10.1109/BWCCA.2011.62. URL http://dx.doi.org/10.1109/BWCCA.2011.62.

[2] Martin R. Albrecht and Carlos Cid. Cold boot key recovery by solving polynomial systemswith noise. In Applied Cryptography and Network Security - 9th International Conference,ACNS 2011, Nerja, Spain, June 7-10, 2011. Proceedings, pages 57–72, 2011. doi: 10.1007/978-3-642-21554-4_4. URL http://dx.doi.org/10.1007/978-3-642-21554-4_4.

[3] Erwin Alles, Zeno Geradts, and Cor J. Veenman. Source camera identification for lowresolution heavily compressed images. In Selected Papers of the Sixth International Conferenceon Computational Sciences and Its Applications, ICCSA ’08, Perugia, Italy, June 30 - July3, 2008, pages 557–567, 2008. doi: 10.1109/ICCSA.2008.18. URL http://dx.doi.org/10.1109/ICCSA.2008.18.

[4] Philip Anderson, Maximillian Dornseif, Felix Freiling, Thorsten Holz, Alastair Irons,Christopher Laing, and Martin Mink. A comparative study of teaching forensics at auniversity degree level. In IT-Incidents Management & IT-Forensics - IMF 2006, Con-ference Proceedings, October, 18th-19th, 2006, Stuttgart., pages 116–127, 2006. URLhttp://subs.emis.de/LNI/Proceedings/Proceedings97/article4931.html.

[5] Ross Anderson and Markus Kuhn. Tamper resistance: A cautionary note. In Proceedings ofthe 2Nd Conference on Proceedings of the Second USENIX Workshop on Electronic Commerce- Volume 2, WOEC’96, pages 1–1, Berkeley, CA, USA, 1996. USENIX Association. URLhttp://dl.acm.org/citation.cfm?id=1267167.1267168.

[6] Shiva Azadegan, Wei Yu, Hui Liu, Ali Sistani, and Subrata Acharya. Novel anti-forensicsapproaches for smart phones. In 45th Hawaii International International Conference onSystems Science (HICSS-45 2012), Proceedings, 4-7 January 2012, Grand Wailea, Maui, HI,USA, pages 5424–5431, 2012. doi: 10.1109/HICSS.2012.452. URL http://dx.doi.org/10.1109/HICSS.2012.452.

[7] Harald Baier and Julian Knauer. AFAUC - anti-forensics of storage devices by alternativeuse of communication channels. In Eighth International Conference on IT Security IncidentManagement & IT Forensics, IMF 2014, Münster, Germany, May 12-14, 2014, pages 14–26,2014. doi: 10.1109/IMF.2014.11. URL http://dx.doi.org/10.1109/IMF.2014.11.

[8] Filippo Barni, Simon W. Lewis, Andrea Berti, Gordon M. Miskelly, and Giampietro Lago.Forensic application of the luminol reaction as a presumptive test for latent blood detection. Ta-lanta, 72(3):896 – 913, 2007. ISSN 0039-9140. doi: http://dx.doi.org/10.1016/j.talanta.2006.12.045. URL http://www.sciencedirect.com/science/article/pii/S0039914007000082.

[9] Mauro Barni and Benedetta Tondi. Optimum forensic and counter-forensic strategies forsource identification with training data. In 2012 IEEE International Workshop on InformationForensics and Security, WIFS 2012, Costa Adeje, Tenerife, Spain, December 2-5, 2012, pages199–204, 2012. doi: 10.1109/WIFS.2012.6412649. URL http://dx.doi.org/10.1109/WIFS.2012.6412649.

109

Bibliography

[10] Johannes Bauer, Michael Gruhn, and Felix Freiling. Lest we forget: Cold-boot attacks onscrambled DDR3 memory. Digital Investigation, 16, Supplement:S65–S74, 2016. ISSN 1742-2876. doi: 10.1016/j.diin.2016.01.009. URL http://dx.doi.org/10.1016/j.diin.2016.01.009. Proceedings of the Third Annual DFRWS Europe.

[11] Michael Becher, Maximillian Dornseif, and Christian Klein. FireWire: all your memoryare belong to us. Talk at CanSecWest (slides: https://cansecwest.com/core05/2005-firewire-cansecwest.pdf), 2005.

[12] Hal Berghel. Hiding data, forensics, and anti-forensics. Communications of the ACM, 50(4):15–20, 2007. doi: 10.1145/1232743.1232761. URL http://doi.acm.org/10.1145/1232743.1232761.

[13] Ariel Berkman. Hiding data in hard-drive’s service areas. Paper published via fulldisclo-sure@seclists.org (paper: http://www.recover.co.il/SA-cover/SA-cover.pdf), 2013.

[14] Erik-Oliver Blass and William Robertson. TRESOR-HUNT: attacking CPU-bound encryption.In 28th Annual Computer Security Applications Conference, ACSAC 2012, Orlando, FL,USA, 3-7 December 2012, pages 71–78, 2012. doi: 10.1145/2420950.2420961. URL http://doi.acm.org/10.1145/2420950.2420961.

[15] Rainer Böhme and Matthias Kirchner. Counter-Forensics: Attacking Image Forensics, pages327–366. Springer New York, New York, NY, 2013. ISBN 978-1-4614-0757-7. doi: 10.1007/978-1-4614-0757-7_12. URL http://dx.doi.org/10.1007/978-1-4614-0757-7_12.

[16] Dominik Brodowski, Andreas Dewald, Felix Freiling, Steve Kovács, and Martin Rieger.Drei Jahre Master Online Digitale Forensik: Ergebnisse und Erfahrungen. In Sicherheit2014: Sicherheit, Schutz und Zuverlässigkeit, Beiträge der 7. Jahrestagung des FachbereichsSicherheit der Gesellschaft für Informatik e.V. (GI), 19.-21. März 2014, Wien, Österre-ich, pages 391–405, 2014. URL http://subs.emis.de/LNI/Proceedings/Proceedings228/article29.html.

[17] Jamie Butler. DKOM (direct kernel object manipulation). Talk at Black Hat USA (video:https://www.youtube.com/watch?v=1Ie20b5IGgY), 2004.

[18] Brian D. Carrier. File System Forensic Analysis. Addison-Wesley Professional, 2005. ISBN0321268172.

[19] Brian D. Carrier and Joe Grand. A hardware-based memory acquisition procedure for digitalinvestigations. Digital Investigation, 1(1):50–60, 2004. doi: 10.1016/j.diin.2003.12.001. URLhttp://dx.doi.org/10.1016/j.diin.2003.12.001.

[20] Eoghan Casey. Digital Evidence and Computer Crime: Forensic Science, Computers and theInternet. Academic Press, 2004. ISBN 9780121631048.

[21] Ellick Chan, Jeffrey C. Carlyle, Francis M. David, Reza Farivar, and Roy H. Campbell.Bootjacker: compromising computers using forced restarts. In Proceedings of the 2008 ACMConference on Computer and Communications Security, CCS 2008, Alexandria, Virginia,USA, October 27-31, 2008, pages 555–564, 2008. doi: 10.1145/1455770.1455840. URLhttp://doi.acm.org/10.1145/1455770.1455840.

[22] Ellick Chan, Shivaram Venkataraman, Francis M. David, Amey Chaugule, and Roy H.Campbell. Forenscope: a framework for live forensics. In Twenty-Sixth Annual ComputerSecurity Applications Conference, ACSAC 2010, Austin, Texas, USA, 6-10 December 2010,pages 307–316, 2010. doi: 10.1145/1920261.1920307. URL http://doi.acm.org/10.1145/1920261.1920307.

[23] Rong-Jian Chen, Shi-Jinn Horng, and Po-Hsian Huang. Anti-forensic steganography usingmulti-bit MER with flexible bit location. IJAHUC, 18(1/2):54–66, 2015. doi: 10.1504/IJAHUC.2015.067788. URL http://dx.doi.org/10.1504/IJAHUC.2015.067788.

110

Bibliography

[24] Philip A. Collier and B. J. Spaul. A forensic methodology for countering computer crime.Artificial Intelligence Review, 6(2):203–215, 1992. doi: 10.1007/BF00150234. URL http://dx.doi.org/10.1007/BF00150234.

[25] Kevin Conlan, Ibrahim Baggili, and Frank Breitinger. Anti-forensics: Furthering digitalforensic science through a new extended, granular taxonomy. Digital Investigation, 18,Supplement:S66 – S75, 2016. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2016.04.006. URL http://www.sciencedirect.com/science/article/pii/S1742287616300378.

[26] CRC Industries Deutschland GmbH. TECHNISCHES MERKBLATT – KÄLTE 75 SUPER– Ref.: 20848. Datasheet: http://www.crcind.com/wwwcrc/tds/TKC4%20FREEZE75S.PDF,2003.

[27] Jonathan I. Creamer, Terence I. Quickenden, Leah B. Crichton, Patrick Robertson, andRasha A. Ruhayel. Attempted cleaning of bloodstains and its effect on the forensic luminoltest. Luminescence, 20(6):411–413, 2005. ISSN 1522-7243. doi: 10.1002/bio.865. URLhttp://dx.doi.org/10.1002/bio.865.

[28] Kamal Dahbur and Bassil Mohammad. The anti-forensics challenge. In Proceedings of the2nd International Conference on Intelligent Semantic Web-Services and Applications, ISWSA2011, Amman, Jordan, April 18-20, 2011, page 14, 2011. doi: 10.1145/1980822.1980836. URLhttp://doi.acm.org/10.1145/1980822.1980836.

[29] Guillaume Delugré. How to develop a rootkit for Broadcom NetExtreme network cards.Talk at REcon (slides: http://esec-lab.sogeti.com/static/publications/11-recon-nicreverse_slides.pdf), 2011.

[30] Guillaume Delugré. Reverse engineering a Qualcomm baseband. Talk at the 28th Chaos Com-munication Congress (28C3) (slides: https://events.ccc.de/congress/2011/Fahrplan/attachments/2022_11-ccc-qcombbdbg.pdf), 2012.

[31] Andreas Dewald and Felix Freiling. From computer forensics to forensic computing: Investi-gators investigate, scientists associate. Technical Report CS-2014-04, Department Informatik,Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU), 2014.

[32] Andreas Dewald, Felix Freiling, Michael Gruhn, and Christian Riess. Forensische Informatik.Books on Demand, Norderstedt, 2nd edition, 2015. ISBN 978-3-8423-7947-3.

[33] Alessandro Distefano, Gianluigi Me, and Francesco Pace. Android anti-forensics througha local paradigm. Digital Investigation, 7, Supplement:S83 – S94, 2010. ISSN 1742-2876.doi: http://dx.doi.org/10.1016/j.diin.2010.05.011. URL http://www.sciencedirect.com/science/article/pii/S1742287610000381. The Proceedings of the Tenth Annual DFRWSConference.

[34] Brendan Dolan-Gavitt. The VAD tree: A process-eye view of physical memory. Digi-tal Investigation, 4, Supplement:62 – 64, 2007. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2007.06.008. URL http://www.sciencedirect.com/science/article/pii/S1742287607000503.

[35] Brendan Dolan-Gavitt, Abhinav Srivastava, Patrick Traynor, and Jonathon Giffin. RobustSignatures for Kernel Data Structures. In Proceedings of the 16th ACM Conference onComputer and Communications Security, CCS ’09, pages 566–577, New York, NY, USA, 2009.ACM. ISBN 978-1-60558-894-0. doi: 10.1145/1653662.1653730. URL http://doi.acm.org/10.1145/1653662.1653730.

[36] Jeroen “sprite_tm” Domburg. Sprites mods – hard disk hacking. Website: https://spritesmods.com/?art=hddhack, 2013.

[37] Jeroen “sprite_tm” Domburg. Hard Disks: More than just block devices. Talk at OHM(video: https://www.youtube.com/watch?v=0Da6OARhgXk), 2013.

111

Bibliography

[38] Christian D’Orazio, Aswami Ariffin, and Kim-Kwang Raymond Choo. iOS anti-forensics:How can we securely conceal, delete and insert data? In 47th Hawaii International Conferenceon System Sciences, HICSS 2014, Waikoloa, HI, USA, January 6-9, 2014, pages 4838–4847,2014. doi: 10.1109/HICSS.2014.594. URL http://dx.doi.org/10.1109/HICSS.2014.594.

[39] EC-Council. Computer Forensics: Investigation Procedures and Response (CHFI). CengageLearning, 2nd edition, 2016. ISBN 978-1305883475.

[40] M. C. Falconer, C. P. Mozak, and A. J. Norman. Suppressing power supply noise using datascrambling in double data rate memory systems, August 6 2013. URL https://www.google.com/patents/US8503678. US Patent 8,503,678.

[41] Wei Fan, Kai Wang, François Cayre, and Zhang Xiong. JPEG anti-forensics using non-parametric DCT quantization noise estimation and natural image statistics. In ACMInformation Hiding and Multimedia Security Workshop, IH&MMSec ’13, Montpellier,France, June 17-19, 2013, pages 117–122, 2013. doi: 10.1145/2482513.2482536. URLhttp://doi.acm.org/10.1145/2482513.2482536.

[42] Wei Fan, Kai Wang, François Cayre, and Zhang Xiong. A variational approach to JPEGanti-forensics. In IEEE International Conference on Acoustics, Speech and Signal Processing,ICASSP 2013, Vancouver, BC, Canada, May 26-31, 2013, pages 3058–3062, 2013. doi:10.1109/ICASSP.2013.6638220. URL http://dx.doi.org/10.1109/ICASSP.2013.6638220.

[43] Wei Fan, Kai Wang, François Cayre, and Zhang Xiong. JPEG anti-forensics with improvedtradeoff between forensic undetectability and image quality. IEEE Transactions InformationForensics and Security, 9(8):1211–1226, 2014. doi: 10.1109/TIFS.2014.2317949. URL http://dx.doi.org/10.1109/TIFS.2014.2317949.

[44] Wei Fan, Kai Wang, François Cayre, and Zhang Xiong. Median filtered image qualityenhancement and anti-forensics via variational deconvolution. IEEE Trans. InformationForensics and Security, 10(5):1076–1091, 2015. doi: 10.1109/TIFS.2015.2398362. URLhttp://dx.doi.org/10.1109/TIFS.2015.2398362.

[45] Houda Ferradi, Rémi Géraud, David Naccache, and Assia Tria. When organized crimeapplies academic results: a forensic analysis of an in-card listening device. J. CryptographicEngineering, 6(1):49–59, 2016. doi: 10.1007/s13389-015-0112-3. URL http://dx.doi.org/10.1007/s13389-015-0112-3.

[46] Joe FitzPatrick and Miles Crabill. NSA playset: PCIe. Talk at DEF CON 22 (slides:https://www.defcon.org/images/defcon-22/dc-22-presentations/Fitzpatrick-Crabill/DEFCON-22-Joe-FitzPatrick-Miles-Crabill-NSA-Playset-PCIe.pdf video:https://www.youtube.com/watch?v=OD2Wxe4RLeU), 2014.

[47] Marco Fontani, Alessandro Bonchi, Alessandro Piva, and Mauro Barni. Countering anti-forensics by means of data fusion. In Media Watermarking, Security, and Forensics 2014,San Francisco, CA, USA, February 2, 2014, Proceedings, page 90280Z, 2014. doi: 10.1117/12.2039569. URL http://dx.doi.org/10.1117/12.2039569.

[48] Dario Forte. Dealing with forensic software vulnerabilities: is anti-forensics a real danger?Network Security, 2008(12):18 – 20, 2008. ISSN 1353-4858. doi: http://dx.doi.org/10.1016/S1353-4858(08)70143-0. URL http://www.sciencedirect.com/science/article/pii/S1353485808701430.

[49] Dario Forte and Richard Power. A tour through the realm of anti-forensics. ComputerFraud & Security, 2007(6):18 – 20, 2007. ISSN 1361-3723. doi: http://dx.doi.org/10.1016/S1361-3723(07)70079-9. URL http://www.sciencedirect.com/science/article/pii/S1361372307700799.

112

Bibliography

[50] Felix Freiling and Michael Gruhn. What is essential data in digital forensic analysis? InNinth International Conference on IT Security Incident Management & IT Forensics, IMF2015, Magdeburg, Germany, May 18-20, 2015, pages 40–48, 2015. doi: 10.1109/IMF.2015.20.URL http://dx.doi.org/10.1109/IMF.2015.20.

[51] Felix Freiling, Jan Schuhr, and Michael Gruhn. What is essential data in digital forensicanalysis? it - Information Technology, 57(6):376–383, 2015. URL http://www.degruyter.com/view/j/itit.2015.57.issue-6/itit-2015-0016/itit-2015-0016.xml.

[52] Simson Garfinkel. Anti-forensics: Techniques, detection and countermeasures. In 2ndInternational Conference on i-Warfare and Security, page 77, 2007.

[53] Simson Garfinkel. Digital forensics research: The next 10 years. Digital Investigation, 7,Supplement:S64 – S73, 2010. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2010.05.009. URL http://www.sciencedirect.com/science/article/pii/S1742287610000368.The Proceedings of the Tenth Annual DFRWS Conference.

[54] Behrad Garmany and Tilo Müller. PRIME: private RSA infrastructure for memory-lessencryption. In Annual Computer Security Applications Conference, ACSAC ’13, New Orleans,LA, USA, December 9-13, 2013, pages 149–158, 2013. doi: 10.1145/2523649.2523656. URLhttp://doi.acm.org/10.1145/2523649.2523656.

[55] Matthew Geiger. Evaluating commercial counter-forensic tools. In Refereed Proceedings ofthe 5th Annual Digital Forensic Research Workshop, DFRWS 2005, Astor Crowne Plaza, NewOrleans, Louisiana, USA, August 17-19, 2005, 2005. URL http://www.dfrws.org/2005/proceedings/geiger_couterforensics.pdf.

[56] Matthew Geiger. Counter-forensic tools: Analysis and data recovery. In 18th AnnualFIRST Conference, Maltimore, Maryland, pages 25–30, 2006. URL https://www.first.org/conference/2006/papers/geiger-matthew-papers.pdf.

[57] Matthew Geiger and Lorrie Faith Cranor. Scrubbing stubborn data: An evaluation of counter-forensic privacy tools. IEEE Security & Privacy, 4(5):16–25, 2006. doi: 10.1109/MSP.2006.132.URL http://dx.doi.org/10.1109/MSP.2006.132.

[58] Zeno Geradts, Jurrien Bijhold, Martijn Kieft, Kenji Kurosawa, Kenro Kuroki, and NaokiSaitoh. Methods for identification of images acquired with digital cameras. Proc. SPIE, 4232:505–512, 2001. doi: 10.1117/12.417569. URL http://dx.doi.org/10.1117/12.417569.

[59] Thomas Gloe, Matthias Kirchner, Antje Winkler, and Rainer Böhme. Can we trust digitalimage forensics? In Proceedings of the 15th International Conference on Multimedia 2007,Augsburg, Germany, September 24-29, 2007, pages 78–86, 2007. doi: 10.1145/1291233.1291252.URL http://doi.acm.org/10.1145/1291233.1291252.

[60] Miroslav Goljan, Jessica J. Fridrich, and Mo Chen. Sensor noise camera identification:countering counter-forensics. In Media Forensics and Security II, part of the IS&T-SPIEElectronic Imaging Symposium, San Jose, CA, USA, January 18-20, 2010, Proceedings, page75410S, 2010. doi: 10.1117/12.839055. URL http://dx.doi.org/10.1117/12.839055.

[61] Travis Goodspeed. Active disk antiforensics and hard disk backdoors. Talk at 0x07 Sec-TConference (video: https://www.youtube.com/watch?v=8Zpb34Qf0NY), 2014.

[62] Johannes Götzfried and Tilo Müller. ARMORED: cpu-bound encryption for android-drivenARM devices. In 2013 International Conference on Availability, Reliability and Security,ARES 2013, Regensburg, Germany, September 2-6, 2013, pages 161–168, 2013. doi: 10.1109/ARES.2013.23. URL http://dx.doi.org/10.1109/ARES.2013.23.

[63] Johannes Götzfried, Tilo Müller, Gabor Drescher, Stefan Nürnberger, and Michael Backes.Ramcrypt: Kernel-based address space encryption for user-mode processes. In Proceedings ofthe 11th ACM on Asia Conference on Computer and Communications Security, AsiaCCS 2016,Xi’an, China, May 30 - June 3, 2016, pages 919–924, 2016. doi: 10.1145/2897845.2897924.URL http://doi.acm.org/10.1145/2897845.2897924.

113

Bibliography

[64] Hans Gross and Friedrich Geerdes. Handbuch der Kriminalistik, volume 2. Pawlak, 1985.ISBN 9783881992640.

[65] Michael Gruhn. Windows NT pagefile.sys virtual memory analysis. In Ninth InternationalConference on IT Security Incident Management & IT Forensics, IMF 2015, Magdeburg,Germany, May 18-20, 2015, pages 3–18, 2015. doi: 10.1109/IMF.2015.10. URL http://dx.doi.org/10.1109/IMF.2015.10.

[66] Michael Gruhn and Felix Freiling. Evaluating atomicity, and integrity of correct memoryacquisition methods. Digital Investigation, 16, Supplement:S1 – S10, 2016. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2016.01.003. URL http://www.sciencedirect.com/science/article/pii/S1742287616000049. Proceedings of the Third Annual DFRWSEurope.

[67] Michael Gruhn and Tilo Müller. On the practicability of cold boot attacks. In 2013International Conference on Availability, Reliability and Security, ARES 2013, Regensburg,Germany, September 2-6, 2013, pages 390–397, 2013. doi: 10.1109/ARES.2013.52. URLhttp://dx.doi.org/10.1109/ARES.2013.52.

[68] Le Guan, Jingqiang Lin, Bo Luo, and Jiwu Jing. Copker: Computing with private keys withoutRAM. In 21st Annual Network and Distributed System Security Symposium, NDSS 2014, SanDiego, California, USA, February 23-26, 2014, 2014. URL http://www.internetsociety.org/doc/copker-computing-private-keys-without-ram.

[69] Mayank R. Gupta, Michael D. Hoeschele, and Marcus K. Rogers. Hidden disk areas: HPAand DCO. IJDE, 5(1), 2006. URL http://www.utica.edu/academic/institutes/ecii/publications/articles/EFE36584-D13F-2962-67BEB146864A2671.pdf.

[70] Peter Gutmann. Data remanence in semiconductor devices. In 10th USENIX SecuritySymposium, August 13-17, 2001, Washington, D.C., USA, 2001. URL http://www.usenix.org/publications/library/proceedings/sec01/gutmann.html.

[71] J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul,Joseph A. Cal, Ariel J. Feldman, and Edward W. Felten. Memory Research Project SourceCode, Center for Information Technology Policy at Princeton. Website: https://citp.princeton.edu/research/memory/code/, 2008.

[72] J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul,Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten. Lestwe remember: Cold boot attacks on encryption keys. In Proceedings of the 17th USENIXSecurity Symposium, July 28-August 1, 2008, San Jose, CA, USA, pages 45–60, 2008. URLhttp://www.usenix.org/events/sec08/tech/full_papers/halderman/halderman.pdf.

[73] J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul,Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten. Lest weremember: cold-boot attacks on encryption keys. Commun. ACM, 52(5):91–98, 2009. doi:10.1145/1506409.1506429. URL http://doi.acm.org/10.1145/1506409.1506429.

[74] Ryan Harris. Arriving at an anti-forensics consensus: Examining how to define and control theanti-forensics problem. Digital Investigation, 3, Supplement:44 – 49, 2006. ISSN 1742-2876.doi: http://dx.doi.org/10.1016/j.diin.2006.06.005. URL http://www.sciencedirect.com/science/article/pii/S1742287606000673. The Proceedings of the 6th Annual DigitalForensic Research Workshop (DFRWS ’06).

[75] Nadia Heninger and Hovav Shacham. Reconstructing RSA private keys from random keybits. In Advances in Cryptology - CRYPTO 2009, 29th Annual International CryptologyConference, Santa Barbara, CA, USA, August 16-20, 2009. Proceedings, pages 1–17, 2009. doi:10.1007/978-3-642-03356-8_1. URL http://dx.doi.org/10.1007/978-3-642-03356-8_1.

114

Bibliography

[76] Frank P. Higgins. Break through the BIOS password. Leaked via AntiSec FFF-E05 dump on2011-11-18. Available online at https://cryptome.org/isp-spy/bios-spy.pdf), 2011.

[77] S. Hilley. Anti-forensics with a small army of exploits. Digital Investigation, 4(1):13 – 15,2007. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2007.01.005. URL http://www.sciencedirect.com/science/article/pii/S1742287607000072.

[78] Maarten Huijbregtse and Zeno Geradts. Using the ENF criterion for determining the time ofrecording of short digital audio recordings. In Computational Forensics, Third InternationalWorkshop, IWCF 2009, The Hague, The Netherlands, August 13-14, 2009. Proceedings, pages116–124, 2009. doi: 10.1007/978-3-642-03521-0_11. URL http://dx.doi.org/10.1007/978-3-642-03521-0_11.

[79] Golden G. Richard III and Andrew Case. In lieu of swap: Analyzing compressed RAM inmac OS x and linux. Digital Investigation, 11, Supplement 2:S3 – S12, 2014. ISSN 1742-2876.doi: http://dx.doi.org/10.1016/j.diin.2014.05.011. URL http://www.sciencedirect.com/science/article/pii/S1742287614000541. Fourteenth Annual DFRWS Conference.

[80] Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Program-ming Guide, Part 1. Intel Corporation, 2010.

[81] Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 2 (2A, 2B & 2C):Instruction Set Reference, A-Z. Intel Corporation, 2012.

[82] Nick L. Petroni Jr., AAron Walters, Timothy Fraser, and William A. Arbaugh. FATKit:a framework for the extraction and analysis of digital forensic data from volatile systemmemory. Digital Investigation, 3(4):197 – 210, 2006. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2006.10.001. URL http://www.sciencedirect.com/science/article/pii/S1742287606001228.

[83] Dan Kaminsky. Secure random by default. Talk at DEF CON 22 (video: https://youtu.be/xneBjc8z0DE?t=203), 2014.

[84] Karl-Johan Karlsson and William Bradley Glisson. Android anti-forensics: Modifyingcyanogenmod. In 47th Hawaii International Conference on System Sciences, HICSS 2014,Waikoloa, HI, USA, January 6-9, 2014, pages 4828–4837, 2014. doi: 10.1109/HICSS.2014.593.URL http://dx.doi.org/10.1109/HICSS.2014.593.

[85] Auguste Kerckhoffs. La cryptographie militaire. Journal des sciences militaires, 9:538, 1883.

[86] Gary C. Kessler. Anti-forensics and the digital investigator. In Australian Digital ForensicsConference, page 1, 2007.

[87] P.L. Kirk and J.I. Thornton. Crime Investigation. Wiley, 1974. ISBN 9780471482475.

[88] Julian Knauer and Harald Baier. Zur Sicherheit von ATA-Festplattenpasswörtern. Proceedingsof D-A-CH Security, pages 26–37, 2012.

[89] Jesse D. Kornblum. Using every part of the buffalo in windows memory analysis. Digital Inves-tigation, 4(1):24 – 29, 2007. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2006.12.002.URL http://www.sciencedirect.com/science/article/pii/S1742287607000047.

[90] J. Laan and N. Dijkhuizen. Firmwall: Protecting hard disk firmware. Published on-line (paper: https://www.os3.nl/_media/2013-2014/courses/ot/jan_niels.pdf tool:https://github.com/janlaan/firmwall), 2014.

[91] ShiYue Lai and Rainer Böhme. Countering counter-forensics: The case of JPEG compression.In Information Hiding - 13th International Conference, IH 2011, Prague, Czech Republic,May 18-20, 2011, Revised Selected Papers, pages 285–298, 2011. doi: 10.1007/978-3-642-24178-9_20. URL http://dx.doi.org/10.1007/978-3-642-24178-9_20.

115

Bibliography

[92] Pierre L’Ecuyer. Tables of maximally equidistributed combined LFSR generators. Math.Comput., 68(225):261–269, 1999. doi: 10.1090/S0025-5718-99-01039-X. URL http://dx.doi.org/10.1090/S0025-5718-99-01039-X.

[93] H.C. Lee and H.A. Harris. Physical Evidence in Forensic Science. Lawyers & JudgesPublishing Company, 2000. ISBN 9781930056015.

[94] Kyoungho Lee, Hyunuk Hwang, Kibom Kim, and BongNam Noh. Robust bootstrappingmemory analysis against anti-forensics. Digital Investigation, 18, Supplement:S23 – S32,2016. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2016.04.009. URL http://www.sciencedirect.com/science/article/pii/S1742287616300408.

[95] Seokhee Lee, Antonio Savoldi, Sangjin Lee, and Jongin Lim. Windows pagefile collection andanalysis for a live forensics context. In Future Generation Communication and Networking,FGCN 2007, Ramada Plaza Jeju, Jeju-Island, Korea, December 6-8, 2007, Proceedings, pages97–101, 2007. doi: 10.1109/FGCN.2007.236. URL http://dx.doi.org/10.1109/FGCN.2007.236.

[96] Eugene Libster and Jesse D. Kornblum. A proposal for an integrated memory acquisitionmechanism. SIGOPS Oper. Syst. Rev., 42(3):14–20, April 2008. ISSN 0163-5980. doi:10.1145/1368506.1368510. URL http://doi.acm.org/10.1145/1368506.1368510.

[97] Simon Lindenlauf, Hans Höfken, and Marko Schuba. Cold boot attacks on DDR2 and DDR3SDRAM. In 10th International Conference on Availability, Reliability and Security, ARES2015, Toulouse, France, August 24-27, 2015, pages 287–292, 2015. doi: 10.1109/ARES.2015.28.URL http://dx.doi.org/10.1109/ARES.2015.28.

[98] W. Link and H. May. Eigenschaften von MOS-Ein-Transistorspeicherzellen bei tieftenTemperaturen. Archiv für Elektronik und Übertragungstechnik, 33(6):229–235, 1979.

[99] Carsten Maartmann-Moe, Steffen E. Thorkildsen, and André Årnes. The persistence ofmemory: Forensic identification and extraction of cryptographic keys. Digital Investigation, 6,Supplement:S132 – S140, 2009. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2009.06.002. URL http://www.sciencedirect.com/science/article/pii/S1742287609000486.The Proceedings of the Ninth Annual DFRWS Conference.

[100] Lorenzo Martignoni, Aristide Fattori, Roberto Paleari, and Lorenzo Cavallaro. Live andtrustworthy forensic analysis of commodity production systems. In Recent Advances inIntrusion Detection, 13th International Symposium, RAID 2010, Ottawa, Ontario, Canada,September 15-17, 2010. Proceedings, pages 297–316, 2010. doi: 10.1007/978-3-642-15512-3_16.URL http://dx.doi.org/10.1007/978-3-642-15512-3_16.

[101] Friedemann Mattern. Virtual time and global states of distributed systems. Parallel andDistributed Algorithms, 1(23):215–226, 1989.

[102] Patrick McGregor, Tim Hollebeek, Alex Volynkin, and Matthew White. Braving the cold:New methods for preventing cold boot attacks on encryption keys. Talk at Black HatUSA (slides: https://www.blackhat.com/presentations/bh-usa-08/McGregor/BH_US_08_McGregor_Cold_Boot_Attacks.pdf), 2008.

[103] Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V. Rozas, Hisham Shafi, VedvyasShanbhogue, and Uday R. Savagaonkar. Innovative instructions and software model forisolated execution. In HASP 2013, The Second Workshop on Hardware and ArchitecturalSupport for Security and Privacy, Tel-Aviv, Israel, June 23-24, 2013, page 10, 2013. doi:10.1145/2487726.2488368. URL http://doi.acm.org/10.1145/2487726.2488368.

[104] Microsoft Corporation. Windows Research Kernel v1.2. Non-public, 2006.

[105] C. P. Mozak. Suppressing power supply noise using data scrambling in double data ratememory systems, May 17 2011. URL https://www.google.com.ar/patents/US7945050.US Patent 7,945,050.

116

Bibliography

[106] Tilo Müller and Michael Spreitzenbarth. FROST - forensic recovery of scrambled telephones.In Applied Cryptography and Network Security - 11th International Conference, ACNS 2013,Banff, AB, Canada, June 25-28, 2013. Proceedings, pages 373–388, 2013. doi: 10.1007/978-3-642-38980-1_23. URL http://dx.doi.org/10.1007/978-3-642-38980-1_23.

[107] Tilo Müller, Andreas Dewald, and Felix Freiling. AESSE: a cold-boot resistant implementationof AES. In Proceedings of the Third European Workshop on System Security, EUROSEC2010, Paris, France, April 13, 2010, pages 42–47, 2010. doi: 10.1145/1752046.1752053. URLhttp://doi.acm.org/10.1145/1752046.1752053.

[108] Tilo Müller, Felix Freiling, and Andreas Dewald. TRESOR runs encryption securely outsideRAM. In 20th USENIX Security Symposium, San Francisco, CA, USA, August 8-12, 2011,Proceedings, 2011. URL http://static.usenix.org/events/sec11/tech/full_papers/Muller.pdf.

[109] Tilo Müller, Tobias Latzo, and Felix Freiling. Hardware-based full disk encryption (in) securitysurvey. Technical Report CS-2014-04, Department Informatik, Friedrich-Alexander-UniversitätErlangen-Nürnberg (FAU), 2012.

[110] Tilo Müller, Benjamin Taubmann, and Felix Freiling. TreVisor - OS-independent software-based full disk encryption secure against main memory attacks. In Applied Cryptography andNetwork Security - 10th International Conference, ACNS 2012, Singapore, June 26-29, 2012.Proceedings, pages 66–83, 2012. doi: 10.1007/978-3-642-31284-7_5. URL http://dx.doi.org/10.1007/978-3-642-31284-7_5.

[111] Noora Al Mutawa, Ibtesam Al Awadhi, Ibrahim M. Baggili, and Andrew Marrington. Forensicartifacts of Facebook’s instant messaging service. In 6th International Conference for InternetTechnology and Secured Transactions, ICITST 2011, Abu Dhabi, UAE, December 11-14,2011, pages 771–776, 2011. URL http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6148436.

[112] Karsten Nohl and Jan “Starbug” Krissler. Deep silicon analysis. Talk at HAR (video:https://www.youtube.com/watch?v=UoLyYZzXjQE), 2009.

[113] Karsten Nohl and Jan “Starbug” Krissler. Silicon chips: No more secrets. Talk at PacSec(slides: http://www.degate.org/Pacsec2009/091001.Pacsec.Silicon.pdf), 2009.

[114] Donny Jacob Ohana and Narasimha Shashidhar. Do private and portable web browsersleave incriminating evidence? A forensic analysis of residual artifacts from private andportable web browsing sessions. EURASIP J. Information Security, 2013:6, 2013. doi:10.1186/1687-417X-2013-6. URL http://dx.doi.org/10.1186/1687-417X-2013-6.

[115] Jürgen Pabel. FrozenCache – Mitigating cold-boot attacks for full-disk-encryption software.Talk at the 27th Chaos Communication Congress (27C3) (slides: https://events.ccc.de/congress/2010/Fahrplan/attachments/1786_FrozenCache.pdf, video: https://www.youtube.com/watch?v=EHkUaiomxfE, blog: http://http://frozencache.blogspot.de/),2010.

[116] Cecilia Pasquini and Giulia Boato. JPEG compression anti-forensics based on first significantdigit distribution. In 15th IEEE International Workshop on Multimedia Signal Processing,MMSP 2013, Pula, Sardinia, Italy, September 30 - Oct. 2, 2013, pages 500–505, 2013. doi:10.1109/MMSP.2013.6659339. URL http://dx.doi.org/10.1109/MMSP.2013.6659339.

[117] Michael Perklin. Anti-forensics and anti-anti-forensics. Talk at DEF CON 20(slides: https://www.defcon.org/images/defcon-20/dc-20-presentations/Perklin/DEFCON-20-Perklin-AntiForensics.pdf, video: https://www.youtube.com/watch?v=1PEOCAxR5Hk), 2012.

117

Bibliography

[118] Huw Read, Konstantinos Xynos, Iain Sutherland, Gareth Davies, Tom Houiellebecq, FrodeRoarson, and Andrew Blyth. Manipulation of hard drive firmware to conceal entire parti-tions. Digital Investigation, 10(4):281 – 286, 2013. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2013.10.001. URL http://www.sciencedirect.com/science/article/pii/S1742287613001072.

[119] Slim Rekhis and Noureddine Boudriga. Formal digital investigation of anti-forensic attacks. InFifth IEEE International Workshop on Systematic Approaches to Digital Forensic Engineering,SADFE 2010, Oakland, CA, USA, May 20, 2010, pages 33–44, 2010. doi: 10.1109/SADFE.2010.9. URL http://dx.doi.org/10.1109/SADFE.2010.9.

[120] Slim Rekhis and Noureddine Boudriga. A system for formal digital forensic investigation awareof anti-forensic attacks. IEEE Trans. Information Forensics and Security, 7(2):635–650, 2012.doi: 10.1109/TIFS.2011.2176117. URL http://dx.doi.org/10.1109/TIFS.2011.2176117.

[121] Heinrich Riebler, Tobias Kenter, Christian Plessl, and Christoph Sorge. ReconstructingAES key schedules from decayed memory with fpgas. In 22nd IEEE Annual InternationalSymposium on Field-Programmable Custom Computing Machines, FCCM 2014, Boston,MA, USA, May 11-13, 2014, pages 222–229, 2014. doi: 10.1109/FCCM.2014.67. URLhttp://dx.doi.org/10.1109/FCCM.2014.67.

[122] Anibal L. Sacco and Alfredo A. Ortega. Persistent BIOS infection – “The early bird catchesthe worm”. Talk at CanSecWest (slides: https://cansecwest.com/csw09/csw09-sacco-ortega.pdf), 2009.

[123] Anibal L. Sacco and Alfredo A. Ortega. Persistent BIOS infection – “The early bird catchesthe worm”. Phrack Magazin, Volume 0x0d, Issue 0x42, Phile #0x07 of 0x11 (http://phrack.org/issues/66/7.html), 2009.

[124] H. Said, N. Al Mutawa, I. Al Awadhi, and M. Guimaraes. Forensic analysis of private browsingartifacts. In International Conference Ionnnovations in Information Technology (IIT), pages197–202, April 2011. doi: 10.1109/INNOVATIONS.2011.5893816.

[125] Santanu Sarkar, Sourav Sen Gupta, and Subhamoy Maitra. Error correction of partiallyexposed RSA private keys from MSB side. In Information Systems Security - 9th InternationalConference, ICISS 2013, Kolkata, India, December 16-20, 2013. Proceedings, pages 345–359,2013. doi: 10.1007/978-3-642-45204-8_26. URL http://dx.doi.org/10.1007/978-3-642-45204-8_26.

[126] Bryan Sartin. Anti-forensics – distorting the evidence. Computer Fraud & Security, 2006(5):4 – 6, 2006. ISSN 1361-3723. doi: http://dx.doi.org/10.1016/S1361-3723(06)70354-2. URLhttp://www.sciencedirect.com/science/article/pii/S1361372306703542.

[127] Bradley Schatz. BodySnatcher: Towards reliable volatile memory acquisition by software.Digital Investigation, 4, Supplement:126 – 134, 2007. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2007.06.009. URL http://www.sciencedirect.com/science/article/pii/S1742287607000497.

[128] Martin Schobert. Semiautomatisches Reverse-Engineering von Logikgattern in integriertenSchaltkreisen (speziell zur Aufklärung geheimgehaltenener Verschlüsselungsverfahren). Talkat 0sec (slides: http://www.degate.org/documentation/0sec_talk_degate.pdf), 2009.

[129] Ruud Schramp. RAM Memory acquisition using live-BIOS modification. Talk at OHM (video:https://www.youtube.com/watch?v=Zmo13Bd4XmU), 2013.

[130] Seagate. Maximize security, lock down hard drive firmware with Seagate Secure Download& Diagnostics. Technology Paper, 2015. URL http://www.seagate.com/files/www-content/solutions-content/security-and-encryption/en-us/docs/seagate-secure-download-diagnostics-with-maximize-sec-lock-down-hard-drive-firmware-tp684-1-1508us.pdf.

118

Bibliography

[131] Maximilian Seitzer, Michael Gruhn, and Tilo Müller. A bytecode interpreter for secureprogram execution in untrusted main memory. In Computer Security - ESORICS 2015 - 20thEuropean Symposium on Research in Computer Security, Vienna, Austria, September 21-25,2015, Proceedings, Part II, pages 376–395, 2015. doi: 10.1007/978-3-319-24177-7_19. URLhttp://dx.doi.org/10.1007/978-3-319-24177-7_19.

[132] Patrick Simmons. Security through amnesia: a software-based solution to the cold bootattack on disk encryption. In Proceedings of the 27th Annual Computer Security ApplicationsConference, ACSAC ’11, pages 73–82, New York, NY, USA, 2011. ACM. ISBN 978-1-4503-0672-0. doi: 10.1145/2076732.2076743. URL http://doi.acm.org/10.1145/2076732.2076743.

[133] Sinometer Instruments. DT8380, DT8550 - INFRARED THERMOMETERS. Datasheet:http://www.sinometer.com/pdf/DT8380,%208550.pdf, 2003.

[134] Sergei Skorobogatov. Low temperature data remanence in static RAM. Technical ReportUCAM-CL-TR-536, University of Cambridge, Computer Laboratory, June 2002. URLhttp://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-536.pdf.

[135] Sergei Skorobogatov and Christopher Woods. Breakthrough silicon scanning discovers back-door in military chip. In Cryptographic Hardware and Embedded Systems - CHES 2012 - 14thInternational Workshop, Leuven, Belgium, September 9-12, 2012. Proceedings, pages 23–40,2012. doi: 10.1007/978-3-642-33027-8_2. URL http://dx.doi.org/10.1007/978-3-642-33027-8_2.

[136] Walter Specht. Die Chemiluminescenz des Hämins, ein Hilfsmittel zur Auffindung undErkennung forensisch wichtiger Blutspuren. Angewandte Chemie, 50(8):155–157, 1937.ISSN 1521-3757. doi: 10.1002/ange.19370500803. URL http://dx.doi.org/10.1002/ange.19370500803.

[137] Matthew C. Stamm and K. J. Ray Liu. Wavelet-based image compression anti-forensics.In Proceedings of the International Conference on Image Processing, ICIP 2010, September26-29, Hong Kong, China, pages 1737–1740, 2010. doi: 10.1109/ICIP.2010.5652845. URLhttp://dx.doi.org/10.1109/ICIP.2010.5652845.

[138] Matthew C. Stamm and K. J. Ray Liu. Anti-forensics for frame deletion/addition in MPEGvideo. In Proceedings of the IEEE International Conference on Acoustics, Speech, and SignalProcessing, ICASSP 2011, May 22-27, 2011, Prague Congress Center, Prague, Czech Republic,pages 1876–1879, 2011. doi: 10.1109/ICASSP.2011.5946872. URL http://dx.doi.org/10.1109/ICASSP.2011.5946872.

[139] Matthew C. Stamm and K. J. Ray Liu. Anti-forensics of digital image compression. IEEETrans. Information Forensics and Security, 6(3-2):1050–1065, 2011. doi: 10.1109/TIFS.2011.2119314. URL http://dx.doi.org/10.1109/TIFS.2011.2119314.

[140] Matthew C. Stamm, Steven K. Tjoa, W. Sabrina Lin, and K. J. Ray Liu. Anti-forensicsof JPEG compression. In Proceedings of the IEEE International Conference on Acoustics,Speech, and Signal Processing, ICASSP 2010, 14-19 March 2010, Sheraton Dallas Hotel,Dallas, Texas, USA, pages 1694–1697, 2010. doi: 10.1109/ICASSP.2010.5495491. URLhttp://dx.doi.org/10.1109/ICASSP.2010.5495491.

[141] Matthew C. Stamm, Steven K. Tjoa, W. Sabrina Lin, and K. J. Ray Liu. Undetectable imagetampering through JPEG compression anti-forensics. In Proceedings of the InternationalConference on Image Processing, ICIP 2010, September 26-29, Hong Kong, China, pages2109–2112, 2010. doi: 10.1109/ICIP.2010.5652553. URL http://dx.doi.org/10.1109/ICIP.2010.5652553.

[142] Matthew C. Stamm, W. Sabrina Lin, and K. J. Ray Liu. Forensics vs. anti-forensics: Adecision and game theoretic framework. In 2012 IEEE International Conference on Acoustics,Speech and Signal Processing, ICASSP 2012, Kyoto, Japan, March 25-30, 2012, pages 1749–1752, 2012. doi: 10.1109/ICASSP.2012.6288237. URL http://dx.doi.org/10.1109/ICASSP.2012.6288237.

119

Bibliography

[143] Matthew C. Stamm, W. Sabrina Lin, and K. J. Ray Liu. Temporal forensics and anti-forensics for motion compensated video. IEEE Trans. Information Forensics and Security, 7(4):1315–1329, 2012. doi: 10.1109/TIFS.2012.2205568. URL http://dx.doi.org/10.1109/TIFS.2012.2205568.

[144] Andrew S.Tanenbaum. OPERATING SYSTEMS: Design and Implementation. Prentice-Hall,1987. ISBN 0-13-637331-3.

[145] Johannes Stüttgen and Michael Cohen. Anti-forensic resilient memory acquisition. DigitalInvestigation, 10, Supplement:S105 – S115, 2013. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2013.06.012. URL http://www.sciencedirect.com/science/article/pii/S1742287613000583. The Proceedings of the Thirteenth Annual DFRWS Conference.

[146] Johannes Stüttgen and Michael Cohen. Robust Linux memory acquisition with minimaltarget impact. Digital Investigation, 11, Supplement 1:S112 – S119, 2014. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2014.03.014. URL http://www.sciencedirect.com/science/article/pii/S174228761400019X. Proceedings of the First Annual DFRWSEurope.

[147] Hung-Min Sun, Chi-Yao Weng, Chin-Feng Lee, and Cheng-Hsing Yang. Anti-forensicswith steganographic data embedding in digital images. IEEE Journal on Selected Areas inCommunications, 29(7):1392–1403, 2011. doi: 10.1109/JSAC.2011.110806. URL http://dx.doi.org/10.1109/JSAC.2011.110806.

[148] Iain Sutherland, Gareth Davies, Nick Pringle, and Andrew Blyth. The impact of hard diskfirmware steganography on computer forensics. JDFSL, 4(2):73–84, 2009. URL http://ojs.jdfsl.org/index.php/jdfsl/article/view/165.

[149] Patchara Sutthiwan and Yun Q. Shi. Anti-forensics of double JPEG compression detection.In Digital Forensics and Watermarking - 10th International Workshop, IWDW 2011, AtlanticCity, NJ, USA, October 23-26, 2011, Revised Selected Papers, pages 411–424, 2011. doi: 10.1007/978-3-642-32205-1_33. URL http://dx.doi.org/10.1007/978-3-642-32205-1_33.

[150] Christopher Tarnovsky and Karsten Nohl. Reviving smart card analysis. Talk at Chaos Com-munication Camp (slides: https://events.ccc.de/camp/2011/Fahrplan/attachments/1888_SRLabs-Reviving_Smart_Card_Analysis.pdf, videos: https://www.youtube.com/watch?v=fFx6Rn57DrY), 2011.

[151] Benjamin Taubmann, Manuel Huber, Sascha Wessel, Lukas Heim, Hans Peter Reiser, andGeorg Sigl. A lightweight framework for cold boot based forensics on mobile devices. In10th International Conference on Availability, Reliability and Security, ARES 2015, Toulouse,France, August 24-27, 2015, pages 120–128, 2015. doi: 10.1109/ARES.2015.47. URLhttp://dx.doi.org/10.1109/ARES.2015.47.

[152] “the grugq”. Defeating forensic analysis on unix. Phrack Magazin, Volume 0x0b, Issue 0x3b,Phile #0x06 of 0x12 (http://phrack.org/issues/59/6.html), 2002.

[153] P. Thomas and A. Morris. An investigation into the development of an anti-forensic tool toobscure USB flash drive device information on a Windows XP platform. In Digital Forensicsand Incident Analysis, 2008. WDFIA ’08. Third International Annual Workshop on, pages60–66, Oct 2008. doi: 10.1109/WDFIA.2008.13.

[154] TCG Platform Reset Attack Mitigation Specification, Version 1.00, Revision 1.00. TrustedComputing Group, Incorporated, 2008.

[155] Alex Tsow. An improved recovery algorithm for decayed AES key schedule images. In SelectedAreas in Cryptography, 16th Annual International Workshop, SAC 2009, Calgary, Alberta,Canada, August 13-14, 2009, Revised Selected Papers, pages 215–230, 2009. doi: 10.1007/978-3-642-05445-7_14. URL http://dx.doi.org/10.1007/978-3-642-05445-7_14.

120

Bibliography

[156] Unified Extensible Firmware Interface Specification, 2.4. Unified EFI, Inc., 2013.

[157] Giuseppe Valenzise, Vitaliano Nobile, Marco Tagliasacchi, and Stefano Tubaro. CounteringJPEG anti-forensics. In 18th IEEE International Conference on Image Processing, ICIP 2011,Brussels, Belgium, September 11-14, 2011, pages 1949–1952, 2011. doi: 10.1109/ICIP.2011.6115854. URL http://dx.doi.org/10.1109/ICIP.2011.6115854.

[158] Giuseppe Valenzise, Marco Tagliasacchi, and Stefano Tubaro. The cost of JPEG compressionanti-forensics. In Proceedings of the IEEE International Conference on Acoustics, Speech,and Signal Processing, ICASSP 2011, May 22-27, 2011, Prague Congress Center, Prague,Czech Republic, pages 1884–1887, 2011. doi: 10.1109/ICASSP.2011.5946874. URL http://dx.doi.org/10.1109/ICASSP.2011.5946874.

[159] Giuseppe Valenzise, Marco Tagliasacchi, and Stefano Tubaro. Revealing the traces of JPEGcompression anti-forensics. IEEE Trans. Information Forensics and Security, 8(2):335–349,2013. doi: 10.1109/TIFS.2012.2234117. URL http://dx.doi.org/10.1109/TIFS.2012.2234117.

[160] R.B. van Baar, W. Alink, and A.R. van Ballegooij. Forensic memory analysis: Filesmapped in memory. Digital Investigation, 5, Supplement:S52 – S57, 2008. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2008.05.014. URL http://www.sciencedirect.com/science/article/pii/S1742287608000327. The Proceedings of the Eighth AnnualDFRWS Conference.

[161] Wiger van Houten and Zeno Geradts. Source video camera identification for multiply com-pressed videos originating from youtube. Digital Investigation, 6(1–2):48 – 60, 2009. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2009.05.003. URL http://www.sciencedirect.com/science/article/pii/S1742287609000310.

[162] Stefan Vömel and Felix Freiling. A survey of main memory acquisition and analysis techniquesfor the windows operating system. Digital Investigation, 8(1):3 – 22, 2011. ISSN 1742-2876.doi: http://dx.doi.org/10.1016/j.diin.2011.06.002. URL http://www.sciencedirect.com/science/article/pii/S1742287611000508.

[163] Stefan Vömel and Felix Freiling. Correctness, atomicity, and integrity: Defining criteria forforensically-sound memory acquisition. Digital Investigation, 9(2):125 – 137, 2012. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2012.04.005. URL http://www.sciencedirect.com/science/article/pii/S1742287612000254.

[164] Stefan Vömel and Johannes Stüttgen. An evaluation platform for forensic memory acqui-sition software. Digital Investigation, 10, Supplement:S30 – S40, 2013. ISSN 1742-2876.doi: http://dx.doi.org/10.1016/j.diin.2013.06.004. URL http://www.sciencedirect.com/science/article/pii/S1742287613000509. The Proceedings of the Thirteenth AnnualDFRWS Conference.

[165] Philipp Wachter and Michael Gruhn. Practicability study of android volatile memory forensicresearch. In 2015 IEEE International Workshop on Information Forensics and Security, WIFS2015, Roma, Italy, November 16-19, 2015, pages 1–6, 2015. doi: 10.1109/WIFS.2015.7368601.URL http://dx.doi.org/10.1109/WIFS.2015.7368601.

[166] Edith Wharton. The age of innocence. D. Appleton and Company, New York, 1920.

[167] Zhung-Han Wu, Matthew C. Stamm, and K. J. Ray Liu. Anti-forensics of median filtering.In IEEE International Conference on Acoustics, Speech and Signal Processing, ICASSP 2013,Vancouver, BC, Canada, May 26-31, 2013, pages 3043–3047, 2013. doi: 10.1109/ICASSP.2013.6638217. URL http://dx.doi.org/10.1109/ICASSP.2013.6638217.

[168] Martin Wundram, Felix Freiling, and Christian Moch. Anti-forensics: The next step indigital forensics tool testing. In Seventh International Conference on IT Security IncidentManagement and IT Forensics, IMF 2013, Nuremberg, Germany, March 12-14, 2013, pages83–97, 2013. doi: 10.1109/IMF.2013.17. URL http://dx.doi.org/10.1109/IMF.2013.17.

121

Bibliography

[169] Alexander Würstlein, Michael Gernoth, Johannes Götzfried, and Tilo Müller. Exzess:Hardware-based RAM encryption against physical memory disclosure. In Architecture ofComputing Systems - ARCS 2016 - 29th International Conference, Nuremberg, Germany,April 4-7, 2016, Proceedings, pages 60–71, 2016. doi: 10.1007/978-3-319-30695-7_5. URLhttp://dx.doi.org/10.1007/978-3-319-30695-7_5.

[170] P. Wyns and Richard L. Anderson. Low-temperature operation of silicon dynamic random-access memories. Electron Devices, IEEE Transactions on, 36(8):1423–1428, Aug 1989. ISSN0018-9383. doi: 10.1109/16.30954.

[171] Miao Yu, Zhengwei Qi, Qian Lin, Xianming Zhong, Bingyu Li, and Haibing Guan. Vis:Virtualization enhanced live forensics acquisition for native system. Digital Investigation, 9(1):22 – 33, 2012. ISSN 1742-2876. doi: http://dx.doi.org/10.1016/j.diin.2012.04.002. URLhttp://www.sciencedirect.com/science/article/pii/S1742287612000229.

[172] Jonas Zaddach. Exploring the impact of a hard drive backdoor. Talk at REcon (slides:https://recon.cx/2014/slides/Recon14_HDD.pdf, video: https://www.youtube.com/watch?v=KjmsLvD76rM), 2014.

[173] Jonas Zaddach, Anil Kurmus, Davide Balzarotti, Erik-Oliver Blass, Aurélien Francillon,Travis Goodspeed, Moitrayee Gupta, and Ioannis Koltsidas. Implementation and implicationsof a stealth hard-drive backdoor. In Annual Computer Security Applications Conference,ACSAC ’13, New Orleans, LA, USA, December 9-13, 2013, pages 279–288, 2013. doi:10.1145/2523649.2523661. URL http://doi.acm.org/10.1145/2523649.2523661.

[174] Hui Zeng, Tengfei Qin, Xiangui Kang, and Li Liu. Countering anti-forensics of median filtering.In IEEE International Conference on Acoustics, Speech and Signal Processing, ICASSP 2014,Florence, Italy, May 4-9, 2014, pages 2704–2708, 2014. doi: 10.1109/ICASSP.2014.6854091.URL http://dx.doi.org/10.1109/ICASSP.2014.6854091.

All online resources were last accessed 2016-08-10.

122