Well that took a little longer to write than I thought. :)
This is a follow-up and expansion on my
post of 11/18/2009.
Nice laptop, good laptop..For the most part, I've been pleased with the HP 4410t thin client laptop. It has a tendency to go into a deep sleep and not come out - you have to pull power and the battery and try to turn it on to fully drain any leftover power. But I haven't found any more major
design flaws.
It is time for me to create an updated build from scratch, instead of iterating on the previous build with small changes. It will have all the latest security updates, updated HP components and other software, and any tweaks I feel are necessary after using the laptops for 18 months.
In that time, I've had three users catch malware. In one case, the malware was installed into the user's area - somewhere in their 'Documents and Settings' folder structure. I had chosen to open up the entire user folder including registry so they could personalize firefox, save things to the desktop, etc., so the malware wasn't being deleted by restarting the laptop. In another case the malware installed itself somewhere in C:\Windows, which gets reset back to its initial state after reboot by the FBWF. In both cases, the malware set itself to be started at boot with an entry in the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Run. The first user had popups everywhere, the second a message that software was missing (from the Run entry).
I've also had several users with corrupted SYSTEM registries, causing the laptop to not boot with the message: 'Windows XP could not start because the following file is missing or corrupt: \Windows\System32\Config\SYSTEM'. I think it may be due to a registry key being written to when the power goes off - the SYSTEM file contains the registry from HKLM\System. I've found it easiest to take 20 minutes to reimage the laptop and reconfigure wireless, bluetooth mouse, and dropbox.
I can't help but think - 'Is there a way to improve my image to stop these problems?'
The malware problemMy first thought is to be more selective in the files I'll let stick around across reboots with FBWF. By opening up the Desktop, My Documents, Firefox settings, and maybe one or two others, hopefully any malware installed to the user's area will disappear on restart.
My second thought is to ignore changes to HKCU\Software\Microsoft\Windows\CurrentVersion\Run so malware installed in the user's space cannot start after a reboot. I figure that one way to do this would be to selectively retain certain user registry keys and let the rest go back to their initial state on reboot.
My journey to retain HKCU registry settingsIn addition to using FBWF to retain entire files across reboots, I learned that Windows Embedded Standard (from XP forward) has the ability to retain specific registry keys across reboots. It is called the Registry Filter service (Regfilter), and it works like this: determine what you want to retain, and configure it in a specific area of the registry. The service will monitor the specified key for changes, if there are any it'll both keep them in memory and write them in a specific way to c:\regfdata (I'll go into this later). From then on, any system call to read or write to that key will instead be reading from and writing to the key in memory and in c:\regfdata. In fact, if you were to turn off the service and look at the key in the registry, you would find it to be the original setting from when you began - since it is never being written to. The final thing you need to do is to add c:\regfdata to your FBWF exclusion list so it is retained across reboots.
Keep in mind that I didn't know all of the above when I started researching.. there isn't much that I could find on the web explaining this. Mostly I found instructions to change this or that in your embedded image's configuration and use Target Designer (WES tool) to make a new image. I however am using an image provided by HP so this is not possible. What I wanted to do is called 'changing at runtime'.
I learned that c:\regfdata is a file used to store a RAM disk for the Registry Filter service, and that each key being monitored has an .rgf file here. I learned how to mount the volume (see below), but I couldn't figure out how to create the .rgf file with the key's initial state, or even blank. I tried copying another, naming it, and specifying this name in Regfilter's config key, but it didn't work. I researched programs with an .rgf file extension but this wasn't fruitful. From my reading it looked like the regfdata file might be created at first boot of a newly created image, but I couldn't change the image.. I tried installing Target Designer and the rest of the embedded tools to figure out how it all worked, but this didn't get me anywhere.
After another dead end, I checked the System Event Viewer and found there was an error on startup 'The registry class name is incorrect or unsupported'. I was trying to retain a key in HKCU since I read that it should work, although unsupported. Then I found a
Microsoft MSDN post - a Microsoft employee (Milong Sabandith) stated 'I think the problem is the user hive is not loaded when regfilter initializes. Regfilter will not persist the key if it cannot find it during initialization.' After all of this, it turns out you cannot persist User keys across reboots! If only I had started testing Regfilter with a key in HKLM.. the service works very well for this!
Since I'm doing all of this at runtime, I initially thought that I needed to create a blank .rgf file for it all to work. Nope, this is part of the Regfilter system. Just configure a key for monitoring and reboot. When/if the monitored key changes, an appropriate .rgf file will be created in the regfdata backed RAM disk. The reason I got confused in the first place was because I started off using HKCU, thus didn't see the .rgf file being created, thus thought I needed to create it myself, etc...
Aside: how to mount the RAM disk being backed up by c:\RegfdataRegfilter's RAM disk is an unmounted drive/volume, but you can mount it with the mountvol command.
Type the command without any parameters to see what the volume's GUID is. You'll be returned all of the possible volumes - those mounted will have drive letters, and one will not. Mark and copy the entire line (you don't want to type it!) for the unmounted volume, it'll look like this:
\\?\Volume{bbf71292-a819-11da-9fcb-806d6172696f}\Type the command again and assign a drive letter, like so:
mountvol x: \\?\Volume{bbf71292-a819-11da-9fcb-806d6172696f}\Be sure to unmount it when you are done!
mountvol x: /DAside: how to configure Regfilter to monitor keysCreate your own entry in the following registry location by incrementing the number by one (3 in this example), and then create subkeys like the following. Note that you'll need to escape your backslashes when they are in quotes. Hint: if there are any there already, export one, modify it in Notepad, and import it with your changes. :)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RegFilter\Parameters\MonitoredKeys\3]
"ClassKey"="HKLM"
"FileNameForSaving"="YourProg.rgf"
"RelativeKeyName"="Software\\Your Program Settings"What I've decided to doWell, I haven't yet - I need to do more testing. Since I can't selectively retain individual keys in HKCU, I'll have to either retain (or not) the entire user registry across reboots. If the apps I want the users to be able to configure don't write to the registry, then I won't retain it. If they do need the registry, then I'll exclude it with FBWF and deny permissions to the Run key for that user. (I'm definitely going to be more selective about which folders in Documents and Settings\username I allow across reboots).
[for the truly geeky with some extra time, I thought of the following: create your own method of persisting user registry keys across reboots. If at logoff you wrote the contents of the key you want persisted to a file at a specific location (the file would be excluded in FBWF) you could then restore it on logon. Not trivial, but also not impossible with registry commands or scripting.]The corrupt SYSTEM file problemSince I've been retaining the SYSTEM file across reboots with FBWF, any power issue can corrupt it. If however I can figure out what exact keys need to be retained, and save just them, then Regfilter will be the only thing getting changed and the SYSTEM file can't get corrupted! I'm going to reread the link referenced in my 11/18/2009 post and do some testing.
Much of the above information I made sure to add to threads online, but they are a little scattered. With this post I'm self-documenting the thoughts and methods I used, and I hope someone else will find it helpful as well!
chris
