## 22 August 2012

### Flash Offline Installers

Adobe and Java rival each other as the world’s most exploited software, forcing us to swallow vendor-pushed updates for fear of attack.  Flash, .PDF and Java are all edge-facing in a big way; Flash and Java from web sites, and .PDF both via web content and emaul attackments.  Many software applications auto-generate .PDF files send as attachments with generic message text, so the recipient has no “Turing Test” opportunity to exclude malware-automated vs. legitware-automated .PDF coming from “someone they know”.

So with that in mind, you’d expect both vendors to be abjectly apologetic, going out of their way to make it easy for users to download and apply the constant stream of repairs for their defective code.  Which is more or less true for Java, but Adobe is another story – I found this blog post that sums it up best:

So the quest is on to find offline installers for Adobe Flash and Acrobat Reader, that are:

• Really from Adobe, and not malware fear-bait fakes or trojanized versions
• Actually up to date, and not older versions
• Ideally, are free of unwanted by-catch (Google this, McAfee that, etc.)

With Acrobat Reader, this is fairly easy; you can use Adobe’s FTP site.  But that doesn’t help you with Flash.

I found some links from here to bypass the buggy installer...

Links from here appear to work...

These links were newest version (as at 22 August 2012)…

…while these were several versions old...

Expect these links to shift around, as Adobe plays the shell game to force us to use their wretched online installers, complete with shoveware that rewards them for our need to fix their junk.

## 21 August 2012

### Live Writer vs. Blogger; Picture Uploads “Forbidden”

I’ve found it very useful to catch screen shots via PrintScreen key to Irfan View, or using camera with flash off and macro on if pre- or post-Windows, and pasting these into support emails.

So what should be easier than to do the same thing here, in blog posts?

When I last looked at this, it was a fiddly affair, requiring a separate host for the picture files etc. but surely in this pro-Cloud age, those issues should have gone by now.

Apparently not; when trying to publish from Live Writer to this Blogger blog, this failed with “Forbidden”, and remained so until all pictures were removed.

So then I waded through Blogger’s online editor to pull up the pictures into the post.  That worked, for very low values of “work”; pictures were blurry, and the Blogger editor stripped spacing between paragraphs (spacing is always a bit of a sore point with HTML).  What a mess!

Behind the scenes, Blogger stores “blog” pictures in Picasa on the web.  So I logged into that and uploaded the pictures I wanted to use there - then in Writer, I pasted in the picture links from a page where I’d navigated to the pictures I wanted to use.  Still a cumbersome and messy procedure, but at least the text formatting wasn’t screwed up and the pictures look reasonable (as they should; all I want is to show small pictures at original size).

### LibreOffice 3.6 “The Selected JRE Is Defective”

Having got past some initial installation hassles that required deleting my LibreOffice profile, I hit a problem with Java, while in Tools, Options.  Here’s how to test this if it happens to you; go to the MediaWiki section in Options…

If you have the problem, you will get this error dialog:

I “fixed” this by installing the 32-bit Java JRE 6 update 33, being the current most updated version of the fading Java 6 line.  It has to be 32-bit as LibreOffuce is a 32-bit application (and fair enough), and it has to be Java JRE 6 rather than 7, because for practical purposes, LibreOffice 3.6 doesn’t work with modern Java JRE 7.5

There’s a lot of “UI pressure” at the Oracle site to download and use JRE 7 rather than JRE 6, which I took to mean 7 is fairly mature and 6’s days are numbered, so I recently switched from the 6 update 31 I was using, to the current 7 update 5.

There’s also a lot of detail on LibreOffice 3.6 and Java JRE 7, claiming that the new Java is supported, why Oracle’s poor installation practices get in the way, and how one overcomes this.

Originally, the LibreOffice code base started as Star Office, which was acquired by Sun and user as a poster child for Java.  This continued with OpenOffice, but since the developers left after the Oracle takeover, the intention is to dump Java.  I’d be very glad if they did, because:

• LibreaOffice already loads faster than OpenOffice after reducing Java
• Java is edge-facing, frequently exploited and frequently updated
• LibreOffice lags behind effective support for latest Java updates
• Java installs tend to leave exploitable older versions in place

The last is a very old issue that still hasn’t gone away completely.

### LibreOffice 3.6 “Unhandled Exception” Error

I’ve just upgraded from LibreOffice 3.5.2 to 3.6.0, and ran into two sets of problems; the one documented here, and issues with Java

I didn’t install over my old version as I usually do, because this is noted not to work in the release notes for 3.6…

For Windows users that have LibreOffice prior to version 3.4.5 installed, either uninstall that beforehand, or upgrade to 3.4.5. Otherwise, the upgrade to 3.6.0 may fail.

…and I couldn’t find 3.5.5 anywhere on the LibreOffice site.  Also recently released by LibreOffice is 3.5.6, but documentation is poor (many links go to 3.6, not 3.5.6) and it’s unclear as to whether this will install over 3.5.2 as 3.5.5 would do, as a version waypoint for those wanting an over-old path from < 3.5.5 to 3.6

So I uninstalled LibreOffice 3.5.2 from my Windows 7 64-bit SP1 PC with 64-bit Java JRE 7.5, then installed LibreOffice 3.6, but after an initial pause on first run, every attempt to launch LibreOffice failed with this “Unhandled exception: InvalidRegistryException” error…

…followed by this “Runtime Error! This application has requested the Runtime to terminate in an unusual way.” from the Microsoft Visual C++ Runtime Library:

Attempts to uninstall and re-install 3.5.6 or 3.6 again did not fix this issue, including after shutting down and restarting Windows.  Uninstalling the older co-installed OpenOffice (which worked fine with LibreOffice up to 3.5.2) did not make any difference, the same failure pattern remained.

I followed advice to delete my LibreOffice profile, i.e. the subtree within AppData\Roaming for LibreOffice, and that fixed the issue, which may have been linked to a language dictionary I’d added to Open Office.  I didn’t try a more refined fix (i.e. trying to isolate which part of the old profile was bad) as I didn’t need anything in the old profile; I did rename it away (while LibreOffice was completely closed, QuickStarter included) rather than delete it, in case I want to go deeper into this issue later.

Which let me get far enough to hit the Java problem (those who noted “Windows 7 64-bit with JRE 7.5 64-bit” may take a guess at the cause before reading my next post)

## 20 August 2012

### Missed UAC Prompts May Silently Undo Installs

This is a more generic issue than what can go wrong with AVG installation, but not the usual user account rights issue.

Windows 7 makes UAC somewhat less obtrusive in various ways, which is generally welcome – but a side-effect can be to silently undo a software installation.

What happens:

• you start an installation
• you aren’t prompted for admin permission
• you leave the install process to run unattended
• a UAC prompt pops up while you’re away
• In Windows 7, this is now a discreet flashing item on Taskbar
• the UAC alert is ignored, times out and assumes “no”
• the installation is silently aborted
• you think the installer completed OK
• then you find your new software’s simply “not there”!

I notice this in particular with LibreOffice, where the expected UAC prompt only appears quite late in the installation process. A possible factor may be renaming the installation executable (e.g. from “Setup.exe” to “NameOfApp.exe”), as this may defeat Windows recognizing it as an installer requiring administrator rights, and thus prompting early for permission to continue.

LibreOffice is an object lesson in why Open Source may be more useful than just being free of charge.  When Oracle took over Sun and cut off the salaries of the Open Office development team, the code itself was beyond their reach – so the product could survive, as continued by the same coders working elsewhere.

One beneficial side-effect of leaving Sun, was a move away from Java, for which Open Office was something of a “poster child”.  LibreOffice is already faster to start up (even without the “quickstarter”) as a result.

### AVG Vanishes After Cleanup and New Install

This is not the generic issues of user account permissions or missed UAC prompts; it’s something more specific to AVG’s installation tools.  Here’s what happens:

• you uninstall AVG
• you restart Windows if prompted to do so
• you do some manual cleanup of AVG leftovers
• you run AVG’s cleanup tool
• you install AVG
• AVG works fine
• you shutdown and restart
• on next Windows session, AVG has vanished

If you run the AVG cleanup tool after uninstalling AVG (and perhaps being prompted to restart Windows) just before installing AVG, then install AVG, you won’t have been prompted to restart Windows between the cleanup and the new install.  The cleanup works by seeding HKLM..RunOnce with an entry to uninstall AVG, which it does, the next time to shutdown and restart Windows – so it kills the new install you have just completed!

The bug may be that because the cleanup tool finds no active traces of AVG when it runs, it doesn’t see a need to prompt a restart of Windows.  It then exits, so is no longer there to note the new material added by the fresh AVG installation.

There also may be a bug in the fresh (in my case, offline installer for AVG Free 2012 32-bit downloaded 19 August 2012) installer, if that fails to look for and detect the RunOnce entry created by the cleanup tool.

I’m fairly sure of the mechanism of this issue, because while still in Windows after installing AVG anew, I spent some time in Regedit and noted the RunOnce entry there.  I’m also fairly sure this is not a malware effect, as the PC had not been online since formal scanning with a variety of antivirus rescue CD scanners (via Sardu) and other tools (via Bart).

However, a possible contributor may be the manual clean-up I did before running the cleanup tool and the new install.  This was in XP SP3, and my efforts were limited to deleting the AVG and MFAData subtrees in Documents and Settings, All Users, Application Data.  I did no registry cleanup (either manual or automated), nor did I clear other Documents and Settings or Program Files AVG locations (where leftovers are trivial compared to 100M or so for each of the two I deleted).  I did delete \$AVG from hard drive all volumes, and both old and new AVG installations were to a non-default path in C:\Program Files. Also, before uninstalling AVG originally, I cleared Virus Vault and logs via the AVG UI, and during the uninstall thereafter, checked Yes to clear the Virus Vault, but not User Settings. The latter are probably held in the small Application Data locations in the per-user subtrees, where I did not delete anything. I also (heh, lot’s off “also”, all of which should be declared in case the bug hinges on them) deselect the “security toolbar”, opt out of sending info to AVG, delete unwanted desktop shortcuts and relocate Start Menu shortcuts to a different folder within the same All Users, Programs. So, steps to avoid this issue: • shutdown and restart after running the AVG cleanup tool • check HKLM..RunOnce is clear • then do the fresh install of AVG • shutdown and restart Windows • check HKLM..RunOnce is clear • check AVG is present and running • re-check AVG is present and running after further startups Some of the re-checking should be redundant, but I’m reluctant to turn my back on it again! Perhaps the time has come to use Microsoft’s free antivirus instead. I’m less keen on Avira (the Rescue CD is prone to false-positives) or Avast, but they’ll have their proponents too. I’ve used and supported AVG for years, but am getting fed up with frequent large new versions, unwanted Do Not Track and “PC Tuneup” stuff (including the especially-unwanted “registry cleaner”) and the way recent versions push users into using these unwanted items. ## 20 November 2011 ### C-Net’s Downloader Pollutes “My Documents” You may have noticed C-Net have started using a downloader stub when you download software from them. The stub adds no value that I can see (it claims to be “more secure”) and tries to push unwanted bycatch, such as browser toolbars etc. So far, so normal and nasty, but there’s something else that makes this totally unacceptable IMO – it changes the location where your download is saved, ignoring your browser’s settings and providing no UI to see where this is beforehand, or change it. And where does it save the download? The Windows Vista/7 Downloads shell folder? No; in “My Documents”. So now you have infectable incoming code dumped into your “data” set, where it will pollute your data backups too. I was wondering why I was seeing so much Incredimail, Babylon Toolbar and other junk on client systems – now I know why. What I now know, is that I must also clear these code downloads from the data set. ## 04 October 2011 ### SkipRearm Setting for SysPrep Failure Technorati Tags: , Here’s how it goes; you have an un-activated Vista or Windows 7 reference system ready for SysPrep and .WIM harvesting, but SysPrep fails. You search, and find articles that mutter about adding a “SkipRearm” setting to an “answer file”, but get stuck there if you don’t know how to apply an answer file. Fortunately, there’s a simpler fix that I found and tested for Windows 7, and it works. For Vista (which I didn’t test)… HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurentVersion\SL\SkipRearm = 1 …and for Windows 7 (as tested OK): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform\SkipRearm = 1 The nice thing is, you don’t have to fiddle with “answer files”, or .WIM mounting and manipulation in WAIK. This fits with the simplistic way I use .WIM imaging; I use only WinPE 3.0, ImageX, and the GimageX GUI wrapper for convenience. My WinPE 3.0 is standard other than the addition of GimageX and ImageX, and a setting to prevent the WinPE boot from falling through to boot the hard drive if no key is pressed (sorry, no link for that). When building a system, I partition via BING, format the prospective C: to NTFS via WinPE, then apply the .WIM, so I have a baseline installation that when booted, will resume Windows Setup as part of what SysPrep did prior to the creation of the .WIM image. I do the first boot OFFline, and kill the duhfault setting to automatically activate Windows. Then I update and install free software to taste, until the new PC is generically fully set up. I use BING to image the C: partition for safekeeping (in case SysPrep screws up), then run SysPrep and Generalize the new PC. I then boot WinPE to capture C: as a new and updated .WIM, then I boot BING to restore the partition to the state before SysPrep was run. At this point I can apply client-specific changes, activate Windows, and ship the new PC. SysPrep does not maintain undoability, and tends to screw up. When it does, you can be left with no bootable reference system and no usable new .WIM, so I again stress the need to image-backup C: before SysPrep. If you’ve done that, you may prefer to restore that image rather than wade through and clean up after SysPrep’s effects. Key safety One of the things you want to avoid when working with what you hope to harvest as a reference .WIM, is inadvertently activating the build, especially with the wrong product key: • Disable the “automatically activate” setting • Keep new PC offline from build until first backup image of C: • Re-check “automatically activate” setting before going online • Do the “image backup, SysPrep, restore C:” sandwich • Check the current key before activating • Activate before shipping as new PC When I tested SysPrep with SkipRearm, I did not enter a product key when prompted, and used Nirsoft’s Produkey tool to check the key. This showed a key other than that of the client, so SysPrep had stripped that OK, and presumably fallen back to some previous or fake key. When I restored the pre-SysPrep BING partition image as C:, this showed the expected client’s key, as I’d entered when originally starting the build from the previous .WIM Final tip; if/as SkipRearm doesn’t reset the full grace period for activation, you may want to minimize the days spent between restoring the previous .WIM and capturing the next one. ## 01 October 2011 ### Mint/Linux, Sandy Bridge, Blank-screen Intel Graphics Mint 11.4 64-bit installs on Cold Lake H67 Sandy Bridge motherboard PC OK, hard drive boots to grub2 OK, but Mint boots to a black screen with no mouse pointer. The OS is running OK, you just can’t see anything – or almost; a close look at the screen shows a pixel-flickering red line down the left edge and a solid short horizontal white line top left, when a 17” CRT is used. The problem appears with LCD screens also, and is variable; some boots may be OK. At present, all 3 of 3 new PC builds have done this on first Mint hard drive boot. The fix: Plug another monitor into the other graphics socket. The desktop will immediately appear on both screens; you can then unplug the second screen and it will work OK (at least for that booted session). Cold Lake motherboards use the H67 chipset, which in turn interfaces the Intel GPU built into the processor, to DVI and HDMI dual display outputs. Typically I use a DVI to VGA adapter to take the DVI’s analog signal to 17” CRT or more modern LCD, leaving the HDMI unplugged, though from memory I recall similar mileage when a digital-signal LCD was plugged into DVI, or HDMI via HDMI to DVI “pigtail” adapter. It seems like Linux can’t figure out what display signal to use? If previous Ubuntu mileage is anything to go by, the “fix” is prolly to wait until the next OS release in the hopes it will use a newer Linux kernel that has a clue about “new” hardware. Bah! Still, that should be due later this month, so let’s see how it goes. ## 11 October 2010 ### Robot Drivers and Driving Tests If we require training and licensing of humans to fly aircraft and cars, then how do those standards apply to software that pilots these things for us? A key is situational awareness. You wouldn't easily give a blind pilot a flying license, yet effectively that is what Airbus tried to do with an engine control system that "landed" a test plane in a forest. It's one thing having a robot hospital cart that negotiates around people's ankles at walking speed, quite another to do that at road speeds, or while attempting to keep an airliner within its flight envelope. Perhaps the human pilot or driver is expected to remain in control, on standby and ready to override the robotics? Good luck with that, as attention wanders and distractions take the foreground in the human's mind. I see Google's already had cars driven by software logic on public roads. I wonder what the traffic cops would have to say about that? ## 07 September 2010 ### Driver Cure or Driver Curse? If you'd just dropped into the PC world last week, you'd think all software was perishable and had to be continuously refreshed. Must always have the latest version BIOS, drivers, etc. This attitude runs counter to an older wisdom, that the first question when something goes wrong, is: "What changed?" With this in mind, the last thing you want is vendor-driven changes to your code base; in fact, for a critical working system, you want no changes at all. The logic behind all this is contradictory... • Software vendors make mistakes, requiring software repairs ("patches" or "updates") • This happens so often, you may not be able to keep up with the constant flow of updates • So it's best to let the software vendor push updates whenever they see fit This boils down to: Trust software vendors to push changes into your code, because they fail that trust so often you can't keep up with the pace of quality repair required. So, should you always patch, or never patch? Or sometimes patch? If "sometimes", then on what basis do you use to decide what needs patching? Balancing risks Some code is so critical, you may consider it too risky to change, e.g. BIOS and device firmware, device drivers, core OS code, and code that is running all the time and can crash the PC if it goes wrong. Some code is so exposed to arbitrary unsolicited material, you may consider it too risky to leave unpatched, for fear that malware may exploit defects in the code to attack your PC. Code should never fall into both of the above categories; if it does, you're probably looking at really bad software design. For example, integrating a web browser so deeply into the system that it's indivisible from the system's own UI, would be a bad design decision. Or consider a service so critical to the system's internal functioning that the OS shuts down the whole PC every time the service fails, that is waved at the Internet on the basis it's "networking"; that would be a really bad decision (Lovesan vs. RPC, remember?). Trust me, I'm a software vendor The two reasons not to trust a software vendor are incompitence and perfidity. A vendor who claims you "must" leave your system open to a constant stream of fixes, has declared themselves incapable of writing code that can be trusted to work properly. And frankly, when even "legit" vendors hide deliberately user-hostile code within their products, set to automatically deny you service if its logic considers your license state is invalid (product activation) or distribute rootkits within "audio CDs" (Sony), I'd not trust any vendor's ethics. Finally, even if you trust the vendor's ethics, you have to look at the mechanics of code distribution. Fakeware abounds, so when a third party claims to serve you fresh code from the vendors you trust, you have to ask yourself how trustworthy is that third party? You also have to ask why you'd trust a particular software package. Open source advocates would say it's because you can read the source code yourself, or at least feel safer in that others have done this on your behalf. Closed source advocates would say it is unrealistic to read source code yourself, and instead would point to pre-deployment testing that would pick up unwanted behavior before the code was used in the real world. Patches and updates change both of these equations, because now the code you read and/or tested, is no longer the actual code that is running. Any patch may add unwanted behaviors that favor whoever pushed the patch into your system. For the same reason, you should avoid software that stores "your" settings on the server side rather than on your PC (e.g. Real Player, many Instant Messaging apps) and "Privacy Policies" and End User License "Agreements" that state "these terms can be changed whenever we see fit", as so many do. The race to patch There's a race between freshly-released malware, vs. your antivirus scanner that protects your system. When a new malware is found, the antivirus vendor analyses the code to work out how to detect it, then how to safely remove the code, then that logic is packages as an update that your PC's scanner pulls to update your protection. Compares this to what happens when a new vulnerability is patched. The malware coders can compare pre- and post-patched code to isolate the fix, then work out what the unfixed code did wrong, and thus how to attack that code. The exploit code is then packaged into malware prepared earlier, such as a downloader stub, and that's pushed into the wild. Notice the similarities between these processes, i.e. recognizing and removing malware compared to extracting and exploiting code defects from studying patches? If you rely on resident antivirus to protect you, then you are betting on the av vendor to beat the malware in the race. By the same token, you may expect malware coders to be fast enough to exploit your edge-facing code before the patch arrives to fix the defect. Hence the manic rush to patch, for fear of prompt exploit. It's actually a bit worse than this, for two reasons. Firstly, sometimes it's the malware folks who find and exploit defects before the code vendor learns about these and fixes them. Secondly, software vendors have to ensure their patches don't break any systems, whereas a malware coder just wants it work enough of the time to spread, and doesn't care if it breaks other systems in the process. Less rigorous testing means "faster to market", right? Self-spreading malware can also spread faster from more systems, and thus beat the patching or updating processes to the punch. Malware can be delivered in real-time via pure network worms, or links to servers that are themselves updated in real time. Often the malware that enters the system is just a downloader stub; it only has to last long enough to pull down the "real" malware, which can replace itself in real time as well. Edge-facing software With all this in mind, you can see why one would want to patch edge-facing software as soon as possible. Examples include web browsers, Java, Acrobat Reader, Flash and media players, and anything that is constantly exposed to the outside world, such as software that waits for instant messages or "phone" calls. The best solution is to remove that edge-facing software, and thus the need to patch it. Do this whenever you don't need that software, when the software or its vendor are too flaky to trust, or when the update process itself is something you want to avoid. For example, you may catch a vendor trying to shove new edge-facing software as "updates", even when that software is not present and therefore doesn't require patching. That's how Apple used to push Safari to PCs running iTunes or QuickTime, until they were pressurized to stop. For another example, a vendor may decide you don't need to be asked before updates are pushed, or even told when this has happened. And when you look at that vendor's updater, you find it running as multiple scheduled tasks; then when you look at the details, you find a task that appears to be run once a day, is actually repeatedly run every hour throughout the day. That's the equation with Google, and why I would avoid any edge-facing Google software. If you can't avoid edge-facing software, then you can protect yourself in two ways; by updating it as soon as possible, and/or by choosing such obscure, small-market-share products that they aren't likely to be attacked. The latter is like living in an unlocked shack in the countryside; that works not because shacks are "so secure", but because there are so few attackers around. Driver Cure or Driver Curse? So now we come to Driver Cure, which is a third party product that pulls in the latest versions of your device drivers. Would you want this? I'd say no, for two reasons. Firstly, device drivers are code that runs so "deep" in the system, that any mistakes are very likely to crash the entire OS, leaving the file system corrupted, data files unsaved, etc. Device drivers usually run all the time, so bad code may prevent the system from being able to boot or run at all, even in Safe Mode. So I definitely don't want unexpected changes to this code, any of which may cause the system to stop working. Secondly, device drivers are not edge-facing, so the risk of explosure exploit should not be high. That means less reason to patch in haste. Thirdly, if malware were to be integrated into the system as deeply as a device driver, it would have considerable power and be very hard to remove. So we'd want to know a lot more about third party software that inserts "drivers" into the system. The "Driver Cure" folks also push XoftSpy, which was one of several hundred fake anti-spyware scanners, until they supposedly "went legit". As such, sites and blogs may no longer call XoftSpy "malware" for fear of being sued; we may instead consider it as a legit antispyware that isn't very good at what it does, and costs money where better products are free. So, in spite of "reviews" like these, I would avoid Driver Cure and anything else from that particular software vendor or distributor. ## 11 June 2010 ### Zoundry Raven Double-Spaces On Blogger I've started using Zoundry Raven as my off-line blog editor instead of Windows Live Writer, as the latter depends on Live Passport before it can do anything, anywhere, and for some reason that's gone haywire in my case. It posts OK to my WordPress blog, but on Blogger (here), I see my text paragraphs are separated by two blank lines, rather than one. Well, HTML always seems to have trouble with white space control; either too many blank lines, or not as many as you'd expect; reminds me of DOS vs. UNIX CR/LF issues in the days of dot matrix printers. Looking at the source code, I see previous posts have the (/p)(p) sequences I'd expect (where I've used parantheses rather than angle brackets to show the codes as text), but the new post has a (/p)(br /)(p) sequence instead. OK, so I'll clean up my posts in the HTML code window before posting, right? Nope; this is "XHTML" in Raven, and it innocently shows the expected (/p)(p) sequences. So perhaps the transport process and/or Blogger's server side is screwing up - bleh. ### AVG 9 Update Blocked By Ashampoo Firewall Geek summary: AVGUpd.exe can't pass Ashampoo Firewall when launched within AVG, but works when run explicitly; as a workaround, create a Task to run on startup and every few hours Firewalls sometimes block antivirus updates, even when all of the antivirus executables have been permitted full Internet access through the firewall. In this case, I hit the problem on a Windows 2000 PC, on which I'd installed AVG 9.0 Free antivirus and Ashampoo Free Firewall. I searched about this and found several threads at AVG's forums, which usually pointed to an article that lists the AVG executables that should be allowed through the firewall. Other posts elsewhere simply declared Ashampoo as incompatible with AVG. Even listing every AVG executable in Ashampoo's rules does not fix the issue, which is more subtle than it looks. Specifically, the AVGUpd.exe update tool does work if launched explicitly, but if it is invoked through AVG's general UI, the update fails. If you run AVGUpd.exe directly, nothing visible happens unless you already have the general AVG dialog open at the time. If you do, then you will see that dialog indicate the update is now in progress, and it works. The problem may be Ashampoo blocking interprocess communication within AVG (though I had disabled that sort of internal functionality), or failing to recognise when AVGUpd.exe is invoked from AVG's code (perhaps it calls it as a .DLL?). A fix (aside from ditching Ashampoo, which I'm reluctant to use for the next Windows 2000 PC that needs a free firewall) is to create Start Menu and desktop shortcuts to run AVGUpd.exe, and/or set a Task to launch this when starting the system and/or every few hours during the day. Both approaches appear to work so far. ## 20 November 2009 ### Sysprep Fails, WinPE Sees Wrong Drive Letters If you… …then you may find… • Sysprep fails before it completes • WinPE “sees” partitions with incorrect drive letters The impact can be severe; finding you’ve built your .WIM from the wrong partition, having Sysprep ruin both the .WIM you harvest plus the reference system you’d built, etc. Attempts to maintain the Windows installation via WinRE or “just” re-install Windows may fail, too; I haven’t tested those scenarios. The fix is to make sure the Windows boot partition is set as active in the partition table before you apply Sysprep or attempt access from WinPE, WinRE, OS installation disk, etc. You can do this after Windows and Ubuntu have been installed; it won’t affect these, or how grub works. The cause is a combination of the way grub works (which bypasses the normal MBR “boot the partition that is set as “active” code logic) and the way Microsoft code assigns drive letters to Windows-visible partitions and logical volumes. #### Standard MBR logic The Master Boot Record (MBR) is the first sector of the physical hard drive, and acts as an extension of the system BIOS. It exists outside of any OS, running as it does before any particular OS has come into effect. The standard MBR contains a partition table defining up to 4 partitions, one of which may be flagged as “active”. The standard MBR code logic is to look for the (first?) active partition and chain into code within the first sector of this space. At this point, the system phase of the boot process ends, and the OS phase begins. #### How grub works The grub boot manager adds some initial code to the MBR which links to the bulk of its code within the Ubuntu partition. At boot time, this modified MBR code will always chain into the rest of grub, irrespective of which partition entry in the partition table is set as “active”. The partition table is still referenced to find partitions, but the “active” setting is now ignored, and is thus irrelevant. You may assume that the partition you booted via grub will be set as “active” in the partition table, but this is not the case; grub (at least grub 2, as contained in Ubuntu 9.10) does not update the “active” flag status according to what you booted last, even if set to default to this on next boot. #### How Microsoft assigns drive letters Microsoft OSs can “see” two groups of partition types; primary partitions that may be bootable and define a single volume, and an extended partition type that is not bootable but can contain multiple logical volumes. Each volume contains a single file system and is typically assigned a single drive letter. Drive letters have validity only within a Microsoft OS. In the absence of “remembered” settings within that OS, they are assigned as follows… A: and B: reserved for legacy diskette drives For each physical hard drive… Assign ascending letters to each “active” primary partition …next drive until all done For each physical hard drive… Assign ascending letters to each logical volume in extended partition …next drive until all done For each physical hard drive… Assign ascending letters to each “inactive” primary partition …next drive until all done For example, if you have an NTFS primary partition and an extended partition containing three logical volumes, these will be lettered as C:, D:, E: and F: if the primary is set as “active”, and F:, C:, D: and E: if the primary is not set as “active” – and so… #### Here comes the pain When Windows boots off the hard drive, it can override the above logic in two ways. Firstly, it is aware of which partition it booted from, and which volume contains the bulk of its own code; these drive letters are recorded within the OS and can’t be changed. Secondly, it remembers drive letters assigned to volumes it has “seen” before. Unlike the letters for boot and OS volumes, these can be changed by the user, causing new values to be “remembered” and applied on subsequent boots. But when you don’t boot this OS code, e.g. you boot WinRE, WinPE or the OS installation disk instead, then all those remembered settings do not apply. I suspect Sysprep applies fresh logic during its processing as well, thus breaking its assumption base and causing it to fail. Further, one may not be aware that the “active” flag status is an variance with boot history, and therefore assume that because you last booted Windows, that Windows partition will be the one currently set as “active”. But that is not what happens when grub is in effect. #### Best practices I would suggest the following, to reduce these sort of risks… 1. Always do an image backup prior to Sysprep Sysprep can be as destructive as “just” re-installing Windows, or shifting/resizing existing partitions. In practice, I have far higher destructive failures with Sysprep than repair installs of XP, over-old OS version upgrades and partition management, all of which have been safer than Service Pack installs. So if you would always backup before doing those sort of things, then all the more so to backup before Sysprep. Unlike Win9x and older Microsoft OSs, accurately copying every single file from one drive to another will not result in a bootable system, even if the drives and partitions are identical in size and you also copy over PBR contents that exist outside the file system. That is why you have to do a partition image backup (e.g. from BING boot, using Drive Image from Bart boot, etc.) to preserve your “undo” trail. 2. Check that the Windows primary is set as “active” This should now be added to your sanity-checks before signing off on a system build, running Sysprep, harvesting .WIM images from WinPE, etc. If you have a WinRE installation set up to boot in the event of Windows boot failure, then it may be important for the correct partition to be set as “active” at all times. 3. Apply descriptive names to disk volumes I apply the names “C-Drive”, “D-Drive” etc. to partitions and volumes as I create them in BING, so that these are the names I will see when working in BING to manipulate them as partitions. BING writes these names into the boot record of the volume, whereas the name you apply in Windows is held as a Volume Label entry within the root directory of that volume. So you can have “pretty” names in Windows, Bart CDR boot, etc. and accurate names in BING. My own practice is to choose “pretty” names that happen to start with the expected drive letter, so I get a quick visual sanity-check before operating on them in Windows. For example, if I see “Core” is C: but “Data”, “Extras” and “Factory” are E:, F: and G:, then I know something’s gone wrong and should be fixed before I generate new paths based on these wrong letters. I’d know to look for an optical drive or other intruder that has become “D:”, and fix that. #### How this was tested I tested this on new PCs build with the following hardware: • Intel “GoldTree” G43 chipset motherboard, latest BIOS applied • E6300 processor, VT enabled in BIOS (is off by duhfault) • 2 x 2G = 4G DDR2-800 Kingston Value RAM • S-ATA Seagate 1.5T hard drive as S-ATA 0 • S-ATA LG DVD writer as S-ATA 3 (last) Partitions and OSs were: • 30G Ubuntu 9.10 partition (not visible to Windows) • 4G Ubuntu swap partition (not visible to Windows) • 64G primary partition, Windows 7 64-bit, as C: • Extended partition containing FAT32 logicals D:, E: and F: • MBR contains grub 2 as installed with Ubuntu 9.10 Two PCs were tested, one with Home Basic and one with Pro as the Windows 7 edition, both being DSP (small OEM) installations. The grub menu was set to default to the OS that was booted last, and this was always Windows during these tests. BING was used to create and manage partitions (unlike Windows, can format FAT32 larger than 32G) and was not installed as boot manager. Test procedure: • BING boot, image backup Win7 primary to logical E: • Set Win7 primary as “active” • Boot hard drive; grub defaults to last selected (Windows), OK • Boot Windows; works, drive letters OK • Boot WinPE; what should be C: D: E: F: seen as C: D: E: F:, OK • Boot Windows, run Sysprep; works OK • BING boot; now… • Set Ubuntu primary as “active” • Boot hard drive; grub defaults to last selected (Windows), OK • Boot Windows; works, drive letters OK • Boot WinPE; what should be C: D: E: F: seen as F: C: D: E: - Fail • Boot Windows, run Sysprep; fails before post-processing boot • Windows is now not functioning, and remains so after reboot - Fail In each case, Sysprep was run without answer file or CLI parameters; OOBE was selected, Generalize was checked, and Reboot selected as the post-processing action. ## 17 November 2009 ### XP Blank Desktop, No Task Manager, No UI Technorati tags: , , I hit this failure pattern in the context of doing an XP SP3 repair install over XP SP3 with IE 8 installed, and it may be that this is a generic issue. Searching the web did not find a solution, which is why I’m writing this. The fix is to install IE 8 from Safe Mode. #### Failure pattern Windows XP boots to the desktop, showing wallpaper, but nothing else; no icons, Taskbar, Start button, etc. Mouse pointer present and moves OK, and the “lock” keys toggle the appropriate keyboard LEDs, so the system is still running. Safe Mode works OK. Pressing Ctl+Alt+Del does not bring up Task Manager, pressing Alt+Tab or the Flag key does nothing, and pressing (but not holding) ATX power off does not initiate a shutdown. Pressing the case Reset button forces a hard reset and holding down ATX power button forces ATX “power off”; both cause some file system damage due to bad exit with files open for writes. Note how this failure pattern differs from some others that are more common; no icons but UI elements present (desktop properties setting to hide icons, icons unselected, etc.), other “shell” failures where Ctl+Alt+Del and ATX power press still work, and malware effects that specifically knock out Task Manager while leaving the desktop UI functioning. #### Typical Scenario It is often necessary to do a “repair install” of Windows XP if one has changed core hardware that breaks compatibility with XP’s pre-PnP code base. This is what happened to me, when I had to replace a dead motherboard with a different one, even though this was based on the same chipset and the hard drive interface remained the same. In addition, folks often “just” re-install Windows for all sorts of problems, even when there are cleaner ways to fix the problem, and/or when doing so is likely to fail. So I’m surprised there hasn’t been solutions visible via Internet search for this issue – if indeed it is as generic as I suspect it may be. A few weeks earlier I’d done a similar replacement on a similar PC, using a completely different motherboard chipset. In that case, Windows booted just fine, did a bit of PnP device detection and driver installation, tossed its Activation cookies out of the cot, but was ultimately fine. But in the second case, I had the half-expected STOP BSoD error (“Windows has been shut down to prevent damage to your computer”) earlier during the boot process. #### What didn’t work Writing to an at-risk system, especially installing new software, can often make things worse – so installing IE 8 was far from the first thing I tried. The PC had already donethe prelim”; RAM, motherboard capacitors, hard drive, file system were all OK and malware had been managed from a Bart boot, and the C: partition had been backed up as a partition image using BING. First, I hunted down and removed all startup items and drivers for old hardware, working both from Safe Mode and Bart boot. No joy. Because Safe Mode worked OK, I suspected a shell integration factor, so I tried setting the shell to Cmd.exe and starting Windows normally. This failed in the same way; no Cmd.exe window appeared, and ATX power, Ctl+Alt+Del etc. still didn’t work. Disabling shell extensions using Nirsoft Extension Viewer didn’t work either. Then I thought there may be a problem with launching the shell, so I edited a batch files run via an existing Task so that it launched Explorer.exe instead of doing what it had done before. I’d noted this Task running behind the dead desktop, but from Safe Mode one cannot create new Tasks properly – some properties can’t be set, such as “run only when logged on”. That’s why I edited the batch file of an existing Task, rather than creating a new one. No joy, again. #### The fix Re-installing Windows often causes problems when bundled subsystems (e.g. Windows Media Player, Internet Explorer) are forced back to older versions. With that in mind, I tried re-installing IE 8 from Safe Mode, half expecting the usual “Windows Installer is not running” failure pattern. Much to my surprise, not only did the installation of IE 8 from Safe Mode work, the next boot brought up a functioning shell in normal Windows mode. Problem solved! ## 26 May 2009 ### Vista UI Annoyances Technorati tags: When a user interface has different behaviours, and you can’t predict which one will arise, it can drive you nuts. Sometimes this is due to cues it takes from material you haven’t seen yet, and sometimes there’s something you need to do slightly differently to select one or other behaviour – but the difference in what you do is too subtle to learn. ### File operation, multi-selection, or re-ordering? This was always a pain in XP’s Start Menu; you try to drag an item to re-order it, and it doesn’t go with the mouse because for some reason the OS didn’t know that’s what you wanted to do. So I’d stamp the mouse button on the thing, hold still with button down for a while, then drag smartly while staying on the menu – trying to make my gestures and timing as clear as possible. No joy; sometimes it works, sometimes not. Then I tried making the first move sideways vs. up or down, making the start of the move gradual vs. sudden, and I still could not get consistent results. In Vista, the problem sprawls over to all folder views, making the problem that much more annoying as it now pervades the whole shell. Even if you deliberately choose List view in an attempt to avoid useless icon positioning info clogging up the registry, Vista still seems to remember item positioning, as imposed via dragging within the pane. The effect is the reverse of the Start Menu context, because usually in the shell I’m trying to select a large number of items by “lasso’ing” them, or move one or a selected wad of items from one pane to another. Sometimes I get what I want; sometimes Vista thinks I’m trying to lasso-select items when I’m trying to drag what I’ve stamped the mouse on, and other times it does the re-ordering thing, which is never what I want. In XP, I didn’t have that confusion between lasso-selection and dragging items. As long as I started by lasso-select from an “empty” point in the folder, I’d know I’d get lasso behaviour, and not drag-and-drop behaviour. But there’s something different in the way Vista selects things, and that’s a problem in its own that we’ll come to later. Perhaps that difference affects this UI behaviour as well? ### Letter case for drive volume names In the days of Windows 95, to avoid the overhead of LFN directory entries for valid 8.3 names, you’d have to stick to ALLCAPS. The NT family may use other more economical cues for ALLCAPS, Sentence.Case and allsmalls names, which is one reason to be less tense about all this… so today, I usually use the letter case that I want to see, rather than try to reduce system overhead of LFNs. This works fine for files and folders, but gets wobbly when it comes to the names used by hard drive volumes. The problem is common to both XP and Vista – it appears to be impossible to force your choice of letter case; sometimes you get ALLCAPS, other times Sentence Case. Now volume labels are tricky things, down at the file system where they are stored. Each volume actually has two separate name locations; one is embedded within the volume’s boot record, and the other is held in the root directory as a “legacy” 8.3 entry. There’s a twist to the way that 8.3 entry is interpreted; all 11 characters are seen as one name (not as 8 character name plus 3 character extension), and lower case and space characters are allowed. This behaviour goes back as far as pre-Windows MS-DOS. When you set the volume name via the shell, only the root directory entry is affected, and this is what is displayed if it exists. If it does not exist, the name embedded within the boot record is shown; if that is blank, you will see “local disk” instead. If you want to operate on the embedded boot record name, you can do that from BING after booting it from CDR, cancelling the install prompt, and using it in partition maintenance mode. On the face of it, preserving letter case should be even easier than for normal files and directories, because the legacy behaviour does this even without LFNs. The shell appears to restrict itself to the original 8.3 entry, as it accepts only 11 characters as input. But whether I use F2, right-click Rename or right-click Properties etc., I cannot impose my choice of letter case, whether I “break the rules” with spaces or not. Often I have some volumes displaying as ALLCAPS and some in Sentence case, after using the same UI methods to name all of these in the same way… very strange. ### Content-sensitive folder views I’m not the only one who hates this with a passion! When you view the items in a folder, Vista gropes those items to “smell” what type of things they are, then selects the appropriate view. AutoPlay does a similar thing when it populates the pop-up list of things you can do. If these behaviours were restricted to clearly-defined contexts, such as defined shell folders and true audio CDs, I wouldn’t mind. The problem is the cues that Vista is using to determine the context, are far too variable and flaky – one image file doesn’t mean this is a collection of photos, and one .MP3 or .WAV doesn’t make it a music collection either. Several apps will include a few image or audio files in the same directory, yet if anything these should be handled as “mixed content”. Vista’s guessing is as absurd as vintage Windows 95’s auto-resolution of shortcuts that point to missing targets (remember “can’t find WINWORD.EXE, should I point to SMARTDRV.EXE instead, and do so forevermore if you click OK?”). Navigate into a new Start menu folder containing the Skype icon, and it will always be shown as thumbnails view; other Start menu folders containing other icons typically look “normal”. Bizarre. There are safety aspects to this as well – when I view a folder, it may be because I know there’s malware in there and I intend to delete files without “opening” them. Having the shell code automatically groping all this material is exactly what I DON’T want – and that applies especially to the “autoplaying” of arbitrary CDRs and external storage devices. ### Dead icons for living shortcuts This also drives me nuts in Vista, and may be related to the way that Windows Installer smurfs pointers to files and icons through CLSIDs. Specifically, shortcuts created by Windows Installer’s processing of .MSI files, will not point to the actual executable, but to a spare copy of this that is held within %WinDir%\Installer – and yes, this junk can’t be relocated off C:. Well, all of that’s just Windows Installer; irrespective of whether that’s on XP or Vista, it’s equally flaky and tedious, e.g. prone to spontaneously demanding install disks for stuff you thought you’d already installed, and weren’t even running at the time. What’s particular to Vista, is how icons within the Start Menu – both (All) Programs and the “recently used” and pinned lists – often flip to the generic “file not found” icon, and stay that way even if you can right-click the shortcut and re-assert the icon. Given that CLSID-based post-.MSI shortcuts preclude user UI editing of target filespecs etc., maybe this isn’t related to Windows Installer after all – then again, I’ve enough other reasons to wish Installer and .MSI to go away forever. ### Is it selected or not? Vista feels “different” to XP when one is selecting items, as well as nodding the current item through these. For example, for item1 … item5, if you’re holding down the Control key and using the arrow keys to nod the current item along, after using Space to select item2 and item4, then the appearance of these items can be confusing. The selection colours are usually quite pale, and the difference between “selected”, “unselected”, “current and selected” and “current but not selected” is extremely subtle. In contrast, XP uses different and mutually exclusive UI techniques for selected vs. unselected (different background color) and current item (outline rectangle). Vista’s fancy 3D pastels may be pretty to look at, and thus nice for the first few minutes, but they’re hard to work through, and thus a pain for ever. In fact, it really amuses me how we’ve “progressed” as far as monitors and GUIs are concerned. First, we used curved reflective tube monitors that picked up reflections from lights and windows, and all we wanted was a matt non-reflective screen, or better yet, a screen with a flat surface that didn’t show these highlights. Now that we have flat LCDs that don’t reflect the room back at us while we’re trying to work, we add fake highlights all over everything. Then we’re told we need higher-performance (and power-hogging) hardware so we can see these added imperfections – very strange. ## 05 March 2009 ### Automatic Update May Force-Feed You Technorati tags: Here’s a fun thing to try, as re-verified tonight in XP SP3: Set Automatic Updates to “Download updates for me, but let me choose when to install them”, then when the yellow shield shows new updates are ready to install, go “Advanced”, UNcheck all of them, and ignore the prompt. Now do the same thing with the yellow shield. See how the updates are checked again? UNcheck them again, as you did before. Now go to the Start Menu, Turn Off Computer. Notice how the dialog box is set to install updates, with the non-icon link text to shutdown without installing them? In tonight’s case, the updates were two; one, a self-serving “Genuine Advantage” for MS Office, and the other, something to update with Windows Live Sign-In Assistant. I’ve debated this topic in a security newsgroup, who are gung-ho to have us consumers swallow updates immediately, even if they advise against immediately rolling updates across their own corporate network “production machines” before these are tested. Well, as a consumer, I have a network of one crucial “production machine”, I don’t have pro-grade in-house testing capabilities, and yet I don’t want my system adversely impacted either. As it stands, you can read “Download updates for me, but let me choose when to install them” to mean “let me choose whether to install them right now, or have them forced into the system on next shutdown” or (as I did), “let me choose whether or not to install them at all”. I want my downloaded updates stored somewhere in a redirectable location (hint: Not C:) so that I can initiate installation when I choose. Yes, pre-check them in the yellow shield dialog box, but if I assert my desire to NOT install them by UNchecking them, then DO NOT install them. ## 11 September 2008 ### Google Chrome - Born Dead? Technorati tags: , Web browsers are serious risk surfaces, so there's always room for a better one - but so far, most new browsers are a lot dumber than the incumbents. So it was with Apple's Safari, when that was ported to Windows as a beta -it was found to be exploitable within two hours of release. So it is with Google's Chrome, which should be no surprise as it uses the pre-fixed exploited code from Safari! By-design safety Google talk a good talk, with these security features widely quoted: • Privacy mode for trackless browsing • Each tab runs in its own context, can't crash other tabs • Tabs run in a "sandbox", can't attack the rest of the system • Updates list of bad sites from Google's servers, to spot phishing scams • Web pages can open without browser UI elements (uhh... why is this "secure"?) My first reaction when I read this was, "wow, Google scooped IE8's feature set", given that IE8 builds IE7's to phishing filter into a more comprehensive updated system, runs tabs in separate processes so they don't crash the whole browser, and Vista runs IE7 and thus IE8 in a safer "protected mode" for well over a year now. I don't know whether Google's "sandbox" is stronger and safer than IE7-on-Vista's "protected mode", or whether either of these constitute an effective "sandbox". Then I thought: Hang on, this is a newly-released beta, whereas IE8 has been in beta for a while now and has already been more widely released as beta 2... so who's first to offer these features? I have to wonder why Google thinks it's a good idea to spawn web content (basically, stuff foisted from the web) as generic stand-alone windows, when we already have so many problems with pop-ups forging system dialog boxes to push fake scanners etc. Why is it considered a good idea to let sites hide the address bar, when phishing attacks so often use misleading URLs that HTML allows to be covered with arbitrary text, including completely different fake URLs? Code safety Google talks about a large sandboxed system to interpret JavaScript, which sounds a bit like the idea behind Java. Well, we've seen how well that works, given the long list of security updates that Sun have to constantly release to keep up with code exploits - so we'd have to hope Google are really good at crafting safe, non-exploitable code. So it doesn't bode well, that the public beta they release is based on a known-exploitable code base, which is already being attacked, at a time when patched versions of this code are already being retro-fitted to existing Safari installations. Why would Google not build their beta on the fixed code base? It's Open Source, and already available, why not use it? Would it have killed them to delay the hitherto-secret web browser beta until they'd adopted the fixed code? Or is the need to leverage pre-arranged hype etc. more important than shipping known-exploited code to users? And why does the fixed release still report the exploitable code base version? Trust me, I'm a software vendor How do you feel about vendors who silently push new code into your system and are slow to tell you what it does? Here's what Google is quoted as saying about that: "Users do not get a notification when they are updated. When there are security fixes, it's crucial that we update our users as quickly as possible in order to keep them safe. Thus, it's important for us to not require user intervention. There are some security fixes that we'll keep quiet because we don't want to disclose security vulnerabilities to attackers" To me, that reads like a dangerous combination of Mickey-Mouse attempts at security via obscurity, plus supreme vendor arrogance. But wait, there's more... Further things have come to light when searching for links for this post, such as installing in a "data" location (thus side-stepping Vista's protection for "Program Files") and a rather too-effective search that finds supposedly private things. "Well, it's a beta", I can hear you say. That's why it's safely tucked away deeply within Google's developer site, so that only the adventurous and knowledgeable will find it, right? I mean, it's not as if it's being shoved at everyone via popular or vendor-set web pages so that it's gaining significant market share, is it? ## 10 September 2008 ### Compatibility vs. Safety Technorati tags: , Once upon a time, new software was of interest because it had new features or other improvements over previous versions. This attracted us to new versions, but we still wanted our old stuff to work - so the new versions would often retain old code to stay compatible with what we already had. Today, we're not so much following the carrot of quality, but fleeing the stick of quality failure. We are often told we must get a new version because the old version was so badly made, it could be exploited to do all sorts of unwanted things. In this case, we want to break compatibility so that the old exploit techniques will no longer work! Yet often the same vendors who drive us to "patch" or "upgrade" their products to avoid exploitation risks, still seem to think we are attracted by features, not driven by fear. Sun's Java I've highlighted the long-standing problems with Sun's Java before, and they are still squirming around their promise to mend their ways. In short, they may still leave old exploitable versions of the Java JRE on your system, but it's no longer quite as easy for malware to select these as their preferred interpreter. Still, you're probably safer if you uninstall these old JREs (as Sun's Java updater typically does not do) than trust Sun to deny code access to them. Microsoft's Side By Side Here's an interesting article on the Windows SxS (Side By Side) facility, which aims to appease software that was written for older versions of system .DLLs and thus ease the pain of "DLL Hell". This works by retaining old versions of these .DLLs so that older software can specify access to them, via their manifest How is that different from Sun's accursed practice? Well, is generally isn't, as far as I can tell, until a particular exploit situation is recognized where this behaviour poses a risk. The current crisis du jour involves exploits against GDIPlus.dll - yep the same one that was fixed before - and the patch this time includes a facility to block access to old versions of the .DLL, leveraging a feature already designed into the SxS subsystem. ## 05 September 2008 ### The Most Dangerous File Type Is... Technorati tags: , The most dangerous file type is... what? Well, you pass if you said ".exe", and get bonus marks for ".pif, because it's just as dangerous thanks to poor type discipline, and more so because of poor UI safely that hides what it is". But today's answer may be neither. By the time a code file lands up on your system, there's a chance your antivirus will have been updated to know what it is, and may save the attacker's shot at goal. But a link can point to fresh malware code that's updated on the server side in real time; that's far more likely to be "too new" for av to detect, and once it's running, it can kill or subvert your defences. We need to apply this realization to the way we evaluate and manage risk, to up-rate the risk posed by whatever can deliver Internet links. Think "safe" messages without scripts or attachments, and blog comment spam (including the link from the comment poster's name). Think also about how HTML allows arbitrary text to overlie a link, including text that looks like the link itself. This link could obviously go to www.bad.com, but it's less obvious that www.microsoft.com could go there instead. Then think how HTML is ubiquitously tossed around as a generic "rich text" interchange medium, from email message "text" to .CHM Help files. ## 13 August 2008 ### Bart Plugin for Spybot 1.6 See previous post about the new version 1.6 of Spybot SD and its issues. I've updated my Bart plugin (tested with XP SP2 code base, Bart Builder 3.1.3) to address these, and offer it here, along with .REG for control in Windows. To use the plugin, do this: • Navigate into your Bart Builder plugin folder • Create new folder called SpybotSD and enter it • Copy this post's plugin files to this location • Create a subfolder Files within this location and enter it • Copy the installed Spybot 1.6 subtree contents into here The plugin is written with these assumptions and dependencies: • Standard Bart PE Builder with nu2menu as shell • Cmdow utility in Bart included Bin folder (not essential) • Paraglider's RunScanner plugin in plugin\RunScanner Cmdow Cmdow hides windows for processors, and I use it to hide the .CMD launcher; it's purely cosmetic, so if missing, the plugin will still work. Because Cmdow can be dropped on systems and used maliciously, many scanners will detect it as a "potentially unwanted program", and fair enough! RunScanner RunScanner allows registry-aware tools to run relative to an inactive set of hives, rather than those of the booted OS. Spybot has native awareness of this situation, so theoretically doesn't need RunScanner, but I find I get better detections if I use it anyway. If RunScanner isn't present, you'd have to revise the .INF and .XML for it else it won't work. SpybotSD.inf This determines how Spybot 1.6 is integrated into the Bart CDR at build time. ; spybotsd.inf ; PE Builder v3 plug-in INF file for Spybot - Search & Destroy by Safer Networking Ltd. ; Created by Patrick M. Kolla, Jochen Tösmann and modified by cquirke for Spybot 1.6 [Version] Signature= "$Windows NT\$"

[PEBuilder]
Name="Spybot - Search & Destroy"
Enable=1
Help="spybotsd.htm"

[WinntDirectories]
a="Programs\SpybotSD",2
b="Programs\SpybotSD\Dummies",2
c="Programs\SpybotSD\Excludes",2
d="Programs\SpybotSD\Help",2
e="Programs\SpybotSD\Includes",2
f="Programs\SpybotSD\Languages",2
g="Programs\SpybotSD\Plugins",2

h="Programs\SpybotSD\HelpHTML",2
i="Programs\SpybotSD\HelpHTML\css",2
j="Programs\SpybotSD\HelpHTML\html",2
k="Programs\SpybotSD\HelpHTML\images",2

[SourceDisksFiles]
*.cmd=a,,1

files\blindman.exe=a,,1
files\SDMain.exe=a,,1
files\SDUpdate.exe=a,,1
files\SDWinSec.exe=a,,1
files\SpybotSD.exe=a,,1
files\TeaTimer.exe=a,,4
files\Update.exe=a,,4
files\aports.dll=a,,1
files\DelZip179.dll=a,,1
files\SDHelper.dll=a,,4
files\Tools.dll=a,,4
files\messages.zres=a,,1
files\Tools.dll=a,,1
files\sqlite3.dll=a,,4

files\Dummies\*.*=b,,1
files\Excludes\*.*=c,,4
files\Help\*.*=d,,4
files\Includes\*.*=e,,1
files\Languages\*.*=f,,4
files\Plugins\*.*=g,,1

files\HelpHTML\*.*=g,,4
files\HelpHTML\css\*.*=h,,4
files\HelpHTML\html\*.*=i,,4
files\HelpHTML\images\*.*=j,,4

0x4, "Safer Networking Limited\Tweaks", "DisableTempFolderCleaning", 0x1
0x1, "Paraglider\RunScanner\SpybotSD.exe", "HKLM", "Software\Safer Networking Limited\Tweaks"

[Append]

Ensure that when you copy and paste these files, that they are free of HTML tags and formatting junk, and that long lines (e.g. the two lines in the last section) are not broken.  The above differs from Safer Networking's plugin for 1.5, in that:

• It includes new code file sqlite3.dll
• It suppresses automatic temp file clearance
• It persists the above setting through RunScanner

The last is useful, so you don't have to use non-zero /t parameters in an attempt to delay registry redirection until Spybot has checked for the "disable temp clearance" setting.

This integrates Spybot 1.6 into the Bart menu system, and is referenced from the .INF during build time.

<!-- Nu2Menu entry for SpybotSD -->
<MITEM TYPE="ITEM" DISABLED="@Not(@FileExists(@GetProgramDir()\..\SpybotSD\SpybotSD.exe))" CMD="RUN" FUNC="@GetProgramDir()\..\SpybotSD\SpybotSD.exe">Spybot 1.5.2</MITEM>

You may change this to strip references to RunScanner, relocate it to a different menu flyout etc. or if you're fed up with disordered menus, you may simply leave out this file (; comment it out in the .INF) and add your reference directly to plugin\nu2menu\nu2menu.xml - once again, watch out for long lines; there is in fact only one line between the MENU ID and /MENU tags.

SpybotSD.cmd

This launches Spybot 1.6 from the nu2menu entry at runtime.

@Echo Off

SetLocal

Set Debug=
Set Prog=SpybotSD.exe
Set Launch=%~dp0..\RunScanner\RunScanner.exe
Set Opt=/t 0

If Not Defined Debug (
Cmdow @ /HID
%~dp0..\..\Bin\Cmdow @ /HID
) Else (
Title Debug
Echo.
Echo ProgDir  %~dp0
Echo Prog     %Prog%
Echo Launch   %Launch%
Echo Opt      %Opt%
Echo.
Pause
Title %~dp0%Prog%
)

If Exist "%~dp0Files\%Prog%" Set ProgDir=%~dp0Files\
If Exist "%~dp0%Prog%"       Set ProgDir=%~dp0
If Defined ProgDir (
If "%SystemDrive%"=="%~d0" (
Start %Launch% %Opt% %ProgDir%%Prog%
) Else (
Start %ProgDir%%Prog%
)
) Else (
Title Error - target executable not found!
Echo "%Prog%" not found in %~dp0 or %~dp0Files\ - abort!
Pause
EndLocal
Exit /b 1
)

If Defined Debug (
Echo.
Echo Done!
Echo.
Pause
)

EndLocal

Exit /b 0

You can edit this to strip out the "debug" part (define the Debug variable to enable it), as well as references to Cmdow and RunScanner.  By changing the variables, you can use this for other "easy" tool plugins (e.g. HiJackThis).

The logic goes as follows; if boot drive is same as where we are, then we're Bart-booted and need to apply RunScanner redirection, else we're not, and can run the tool directly.  This logic will also not use RunScanner if run from a WinPE 2.0 boot disk, which is OK with me as I don't know how safe RunScanner is for Vista hives.

An extra bit of logic is applied to deriving the path to the tool, so that the .CMD will work when run from the pre-build subtree.  This is also why the .XML uses relative "GetProgramDir()\..\" paths, rather than the more commonly used "GetProgramDrive()\Programs\" paths that break in the pre-build or pre-iso environments.

Windows .REG

You can also control some of Spybot's potentially unwanted behaviours via .REG in Windows, similar to the Software.AddReg section in the .INF above:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Safer Networking Limited\Tweaks]
"DisableTempFolderCleaning"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Paraglider\RunScanner\SpybotSD.exe]
"HKLM"="Software\\Safer Networking Limited\\Tweaks"

The second part of the above will pre-load appropriate settings for a Bart session using RunScanner, in case the RunScanner's parameters cause it to read its settings from the hard drive's hives.

Some settings can be changed interactively, e.g. disabling the intrusive Tea Timer feature, while others have to be excluded at the time of installation.  One of the latter, is the right-click context menu action to scan using Spybot, which annoyed these folks who offer this fix:

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\*\Shell\sdfiles]

[-HKEY_CLASSES_ROOT\Folder\shell\sdfiles]

[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\Shell\sdfiles]

The * association is applied to all things, hence all things can be right-clicked and scanned.  There's an Undo .REG in the same post in that thread.