WIndows SetupAPI log files

USB device history is a great source of evidence during forensics analysis. In windows, there are more specific locations where reveal USB device history and various data related to USB devices. In most of these locations, we can see either a Windows registry key or a bunch of windows registry keys or a log file. SetupAPI files are great example log files to this.

The SetupAPI log files mainly split into two types based on log entries.

1. setupapi.dev.log:

This log file contains log entries related to the device and device driver installations

2. setupapi.app.log:

This log file contains log entries related to the application installations.

The first log file, setupapi.dev.log, can be used to determine the temporal usage of specific USB devices connected to a Windows Machine. They store all events related to drivers and devices loaded on to the system with timestamps and driver information.

You can see this log file in the below-mentioned paths in your windows machines.

In Windows XP machines,

C:\Windows\setupapi.dev.log

In Windows 7/8/10,

C:\Windows\inf\setupapi.dev.log

After analyzing this setupapi.dev.log file, you can extract some great artifacts related to your windows machine and USB devices you or someone else plugged into your machine. Briefly following artifacts can be extracted from this log file.

1. OS version: The current version of your windows operating system installed on your machine.

2. Service Pack: Windows operating system service pack or the windows update, often combining previously released updates.

3. Suite:

4. Product type:

5. Architecture:

6. Boot sessions: this is a timestamp data related to system boot time.

all of the above artifacts are formated as follows in the setupapi.dev.log file.

[Device Install Log]
     OS Version = 6.1.7601
     Service Pack = 1.0
     Suite = 0x0100
     ProductType = 1
     Architecture = amd64

[Boot Session: 2020/12/29 21:47:17.453]

7. USB vendor Ids:

using these artifacts, you have access to determine,

the external devices were plugged in for the first time
a malicious driver was loaded onto the system
what drivers were loaded for an unknown device and its functionality.
providing a device was successfully installed and accessible.

Basically, the full log entry is based on three sections. First, it has a section header, then the body of the log entry, lastly, the foot of the log entry. With these three sections, we have a complete log entry about what happened after we plugged a USB device into our windows machine and we have a lot of data about behind the scenes.

we can visually represent this as below,

>> [Header section]
>>  [body]
>> [Foot]

Header section:

The section header is a combination of three fields.
1. section_title = all header sections have a section title and it provides a title for the operation that is associated with the section.

2. instance_identifier = provides an identifier that, ideally, uniquely, identifies the instance of the operation.

3. timestamp subfields = provides the time data related to the start of the section. the timestamp format they used to enter the log is as follows. yyyy/mm/dd/ hh:mm:ss.sss

yyyy = year as a four-digit number
mm = month as a two-digit number
dd = day as a two-digit number
hh = hour as a two-digit number
ss = seconds as a two-digit number
sss = milliseconds as a three-digit number.

We can represent the format of the section header as follows.

>> [section_title instance_identifier]
>> [start timestamp field]

If we provide some examples for this section header, it looks like follows,

>>>  [Device Install (Hardware initiated) - STORAGE\VolumeSnapshot\HarddiskVolumeSnapshot19]
>>>  Section start 2020/12/30 20:04:13.174

>>>  [Import Driver Package - C:\Program Files\Microsoft Office\Office15\OneNote\\prnSendToOneNote15_Win7.inf]
>>>  Section start 2020/12/30 19:56:51.549

>>>  [SetupCopyOEMInf - C:\Windows\System32\DriverStore\FileRepository\wdcsam.inf_amd64_neutral_2efd3a3b82aeb664\wdcsam.inf]
>>>  Section start 2020/12/29 23:25:47.511

In this scenario, it's worth mentioning that I analyzed Alan's(older pc running windows 7. I named it Alan.) setupapi.dev.log file with Windows 10 setupapi.dev.log file and the basic structure of the log entries are very similar.

Body:

you can see either zero or more log entries in this section. entry_prefix, time_stamp, event_ category, indentation, formatted_message fields are contained in the basic structure of the body section. This can be represented as follows.

>> [entry_prefix time_stamp event_category indentation formatted_message]

Especially note that the maximum length, in characters, of a section body log entry is 336.

There are a lot of signs and symbols to know in this section. To read and understand the log entries in a meaningful way, you need to know about those signs and symbols and their meanings.

In the entry_prefix field, you can see the following symbols and this field is used to identify the type of the message. This field is always present.

!!! = An error message
! = A warning message
= An information message

time_stamp field indicates the system time when the logged event occurred and it is very similar to the timestamp field you saw in the header section. in the body section, the timestamp field is an optional field. by default, in a lot of log entries, you won't see a timestamp field. In the following two examples, you can see a message without the timestamp and another message with the timestamp. A function called SetupWriteTextLog has the responsibility to write the time_stamp field in the log entries. In another post, I will cover the SetupWriteTextLog function.

time_stamp = 21:48:11.429

     ndv: Waiting for previous device install to complete. 21:48:11.429

no time_stamp field.

!!!  inf:                          Failed to load the OLE Control 'C:\Windows\system32\igdumd32.dll'.

event_category field indicates the category of operation that made the log entry. this field is usually present but some log entries haven't an event_category field. To identify the event_category field in a meaningful way, we have to know below strings and symbols and their meanings.

...: = vendor-supplied operation

bak: = backup data

cci: = class installer or co-installer operation. Eg:

     cci:                NdisCoinst: Connection name is Local Area Connection

cpy: = copy files Eg:

     cpy:      Policy is set to make all digital signatures equal.

dvi: = Device installation Eg:

     dvi:      Searching for hardware ID(s):

flq: = Manage file queues Eg:

     flq:                          CopyFiles from an inbox inf.

inf: = Manage INF files Eg:

     inf:                     {Install Inf Section [atapi_Inst] exit (0x00000000)}

ndv: = New device wizard Eg:

     ndv:      Pruning file queue...

prp: = Manage device and driver propertises reg: = Manage registry settings

set: = General setup Eg:

     set: DIF_FIRSTTIMESETUP failed with 0xE000020E for class {25dbce51-6c8f-4a72-8a6d-b54c2b4fc835} (Mobile devices)

sig: = Verify digital signatures Eg:

     sig:           FilePath = C:\Windows\inf\netrasa.inf

sto: = Manage the driver store Eg:

     sto:      Importing driver package into Driver Store:

ui: = Manage user interface dialog boxes

ump: = User-mode PnP manager Eg:

     ump:      Server install process exited with code 0x00000000 21:59:40.489

indentation field is a sequence of zero or more indentation units(monospace strings). This is an optional field and in an indentation unit, we can see five spaces. As I mentioned earlier, SetupWriteTextLog supports changing the number of indentation units that are included in a log entry.

formatted_message field contains specific information about the log entry like what happened in that specific current time.

It is also worth mentioning that the log entries we can saw in the body section depend on two levels, event-level is the first one and category level is the second one. In a later post, I will cover more details about these settings. Also, indentations are applied to log entries in the body section to notify subsections from main sections.

As an example, we can see below log entries.

     inf: {SetupCopyOEMInf: C:\Windows\INF\oem14.inf} 21:59:38.975
     inf:      Driver Store location: C:\Windows\System32\DriverStore\FileRepository\ich78id2.inf_amd64_neutral_64bf4c4608ae7e8a\ich78id2.inf
     inf:      Published Inf Path: C:\Windows\INF\oem14.inf
     inf:      Opened INF: 'C:\Windows\INF\oem14.inf' ([strings])
     inf:      Saved PNF: 'C:\Windows\INF\oem14.PNF' (Language = 0409)
     inf:      Installing catalog ich78id2.cat as: oem14.CAT
!    inf:      Failed to install catalog - error ignored
!    inf:      Error 2: The system cannot find the file specified.
     inf:      OEM source media location: C:\Windows\INF\
     inf: {SetupCopyOEMInf exit (0x00000000)} 21:59:39.178

The Footer section is the closing section of a complete log entry. The footer section can represent in the following way with its fields. we can identify a footer section in an easy way because it started with the prefix <<<.

<<< [time_stamp Section end] or <<< [Section end time_stamp]
<<< [Exit Status(status)]           [Exit Status(status)]

The format of the status field is 0xhhhhhhhh where hhhhhhhh is an 8-digit hexadecimal number.

sometimes we can see the status field has clear meaningful words like SUCCESS. For example;
<<< [Exit status: SUCCESS]

The above mentioned, hexadecimal status field appear due to some failures or errors. for example,
<<< [Exit status: FAILURE(0xe0000203)]

0xe0000203 is the error code and it represents the error that occurred during the process. Also, note that above mentioned, [time_stamp Section end] format used in older windows machines like XP.

There are lots of information to tell you about these log files and how to read these log entries. I will cover more depth information about reading these logfiles because a lot more log entries aren't reader-friendly.

Finally, why we need this data and informations and how to use this for real-world applications. We can easily identify issues, their type, what is the reason for those issues or a particular issue related to our windows machines by analyzing and convert these log files into a more reader-friendly way. creating a firmware like software or a program and apply that to a USB device to automatically diagnose the entire windows system to identify the errors and automatically provide the solutions for those errors. Analyzing and identifying these log files give you special benefits for creating applications like mentioned above.

I hope you enjoyed the post and Thank you for reading.

CW's Programming