BinCarver Automatic recovery of binary executable files Presented

Bin-Carver: Automatic recovery of binary executable files Presented by: Ryan O’Donnell

What is file carving? The process of reassembling files from disk fragments in the absence of metadata.

When would we need file carving? • Accidental user deletions • Intentional user deletions • Malware

Traditional file carving method Using. jpeg file as an example Find header (FF D 8) Know footer pair (FF D 9) Find all contiguous data • • •

Problems with traditional method • fragmentation • doesn’t work without exact header and footer information • doesn’t work with all file types o focuses on documents of forensic interest o binary executables not included

Bin-carver overview -1 • recover Executable Linkable Format (ELF) file e from disk image D • D strictly consists of file content blocks • Assume D is an EXT 2 file system, block size 4 k

Bin-carver overview -2 • file content has not been overwritten • file content is stored in increasing order • ELF file e has n blocks in the disk We want to link these n blocks together utilizing internal graph node logic.

Bin-carver overview -3

Challenges • Filename recovery is typically not • possible without the file system metadata Fragmentation

Components • ELF-header scanner o scan all possible ELF headers hi using ELF- file magic value • block node linker o scans disk image, identifies nodes and links them • conflict-node resolver o removes conflict nodes and outputs ELF-file ei

System Overview Diagram

Scanner -1 Headers hold a “road map” describing ELF file organization. Searching for the magic number sequence 7 f 45 4 c 46 allows us to locate headers, telling us how to traverse all other sections.

Scanner -2 Each header is 52 k and contains: program header table (PHT) • o array of program headers • section header table (SHT) o array of section headers

Searching SHT • usually located at end of ELF file o can serve as a footer because of this • since A(footer) > A(h ) we can start our search at the 0 x 14 disk block • gives us a multitude of other constraints i that allow us to calculate the location of the footer

Searching PHT • locates segments that create memory image of the program • each program header is 32 bytes • usually starts right after ELF headers o same 4 k block

Searching PHT • from program header, infer vase virtual address of image file • keep iterating and build our road map • our goal is to find every fill this road map with content (bi)

Finished? With no fragmentation, our job is done. But, with any garbage gap, this approach would fail. So how do we link each individual bi if the disk is fragmented?

Block-node linker -1 We have to logically connect bi and bj We explore the caller-callee relationship: fill block place of bcaller and bcallee • o find address • logically link them together o function prologue signature (local calls) o PLT instruction sequence (library calls)

Block-node liner -2 On a library call • use PLT block number as an anchor • use this anchor to identify absolute block number of the caller block On a local call • only determines distance • only works with blocks starting with e 8 (CALL opcode) Most cases library calls are used to resolve block numbers

Conflict-node resolver -1 A particular placeholder i could have several candidates. To eliminate redundant placeholders: • use identified non-conflict nodes • explore logic connections • resolve node • iterate through until a fixed point is reached

Conflict-node resolver -2 Block-node linker only focuses on linking code blocks. Conflict-node resolver handles other data blocks (. data, . debug).

Conflict-node resolver -3 To retrieve data blocks: • treat data sections as a block between the ELF header and the first block of code section • resolvers explores constraints defined in PHT and SHT • worst case scenario: data section does not have identifiable sections and we must use dynamic execution to eliminate bogus permutations o essentially, if the recovered binary file doesn’t crash, it may have been recovered successfully

Evaluation - Comparisons were intended to be made to other similar tools, both Foremost and Scalpel do not support carving for fragmented ELF binary files.

Evaluation -1

Evaluation -2 • All files are ELF binaries o worst case, high false positive rates o addition of heterogeneous data irrelevant • performance of algorithm is invariant to size of the disk • performance relies on number of files to be recovered

Evaluation -3 To evaluate accuracy, need to prove the recovered files are true elf files. Need to create an MD 5 hash of first block and every individual block for each true ELF binary to detect true data in worst case fragmentation scenario.

Effectiveness -1 Identification rate: shows portion that can be identified no matter how fragmented the disk is • o must be able to match hash values Recovery Rate valid files in the system that were identified and recovered •

Effectiveness -3 Overall, very effective. On average: Identification rate of 96. 3% Recovery rate of 93. 1% • •

Effectiveness -3

Runtime Analysis -1 All performance slowdowns occur during linker and resolver phases. Large gaps hurt performance, and the large number of caller-callee instructions cause performance penalties.

Runtime Analysis -2