Forensic Blogs

An aggregator for digital forensics blogs

by

Quickpost: ExifTool, OLE Files and FlashPix Files

ExifTool can misidentify VBA macro files as FlashPix files.

The binary file format of Office documents (.doc, .xls) uses the Compound File Binary Format, what I like to refer as OLE files. These files can be analyzed with my tool oledump.py.

Starting with Office 2007, the default file format (.docx, .docm, .xlsx, …) is Office Open XML: OOXML. It’s in essence a ZIP container with XML files inside. However, VBA macros inside OOXML files (.docm, .xlsm) are not stored as XML files, they are still stored inside an OLE file: the ZIP container contains a file with name vbaProject.bin. That is an OLE file containing the VBA macros.

This can be observed with my zipdump.py tool:

oledump.py can look inside the ZIP container to analyze the embedded vbaProject.bin file:

And of course, it can handle an OLE file directly:

When ExifTool is given a vbaProject.bin file for analysis, it will misidentify it as a picture file: a FlashPix file.

That’s because when ExifTool doesn’t have enough metadata or an identifying extension to identify an OLE file, it will fall back to FlashPix file detection. That’s because FlashPix files are also based on the OLE file format, and AFAIK ExifTool started out as an image tool:

That is why on VirusTotal, vbaProject.bin files from OOXML files with macros, will be misidentified as FlashPix files:

When the extension of a vbaProject.bin file is changed to .doc, ExifTool will misidentify it as a Word document:

ExifTool is not designed to identify VBA macro files (vbaProject.bin). These files are not Office documents, neither pictures. But since they are also OLE files, ExifTool tries to guess what they are, based on the extension, and if that doesn’t help, it falls back to the FlashPix file format (based on OLE).

There’s no “bug” to fix, you just need to be aware of this particular behavior of ExifTool: it is a tool to extract information from media formats, when it analyses an OLE file and doesn’t have enough metadata/proper file extension, it will fall back to FlashPix identification.

 

Quickpost info

by

Recovery of Data Fall Blog 1

Comic about data recovery Data Recovery Project Goal

This semester, The Leahy Center for Digital Investigation created a project to solve issues related to data recovery. This project shows that the average user often does not truly delete their data, and that it is possible to recover this data without spending money on high end tools, such as EnCase and Axiom. These are tools which range from $1,700 to $4,800 a year. The Data Recovery Team at the LCDI has researched free tools that anyone can use to recover deleted files, whether you are someone who has erased files they need or the next owners of a poorly wiped drive. 

Is data ever “deleted”?

PC hard drives often contain data known as Personally Identifiable Information, or PII. This includes names, credit card numbers, addresses and other information important to one’s personal life. This is why true data deletion is so important. The average user doesn’t understand that they’re not actually deleting their data. The fact that this data is not always deleted is what can lead to the leak of the user’s PII when they sell the drive. One can truly delete their data by using the common standards for wiping drives.  

Visual vs Actual Deletion

Many people assume that they are deleting the file when it is no longer visible (for example, after it is in the recycle bin). This is never the case. After dragging said file to the bin, the user still needs to empty it. Even when the user empties the bin, the user has not actually deleted the file. When a user drags a file to the Recycle Bin, all that does is remove the link to said file from the user. The user has hidden the data, not deleted it. It will stay available on the computer until that part of the hard drive is overwritten by other files.

Proper Data Recovery Services

To achieve proper data deletion, one needs to use common drive wiping standards, such as US DoD 5220.22-M. This standard implements a three pass system, working as follows:

First pass: Overwrite all addressable locations with binary “zeroes”. Second pass: Overwrite all addressable locations with binary “ones”. Third pass: Overwrite all addressable locations with a random bit pattern Verify the final overwrite pass.

Another common standard for deleting data is the NIST method. This method describes different types of sanitation for drives, and recommends using more than one type.

Who Cares?

Net collecting black, yellow and white squares symbolizing data.

One of the most important questions that we at the Data Recovery Team ask is: why does any of this matter? This information can serve to help the user protect their PII. Whether it is by teaching the user how to delete their data, or teaching them how to recover it. This means that a normal user could recover their data without having to spend a lot of money. We understand that sometimes accidents happen and data may get erased unintentionally. Hopefully, with the information that this project will provide, users can retrieve their own lost data. 

Be sure to look for future posts and stay up to date with Twitter @ChampForensics, Instagram @ChampForensics, and Facebook @ChamplainLCDI!

 

The post Recovery of Data Fall Blog 1 appeared first on The Leahy Center for Digital Forensics & Cybersecurity.

by

PowerShell, Add-Type & csc.exe

Have you ever noticed that some PowerShell scripts result in the execution of the C# compiler csc.exe?

This happens when a PowerShell script uses cmdlet Add-Type.

Like in this command:

powershell -Command “Add-Type -TypeDefinition \”public class Demo {public int a;}\””

This command just adds the definition of a class (Demo) with one member (a).

When this Add-Type cmdlet is executed, the C# compiler is invoked by PowerShell to compile this class definition (a C# program) into an assembly (DLL) with the .NET type to be used by the PowerShell script.

A temporary file (oj5zlfcy.cmdline in this example) is created inside folder %appdata%\local\temp with extension .cmdline. This is passed as argument to the invoked C# compiler csc.exe, and contains directions to compile a C# program (oj5zlfcy.0.cs):

/t:library /utf8output /R:”System.dll” /R:”C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll” /R:”System.Core.dll” /out:”C:\Users\testuser1\AppData\Local\Temp\oj5zlfcy.dll” /debug- /optimize+ /warnaserror /optimize+ “C:\Users\testuser1\AppData\Local\Temp\oj5zlfcy.0.cs”

The C# program (oj5zlfcy.0.cs in this example) contains the class definition passed as argument to cmdlet Add-Type:

public class Demo {public int a;}

Both these files start with a UTF-8 BOM (EF BB BF).

The C# compiler (csc.exe) can invoke compilation tools when necessary, like the resource compiler cvtres.exe.

This results in the creation of several temporary files:

All these files are removed when cmdlet Add-Type terminates.