Truly Write Protecting a USB Drive

No registry hacks required.

I came up with this solution after my thumbdrive fell victim to a 'Virut' infected machine at work. 'Virut' attached itself to two executables on the drive, so that running either of the programs infected whatever system my USB drive was attached to.

After cleaning my drive with AVG Free Anti-Virus I searched far and wide for a way to be make my USB drive read-only. I looked into mounting the drive as a CD under the ISO9660 standard; I thought of encrypting the drive's contents; I played with multiple partitions...

I'm saddened to report that there is no way to truly write-protect a USB drive at the software level, and so the method I present here is admittedly imperfect. Nonetheless it provides some real advantages. Further, it is the only portable solution you will find short of buying a USB drive with a write-protect switch.

The Solution


The trick is to fill the disk space entirely. When the USB drive is full all write operations will be denied. Viruses will neither be able to infect existing files, nor create their own.

I found this concept here at Jared Heinrichs' blog. All credit is due to Jared Heinrichs for exposing this all-too simple method, used elsewhere in pay-software.

Using the command-line tool 'fsutil' included in windows we can create a dummy file that fills every last bit of free space remaining on our drive, thus securing it. For an explanation of how to do this manually, visit Jared's post.

As for me, I wrote a batch file to automate the job.

The Code


@echo off

REM * Written by: Roy Tousignant
REM * Date: May 19th, 2009
REM * URL: youfuckingpeople.blogspot.com

SETLOCAL EnableDelayedExpansion
ECHO.

SET sizelimit=1024000000
SET tmpfile=%cd:~0,1%:\readonly.tmp

FOR /f "tokens=3 delims= " %%A in ('dir \ /-c ^| find /i "bytes free"') DO (
SET freespace=%%A
)

IF /i %freespace% lss %sizelimit% (
IF /i %freespace% gtr 0 (
IF EXIST !tmpfile! (
FOR /f "tokens=3 delims= " %%A in ('dir !tmpfile! /-c ^| find /i "1 file(s)"') DO (
SET tmpfilesize=%%A
)
) ELSE SET tmpfilesize=0
SET /a freespace = freespace + tmpfilesize
ECHO Writing !freespace! bytes to !tmpfile!
SET /P okay=Okay?[y/n]
SET okay=!okay:Y=y!
IF !okay! equ y (
ECHO.
del !tmpfile!
fsutil file createnew !tmpfile! !freespace!
GOTO End
) ELSE GOTO Abort
)
ECHO Disc is already full.
GOTO Abort
)

ECHO Script detects more than !sizelimit! bytes of free space.
ECHO This script refuses to fill more than !sizelimit! bytes of space.
GOTO Abort

:Abort
ECHO The procedure is aborted.
ECHO.
PAUSE

:End


Usage


Copy the code above into 'notepad' and save it to your usb drive as 'readonly.bat'. Run it and answer 'y' to the prompt to create your dummy file. The window will close itself upon successful completion. To "unlock" your drive, just delete the readonly.tmp file it creates.

More Usage


I've restricted the code from writing a dummy file larger than 1Gb. This is a cheap way to prevent fsutil from filling up your hard drive or some other disk, in the event the batch file is accidentally run from the wrong drive. Remember: The batch file must be run from the USB drive itself.

If your USB drive is larger than 1Gb you can change this value in the batch script on the line that reads SET sizelimit=1024000000

To change it to the exact size of your thumbdrive, open My Computer, right click the 'Removable Disk' that represents your thumbdrive and click Properties. Use the number listed as "Capacity" to replace the 1024000000 in the code, making sure to remove all the commas. Careful here! One too many digits and the size limit could end up being 20Gb instead of 2Gb.

Limitations


The flaw in this method of protection is that nothing prevents the deletion of files. If a virus is so inclined it can still wipe out your thumbdrive the instant you connect it. And if a virus' author were sufficiently devious, he could write a sneaky little function that deletes a few adjacent files, freeing just enough space on the disk to place the virus or infect an executable.

The flipside here is that even virus authors have lives and I'm not aware of any virus that makes such a herculean effort out of anticipating a full disk.

It's a flawed solution. But it is the best we can do without a hardware fix. It's greatest virtue is how unlikely it is that a virus will infect the drive without the user knowing. A virus may remove and replace a file completely, but cannot easily infect one to keep itself hidden. It can delete files to make room for itself, but we have gained warning by way of our missing files.

Design Notes


To prevent the program from running on a large local disc, it would be better to evaluate the total capacity of the drive instead of the free space remaining. But I could find no reasonable method of gaining a drive's true capacity at the command line. At first I figured adding together the free space and the used space values provided by dir \ /s /-c would work, but in testing the value of used space reported over 100k less than correct. The only other method I could find involved the wmic, which added an intolerable delay to initializing an otherwise simple script.

End of Line


As a computer repair technician, I'm satisfied with this solution for myself and I'm happy to recommend it. Though, if pressed, I recommend buying a USB drive with a write-protect switch even more.

Posting Blocks of Code on Blogger

I had a hell of a time getting code blocks to look and behave as I wanted across the varied browsers on Blogspot. Simply, I wanted the white space preserved so I could indent lines, and I didn't want my text wrapped. Sounds like the <pre> tag should cover it, right? Ha! There's a whole litany of issues that arise in Internet Explorer when invoking the horizontal scroll-bar; Blogger's template was telling IE to word-wrap the <pre>; And even Firefox - though rightly - managed to give me a bit of the run around. Before I get into it all here's the final, working CSS I've discovered for code blocks. Copy it now! (Though don't run off without reading the Template Tip toward the bottom of the post.)

pre.code {
width: 94%;
overflow: auto;
overflow-y: hidden;
display: block;
line-height: 1.2em;
background-color: #f5f5ff;
padding: 0.5em 1em;
border: 1px solid #bebab0;
padding-bottom:15px;
}


From the CSS you can divine that I'm using <pre class="code"> to wrap my blocks. I started out using <pre><code>, and perhaps that could be made to work as well, but somewhere throughout my cross-browser compatibility struggles I ditched the code tag. It's redundant anyway. Pre tags preserve your whitespace and set a monospace type. Code tags set a monospace type. So why bother saying the same thing twice? Why? Why say it twice? Seriously, why should I say it twice?

I also had a lot of trouble with the <pre><code> arrangement where, because I was wrapping one in the other, IE would favor the <code>, ignore the <pre>, eat my whitespace and word-wrap my text. Meanwhile Firefox looked perfect - that is until you grabbed the scrollbar. Scrolling the code block would leave the background-color and border behind, sliding us into a void of undeclared white-space. In the end it proved too much hassle keeping the redundant <code> tag in just for it's own sake.

Even with the <code> tag out the window, I ran into the much maligned IE v-scroll bug. When a Mozilla browser adds a horizontal scroll bar to a block, it does it on the outside of the block. IE does it on the inside... You say tomato, I say flibbidy floo. Problem is, IE doesn't seem to account for the space the h-scroll has come to occupy. It doesn't stretch the container out, it just slaps the bar over the top of it. Now you've got a horizontal bar blocking out the last line in your <pre>, which necessitates that IE stamp a vertical scroll bar onto the block as well!

Sure, this is an ugly and unnecessarily contrived way of getting the job done: granted; but there's a bigger downside than aesthetics here. If you try to post a single line of code into a <pre>, Internet Explorer's intrusive horizontal and vertical scroll bars completely obscure your text. Scroll up, scroll down, the most you'll ever see is a sliver of what's there. Your one-line block of code is now a tasty block of scroll bar.

The simple style sheet above cures all that ails. I'm not going to explain it, just take it and go! Oh, but not until after reading this next part, of course.

The Aforementioned Template Tip


Even with the CSS implementation described here IE continued to word-wrap my code blocks. Testing outside of Blogspot proved the CSS good. So I started peeling through Blogspot's template, looking for some overriding declaration. I didn't catch it myself, but eventually found an old post on the Blogger Help forums containing the offending declaration's locale.

#main-wrap1 {
...
word-wrap: break-word; /* fix for long text breaking sidebar float
in IE */
}


If IE refuses to respect the <pre> tags on your Blogspot site, search your template for a word-wrap: break-word; being declared in the #main-wrap1 id and comment it out. If your template doesn't have a #main-wrap1 id, then you'll have to poke around until you find what your template calls it.

Caution: You'll likely find more than a few word-wrap: break-word; declarations throughout the template, and it's best not to remove them all. It should be obvious - by their names - which declarations belong to the sidebars, headers, footers, etc., and which belongs to the div(s) where your posts live.

Why, you guys? Why should I say it twice?

Blogger Bug - Internal Links Rewritten by the Composer

The best way to link to your own articles on Blogger is - or should be - with an internal link. Instead of using the full address to an article ("http://myblog.blogspot.com/2009/05/my-article.html") we should prefer an ambiguous internal link ("/2009/05/my-article.html")

Using an internal link means that if I decide to change the namespace of my blog at some point in the future the link will remain valid, since it only ever specified the subdirectory paths. This is especially important if you are using a domain name with your blogspot site, as you may in the future cease to own the domain. If you were to specify the full address in your links they will all break and become invalid if and when you let your domain lease run out.

The Bug


Entering Compose mode in Blogger's text editor resolves and rewrites all ambiguous links as children of www.blogger.com, thereby breaking them.

Example


Starting in the Compose window I click the Link button. In the URL field I enter the following ambiguous, internal link:

/2009/05/my-article.html


If I switch into the Edit Html mode my link is still properly preserved and displays the HTML code:

<a href="/2009/05/my-article.html">Visit My Article<a>


However, if I switch back into the Compose window - though I cannot see it yet - in the background my link has been resolved and specified. The HTML now reads:

<a href="http://www.blogger.com/2009/05/my-article.html">Visit My Article<a>


Not only has this negated the purpose of the ambiguous link - which is to maintain site integrity across changes in the domain name - but it has broken the link by resolving it to www.blogger.com instead of our blogspot site.

Even worse: Because the trigger here is simply entering into the Compose mode, if you merely attempt to edit or update an article containing ambiguous links, and if the editor opens into the Compose mode by default, then it will have already broken all internal links on the page just by reopening the post. If you save this reopened post you will have corrupted all your links.

Workaround


The only solution here is to never, ever use Compose mode. Switch into the Edit Html interface and get comfy. It's not much of a workaround, I know, but it's the only "solution" I've found.

I had hopes of finding a different access method that would allow linking to blogspot sites by blogID and postID. Alas I can find no record of the proper method for this and spamming the likely implementations hasn't gotten me anywhere, either.

For now, those concerned with using and maintaining ambiguous links will want to make sure the Settings>Formatting> option "Convert line breaks" is set to Yes and relegate themselves to the Edit Html interface. It's probably not a bad idea in any circumstance, as this is surely not the only bug in the Composer.

Blogger Bug - Corrupted Javascript for() loops

The Bug


Twice, when I have had call to write a javascript implementation for a blogspot page I have found that everything beneath the first line of a for() loop is chewed up, garbled, and spit back out upon saving it. Blogger doesn't throw an error of any kind, it just saves your code to the gadget, having silently mutated and destroyed what was written. This is observed by simply returning to the gadget via the edit button. There the code will be corrupt.


Example


<script type="text/javascript">

function addPlayers() {
var allmp3s = document.getElementsByName('mp3');
for (i=0;i<allmp3s.length;i++){
var mp3Player = buildEmbed(allmp3s[i]);
allmp3s[i].insertBefore(document.createElement('br'), allmp3s[i].firstChild);
allmp3s[i].insertBefore(mp3Player, allmp3s[i].firstChild);
}
}
</script>


Paste the code above into an HTML/Javascript gadget and save it. Now click edit to return to the code. Others have confirmed that as of this post's date blogspot corrupts it like so:

<script type="text/javascript">
function addPlayers() {
var allmp3s = document.getElementsByName('mp3');
for (i=0;i<allmp3s.length;i++){
}
}
mp3player="buildEmbed(allmp3s[i]);
" br var allmp3s[i].firstchild);
allmp3s[i].insertbefore(document.createelement( ),
allmp3s[i].insertbefore(mp3player,></script>


Workaround


Simply use another type of loop. A while() loop and a counter variable can be used to do accomplish the same results your for() loop might have. I haven't observed Blogger to corrupt while() loops.

A Good Reason to Kill Yourself

This summary is not available. Please click here to view the post.