Individual Liberty — Individual Responsibility 

A hacksaw is a wonderful tool

We’ve finally had a couple of days of semi-decent weather in a row out here and I was able to get back to working on my car. I’ve managed to get it running – that was an adventure after five years of sitting in the garage. Ultimately the solution to that problem turned out to be as simple as replacing some dried and cracked fuel line. Before I fired it up I changed the oil and oil filter, took care of the transmission and in general did a lot of “fluid” maintenance. The car runs fine now – on regular unleaded, which is something it didn’t do well before I put it in the garage.

Of course, no car can be driven unless you can also stop it. While I was doing the fluid maintenance I happened to check the brake fluid, anticipating the need to replace it. Yes, replacement was in order, but there were signs of another problem as well – the master cylinder was almost empty. All of that brake fluid had to have gone somewhere, but there wasn’t any easy way to find out where.

After replacing brake fluid you have to bleed the brake lines of air. While hydraulic brake fluid isn’t compressible, which is why it actually works to force that friction material on the brake pads against the steel of the brake rotors (or brake shoes and brake drums for older, cheaper brake systems) air is very compressible. If there’s air in your brake lines you get a “spongy” feel to your brake pedal, and the brakes might just fail.

So I started bleeding the brakes. The car has been on jackstands since I started the operation, and the wheels have been set aside, giving me easy access to the brake calipers. Third generation Corvettes like mine have four wheel disk brakes with four-piston calipers. There are two bleed screws for each caliper, and you have to bleed the air out through both of them, because one deals with the pistons on the inside of the wheel and the other with the pistons on the outside of the wheel.

These brake calipers are notoriously difficult to bleed of air. You might think you have it all out of them and still have a spongy pedal. This is because air can get trapped inside the pistons. The solution? Take a mallet and rap on the caliper just above the pistons. This knocks any air bubbles loose and lets you get the air out. Even with all of this I still had a spongy feel after bleeding the brakes. Obviously somewhere there was either still air in the lines or I had a leak in one of the lines – or so I thought.

I found the source of the problem as I tried one more time to get any air out of the calipers when I started working on the left rear wheel. With all of the bleed screws closed there was still an occasional gush of fluid when my son pressed on the pedal. I finally managed to locate the problem, a leak on the rear outside piston, and not a small one. There’s only one way to deal with that problem – remove and repair or replace the caliper.

Much easier said than done. Another feature of these brake systems is the easy way you can replace the brake pads. They’re held in by a retaining pin that runs through the body of the caliper, through the top of the pads, and back through the body of the caliper. A cotter pin holds the big retaining pin in place. To change the pads all you have to do is remove the cotter pin, pop out the retaining pin and slide the old pads out vertically. Putting the new pads in is simply the reverse procedure, except that you have to push back the pistons to make room for the additional friction material on the pads – which is trivial to do with the proper tool and an open bleed screw.

This easy procedure for changing the pads is so straightforward that I would be willing to bet that most third generation Corvettes still have the original calipers and brake rotors. I know that mine does. After thirty two years of exposure to the elements, heating and cooling cycles and weather, the bolts that hold the calipers in place have become rusted in place. I was able, using a 5/8” socket and a breaker bar together with some penetrating lube to remove the rear bolt holding the caliper in place – but it took a lot of work. Removing the front bolt was a different proposition altogether.

For one thing, there’s almost no clearance to get a wrench around the bolt head. Even after you’ve managed that, there’s not a lot of room to turn any wrench – the transverse leaf spring is in the way, as is the shock dampener and the exhaust. To top things off, the bolt in question sits just above a square pad welded onto the trailing arm, so if you manage to get a ratchet or a breaker bar into position with the socket the simple act of turning it will cause the tool to act as a lever to pry your wrench off the bolt. So you have to use an extension.

I fought with that bolt for hours the first day I was working on it. Torn knuckles didn’t stop me. Neither did rounding off the interior of my 5/8” socket – it was a 12 point tool, and they just don’t grip as well as a six sided socket does. Off to the store to buy a 6 sided socket. A few hours later (on the next day) and I had another tool with a rounded interior, and very sore muscles in my arms. The bolt was still stuck fast.

And then the rains came. Not only did it begin raining, but it continued raining for two and a half weeks. Yesterday was the first day it didn’t rain at least part of the day and I was out by the car again, this time with a propane torch. The idea here was to try differential heating of the flange the bolt screws into and the bolt. In theory the two metals (the bolt is steel, the flange is cast iron) should expand at different rates and move against one another, breaking the corrosion based frictional seal between them.

Using a torch around a car, especially a car with a fiberglass (glass fiber and plastic resin) body requires a lot of care and attention. No, I didn’t burn my car to the ground. No, I didn’t burn the axle seals. Yes, I did partially melt the rubber seal to one of the cylinders in the caliper, but I figured it was a loss anyway. No, I didn’t get the bolt loose.

I tried again today. No luck, that bolt stayed stuck. And so I finally resolved to apply the plan of last resort. The tool of choice? A hacksaw. After about twenty minutes of the old back and forth with the hacksaw I finally managed to cut through the bolt. It would have taken considerably less time, but working inside a fender doesn’t give you much room to work with, and I was only able to take very short (maybe about an inch and a half) strokes. But, the bolt is cut and the old caliper is off.

It’s supposed to rain again tomorrow. But, according to weather reports Saturday is supposed to be a clear day. So Saturday morning (or afternoon, depending on my level of motivation) I’ll drill out the rivets that hold the rotor in place. That will give me access to the back side of the flange with the remaining half of the bolt in it. I’ll drill out the center of the old bolt and try a punch and hammer to see if I can’t collapse the threads and knock the rest of the bolt out. And of course, I’ll have to wash away all of the debris from cutting the old bolt – that’s not something I want cutting through the seals or bearings on my axle now is it?

Who knows, I might get lucky enough not to have to re-thread the flange and insert a heli-coil. At least the old caliper is off and it looks like I may well manage to get this car drivable again – the sooner the better!

Thank God for the man that invented the hacksaw!

It’s not collagen

I use a URL rewriter library to set up my permalink URLs. I did this for a couple of reasons. The primary reason is that it allows me to provide you with a simple way to get to my archive. For example, the URL for this post should be http://perrinelson.com/2009/11/12/1392.aspx. The format is obvious – the path consists of the year, month, and day of the post, followed by the post ID. This together with the way the URL rewriter library lets you hack off the end of the post URL and get an archive of posts.

For example, the URL http://perrinelson.com/2009/11/12 would present you with a list of all of the posts that I made today. The URL http://perrinelson.com/2009/11 would present you with a list of all of the posts that I made this November – grouped by day, and the URL http://perrinelson.com/2009 would present you with a list of months, and the number of posts I made each month.

Another reason is that URLs of this form are (or were) more search engine friendly. A URL like http://perrinelson.com/viewpost.aspx?postid=1392 is only distinguished from another post URL by a querystring parameter. This tells the search engine that the content is dynamic rather than static – and at one time dynamic content wasn’t indexed by some search engines. At least, that’s the way I recall it – whether correctly or not.

There’s still another reason for doing this. Exposing a URL like http://perrinelson.com/viewpost.aspx?postid=1392 is an open invitation to hackers to attack my site using SQL injection. I’m not particularly worried about that problem though – I’ve taken other steps to prevent SQL injection attacks from working on my site.

Just a few minutes ago my site sent me e-mail. I set it up to do this whenever certain events take place – typically events due to a programming error on my part. There’s one programming error that I made a long time ago and have never bothered to fix. It involves the parsing of the post ID.

You see, I use a SQL database to store metadata about my posts. The actual posts are stored in an HTML document that is stored in the file system on the server. I have much more available file system space than SQL data storage, so it makes sense to do this this way. Anyway, the metadata rows have a field that identifies the post – the post ID, which is generated by the database engine. This ID is an integer value (like 1392 for this post) and so I treat it as a number and not a character string. To do this, I have to convert the character string to an integer data type, and I neglected to put an exception handler around the parsing of the number. If the postid querystring parameter contains anything but digits the parser throws an exception and I get e-mail telling me that I made a bone-headed programming error.

It’s an easy enough error to fix, but I have no plans to fix it. I’m entertained by the things that people put in the querystring when they’re trying to hack my site. In July of 2008 I posted an analysis of one hack attempt that was truly imaginative. That one used a combination of SQL injection to try to insert code into every text column in my database (it failed) that ran a foreign piece of javascript that inserted a tracking cookie onto the client’s machine and inserted an IFRAME element into the page. The document that would have been loaded into the IFRAME exploited a buffer overrun bug in Internet Explorer (since fixed) to install malware on the client’s machine.

Interestingly enough, several major websites, including a few British financial institution websites were compromised by that particular attack. In contrast, today’s attack is much less imaginative. Here’s what they tried putting in the postid querystring parameter.

postid=270'%20And%20char(124)%2b(Select%20Cast(Count(1)%20as%20
varchar(8000))%2Bchar(124)%20From%20[sysobjects]%20Where%20
1=1)>0%20and%20''='

Some of this is simply URL encoded character substitution. For example “%20” represents a space character and “%2b” is the “+” character. While we’re dealing with character subsitution, we can also get the “char(124)” out of the way too. That expression evaluates to the vertical bar character. Doing the substitution gives us…

postid=270' And '|'+(Select Cast(Count(1) as varchar(8000))+'|' From [sysobjects] Where 1=1)>0 and ''='

This isn’t even good SQL!  At least it’s not good TSQL. An expression like “|554|>0”  might be acceptable in some other variants of SQL such as MYSQL – it’s been a while since I actually coded for those variants, but an expression like “|554|” can’t be converted to an integer value in TSQL, so SQL Server would throw an error with this code. I can only conclude that these attempts were a probe to see whether SQL injection even had a chance at success on my site – and if they had been successful I’d be subject to still more attacks.

SQL injection is such a tired old hacking technique – I’m surprised that anyone still tries it – or that anyone is still victimized by it. Still, I guess there are some out there that want to compromise other people’s systems for any number of reasons, not the least of which is watching the world burn.

In these days when malware is proliferating through so many different channels it pays to err on the side of caution whenever you receive a suspicious piece of e-mail, or visit a web site you aren’t familiar with. In fact, you should err on the side of caution even with web sites you are familiar with. Who knows what some malicious hacker has managed to get away with?

Oh, and if you write code for web sites, please, please, please make sure that you learn how to mitigate the risks associated with SQL injection and other types of hacking attempts. It ought to be obvious by now that you’re putting your customers at risk if you don’t.