Search This Blog

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 delaywithwhich they weredetected 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:

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:

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 localtimeto 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:

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):

[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 win4n6mailing 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

Thisis anothererror (indeed not really an error but a fault) detectedwith 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 anytoolyou areusing) 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.pland userassist2.pl plugins at least. You will be informed on win4n6 ml, on Brett Shavers blog and on the Google code site.

Comments

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

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

Those who follow this blog may have noticed few months ago a post that introduced WhatsApp Xtract: this script was able to display in an HTML document all the WhatsApp messages extracted from an iPhone. And those who follow the xda developers forum may have recently noticed a thread on it.
This last month, thanks to Martina Weidner (aka ztedd) who has decided to take control of its development, we have obtained valuable results. Intro:WhatsApp is a widespread instant messaging application for smartphones, available for iOS, Android, BlackBerry, Symbian and Windows Phone. The chance to replace the traditional SMS service avoiding its cost, has allowed this application to gain popularity very quickly. The automatic synchronization of the app to the phone address book, the unlimited message length and the possibility to share an high range of multimedia attachments have persuaded many people... and who cares if it has suffered from some security issues!

Few weeks ago I was contacted about how to decrypt Windows Dropbox DBX files and the same topic appeared on SANS DFIR mailing list too. So I decided to create an Open Source toolkit and this post to brush up on the DBX files create by the Dropbox client on a Windows machine.

The Windows Dropbox client keeps its own files - user info, configuration, 'my dropbox' files sync status and even more - inside the user profile: on the Windows 7 and Windows 10 machines I used for test they reside in '\Users\%USERNAME%\AppData\Local\Dropbox\' and sub folders. Among them there are files with .DBXextension, which are the target of this post. When you take a raw look at them, you see garbage, noise... encryption is in place.

Without too much suspence, this is well-known. Nicolas Ruff and Florian Ledoux had a talk at hack.lu2012 on the topic, “A critical analysis of Dropbox software security” (here). They discovered that the encryption key used for DBX files is kept in the registry …

Windows Phone 8 and greater allows the user to lock/unlock the phone by using a numeric PIN code: it's even possible to use a complex alphanumeric password. This post addresses how to obtain the simple numeric PIN code by cracking the authenticator kept in the SOFTWARE hive. an useless quest?
Actually if you have a physical access to a Windows Phone you don't need the user pincode to examine the user data: with the proper hardware you can usually get a whole dump of the un-encrypted device memory. To my current knowledge the pincode is not used anywhere if not for device locking, so it's almost useless to know it. If the device is under a properly configured MDM, you could face a fully encrypted phone with TPM: in this case you'll have no chance to crack the pincode, even if more testing should be done.

This is exactly what I thought when my colleague Mattia Epifanitried to lure me with the Windows Phone PIN issue: he knows the curious monkey inside me... but I was a re…