A tale on RegRipper Plugins unnoticed

Last weeks...

it cames out that some RegRipper Plugins have errors and/or do not parse correctly/at all the desired keys. This fact should not be unexpected since there exist many plugins (from far less many contributors, unfortunately) and since they should work on xp-(s)vista-7 Windows OSes: errors are around the corner. What is really unexpected is the delay with which they were detected by the DFIR community (included me, of course). Let's start with the first case.

 

timezone.pl

This plugin "accesses the System hive file to get the contents of the TimeZoneInformation key", and it's one of the first-most important information I usually get from the System hive, since I need to understand when things happened. That's the output coming from version 20110901, executed on a XP system:

Launching timezone v.20110901
timezone v.20110901
(System) Get TimeZoneInformation key contents

TimeZoneInformation key
ControlSet001\Control\TimeZoneInformation
LastWrite Time Mon Mar 28 08:02:41 2011 (UTC)
  DaylightName    -> ora legale Europa occidentale
  StandardName    -> ora solare Europa occidentale
  Bias            -> 4294967176 (71582787.2666667 hours)
  ActiveTimeBias  -> 4294967236 (71582786.2666667 hours)
  TimeZoneKeyName -> N/A

In bold-black there is the main information I usually look for, that is the TZ StandardName. In bold-red there is the information I noticed but I did not take into account: I could argue a lot of "good" excuses for not having considered it, but I think that the mission of a DIFR includes to never overlook/skip anything weird/not understood. So I started getting information about it (them).

Gugling around I was able to find many references on Bias and ActiveTimeBias, included on MSDN. Bias: "This is the time Bias for the configured time zone. The Bias is specified in minutes from UTC". ActiveTimeBias: "The active time Bias as configured for the time zone accounting for DST. This is the bias that was used to configure the CMOS clock. The Bias is specified in minutes from UTC". Hum, ok, but then, considering the output above, I'm expecting to see Bias=60 and ActiveTimeBias=120 since the hive is coming from Rome Tz, UTC+1 (+daylight), and it's not. Le'ts go into the registry:

 

They are both REG_DWORD, and they seem to be signed values... but the plugin is not considering sign. I modified the plugin to show the sign and that's the result:

DaylightName    -> ora legale Europa occidentale
StandardName    -> ora solare Europa occidentale
Bias            -> -120 (-1 hours)
ActiveTimeBias  -> -60 (-2 hours)
TimeZoneKeyName -> N/A

Ok, that's far more better! But two other questions arises (everybody spotted them, isn't it?): why they are negatives (the example is UTC + 2!) and why the Bias is greater than ActiveTimeBias? I guess the first question answer: the Bias and ActiveTimeBias are the amount of minutes that should be added with sign to the localtime to get the UTC time. And that's probably the reason why west-people (usually on the left on the map with respect to Greenwich, but that's relativity...) did not ever complained about those values, since they get positive values to obtain UTC time. But they should have complained (est-people too, me included obviously) with regard to the swapped Bias/ActiveTimeBias values! Looking at the plugin code:

my $bias   = $tz_vals{"Bias"}/60;
my $atbias = $tz_vals{"ActiveTimeBias"}/60;

::rptMsg("Bias -> ".$tz_vals{"ActiveTimeBias"}." (".$bias." hours)");
::rptMsg("ActiveTimeBias -> ".$tz_vals{"Bias"}." (".$atbias." hours)");

The printout swapped the two variables. This output error was noticed by Tom Paschal who reported it on the RegRipperPlugins site: I really thanks him for reporting the error and for the modality he chose, by opening an Issue on the Google Code site (that's not the only way, but it's effective and allows the maintainers to be quickly alerted). His issue allowed me to finally face those horrible negative values... And that's the final result (I added the "Bias" value too):
 

 DaylightName    -> ora legale Europa occidentale
 StandardName    -> ora solare Europa occidentale
 Bias            -> -60 (-1 hours)
 ActiveTimeBias  -> -120 (-2 hours)
 DaylightBias    -> -60 (-1 hours)
 TimeZoneKeyName -> N/A

[01/may/2012 thought: Windows expects a localtime timestamp from BIOS/CMOS clock, so it needs to know how much add/subtract from it to get the UTC timestamp, used, for example, inside NTFS metadata. Who is remembering the annoyances coming from dual-boot Windows/Linux, the latter usually expecting the BIOS/CMOS timestamp as being UTC?]


The last question is: how can these discrepancies have been ignored for so long? That's will allow me to write the moral of the post, later.

userassist2.pl

 
I will not provide so many details here, just the fact that the parsing error inside this plugin was spotted by Brad Reninger at 12 April 2012: again, thank you Brad for reporting on win4n6 mailing list, the best (great) place to share these issues. It came out that the error (see win4n6 for details) was already noticed and fixed by Shafik Punja (and from another "anonymous") in December 2011, who then provided the fix together with error description: thank you Shafik [01/may/2012 addendum: as Shafik commented, the fix was provided by John Lehr. Credits to both!]. But let's go further...

comdlg32.pl

This is another error (indeed not really an error but a fault) detected with an incredible delay. On the win4n6 ml Jimmy Weg spotted the plugin fault at 4 April 2012: thanks Jimmy! The plugin does not parse the subkeys inside "NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32" coming from Vista/Windows7 OSes: I'll not recall here the relevance of such subkeys, please inform by yourself. I think there are 3-4 years that none is able to get such information from Vista/7 hives using RegRipper! Once informed, Harlan Carvey started to explore the issue: the binary format used in OpenSavePidlMRU subkeys is not straightforward and it is needed some study to correctly parse it. I tried to face the problem too, and I was not able to completely understand all fields composing that binary blobs. I want to thank both Alfons Kramer (X-Ways Forensics) and Mark Woan (Woanware) that shared information with me by pointing out that those data structures are Item Descriptor Lists, related to the Windows Shell: indeed X-Ways Forensics and RegExtract are doing a good job in parsing those keys (even if missing/not reporting some details). I was able to get useful links from Microsoft, such as "Introduction to the Shell Namespace" and "ITEMIDLIST structure" but despite those tips I have not yet the solution (lack of time resources too).

The moral of the post

It's not a matter of getting a new/fixed RegRipper plugin but it's a matter of understanding what this tool (or any tool you are using) is reporting: it's a matter of knowledge. Since DFIR is facing the whole digital world there is a need of DFIR knowledge sharing: none should think to be able to manage it by himself (IMHO). By contributing to spot/fix discrepancies, faults and errors on RegRipper (or whatever), one is contributing to increase the DFIR knowledge and confidence/trust in artifacts' significance. As should be evident, the first level is parsing, the second level is parsing correctly (syntactic), the third level is understanding what those values represent (semantic, in general and in the specific case).

RegRipperPlugins update

For those people interested in the RegRipperPlugins packages, a new one will be released soon, containing the fixed timezone.pl and userassist2.pl plugins at least. You will be informed on win4n6 ml, on Brett Shavers blog and on the Google code site.