Which forensic imager is the fastest?

We all face the problem of growing amounts of evidence on a regular basis. Improving raw acquisition speed is one way to limit the impact of this, and Evimetry has been consistently delivering the fastest acquisition speeds bar none since we launched two years ago.

Yet we aren’t the only solution claiming to be the “fastest” or have “unparalleled” speeds.

Led by a practitioner and forensic scientist, it is in Evimetry’s DNA to value substantiation. Our results are backed up by scientifically peer-reviewed publications and documented in our blog posts and workshops.

The following graph shows the acquisition rate of a 1TB Samsung 960 Pro NVMe drive. We used Evimetry to undertake linear acquisitions to 4x Samsung 512 GB 860 Pro SSD’s as striped images, using a 6-core Xeon-D CPU. The variable is drive allocation: we started with an empty (TRIM’ed) drive, then filled it with a Windows 10 OS install and a corpus of common corporate documents and video. These figures don’t account for verification time.

We can acquire an empty 1TB NVMe drive in 4 minutes 52s. That’s a rate of 200 GB/m, or 12 TB/h. No other product comes close to these speeds.

In the real world, suspect drives contain data rather than empty runs of 0×00, and Evimetry’s acquisition speeds depend on how much actual data is stored on the suspect drive. For a drive that is 40% utilized it takes us 7m48s (still faster than anyone else’s claim) and at 95% utilized it takes us 12m57s.

In absence of substantiation from other quarters we remain confident that we offer the fastest acquisition solution available today. We encourage you to do your own validation of both our results, and the claims of other tools.

Simple Deadboot provisioning and acquisition with Evimetry

We have just shipped two releases of Evimetry: v3.0.7 (in our stable stream) & v3.1.5 (in our pre-release stream). Recent releases bring native Deadboot media creation, and introduce an improved Deadboot Imager UI.

Native Deadboot Media Creation.

We can now create Evimetry Deadboot USB’s directly from the Controller, and for larger drives, use the additional space for evidence storage. With a single hard drive serving both as an Evimetry Deadboot and Evidence Repository, scarce USB ports are freed up on target devices, workflow is simplified, and the number of devices to manage limited.

Creation of a Deadboot USB flash drive in the Controller.
Creation of a Deadboot USB flash drive in the Controller.

Small USB flash drives are setup solely as a Deadboot, just like our former workflow.

Read more about this feature here.

Improved Deadboot Imager UI.

For a while now the Deadboot agent has included a simple ASCII console-based Imager application. This is useful for acquiring single computers, when it is either inconvenient or unfeasable to use the Controller and a network.

While we love the retro feel and simplicity of an ASCII/curses interface, the world is no longer friendly to text-mode UI’s, with high-DPI monitors and text-mode free UEFI implementations meaning that text-mode no longer works everywhere. A graphical window based UI is now necessary.

Acquisition almost completed using Evimetry Imager
Acquisition almost completed using the new Deadboot Imager UI.

In the v3.1.3 pre-release we launched a *graphical* Imager application, and in today’s prerelease (v3.1.5) the layout of the Imager UI has been refined.

Pulling it all together.

The following video demonstrates the workflow of preparing a Deadboot USB and then subsequent acquisition of a 500G NVMe drive in under 6 minutes.

More information.

Full release notes are available via the releases page. The software may be downloaded from the portal.

Was the firewall blocking traffic? Identifying active firewall rules using registry analysis.

I came across this question recently in relation to claims that access to a Windows 8 host via Windows Remote Desktop Protocol was blocked by the firewall configuration. This post describes my research into the registry artefacts related to answering the question, and provides a patch to RegRipper to assist in analysis.

Theory of operation

Windows 8 uses the same firewall configuration entries used by Windows 7. Windows ships with a number of firewall rules enabled, and these may be added to or modified by the user, for example using the windows firewall control panel applet.


Rules are scoped by Profile, which is either Public, Private, or Domain. Note that I am going to refer to these are a “Network Category” herein, for reasons that will become apparent. These Network Categories (profiles) are associated with particular networks: for example, in the window capture below you can see that my home wireless connection is a “Private network”. For a “Private Network”, firewall rules with a value of “Private” will be applied.


The firewall rules are stored in the registry at HKLM\System\CurrentlControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules\.


The value of the rule above for “RemoteDesktop-UserMode-In-TCP” is


Comparing this the applet above, we can see that this corresponds to the disabled RemoteDesktop-UserMode-In-TCP rule. Looking for the second TCP related RDP, I found the following rule with the key name “{6AFE835E-629E-48DA-A87E-AB6C367D2BB7}”, which corresponds to the similar rule that is enabled for both Private and Domain.


Observation: Identifying the Category

Existing theory around mapping active networks from the registry is generally accepted: network profiles are stored in HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\. The RegRipper networklist plugin interprets the contents of this registry sub tree.

What my review of the current literature didn’t reveal is how to identify whether a Network Profile is configured as “Private”, “Public”, or “Domain”. Hence, I started looking for automated ways configuring a network in such a manner, from which I hoped to identify the relevant registry keys.

The  documentation for the PowerShell “Set-NetConnectionProfile” command lists the following parameters for the “-NetworkCategory” arguments:

Specifies an array of category types of a network. You cannot set the DomainAuthenticated type by using this cmdlet. The server automatically sets the value of DomainAuthenticated when the network is authenticated to a domain controller. The acceptable values for this parameter are:
-- Public
-- Private

I opened up powershell and issued the following command.

PS C:\Users\bradley.SCHATZFORENSIC> Set-NetConnectionProfile -interfacealias “WiFi 3″ -NetworkCategory Public

On running this, we see the Network and Sharing Centre applet immediately updated to indicate that the network was now a Public Network.


Examination of the associated profile shows a registry key called Category. Based on the naming of the powershell argument “NetworkCategory”, I hypothesised that the Category key might contain the value of relevance. In this instance it was set to a value of 0.


I opened then issued the following command.

PS C:\Users\bradley.SCHATZFORENSIC> Set-NetConnectionProfile -interfacealias “WiFi 3″ –NetworkCategory Private

On running this, I saw the Network and Sharing Centre applet immediately update to indicate that the network was now a Private Network.


Refreshing the registry viewer, the value of the Category key was now 1.


I undertook the above for three iterations and observed the same changes every time. I additionally attempted to undertake a Remote Desktop session while both settings were in place. The outcomes were consistent with the description of the above Firewall Rules. When the network was configured as private, I was unable to establish a connection, and when it was configured as public, I was able to establish a Remote Desktop session.

Hypothesis formulation

At this point my hypothesis was that the value of the Category key corresponded to the Network Category of a network profile. That is:

0 == Public

1 == Private

Of course, this hypothesis could be wrong: what if what I was observing was just one of many configurations occurring as a result of the powershell command?

Accordingly, I undertook an experiment to confirm both these interpretations of the values, and their application of the corresponding firewall rules.


I manually edited only the Category key of corresponding Network Profile and set it to 0. I restarted the Windows Firewall Service, at which point, I saw the Network and Sharing Centre applet immediately update to indicate that the network was now a Public Network. I attempted to establish a Remote Desktop session, which failed.

I then manually edited the Category key and set it to 1. I restarted the Windows Firewall Service, at which point, I saw the Network and Sharing Centre applet immediately update to indicate that the network was now a Private Network. I attempted to establish a Remote Desktop session, which succeeded.

I undertook the preceding experiment 3 times and received the same result each time.



I modified the networklist.pl plugin of RegRipper to interpret the Category key per the above theory. A third value of the “Category” key was observed: the value of 2. Based on context in which it came up I have inferred that it refers to a Network Category of Domain. I have not tested this.


I didn’t undertake an exhaustive literature review in regard to the above research, so it may well be that this registry artefact has already been treated elsewhere. Please do let me know if I have missed any prior work that you are aware of.

The updated networklist.pl script is currently in my GitHub branch of RegRipper.

I encourage you to validate this new version of networklist.pl against your own registry and let me know if it is consistent with your running configuration, or not.


UPDATE: Harlan Carvey has merged this patch into the main RegRipper development tree at GitHub.

Presentation: Digital Evidence and the Information Security Manager

I had the pleasure of addressing a seminar related to forensic readiness yesterday to a co-located meeting of three Brisbane professional groups:

Thanks to the attendees for their high degree of participation – it always makes for a lively and engaging time when the audience share their experiences and questions.

Digital evidence and the information security managerUpdate: Typo fixed in slideshare link

View more presentations from blschatz.

Fraudulent email: lessons learned from the OzCar scandal

By now, all but the most naïve of us are immune to the promises of Nigerian riches and the disquieting urges to action from banks which find their way into our email inboxes. Fraudulent emails barely rate any action or consideration beyond that needed to delete them from our inbox. Why is it then that the leader of the Australian opposition, and one of Australia’s most senior lawyers besides, has been tripped up by a fake email?


Australian media reporting has been dominated over the last week by the OzCar scandal. The scandal centres around claims that the Prime Minister (Kevin Rudd) has given preferential treatment to a friend and political donor, car dealer John Grant. Mr. Grant had previously given the Prime Minister a car for use in his campaign and contributed financially to his legal and political endeavours.

An apparent smoking gun in the form of an email was referred to in the senate testimony of Treasury official, Godwin Grech. Mr Grech recalled an email from the PM’s office in relation Mr. Grant and the OzCar financial bailout scheme, which Mr. Grech administered. The email was supposed to have been written by the PM’s economic adviser, Dr Andrew Charlton. The opposition leader seized on the email, calling for the PM to resign.

The PM responded by bringing in the Australian Federal Police (AFP) to investigate the email. On the Monday following Mr. Grech’s testimony, they executed a search warrant on Mr. Grech’s home, and very quickly released their preliminary investigation results. They had found the email in question sitting deleted on his computer. They concluded it was a hoax. Further reports have indicated that the email originated within Treasury.

Mr. Turnbull spent the rest of the week defending both his reliance on the fake email, and  claims that the scandal had been orchestrated. He has since suffered a large fall in public satisfaction, as revealed by today’s poll results.

On email authenticity

This matter highlights the need for a greater degree of scepticism when it comes to reliance on email evidence, as compared with its paper counterpart. Modification of text on paper leaves a trace, whereas the substance of email is modifiable without an obvious trace. Hand written signatures go a long way towards authenticating the author of mail; the email equivalent of a signature is technically possible, however its use remains a niche practice.

Email authentication requires additional corroborating evidence and technical expertise. Metadata hidden within an email can indicate, among other things, the path that the email has taken from the sender to the recipient. This data is typically stored with the email, and can be used to detect tampering or outright forgery of emails.

Each server that an email passes through usually makes a note of the receipt and handoff of the email to the next carrier along the way. Multiple copies of the email may additionally be stored in the senders “Sent Items” folder and in archival or disaster recovery backups. Such information can be used to identify which computer an email originally came from.

Gaining access to these evidence sources is time consuming and often involves the cooperation of multiple parties. Determining authenticity based on such evidence then requires a high degree of expertise.


It is unlikely that either Mr. Grech or Mr. Turnbull would have had access to the corroborating evidence or possess the expertise required to judge the authenticity of the email. Nor for that matter would the average email user.

Day to day though, email authenticity isn’t a problem. Our society largely manages to muddle along with email as one of our primary communications mediums. The reason it works is that each of us make decisions of trust around every email we receive.

Assuming neither Mr. Grech nor Mr. Turnbull fabricated the email, whoever inside Treasury created and sent the email to Mr. Grech relied on exploiting his trust of emails appearing to come from that source. It appears that Mr. Turnbull trusted Mr. Grech in turn.

This affair may mark the end of this kind of trust in emails as concrete evidence and the general acceptance of their authenticity. Certainly you would think so in the case of politicians attempting to score points against their opponents.

More generally though, the wider implications of the increased awareness of the vulnerability of email to fraud will be felt in our courts, where emails are often cited as evidence in both criminal and civil matters.

As for the fake email which has brought all of this to the public’s attention, presumably the AFP are still investigating who the original concocter of the email was. This investigation should lead to an examination of the computer systems of Treasury, where traces of the email, and hence clues to the original concoctor of the email may well remain. In which case, we wait with bated breath to see the next twist in this political drama.

Macintosh Forensic Acquisition

Recently the Mac OS X Forensics site has been amassing a wealth of information on acquiring and analysing Macintosh OS X computers. Additionally, the “Inside the Core” podcast has made a strong start at presenting similar and related content as a podcast. Both teams deserve congratulations and encouragement for their contributions.

One problem that I have observed with acquiring Macs is a particular problem with some Apple keyboards that have a brushed aluminium appearance. They will not reliably allow one to boot to CD or target mode using option keys, due to (purportedly) a firmware bug. The result of this can be an unplanned booting of the hard disk in the computer, and resulting modification of the state of the disk.

I haven’t observed this problem with any other Apple keyboards. Forensic practitioners may want to consider making it a part of your practice to ensure that you are booting with a non aluminium keyboard.

Paper on new evidence container format accepted for presentation at DFRWS2009

Michael Cohen, Simson Garfinkel and I have been collaborating recently on the development of a new digital evidence storage container format. Today we have had notification that a paper detailing the research behind this development has been accepted at the 2009 Digital Forensics Research Workshop, to be held in Montreal Canada. The title of the paper is “Extending the Advanced Forensic Format to accommodate Multiple Data Sources, Logical Evidence, Arbitrary Information and Forensic

A new evidence container is sorely needed by the computer forensics community, due to the large amount of manual work currently required in managing evidence and the closed nature of the current generation of forensic containers and tools. With this new forensic container, we provide an open and extensible container standard which promotes forensic tool interoperability and simplifies evidence sharing and management.

Technically, this new container achieves these things by enabling:

  • efficient random access storage of multiple streams of digital evidence within a single container;
  • storage of arbitrary information such as case relevant information or tool derived analysis results;
  • composition of evidence containers into a larger corpus of related evidence through an inter container referencing scheme;
  • decomposition of evidence containers into sets of smaller containers to support filesystem limitations;
  • definition of virtual evidence streams as maps of existing evidence streams.

The new format is slated to replace the current generation of Simson’s Advanced Forensic Format (AFF) and will be known as AFF4. Michael has been providing some documentation on the format over at the forensicswiki, and he has a beta quality implementation in the C language. Plans are in place for a JAVA based parallel implementation.

The abstract follows:

Forensic analysis requires the acquisition and management of many different types of evidence, including individual disk drives, RAID sets, network packets, memory images, and extracted files. Often the same evidence is reviewed by several different tools or examiners in different locations. We propose a backwards-compatible evolutionary redesign of the Advanced Forensic Format—an open, extensible file format for storing and sharing of evidence, arbitrary case related information and analysis results among different tools. The new specification was designed to be simple to implement, allowing the use of the well
supported Zip File format specifications for bit level file access.

UPDATE: The paper is now published on the DFRWS 2009 website.

dd2vmdk relocated into the cloud

A while ago I wrote a tool to convert flat disk images (which we commonly call dd images) to VMWare .vmdk disk images (the original blog post on the tool, called dd2vmdk is posted here). I have in the mean time ceased development of it, but despite its relatively archaic nature, some still find it of use.

Today I relocated hosting of it to Google’s new cloud web application service, Google App Engine. My motivations to do this were to reduce adminitrative burden, to eliminate server costs, and to increase long term availability (the Java App Engine is Beta, so there might be some short term availability issues).

The relocation took roughly one hour of my time, was dead simple, and required no code modification, just the simple addition of a new text configuration file.

dd2vmdk is still available via my personal website.

Schatz Forensic launched

Since March I have returned to practicing under my own banner. I have taken this opportunity to change the name of my company to Schatz Forensic, to better reflect the focus of the business and the personal nature of the services that I offer. Schatz Forensic is now operating out of premesis in the Brisbane CBD, and continues to offer the same computer forensics and electronic discovery services that I have provided in the past.

libewf has relocated

This won’t be news to many, but I came across a colleague today who didn’t realise that the libewf project has moved home to sourceforge.

Libewf is the only open source implementation of the Expert Witness Format (EWF) file format, which is the de facto standard for storage of forensic disk images. This open source implementation contains numerous utilities, including a faster than LinEn, UNIX based, command line EWF acquisition program, ewfacquire, and a command line validation utility called ewfverify. This latter tool I have found extremely useful in automating the evidence preservation process.

Related news is that Joachim Metz, the creator of libewf has recently released libpff, an open source implementation of the Outlook PST, OST and PAB file formats.