Introducing Evimetry: digital forensics at wire speed

Digital forensics is full of waiting. Waiting for acquisitions to complete. Waiting for images to process. Waiting for flights and waiting in data centres.

We set out to remove this wait.

In November 2014, Schatz Forensic quietly opened a beta program for a new forensic tool aimed at speeding forensic workflow. The innovative system accelerates acquisition and processing of evidence and closes the gap between acquisition and analysis.

A long beta program has allowed us to listen to our testers, and target the pain points in their forensic process. Practitioners love the faster acquisitions and processing, and cutting hours of wait time from cases. Incident responders are excited by travel-free remote live analysis, and rapid partial imaging of high value artefacts.

Today marks the general availability release of Evimetry Wirespeed. If you are ready for a more efficient workflow and less waiting, visit or contact us.

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 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 script is currently in my GitHub branch of RegRipper.

I encourage you to validate this new version of 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.

Zone Identifier Internals

The “Zone.Identifier” file is a common artefact observed when undertaking forensic examinations of Windows systems. More correctly, this isn’t a file. Rather, it is an Alternate Data Stream (ADS), attached to content downloaded from the internet by Internet Explorer. The stream’s purpose: to record the source of the file so that judgements about its level of trust can later on be made by the Windows OS, particularly when running downloaded executable files.

Raymond Chen describes using windows API’s to access this, and points to further background on this artefact.

CFP: Digital Forensics of Embedded Systems

The Journal of Digital Investigation is currently calling for papers for a Special Issue on Digital Forensics of Embedded Systems. The Guest Editors of this issue are Pavel Gladyshev, Ronald van der Knijff & Bradley Schatz.

We would welcome any novel research into aspects of digital forensics of embedded and mobile computing devices. Submissions are due 1 October 2013.

UPDATE: The due date for submissions for this CFP has been extended to 20 February 2014.


The Journal of Digital Investigation covers cutting edge developments in digital forensics and incident response from around the globe.

We welcome submissions for a special issue on Embedded Systems.

The issue will focus on the challenges presented to digital forensics and incident response in the shift from commodity monolithic operating systems and hardware platforms to bespoke and embedded computing devices.

We seek submissions including case studies, practitioner reports of what works in practice, survey articles covering state-of-the-art and future needs, objective tool reviews, and relevant legal analysis. We are also looking for work that proposes possible normalization and standardization in this area.

Deadline for submissions is 20 February 2014.

Visit the journal page for more information and to contribute to this special issue.
An embedded system is a computer system that controls operation of a special purpose machine or device, such as

  • automobile engine, brakes, navigator,
  • mobile phone,
  • SCADA/ICS device,
  • smart meter,
  • CCTV camera  recorder,
  • toy,
  • washing machine,
  • mini PABX,

Individual embedded systems are becoming increasingly networked forming the foundation of what is now called smart homes and smart cities. Being part of everyday human activities, embedded systems can be an important source of evidence in digital investigations.

The embedded systems range in complexity from primitive controllers with well defined, fixed functionality, to 32-bit systems capable of running full versions of Linux or Windows.  Most embedded systems are proprietary, bespoke systems, whose interfaces, data structures and internal operation are protected by NDAs.  As a result, the extraction and interpretation of the data from such systems is a major challenge of embedded system forensics.

Embedded systems are increasingly employed for acquisition & analysis tasks in forensic practice. There may be novel forensic applications of embedded systems with the potential to greatly enhance the efficiency of investigations.

In an effort to increase understanding and advance the state of the art, this special issue is dedicated to presenting the varying views regarding digital forensics of, and with, embedded systems.
Submit a case study, survey paper, tool review, or other contribution now.
Visit for more information.

Mobile phone forensic analysis–analysis of JTAG and Chip Off images of Android YAFFS Flash

On 18 October 2012 I presented, at the Breakpoint 2012conference, some preliminary results of research I have been undertaking in the area of forensic acquisition and analysis of mobile phones. Specifically I have been focusing on Android phones using NAND flash memory and the YAFFS2 file system. The seminar principally addressed methods of acquisition (JTAG and Chip Off) and the fundamental challenges of reconstructing YAFFS2 file systems from said acquisitions. The slides from the presentation can be found here.


Object Headers Slide Screenshot

If you are currently undertaking work in this area and having trouble interpreting any flash images, I would be happy to hear from you.

Android forensic analysis lecture at Breakpoint2012 (AU)

I will be presenting a lecture on Android forensics, focusing on flash acquisition and YAFFS2 filesystem analysis at the Breakpoint 2012 conference in Melbourne, Australia, this October 18.

The speaker lineup is looking fascinating, with leaders in the area of mobile security (both IOS and Android), hardware reverse engineering and Windows internals being on my list of lectures to attend.

Digital forensic evidence chapter published in Expert Evidence text

My chapter on digital evidence has recently been published in the Australian authority on Expert Evidence. The chapter joins technical treatment of over 75 other areas of expert evidence.

The chapter aims to inform the legal professional and fact finder as to the foundations, context, principles, practices, limitations and challenges of the field of digital forensics, in order that they may understand the field enough to effectively engage with the digital forensic expert. It is anticipated that this chapter will additionally be of interest to practitioners and researchers in the field.

The chapter is currently available only to subscribers of the loose leaf service and online via Westlaw AU and Thomson Legal Online. The chapter will be individually purchasable via the above website in due course; if you wish to purchase a copy in the short term, please contact Thomson Reuters via email.

Digital Evidence and Computer Crime 3rd edition – book chapter in press

I just received in the mail an author’s advance copy of Eoghan Casey’s "Digital Evidence and Computer Crime". Originally published in 2000, this update sees the book now in its third edition. Amongst a wide range of significant updates  is a chapter Eoghan and I co-authored. The focus of the chapter is on methods of conducing digital investigations.

Identifying methods of reliably transitioning from investigative goals or claims to substantiated facts has been a significant preoccupation within the field over the last decade. Perspectives have ranged across extremes: from those that deny such methods exist (“it’s an art”) to those that attempt to characterise method as a system or recipe  (“it’s a process”). Only in recent years have clear inroads been made into the relationship between digital forensics and the scientific method in general.

The chapter begins with a comparison of a wide range of perspectives on digital investigation methodologies, and follows with practical guidance on applying the scientific method as a methodology for each step of a digital investigation. The chapter concludes with an investigative scenario demonstrating how the scientific method may be applied in the context of an actual case.

Finding Object Roots in Vista (direct from dump file)

The last post discussed finding object roots in Vista using the self referential semantics of the Kernel Processor Control Region (KPCR). Object roots are the starting points that structural interpretation approaches use to begin to interpret kernel structures, in much the same way that one might use the MBR of a hard disk to find partitions on a drive, or the NTFS boot sector to find the MFT area in a filesystem.

The KPCR scanning approach is general purpose in nature. Assuming an appropriate value for the Directory Table Base of the kernel address space, it will yield potential KPCR structures. It is, however, time consuming. Windbg is able to almost instantly find the KPCR in images stored as dump files, so it obviously isn’t employing scanning as a method of identification.

Looking further into the Microsoft dump file format, the dump file has a header which contains a field called KdDebuggerDataBlock, which is a pointer to the kernel virtual address of a KDDEBUGGER_DATA64 structure. This is the same structure which is the end goal of the KPCR trick.

Accordingly, when run against a dump file, the experimental version of volatility currently uses the KdDebuggerDataBlock as the object root, rather than KPCR.

Finding Object Roots in Vista (KPCR)

This is the third of a series of posts describing how  the volatility memory forensics application was ported to a new Windows operating system version.

Apart from the inevitable changes in kernel data structures which typically come with a new kernel version, Vista brought with it a change which broke one of volatility’s key techniques for identifying kernel objects. The change was Address Space Layout Randomisation (ALSR). Thanks to Gil Peterson for sharing this detail.

Structural interpretation approaches to volatile memory analysis rely on finding an initial kernel object from which one may traverse to other objects, in order to find  objects of interest to the investigator. With XP, volatility employed “the KPCR trick”. XP reliably stored the “Kernel Processor Control Region” at a fixed kernel virtual address (0xffdff000). From the KPCR structure, one then traverses intermediate structures (KdVersionBlock, then DebuggerDataList)  to access interesting structures such as the active process list.

In Vista, KPCR is not stored at a fixed address, so the first problem in porting volatility to Vista and above, to reliably get an initial reference to a valid KPCR structure.

Damien Aumaitre points out in his 2009 paper "A little journey inside Windows memory" that KPCR is self referencing. Based on this observation I undertook the following investigations:

1. I loaded up windbg to look at the KPCR of a XP dump file.

2. Set the symbol path

.sympath SRV*C:devsymbolcachesymbols*


3. Examined the KPCR

kd> !pcr
KPCR for Processor 0 at ffdff000:
    Major 1 Minor 1
    NtTib.ExceptionList: ed89dcf0
        NtTib.StackBase: ed89ddf0
       NtTib.StackLimit: ed89a000
     NtTib.SubSystemTib: 00000000
          NtTib.Version: 00000000
      NtTib.UserPointer: 00000000
          NtTib.SelfTib: 7ffdf000

                SelfPcr: ffdff000
                   Prcb: ffdff120
                   Irql: 00000000
                    IRR: 00000000
                    IDR: ffffffff
          InterruptMode: 00000000
                    IDT: 8003f400
                    GDT: 8003f000
                    TSS: 80042000

          CurrentThread: 86724020
             NextThread: 00000000
             IdleThread: 80552740


4. Note that the first line indicates that KPCR is at VA 0xffdff000, which is to be expected. Note also that the SelfPcr attribute (at offset 0x1c from the start of the structure) has the same value at the address of the KPCR. This is what Aumaitre means by self referencing. There exists an additional self referencing property here related to the Prcb field which I will not go into.

5. Repeating the above on a Vista image gives the following. Note that the KPCR structure is not at 0xffdff000, and again, that the SelfPcr field points to the KPCR address.

kd> !pcr
KPCR for Processor 0 at 818f4700:
    Major 1 Minor 1
    NtTib.ExceptionList: 9a7bfcf0
        NtTib.StackBase: 00000000
       NtTib.StackLimit: 00000000
     NtTib.SubSystemTib: 80148000
          NtTib.Version: 000c3fac
      NtTib.UserPointer: 00000001
          NtTib.SelfTib: 7ffdf000

                SelfPcr: 818f4700
                   Prcb: 818f4820
                   Irql: 00000000
                    IRR: 00000000
                    IDR: ffffffff
          InterruptMode: 00000000
                    IDT: 822eb400
                    GDT: 822eb000
                    TSS: 80148000

          CurrentThread: 89d5eac0
             NextThread: 00000000
             IdleThread: 818f8300


6. I checked the offsets for the SelfPcr as below:

kd> dt -r0 _KPCR 818f4700
   +0×000 NtTib            : _NT_TIB
   +0×000 Used_ExceptionList : 0x9a7bfcf0 _EXCEPTION_REGISTRATION_RECORD
   +0×004 Used_StackBase   : (null)
   +0×008 Spare2           : (null)
   +0x00c TssCopy          : 0×80148000 Void
   +0×010 ContextSwitches  : 0xc3fac
   +0×014 SetMemberCopy    : 1
   +0×018 Used_Self        : 0x7ffdf000 Void
   +0x01c SelfPcr          : 0x818f4700 _KPCR
   +0×020 Prcb             : 0x818f4820 _KPRCB
   +0×024 Irql    
0;        : 0 ”
   +0×028 IRR              : 0
   +0x02c IrrActive        : 0
   +0×030 IDR              : 0xffffffff
   +0×034 KdVersionBlock   : 0x818f3c18 Void
   +0×038 IDT              : 0x822eb400 _KIDTENTRY
   +0x03c GDT              : 0x822eb000 _KGDTENTRY
   +0×040 TSS              : 0×80148000 _KTSS
   +0×044 MajorVersion     : 1
   +0×046 MinorVersion     : 1
   +0×048 SetMember        : 1
   +0x04c StallScaleFactor : 0×962
   +0×050 SpareUnused      : 0 ”
   +0×051 Number           : 0 ”
   +0×052 Spare0           : 0 ”
   +0×053 SecondLevelCacheAssociativity : 0 ”
   +0×054 VdmAlert         : 0
   +0×058 KernelReserved   : [14] 0
   +0×090 SecondLevelCacheSize : 0
   +0×094 HalReserved      : [16] 0
   +0x0d4 InterruptMode    : 0
   +0x0d8 Spare1           : 0 ”
   +0x0dc KernelReserved2  : [17] 0

Scanning KPCR in Vista memory dumps

With the former in mind, I set about writing a volatility scanner that scans the kernel address space for potential KPCR structures. I note here that in my development I have relied on dump files generated by Matthieu Suiche’s win32dd. Dump files store the physical address of the kernel page directory base, which is enough to reconstruct the kernel address space, however, other means will be necessary if operating on raw (DD) style memory images.

The scanner runs through each kernel address space memory region, looking for memory patterns that match the following constraints:

  1. The VA of the start of candidate bytes  >= 0×80000000 (i.e. it is in the kernel address space)
  2. The SelfPcr field at offset 0x1c from the start of the candidate bytes contains a pointer to the virtual address of the start of the KPCR structure
  3. The Prcb field at offset 0×20 within the structure contains a pointer to the start of the _KPRCB structure, which is embedded within the KPCR structure at offset 0×120.

I have observed the above scanning technique to identify one KPCR value per processor, which is consistent with the described function of the KPCR – it is a per processor structure.


The above scanner is usable as the volatility command kpcrscan, and the output of it used via the parameter –kpcr=

An example of usage is presented in the screen capture below: