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.


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
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.


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...


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.


  1. a most excellent post francesco; thank you so much for sharing. credit for fixing the userassist2.pl goes to John Lehr (http://linuxsleuthing.blogspot.ca/); it was his ideas of comparing this plugin to its tln version, that led me to the code comparison exercise!! i look forward to the plugin updates when they are ready!!!

    1. Thanks Shafik for the specification (post updated) and for the John's blog link I did not know (just added to my blog list).

  2. Excellent post. Since I released RegRipper in 2008, it's been completely open source, and yet I've been surprised at the number of users who will ask a question about the data provided by RegRipper without first either searching the plugins, or actually looking at a plugin with Notepad. This probably accounts for why some issues aren't reported, and of those that are (ie, Userassist.pl) some aren't addressed in as timely a manner as most would like.

    I've been looking into the comdlg32.pl plugin, as well...and I did receive your email about the links, but it's taking a great deal of time to make the transition from MS "documentation" to a working plugin that doesn't rely on the MS API.

    Thanks for highlighting this issue.

    1. Thanks Harlan. I share with you the feeling that RegRipper users usually don't open (take a look inside) plugins, like they were black-box-technology: inside plugin there exist references and comments that are essential information (moreover they are quite easy to be read).

      I think that Analysts have a huge responsibility (better: it's up to them) in spotting faults/errors from tools, since they will base conclusions on processed artifacts. Then, they will be called to explain those conclusions and those artifacts regardless of the tool used. As I asked to myself, how many missed and wrong interpretated artifacts are around? I think there are few resources dedicated to the verification/testing phase... (I recall the Girl Unallocated post "Sherlock and the Un-Scientific Method" here http://girlunallocated.blogspot.com/2011/06)/sherlock-and-un-scientific-method.html avoiding to "bother" with Popper's disquisition on the scientific method).

      Finally, thanks for your "comdlg32" efforts: I'm missing exactly what you pointed out, that is the complete format understanding without MS API. Waiting the next step here, whoever will contribute.


Post a Comment

Popular posts from this blog

Huawei backup decryptor

iOS 15 Image Forensics Analysis and Tools Comparison - Processing details and general device information

A first look at Android 14 forensics