Model-Driven Engineering in Digital Forensics. Jeroen van den Bos with Tijs van der Storm and Leon Aronson

Transcription

1 Model-Driven Engineering in Digital Forensics Jeroen van den Bos with Tijs van der Storm and Leon Aronson

2 Contents Digital forensics MDE in forensics Domain-specific optimizations Conclusion

3 Digital Forensics Background and Challenges

4 Netherlands Forensic Institute Improve our clients information position through high-quality forensic services

5 What is digital forensics? From Wikipedia: Digital forensics is a branch of forensic science encompassing the recovery and investigation of material found in digital devices, often in relation to computer crime.

6 Do we need (custom) software (engineering)? Software: yes, there is no other way to do digital forensics. Custom software: yes, because we have specific requirements. Software engineering: yes, for legal, business and engineering reasons.

7 RDD Defraser TULP2G Aftertime

8 Main activities Acquisition Recovery Analysis Securing the data Turning data into information Finding relevant information

9 Challenges in all areas Data acquisition From hard drives to solid-state memory. Moving into the cloud (mostly legal issues). Data recovery New platforms, apps and versions emerge daily. Lots of variants due to vendor-specific implementations. Data analysis New visualizations to detect innovative use of technology. Finding complex relationships in data sets.

10 Challenges in all areas Data acquisition From hard drives to solid-state memory. Moving into the cloud (mostly legal issues). Data recovery Scalability is a problem everywhere. New platforms, apps and versions emerge daily. Lots of variants due to vendor-specific implementations. Data analysis New visualizations to detect innovative use of technology. Finding complex relationships in data sets.

11 Challenges in all areas Data acquisition From hard drives to solid-state memory. Moving into the cloud (mostly legal issues). Data recovery New platforms, apps and versions emerge daily. Lots of variants due to vendor-specific implementations. Data analysis New visualizations to detect innovative use of technology. Finding complex relationships in data sets.

12 Requirements 1. Data structure definitions that are easy to develop and modify. 2. Highest possible runtime performance and scalability. 3. Reuse of changes across applications. 4. Separation forensic investigation and software engineering concerns.

13 MDE in forensics File Carving, Excavator and Derric

14 Data acquired: 1TB. File carving

15 File carving 264GB allocated to main file system.

16 File carving 40GB found analyzing metadata, additional 240GB file system.

17 File carving That leaves 456GB unaccounted for.

18 File carving 96GB probably contains files. What about the other 360GB?

19 File carving File carving is the process of recovering files without the help of (file system) storage metadata. A file carver typically consists of two parts: The carver itself, which selects and/or combines blocks of data from the input as candidate files. A set of format validators that determine whether a candidate file is of any of the formats they validate.

20 input to storage device Derric Descriptions Code Generator Format Validators File Carver recovered files input to produces input to produces Excavator architecture

21 A DERRIC description 1. Header Name and encoding/ type defaults format PNG strings ascii size 1 unit byte sign false type integer order lsb0 endian little 2. Sequence Data structure ordering sequence Signature IHDR (ITXT ICMT)* PLTE? IDAT IDAT* IEND 3. Structures Layout of individual data structures structures IHDR { l: lengthof(d) size 4; n: IHDR ; d: {... } c: checksum (...) size 4; }

22 structures Chunk { length: lengthof(chunkdata) size 4; chunktype: type string size 4; chunkdata: size length; crc: checksum(algorithm="crc32-ieee", fields=chunktype+chunkdata) size 4; end: 0xFF3F; } IHDR = Chunk { chunktype: "IHDR"; chunkdata: { width:!0 size 4; height:!0 size 4; bitdepth: ; imagesize: (width*height*bitdepth)/8 size 4; interlace: 0 1; } }

23 Applying Derric Each format has one/several descriptions. Code generator uses descriptions: Applies (domain-specific) optimizations/transformations. Runs quickly, so easy to rerun after changes. May output for multiple targets. Runtime system uses generated validators: Recognizes, extracts or ignores files. Implements algorithms and common optimizations.

24 Comparing to Existing Tools on a Set of Benchmarks Excavator ReviveIt PhotoRec Scalpel Files Recovered (count) Processing speed (MB/second)

25 Intermediate conclusion Model-driven approach works well: Runtime performance, quality of results of Excavator are good. Derric allows division of labour to improve productivity. However, no large benchmarks exist, so scalability has not been evaluated.

26 Domain-Specific Optimizations Transformations to Improve Scalability

27 Speeding up a file carver Two ways to improve performance: Reduce the amount of validator invocations. Improve the runtime performance of the validator. Both can potentially be achieved by reducing validator accuracy.

28 Validator accuracy Clusters acquired from a hard drive: A A A A A B B B B C C C C C C C B B B B

29 Three Transformations, Four Validators Base NoCA NoDD Remove Content Analysis Remove Data Dependencies HFMatch Reduce to Header/Footer Matching

30 structures Remove Content Analysis Chunk { length: lengthof(chunkdata) size 4; chunktype: type string size 4; chunkdata: size length; crc: checksum(algorithm="crc32-ieee", fields=chunktype+chunkdata) size 4; end: 0xFF3F; } IHDR = Chunk { chunktype: "IHDR"; chunkdata: { width:!0 size 4; height:!0 size 4; bitdepth: ; imagesize: (width*height*bitdepth)/8 size 4; interlace: 0 1; } }

31 structures Removed Content Analysis Chunk { length: lengthof(chunkdata) size 4; chunktype: type string size 4; chunkdata: size length; crc: size 4; end: 0xFF3F; } IHDR = Chunk { chunktype: "IHDR"; chunkdata: { width:!0 size 4; height:!0 size 4; bitdepth: ; imagesize: (width*height*bitdepth)/8 size 4; interlace: 0 1; } }

32 structures Remove Data Dependencies Chunk { length: lengthof(chunkdata) size 4; chunktype: type string size 4; chunkdata: size length; crc: size 4; end: 0xFF3F; } IHDR = Chunk { chunktype: "IHDR"; chunkdata: { width:!0 size 4; height:!0 size 4; bitdepth: ; imagesize: (width*height*bitdepth)/8 size 4; interlace: 0 1; } }

33 structures Chunk { length: size 4; chunktype: type string size 4; crc: size 4; end: terminatedby 0xFF3F; } IHDR = Chunk { chunktype: "IHDR"; chunkdata: { width:!0 size 4; height:!0 size 4; bitdepth: ; imagesize: size 4; interlace: 0 1; } } Removed Data Dependencies

34 Reduced to Header/Footer Matching format PNG sequence start end structures start { header: 137, 80, 78, 71, 13, 10, 26, 10; } end { footer: terminatedby 0, 0, 0, 0, 73, 69, 78, 68, 174, 66, 96, 130; }

35 Constructing a Benchmark No suitable public benchmark exists Constructed own 1TB test image: >1.2M image files, 357GB total from Wikipedia JPEG, PNG and GIF files 543GB random data, 100GB zeros Fragmentation based on observations

36 Test setup Twelve runs total: Three format specifications in Derric Four validator implementations One base, three transformed 3.4GHz Intel Core i7-2600, 8GB RAM, 2TB 10kRPM SATA HDD, JavaSE6-u13

37 Results: Running Time (m) JPEG (930k files) GIF (37k files) PNG (236k files) Base NoCA NoDD HFMatch

38 Results: Precision (%) JPEG (930k files) GIF (37k files) PNG (236k files) Base NoCA NoDD HFMatch

39 Results: Recall (%) 95 71,25 47,5 23,75 0 JPEG (930k files) GIF (37k files) PNG (236k files) Base NoCA NoDD HFMatch

40 Benchmark results NoDD and HFMatch are close: Both I/O bound Return nearly the same files Base is much slower: Expensive calculations Large amount of attempts

41 Intermediate conclusion Results indicate usable approach: Up to three times the speed At the cost of 8% precision, 5% recall Some questions that remain: Other file formats? Effects on actual analysis time?

42 Conclusion MDE has clear benefits in digital forensic data recovery: Helps engineers to focus on engineering and investigators on investigating. Does not incur any penalty in terms of runtime performance or quality of results. Enables useful additional automation.

43 Questions?