Pages

Wednesday, September 28, 2005

System Clock

Recently, a post in a public forum appeared, asking about how to verify the accuracy of the system clock. That got me to thinking...how do you verify the accuracy of the system clock, given nothing more than an image of a Windows system?

I decided to start some of my own research, and to post in other lists to see what others were doing. I received several responses, but most have been along the lines of:
  • Completely missing the part about an "image"
  • Using email headers
Now, these responses aren't bad, because they do point out something very important...that there really isn't any set way to establish the accuracy of the system clock, based solely on the contents of an image. The use of email headers does, however, assume that the intermediate systems that stamp the email have accurate system clocks...something I wouldn't be willing to bet on.

So I set about performing my own experiments to see what happened. First, I ran InControl5 to baseline my system. When the baseline was complete, I double-clicked the time display on the far right of my Task Bar, and that opened the "Date and Time Properties" window, which is essentially the timedate.cpl Control Panel applet. I modified the system time, clicked "OK", then ran the second half of the InControl5 process.

Viewing the results, I ran across a couple of interesting things. First off, the following UserAssist key had been updated.

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}/Count

I ran my "uassist.pl" Perl script to translate the values under this key, and found "timedate.cpl". Unfortunately, this key doesn't maintain its values along with an MRU list, so we don't know which was the last value, and therefore, the LastWrite time of the key is of little value to us.

When I actually opened the Control Panel and double-clicked the "Date and Time" applet, another entry occurred in the above UserAssist key...specifically, "UEME_RUNCPL:"C:\WINDOWS\system32\timedate.cpl",Date and Time".

Since I'm on an XP system, I thought I'd take a look in the Prefetch directory and see if there were any tidbits lurking around. Well, the thought didn't simply occur to me...the output of InControl5 told me that the file named "Rundll32.exe-randomstuff.pf" had been changed in some way. Knowing that rundll32.exe is a legit MS app, and that it's used to run things like Control Panel applets, I opened the .pf file in BinText and found Unicode strings that referenced timedate.cpl and w32time.dll, amongst other things.

All this is fine, in that it gives us clues, but I don't think that it's all that definitive. Another place to look, however, is in the Event Log. Specifically, within the Security Event Log there may be an event ID 520 (Category is "System Event") that states that the system time was changed, and includes the username, previous time, and new time. Very helpful!

Barring that (pretty definitive, isn't it??), there may be discrepancies in the actual times associated with the event records themselves. For example, if an event record with a higher number (more recent event) has a generated or written time that's before a previous event, then you may be on to something.

So far, many of the responses I've seen have said something along the lines of "look at your watch when you're standing in front of the system, before you unplug it and image it"...but, like I said, answers like that sort of miss the point of the question.

So...thoughts?

4 comments:

  1. Anonymous2:16 PM

    What about http header responses from "known" servers like Google, is it possible to retrieve them from cache or something ?

    ReplyDelete
  2. Anonymous3:16 AM

    shopping site resources are tough to find. Good post though. Have a look here if you would shopping site

    ReplyDelete
  3. Anonymous10:01 AM

    [rant == ON] I wish all of the idiots leaving posts for products or their sites would go away and stay away. [rant == OFF]

    This is an interesting subject that deserves some attention. In fact, it is a question that I am currently experimenting with myself. After the new entry is added to the UserAssist key and we have an LWT for it, why do you feel that it isn't all that definitive? Wouldn't it at least give us an approximate time that the Date and Time Control Panel Applet was last launched?

    If I'm trying to prove when that happened (because I believe that someone has changed the system time and then modified some files to help cover their tracks), it seems valuable to me. Perhaps there is some other way of limiting my ability to prove this or the LWT in and of itself, is insufficient. If so, please elaborate.

    BTW, I should be getting your book sometime this week - and the registry chapter is the first place I'm headed. ;-)

    ReplyDelete
  4. The only thing worse than the product spam is legit posters taking the time and effort to [rant]. ;-)

    > Wouldn't it at least give us an
    > approximate time that the Date
    > and Time Control Panel Applet
    > was last launched?

    It does exactly that...however, I've launched the applet several times without ever changing the date or time...I've simply checked the calendar.

    Depending on how long the system time was changed for, and if you're looking at an XP system, you may find evidence of the time change in the Restore Points...consecutive RPs may have non-consecutive times. On Windows systems in general, you may want to check the Event Logs, not only for an events relating to a time change, but also for the sequence of event IDs correlated with the event record generated and written times.

    > BTW, I should be getting your
    > book sometime this week - and
    > the registry chapter is the
    > first place I'm headed. ;-)

    Good to hear! Recommend it to your friends, and everyone you meet! That way, if the book is popular enough, the publisher will want a second edition...and you should see some of the stuff I've got to add!

    H

    ReplyDelete