Adobe Flash Update is a f*cking joke!

I had this bright idea that I would blog some of my accomplishments.  At least the ones that might be helpful to other people.  That was like 10 years ago.  Woops.

Remember when Flash Player was a Macromedia product?  I miss those days.  Adobe needs to pull their developers head from their respective asses and figure out how to make a product updater that actually works.  If all of your users are local administrators (are you stupid?) and you don't use a proxy server with active directory authentication (must be nice), and you trust your users to allow the update to run when asked (all too often) then you must represent their imaginary customer.

For the rest of you like myself, I had to write a horrific batch script to accomplish some simple tasks.

• Is there a new version that we need to install?
• If so - remove all the old stuff.
• Install the new stuff.

I like to install both the ActiveX *AND* the plugin.  You don't need the plugin if you only run IE in your environment.  But we are encountering a lot of applications written for Mozilla code (read Firefox).  Might as well have it there if we need it.

Go download the files.  To get your hands on the MSI installers, you will need to sign a distribution agreement.  So I can't give you those files.  Or even a link to them.  While Adobe has no time to cater to the needs of their customers, they seem to have plenty of time tracking down and yelling at people like me.

Put your files out in some common place.  Like the NETLOGON folder in your AD environment.  Or a file share somewhere.

But enough of that - here is the script.  Note, you might want to uncomment the pause at the bottom of this script so that you can do some debugging with it.

@ECHO OFF

REM Update Adobe Flash Player

REM Steve Ballantyne 12/12/2014

SET LATESTVERSION=16.0.0.235

REM Make sure our Temp folder exists.

IF NOT EXIST c:\Temp MKDIR c:\Temp

REM Check the LOGONSERVER variable - sometimes Windows is STOOPIDS

IF [%LOGONSERVER%] == [] (set LOGONSERVER=\\SOMEDOMAINCONTOLLER)

REM We must get rid of old versions of Flash

IF EXIST c:\Windows\System32\Macromed\Flash\FlashUtil*ActiveX.exe (set SYSTYPE=System32)

IF EXIST c:\Windows\SysWOW64\Macromed\Flash\FlashUtil*ActiveX.exe (set SYSTYPE=SysWOW64)

DIR /B c:\Windows\%SYSTYPE%\Macromed\Flash\FlashUtil*ActiveX.exe > c:\Temp\flashuninst.txt

set /P FLASHUNINST= < C:\Temp\flashuninst.txt

REM Do a version check against INSTALLED version (eg FlashUtil32_15_0_0_246_ActiveX.exe)

for /F "tokens=2 delims=_" %%a in ("%FLASHUNINST%") do SET MAJORV=%%a

for /F "tokens=3 delims=_" %%a in ("%FLASHUNINST%") do SET MINORV1=%%a

for /F "tokens=4 delims=_" %%a in ("%FLASHUNINST%") do SET MINORV2=%%a

for /F "tokens=5 delims=_" %%a in ("%FLASHUNINST%") do SET MINORV3=%%a

echo INSTALLED VERSION IS %MAJORV% %MINORV1% %MINORV2% %MINORV3%

REM Chop up version number of the LATEST FlashPlayer (variable set at the top of this file)

for /F "tokens=1 delims=." %%b in ("%LATESTVERSION%") do SET IMAJORV=%%b

for /F "tokens=2 delims=." %%b in ("%LATESTVERSION%") do SET IMINORV1=%%b

for /F "tokens=3 delims=." %%b in ("%LATESTVERSION%") do SET IMINORV2=%%b

for /F "tokens=4 delims=." %%b in ("%LATESTVERSION%") do SET IMINORV3=%%b

echo LATEST VERSION IS %IMAJORV% %IMINORV1% %IMINORV2% %IMINORV3%

REM Compare MAJOR version first (if it's the same or lower we keep on truckin)

IF %IMAJORV% GTR %MAJORV% goto UPDATE

REM Compare Minor versions next

IF %IMAJORV% EQU %MAJORV% goto CHECKMINOR1

:CHECKMINOR1

IF %IMINORV1% GEQ %MINORV1% (goto UPDATE) ELSE (goto CHECKMINOR2)

:CHECKMINOR2

IF %IMINORV2% GEQ %MINORV2% (goto UPDATE) ELSE (goto CHECKMINOR3)

:CHECKMINOR3

IF %IMINORV3% GTR %MINORV3% (goto UPDATE) ELSE (goto CHECKMINOR3b)

:CHECKMINOR3b

IF %IMINORV3% EQU %MINORV3% (goto DONE) ELSE (goto FAIL)

:FAIL

echo.

echo Something is wrong ...

echo Maybe the installed is newer than 

echo the one we are installing?

echo.

echo %computername% (%USERNAME%) FAILED to install Flash Player - Installed version %MAJORV%.%MINORV1%.%MINORV2%.%MINORV3% and the latest version %LATESTVERSION% on %DATE% at %TIME% >> \\SOMEWHERE\FlashInstallLog.txt

echo.

goto DONE

:UPDATE

ECHO c:\Windows\%SYSTYPE%\Macromed\Flash\%FLASHUNINST% -uninstall

REM Install ...

msiexec /i %LOGONSERVER%\NETLOGON\flashplayer\install_flash_player_%IMAJORV%_plugin.msi /quiet

msiexec /i %LOGONSERVER%\NETLOGON\flashplayer\install_flash_player_%IMAJORV%_active_x.msi /quiet

REM Leave a breadcrumbs file

date /t > c:\Windows\%SYSTYPE%\Macromed\Flash\DA-FlashPlayer-Installed-%LATESTVERSION%.txt && time /t >> c:\Windows\%SYSTYPE%\Macromed\Flash\DA-FlashPlayer-Installed-%LATESTVERSION%.txt

REM Cleanup

DEL c:\Temp\flashuninst.txt

echo %computername% (%USERNAME%) succeeded in installing Flash Player - Installed version was %MAJORV%.%MINORV1%.%MINORV2%.%MINORV3% updated to %LATESTVERSION% on %DATE% at %TIME% >> \\SOMEWHERE\FlashInstallLog.txt

GOTO DONE

:DONE

REM Goodbye!

REM pause

Goodbye posssibly?

Friends, it's been a great couple of years.  But I have my doubts that my little blog will be around much longer.  Google has been destroying Blogger.com since they took it over with some of the worst decisions in the history of bad decisions.  At one point, I would have put them over Wordpress on who would win the Blog-war of 10 or so years ago.

Since then they have:

• Allowed SPAM to run amok for something like seven years.
• Launched several experimental features - while implimenting none of them.
• Added a few new themes (at the rate of one or two every couple of years).
• Ignored all voices of reason from their user base.

At least Blogger is good for one thing - and that's the occassionaly porn-blog.

But then I got this notice ...

Please be advised that on June 30th 2013, we will be updating our Content Policy to strictly prohibit the monetization of Adult content on Blogger. After June 30th 2013, we will be enforcing this policy and will remove blogs which are adult in nature and are displaying advertisements to adult websites.

For those keeping score - thatis FOUR FUCKING DAYS from now.  So if you had an adult blog - I guess they are telling you to go fuck yourself.  You have four days before your shit is permanently taken offline.

I was once an Android developer, and I got the same bullshit with their Market rules.  Seems like once a month they were sending out new rules, while reminding you that "we said we are allowed to make up the rules as we go along, and fuck you, we're Google".

So it's probably only a matter of time before they find something in my 10+ years of material here that 'they' don't like, at which point the lights will go out here.

If you actually look here for new content, or are still a subscriber (?) to this old Blog - thank you for reading over the years, and goodbye ... probably.

Trend Micro Officescan 10 Removal Script

The folks at Trend Micro make a pretty nice Anti-virus tool, but like other Anti-virus vendors, they do not provide a good means of uninstalling the client.

On multiple occasions I have had clients which end up with a half-installed version of Officescan. The result is that you cannot install the client because it's all ready there. And you can't remove it, because it's not installed.

Trend Micro has an article in their knowledge base which tells you what needs done to manually uninstall the client ... but it's a lot of steps and it's no fun to repeat this across multiple workstations/servers. For that reason - I have created a batch script which performs all of the steps for you. It takes only a few seconds to run and it works like a champ! Honestly, I don't know why they don't just package this into an exe for their users and save them some brain cells.

To use my script (for Windows XP and 2003 ONLY):

1) Copy and paste the contents below into a file named "trendmicroremoval.bat".

@echo off

echo Trend Micro OfficeScan 10 client removal script!
echo by Steve Ballantyne 4/30/2010
echo Based upon: http://esupport.trendmicro.com/Pages/Uninstalling-the-OfficeScan-10-client.aspx#P140_2883
echo.
echo This script assumes that you have all ready uninstalled
echo the TrendMicro OfficeScan client from add/remove programs
echo and it did a sloppy job. If not, go in and add/remove it
echo first and then only run this if you need to!
echo.
echo This only works for OfficeScan 10, and only for XP/2003.
echo Other operating systems won't run 'devcon.exe' for the
echo device removal portion of this script. See the referenced
echo URL for the full instructions.
echo.

echo SERVICE REMOVAL
echo.

REM Stop all services
net stop "tmlisten"
net stop "tmproxy"
net stop "ntrtscan"
net stop "TMBMServer"

REM Remove the services.
sc delete "tmlisten"
sc delete "tmproxy"
sc delete "ntrtscan"
sc delete "TMBMServer"

echo.
echo PROGRAM FILES DIR REMOVAL
echo.

REM Program Files Directory.
DEL /S /F /Q "C:\Program Files\Trend Micro\"

echo.
echo REGISTRY KEYS REMOVAL
echo.

REM Registry keys GALORE.
REG DELETE "HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\OfficeScanNT" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\OfficeScanNT Monitor" /F

REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ntrtscan" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmcfw" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmcomm" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TmFilter" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tmlisten" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmpfw" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TmPreFilter" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TmProxy" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmtdi" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSApiNt" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmlwf " /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmwfp " /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TMBMServer" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmevtmgr" /VA /F

REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\ntrtscan" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\tmcfw" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\tmcomm" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\TmFilter" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tmlisten" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\tmpfw" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\TmPreFilter" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\TmProxy" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\tmtdi" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\VSApiNt" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\tmlwf " /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\tmwfp " /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\TMBMServer" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\tmevtmgr" /VA /F

REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\ntrtscan" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\tmcfw" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\tmcomm" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\TmFilter" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\Tmlisten" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\tmpfw" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\TmPreFilter" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\TmProxy" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\tmtdi" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\VSApiNt" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\tmlwf " /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\tmwfp " /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\TMBMServer" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\tmevtmgr" /VA /F

REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\ntrtscan" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\tmcfw" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\tmcomm" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\TmFilter" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\Tmlisten" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\tmpfw" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\TmPreFilter" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\TmProxy" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\tmtdi" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\VSApiNt" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\tmlwf " /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\tmwfp " /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\TMBMServer" /VA /F
REG DELETE "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Services\tmevtmgr" /VA /F

echo.
echo HIDDEN DEVICE REMOVAL
echo.

REM tmcomm
devcon /r remove "ROOT\LEGACY_TMCOMM\0000"
REM tmactmon
devcon /r remove "ROOT\LEGACY_TMACTMON\0000"
REM tmevtmgr
devcon /r remove "ROOT\LEGACY_TMEVTMGR\0000"
REM Trend Micro Filter ?? (not verified)
devcon /r remove "ROOT\LEGACY_TMFILTER\0000"
REM Trend Micro PreFilter ?? (not verified)
devcon /r remove "ROOT\LEGACY_TMPREFILTER\0000"
REM Trend Micro TDI Driver
devcon /r remove "ROOT\LEGACY_TMTDI\0000"
REM Trend Micro VSAPI NT ?? (not verified)
devcon /r remove "ROOT\LEGACY_VSAPINT\0000"
REM Trend Micro Unauthorized Change Prevention Service ?? (not verified)
devcon /r remove "ROOT\LEGACY_TMBMSRV\0000"
REM Trend Micro WFP Callout Driver ?? (not verified)
devcon /r remove "ROOT\LEGACY_TMWFP\0000"

echo.
echo DONE - Now try to reinstall!
echo.
PAUSE

2) Grab a copy of DEVCON from this Microsoft download page. Place the devcon.exe file next to the trendmicroremoval.bat file. This will allow the batch script to remove some hidden devices.

3) Run the batch file, and watch in awe.

4) Now you can reinstall the client (assuming that was your goal to begin with).

Did this help you? Drop me a comment!

NOTE: Devcon is what limits this script to XP/2003 only. If you are running Windows 2008, Vista, Windows 7, etc. you can still run the batch file, just not the devcon part. You would have to follow manual instructions for device removal according to the Trend Micro KB.

Thin Clients Part II - Security Added

Late last week I took my little thin client computing concept a step further and added some security. My goal was to add at least one layer of security, if not two layers to this process. Like a smart card concept I wanted to have a physical token (the thumb drive itself) as well as a "secret PIN" which the user would need to supply. This might add a bit of time to the login process, but the security would be well worth it.

The New Process
We will still use an autorun.inf file which will allow the user to plug in the thumb drive and simply press enter for the default choice. The default choice, is to run a batch script which I have called "connect.bat". Here are those files.

autorun.inf
[autorun]
open=connect.bat
ACTION = LAB CONNECT

connect.bat
SET STARTRUN=%0
7za.exe e -oC:\TEMP -y RDPPACK.zip
REM COPY %0\..\*.* C:\TEMP
C:
cd C:\TEMP
start /normal ssh.bat
PING -n 8 127.0.0.1>null
start /normal RDP.bat
start /normal WAIT.bat

When connect.bat runs, it launches 7zip, which extracts a zip file to the c:\Temp directory. I used 7zip for a couple reasons: a) it's freely downloadable at http://www.7-zip.org, b) you can create password protected (encrypted) zip files with it, c) I had it installed and I all ready use it in other batch processes.

My zip file, RDPPACK.zip, is an archive which contains several other batch files. One of these batch files contains passwords so we protect the zip file by password protecting it when we create it.

My RDPPACK archive contains the following files:
labconnect.rdp - This is the file which contains RDP details such as IP and port number.
plink.exe - This is a free command line secure shell client for windows.
RDP.bat - Simple batch file to connect to the host using the settings in labconnect.rdp.
ssh.bat - This is a new batch file which uses plink.exe to open a secure shell session with our VirtualBox server.
WAIT.bat - This waits for the thumb drive to be removed, and then cleans up and kills things when that happens.

Once the zip is un-extracted (takes only a split second) we start up three other batch files simultaneously.

Here is the play by play. The user plugs in the thumb drive which runs connect.bat. This starts the file extraction which pauses momentarily and waits for the user to enter their password. In my examples I used a simple four digit "PIN Number". The files are extracted, and "ssh.bat" is launched.

ssh.bat
SET STARTRUN=%0
plink -ssh -L 13390:localhost:3390 -pw password username@10.0.46.55
EXIT

There are two items of bad news to mention here. One is that there is an EIGHT SECOND wait placed after this script runs. This is the unfortunate amount of time it takes for the secure session to be established. The other bad news is that the username and password are exposed here "in the clear". This could be hidden by putting an @ symbol in the batch script in front of that first line (keeping the command from being echoed to the user). But it will sill remain in the Temp directory while this script is running and a bad guy could find it. I would like to think that the user will not share the PIN number which revealed this information, and if their thumb drive was lost or stolen you could simply change this password on the server. So it's "pretty good" security in my book.

The plink syntax works like this: "-ssh" means to use the secure shell protocol, the "-L 13390:localhost:3390" will redirect connections that the host makes to itself on port 13390 to the server on port 3390, the "-pw password" would be this users password on the server, "username@10.0.46.55" would be the users username and the servers IP address. This means that we have created the user on the server, assigned them a password, enabled the secure shell daemon, and we are firewalled to disallow connections on port 3390. Yes, we do NOT want to allow connections to port 3390 from anybody. The only reason our remote users can do it is because they are sending these connections through the secure tunnel we established here. Clever, huh?

Once the secure session is established (we simply waited 8 seconds and assumed it's ready) we then run RDP.bat and WAIT.bat simultaneously.

RDP.bat
mstsc /f labconnect.rdp
EXIT

WAIT.bat
PING -n 10 127.0.0.1>null
GOTO CHECKEXIST

:CHECKEXIST
IF EXIST %STARTRUN% GOTO WAIT
GOTO KILLTASK

:WAIT
PING -n 3 127.0.0.1>null
GOTO CHECKEXIST

:KILLTASK
taskkill /f /im "mstsc.exe"
taskkill /f /im "plink.exe"
DEL /F C:\Temp\autorun.inf C:\Temp\connect.bat C:\Temp\labconnect.rdp C:\Temp\plink.exe C:\Temp\RDP.bat C:\Temp\ssh.bat C:\Temp\7za.exe
EXIT

RDP.bat will connect us up to the server. There were some changes made in the RDP file. That is, the client now connects to localhost:13390 instead of the server IP and port 3390.

WAIT.bat will start pinging itself in a loop, and wait for the drive to come disconnected. When that occurs, it will immediately end task on the terminal services connection, and then the secure shell tunnel. Afterward (and this is new) it does some cleaning up and deletes all that stuff that it left laying around in C:\Temp. The only thing which will remain is the WAIT.bat file itself. Which as you can see, presents no risk as it contains no passwords, etc.

Problems
I probably spent a couple of hours on this process over the span of a week. What was most frustrating was getting VirtualBox to cooperate with me. There are a few known issues with various VRDP elements. One is "authentication". Theoretically you can authenticate your VRDP sessions against a local user database on your VirtualBox server. This didn't work at all for me and after reading through a couple of forums I found that it doesn't work for anyone else either.

I am also having problems with my Windows clients when they connect to a VirtualBox at full screen. It seems that the windows get doubled up and don't display correctly. If you specify an exact window size in your RDP file such as 800x600, you will not have this problem. I went through the trouble of setting up a Windows VirtualBox server and found that the problem exists there as well. I have since opened up a Bug report with VirtualBox which I hope gets some attention.

Lastly, expect VRDP on VirtualBox to provide you with rather slow window refreshes. I would like to think that this is also something that the VirtualBox developers are improving as they have always been aware of this bug.

Hack on, and I hope that someone out there finds this information useful, at some point. ;-)

Thin Client Computing on the Cheap

Many, many years ago I was attending a trade show and I saw something really cool. There was a booth set up with a couple of screens which had card readers attached to them. You could insert one of their sample cards and a screen popped up running Windows and a couple of applications. When you removed the card, it was gone. You could then walk to one of the other terminals and insert the card - and there was what you were last working on (instantly). It was pretty neat, and the concept was simple. Running on the back end was a heavy duty server which was emulating a dozen or so Windows machines. The front end was a dumbed down Linux terminal which just connected the user to the virtual Windows machines by means of a remote connection protocol (RDP). There was a little more to it, such as strong certificate based security, but we won't tackle that just yet.

My plan today was to create a collection of virtual Windows machines, and a USB "key" which could connect me to one simply by inserting it to a workstation.

The Server: In my case, this was easy since I all ready have a Linux box running VirtualBox. If you want to create this environment, go on out to VirtualBox.org and get yourself a copy. Note that it's *FREE* to those who qualify (read the fine print). Also, there is an Open Source Edition which is free to everybody, but it lacks some key features like USB support (so avoid it for this discussion). Once you have VirtualBox you will want to create at least one workstation. This can be anything really. In my case, it was Windows XP. In the settings for that workstation you will want to go into Settings and then Remote Display. Enable remote display and set your port number (default will be 3389).

The Workstation: I am referring here to the "dumb terminal" that you will be using. This should be on the same network as the server (or there should be routing established between them). Nothing needs to be done special on this workstation. It should be running Windows for our discussion. In my case I am using Windows XP boxes.

Prepare an RDP File: This can be done on any Windows machine. Basically we just want to make a settings file that we can put on our Thumb Drive. To create this, get onto a Windows PC and click Start > All Programs > Accessories > Communication > Remote Desktop Connection. Enter your IP and port number like this SERVER:3395. If you used the default port of 3389, just enter the server name. You can specify all sorts of other info here if you want. Many of these settings have no bearing since you are connecting to VirtualBox, and not "Windows itself". When you are done, choose to save your settings. Save this right onto your thumb drive and call the file "connect.rdp".

The Thumb Drive (or Jump Drive): This is where all my work came in. You will need to create a couple of batch files on the root of the thumb drive. Here is what they are named, and what should go inside of them ....

autorun.inf - This will initiate your remote client upon plugging in the Thumb Drive.
[autorun]
open=connect.bat
ACTION = LAB CONNECT

connect.bat - This is required to launch the RDP session, and the "watcher".
SET STARTRUN=%0
COPY %0\..\*.* C:\TEMP
C:
cd C:\TEMP
start /normal RDP.bat
start /normal WAIT.bat

RDP.bat - This will launch the remote window and ultimately quit.
mstsc /f connect.rdp
EXIT

wait.bat - This will watch for the removal of the thumb drive. If it's removed, the remote session is closed within 3 seconds.
GOTO CHECKEXIST

:CHECKEXIST
IF EXIST %STARTRUN% GOTO WAIT
GOTO KILLTASK

:WAIT
PING -n 3 127.0.0.1>null
GOTO CHECKEXIST

:KILLTASK
taskkill /f /im "mstsc.exe"
EXIT

With all this in place, here is how it will work.

When you insert your thumb drive, Windows XP will find the autorun.inf file and use it to launch an "Autorun list" in Windows XP. All you should have to do here is press enter (for security reasons this choice cannot be made automatically). At that point, you should see a remote connection window pop up. This whole process takes a few seconds.

While you are remotely connected, there will be two Command Prompt windows lingering in the background. One is just running the RDP application. The other is running a watch on the thumb drive. If you watch it, you will see that the PC pings itself three times, sending the result to "nowhere". The reasoning behind this is to give the PC something to do to waste time. Windows XP does not have a sleep or wait method that you might use to waste time cycles. Every time it completes it's three pings, it will check for the existence of the drive letter being used by the thumb drive. Through some clever tricks involving the "%0" variable, we are able to determine this drive letter regardless of what was chosen when it was inserted. If the drive letter is gone, the batch process hunts down the RDP task and kills it, then ends that script by exiting. The other script which had been running the RDP task moves to the next line, which tells it to exit also. The result is, the remote connection window and all it's friend vanish almost the instant the the thumb drive is removed.

You will see that my scripts first copy themselves to C:\Temp before running. The reasoning behind this was that if the drive is removed while a batch script is running from it, the script will fail and leave a "Terminate Batch" prompt on the screen. A colleague noted that in a production environment you would probably want yet another batch file in this process which removes all these items from Temp once it's done running. But it's a work in progress.

Next, I will focus on adding some form of security to this process as there presently isn't any.

Poor Mans Low Level Format

On occasion I am asked to "blank out a device" or remove any data it contains. Usually this is because we are disposing of media or we are selling off equipment at the hospital which once may have contained a patients medical records. This seems to be an easy task, with a complicated solution. The goal is to "write zeroes" to the hard drive repeatedly. This is affectionately referred to as a low-level format.

Sure, there are utilities to perform this task. Some are free, while others and get quite expensive. I also seem to run into problems where certain utilities only work with certain drives (a Western Digital utility only works with Western Digital drives).

Enter the simple and free solution: Linux.

I have several different versions of Linux laying around. Old versions of Ubuntu, new versions of Xubuntu, you name it. So here is what I did.

1) Insert your live distribution of Linux, and boot to it (this may require changing BIOS options, or changing boot options).
2) Wait for the desktop to appear, or fail to appear. I was working with some bizarro medical machines today which failed to boot completely and instead dumped me into "BusyBox". BusyBox is like a small shell which can only execute very minimal commands. But this will do.
3) If you boot all the way to a graphical desktop you can either open a Terminal window, or press Ctrl+Alt+F1 to get a virtual terminal.
4) Enter this command: cat /dev/zero > /dev/sda (or /dev/hda for older IDE drives).
5) Wait for the error message, "No space left on device".

The error message is inevitable. We are simply running a contents list of an imaginary device called "zero" which is filled with an infinite amount of zeroes. Then we are redirecting that stream of zeros right into the hard drive device ignoring all boundaries, partitions, master boot records, etc. Eventually we strike the end of the drive and it tries to keep going, hence the error message.

If you want to follow the old "D.O.D. Standards" you will want to repeat this low level format at least 6 more times (if not 9 more). You can run this command repeatedly by separating your commands with semicolons. For example ...

cat /dev/zero > /dev/sda; cat /dev/zero > /dev/sda;cat /dev/zero > /dev/sda

... would perform three consecutive low level formats. Sure, you could write this into a shell script. But then we are talking about something quick and dirty here which you can do simply by booting whatever distribution of Linux you have laying around.

Disclaimer: A purist might say "That's hogwash Steve! That data is still retrievable by using a chemical separation process on the platters". To which I would say, "then take them home and prove me wrong". Yes, data could still theoretically be retrieved from these disks ... if you have a laboratory environment, or the money to pay someone retrieve it. If you are really paranoid, consider alternating between writing zeroes to the device, and writing random data to the device. This can just as easily be performed with ...

cat /dev/urandom > /dev/sda

They say that by alternating and randomizing the data that you write, recovery becomes all the more impossible.

Thinkpad x60 Booting Disaster

A while back one of our doctors at the hospital bought himself a ThinkPad x60. At the time, it was about the most portable model that you could buy without sacrificing speed and extra memory. Yet - it was a ThinkPad. I will spare you the soapbox essay on why I believe that ThinkPads are crap. If you are using a ThinkPad and you you "just love it", good for you. But heed my warning: keep your stuff backed up, because your hard drive will fail in a year (or maybe sooner). And don't even get me started on the "lenovo" brand - which produced this gem. I think lenovo must translate into Chinese as "cheaply manufactured crap".

The good doctor brought me his laptop with a failed hard drive. That was no surprise. It was very well covered under warranty, but I had a hell of a time finding a number to call on the lenovo support site. IBM seemed to have disowned anything that lenovo produced, so they were not offering anything but a redirecting URL. Eventually I called a "paid support line" where I would be expected to put $70 on a credit card for a one-time support request. Knowing full well I wasn't paying a dime for something covered under warranty - I bounced around in their phone system a couple times and eventually found a live person. Lo and behold, this was the right department and they were able to send me a new drive. To their credit - it arrived less than 24 hours later.

All I had to do now was to restore the ghost image I took of the failing drive. I went through the usual process only to find that the PC was not going to boot. This was not all that shocking seeing how I imaged a failing hard drive and probably picked up a few errors along the way. All I really needed to do was to boot the Windows XP SP2 CD, and slip into the Recovery Console. From there you can run a "fixboot" and "fixmbr" to put things in order. There was just one problem ... this model has no CD-ROM drive.

Following what seems like poorly written instructions - I was able to slap together a Windows XP SP2 bootable ThumbDrive image, using this guide. While I was able to boot from the USB stick, I was not able to get past the "Setup is starting Windows" before it would blue-screen on me with a stop message. The problem seemed to be that Windows was losing itself, after having booted from the stick.

The solution to that issue ended up being to go into the BIOS of the x60 and setting the SATA option from "AHCI" to "Compatibility Mode". Not sure what that had to do with the USB boot problem, but it worked. No more blue screens. And I was able to start the Windows XP Recovery Console. But here was the other catch - by performing a "fixboot" and "fixmbr" I actually fixed the boot files of the laptop hard drive, but then BROKE the boot sector of the USB stick!

Lessons learned. Who knew that these old Recovery Console commands had arguments and switches. After rebuilding my thumb drive (there's an hour lost) I was able to get back to the Recovery Console and run both commands with a drive letter. That is, "fixboot c:" and "fixmbr c:".

Now - I am back in business with a booting, working, and updated copy of Windows XP. I went ahead and set the BIOS options back to default for the SATA controls, as I don't know if that really has any effect on how the drive is accessed. You had better believe that I am taking a ghost image of this while it's working. This hard drive will surely fail in another year or so.