Thursday, October 09, 2008

HUM Playing Reunion Show New Year's Eve 2008!!1!!

My favorite band HUM, who broke up years ago, is playing a show new years eve at The Double Door.  What is even SUPER MORE AWESOMER is that they're playing with one of my favorite existing bands The Life and Times.  My wonderful wife actually found out about the show looking for a birthday present for me.  I can't believe that I didn't hear about this sooner.  I got my tickets and will commence preparations for rock!  Science!  Loud guitar!  Open bar!  Our tickets are ordered.

"I'll send you flowers made of silent tiny pieces of the sun." - HUM

Visual Basic 6 Support for Microsoft's LOC Counter

Microsoft has released a great free lines-of-code (LOC) counter.  It is available for download here:

The tool, however, doesn't come with VB6 support.  As much as I hate VB6, we still have a ton of it where I work.  Luckily, the tool is extensible and by editing the LineCounters.xml file and creating some regular expressions I was able to get it to work pretty well with VB6.  The LineCounters.xml file is installed in the same directory as the program.  Open it in your favorite text editor and plop in the following lineCounter section (after one of the /lineCounter closing tags of course):

<lineCounter name="VB6">





  <codeArea name="Blank lines" isCode="false">



  <codeArea name="' comments" isCode="false">



  <codeArea name="VB6 Class and Form Garbage" isCode="false" multiLine="true">


      <endExpression>^Option Explicit.*$</endExpression>


  <codeArea name="VB6 File Attributes" isCode="false">



  <codeArea name="VB6 Option Explicits" isCode="false">

      <expression>^Option Explicit.*$</expression>


  <pspMetricArea name="Class" toCount="true" caseSensitive="false" >






  <pspMetricArea name="Method" toCount="true" caseSensitive="false" >







Note that for this to work properly to remove the garbage at the top of a form file the forms must have "Option Explicit" in them.  This worked for me as that has always been a standard.  Hopefully it is useful for someone else.

Monday, September 15, 2008

Guitar Effects Pedal Board - Ninja Style

Almost everyone uses Velcro to secure guitar effects pedals to their pedal boards and, until recently, I was no exception. Unfortunately, the Velcro on my board just wasn't sticking well anymore so I began looking for other options. The board itself was still very nice. It was constructed for me by my former bassist (who is now a carpenter for good reason) and I wanted to reuse the board. I stumbled across the following solution on the Internet somewhere so I cannot take credit for it. I just thought I would provide a write up and some pictures for anyone else who is tired of being oppressed by the tyranny of Velcro.

All you need to mount your pedals securely is a plank of wood (the pedal board itself), a bicycle chain, a bicycle chain repair tool, and some small wood screws. A drill also helps and I also used some cat5 data cable staples to clean up the job a bit.

The idea is to use links from a bicycle chain to mount the pedals securely to your pedal board. If you have the chain you will need to use the repair tool to break the links apart:It was difficult to use this cheap tool (about $5 at Wal Mart) to break the links apart so I assisted myself with a pair of vice grips which resulted in me breaking the tool:After going back to buy two more of the same tool I ended up with a pile of links:Once you have the links you need to attach them to the bottom of your pedals using the existing screws on the bottom of the pedals whenever possible:Then, screw them down to the board using the wood screws:Some pedals didn't have screws on the bottom (or the screws weren't close enough to the edge). On my (modified) Pro Co Rat and my Big Muff I needed to drill some holes then use some random small sheet metal screws I had laying around to attach the links:Here is the mostly finished board:I use a homemade power supply to power all my pedals as it was much cheaper than the commercial alternatives, just as good and fun to build. To keep all the wiring neat I used some cat5 data cable staples (and one NM cable staple) after I had everything routed how I wanted it:Rock on...

Friday, June 13, 2008

Improved Administration of AzMan with DSACLS

I've recently been working with Microsoft Authorization Manager (AzMan) using ADAM for storage. I became frustrated when I noticed that, for administration, AzMan only supports two roles: Administrators and Readers. In our particular implementation, we have a development tier (for application development) a QA tier (for QA testing) and a production tier (for, wait for it, production applications). The idea is that the applications can be defined on each tier and different folks can have access to various application features on the different tiers. For example, developers would have access to all application functions when running in development mode but not when running in production mode.

My desire was to set the development AzMan store so that the developers could create and configure their applications in development and then have their software released to various tiers. Unfortunately, by making them administrators at the store level, they can delete any configured application and delete the store itself. By making them readers they cannot create or configure new applications. It seemed like it was all or nothing here.

Fortunately, I figured out the permission scheme in the underlying ADAM directory service and was able to modify it exactly how I wanted through the use of the DSACLS.EXE program.

The permission set I wanted for developers was read and write and create applications but not delete applications or the authorization store. On our ADAM server, let's say there was an application partition called CN=AzManPartition that was to house our authorization store. By using ADAM ADSI Edit you can see that there is a CN=Roles,CN=AzManPartition container defined where the Administrators and Readers groups are defined. I created a new group here called CN=Developers that I was going to use to put the developers in. If you haven't used ADAM ADSI Edit before it is done like this:

Right-click on CN=Roles,CN=AzManPartition and select New->Object
Choose Group and click Next
Enter the name (in this case Developers) for the cn attribute
For the groupType enter -2147483646 (which denotes a user group)

To edit the membership of this group:

Right-click on CN=Developers,CN=Roles,CN=AzManPartition and select Properties
Find the "member" property and click Edit
Select "Add Windows Account" to add users or groups from Active Directory

One further thing, members of this Developers group will also need read access when we create the store so add the Developers group as a member of the Readers group:

Right-click on CN=Readers,CN=Roles,CN=AzManPartition and select Properties
Find the "member" property and click Edit
Select "Add ADAM Account"
Enter CN=Developers,CN=Roles,CN=AzManPartition and click OK

Now we can create our AzMan store. Run the AzMan snap-in and ensure you're in developer mode:

Right-click on "Authorization Manager" and click Options
Select Developer mode and click OK.

To create the new store:

Right-click on "Authorization Manager" and click "New Authorization Store"
Select "Active Directory"
For the store name enter: msldap://servername:port/CN=AzMan,CN=AzManPartition

Finally, to grant the required rights to developers open the ADAM Tools Command Prompt. I needed to grant Developers the generic read, generic write and create children permissions (not full control as making them administrators would have done). I did this with DSACLS.EXE as follows:

C:\WINDOWS\ADAM>dsacls.exe \\servername:port\CN=AzMan,CN=AzManPartition /I:T /G CN=Developers,CN=Roles,CN=AzManPartition:GR
C:\WINDOWS\ADAM>dsacls.exe \\servername:port\CN=AzMan,CN=AzManPartition /I:T /G CN=Developers,CN=Roles,CN=AzManPartition:GW
C:\WINDOWS\ADAM>dsacls.exe \\servername:port\CN=AzMan,CN=AzManPartition /I:T /G CN=Developers,CN=Roles,CN=AzManPartition:CC

Now developers can create and configure applications in AzMan but if they try to delete anything (or modify permissions) they are denied access.

More information on the different permission sets you can grant with DSACLS.EXE is available here:

Friday, May 02, 2008

Using AzMan with CSLA Business Objects

Using AzMan to provide authorization to your CSLA business objects is a relatively easy task. In the following examples I'm using AzMan through the Enterprise Library AzMan Authorization Provider. If you're using the COM API directly you should be able to modify the AzManPrincipal class below to wrap that instead of the EL provider.

First, I've created a class called AzManPrincipal which extends the Csla.Security.BusinessPrincipalBase class. This is the class that is an IPrincipal and as such has the implementaion of IsInRole. It is worth noting that my implementation below will authorize access on the "task" defined in AzMan.

internal sealed class AzManPrincipal : Csla.Security.BusinessPrincipalBase
private IAuthorizationProvider _authProv = null;
public AzManPrincipal(IIdentity identity)
: base(identity)
string providerName = ConfigurationManager.AppSettings["AzMan Provider"];
_authProv = AuthorizationFactory.GetAuthorizationProvider(providerName);
public override bool IsInRole(string role)
return (_authProv.Authorize(this, role));

Next, at the start of your application you will need to set your custom principal on the Csla.Application.User

Csla.ApplicationContext.User = new AzManPrincipal(WindowsIdentity.GetCurrent());

Finally, your classes may use the current application context to authorize any actions on the class (CRUD methods or read/write properties) as in the following example:

public static bool CanGetObject()
return (Csla.ApplicationContext.User.IsInRole("Read Customer Task"));

Monday, January 21, 2008

Something Idiotic That Almost Everyone Does

I've recently noticed that a lot of people, when waiting for water from a faucet to become warm, will turn the water on so that when it is up to temperature it will be the temperature that they want. When you do this, some of the water comes from the cold water line. This water is completely wasted. Also, since you're not pulling the maximum amount from the hot water line it is going to take longer to empty that line of room temperature water.

I'm not much of an environmentalist so I'm the last person that would be telling people to conserve water. I am, however, interested in making my life more efficient. So, when you want warm water turn it fully to the hot side until it warms up then adjust it. Water conservation is just a nice side-effect.

Monday, August 20, 2007

DirecTV HD-DVR (HR-20 700) Pixelation and Audio Dropout Diagnosis

If you're noticing audio drops and pixelation when watching live or recorded HD programs on your HR-20 this is how to diagnose the problem. I was having the problem on the MPEG-2 encoded HD channels (70-79) and it was annoyingly intermittent. At best it would happen every half-hour or so and at worst it would happen every few seconds.

The first thing to check is the signal strength (of course) but you have probably already done that. That wasn't my problem but if you haven't verified that the signal is ok do this:

Menu->Help & Settings->Setup->Sat & Ant->View Signal Strength->Signal Meters

You're looking for green on both Tuners. 75 or better. If you're not there then stop here. You'll probably need to adjust your satellite.

If your signal is ok, we'll next want to determine if the B-Band converters are causing the problem. These are the small boxes inline with the coax coming in from the satellite. Remove them and see if the problem goes away. If it does, your B-Band converters are bad. Call DirecTV and ask for new ones. They are free.

If removing the B-Band converters didn't solve the problem we need to determine if the problem is on one or both signal lines. Every time you change the channel the HR-20 switches tuners (unless something is being recorded on one tuner). Stop any recordings and turn to channel 75 (TNT-HD). Note whether you see pixelation or not. Press: channel up, channel up, and then dial in 75 again. This should put you back on channel 75 but on the other tuner. The first channel up puts us on 76 opposite tuner, the second channel up put us on 77 same tuner and the dial in of 75 puts on back on 75 with the opposite tuner.

If you noticed the problem on on tuner but not the other then we have to determine if it is the coax or the tuner itself. Disconnect tuner 2 on the back of the box. Tune to 75 and note whether you see pixelation or not. Disconnect the line into tuner 1 and put the line that was in tuner two into tuner 1. Tune to 75 again and note whether you see the problem. Repeat the process with tuner 2 trying each line in tuner 2.

If the problem occurs with both lines on one tuner, but not the other, then your tuner is shot. Hopefully your HR-20 is still under warranty. If the problem occurs on both tuners with one coax line but not the other, then the wiring is bad. Run a new cable.

Hopefully this will save a few people an expensive service trip.

Thursday, February 01, 2007

10 Guidelines for Becoming a More Secure Coder

The number of software developers that know nothing about security is staggering. In the coming years software security is going to become more and more important. I wrote these guidelines as a starting point for any developer that wants to learn how to write secure code. There are many types of software as there are many different programming languages. I tried to keep these guidelines as technology and language agnostic as possible.

1. Use a Safe Language / Development Framework

By using a type-safe language (like Java or any of the .NET languages) you can avoid a number of the classic security bugs (most notably buffer overflows). Non type-safe languages, like C and C++, allow the developer to decide how memory should be managed, accessed and interpreted. This is a complex task and is quite error-prone. If you insist on using a non type-safe language and want to do it securely, you will have a lot more research to do. Additionally, make use of sandboxed environments whenever possible to make sure that a security bug doesn’t have full access to the system that it is running on. For you .NET developers, this means not running with full-trust whenever possible. More on type-safety:

2. Trust Nothing and Make No Assumptions

Data should not be trusted if it comes from an untrusted source (like a user). This goes for all input from web applications (all GET/POST parameters, HTTP headers, cookies, etc…), input from thick-clients, and files that get processed by your system (XML) to name a few sources. This type of data must be normalized and sanitized before using it in your system. Normalization (and we’re not talking about relational databases here) is the process of getting input into an expected form. Many software systems allow different character sets (Unicode, ASCII, UTF-8, etc…) and different encodings (hex encoding, URL encoding, HTML encoding, etc…). The data needs to be in normal form for the sanitation to be effective. Sanitation means cleaning the data of any potential unsafe characters. If you’re going to issue the data into an HTTP response stream you will need to HTML encode the data (Server.HtmlEncode in ASP, System.Web.HttpUtility.HtmlEncode in .NET) which will properly escape things like < and > with &lt; and &gt;

Make no assumptions about how your software will be used as it is an attacker’s job to find these assumptions and exploit them. Continuously ask yourself if you’ve made any assumptions about the code you’re writing. Don’t assume that because you haven’t provided a link on your website to moneyTransfer.aspx that an attacker won’t request it.

3. Embrace Least-Privilege

The concept of least-privilege means that any accounts should have the least amount of access necessary for the software to properly function. For example, if your software uses a database account to access data, that account should only have access to the data required by the application. The database account should not have access to entire databases or servers and if it only needs to read data it should only be able to read the data. This is important because if your software system does have a security vulnerability (perhaps one that allows access to data) you will have limited the surface area of any potential attack. The best an attacker could do is access or tamper with the data of that application, not all of the data on the server.

4. Don’t Store Passwords in a Recoverable Format

Passwords for things like web applications should not be stored anywhere (including a database) in readable text. There is no reason to store a readable password. The password should be hashed and the hash should be stored. A hash is a cryptographic function which is not reversible. At login time you would simply apply the hash function to the entered password and compare it to the hash in the database. If the password was correct the hashes should match. Historically, hashes like MD5 and SHA-1 have been used for this purpose. These hashes have been shown to have some security problems and while those problems don’t apply to this password hashing mechanism it is easier to use a newer, more-secure hashing algorithm than to explain to others why the vulnerabilities don’t apply. Select something like SHA-256, SHA-384 or SHA-512. More info on hash functions can be found here:

5. Create and Enforce a Password Policy

It doesn’t make much sense to build a secure application if it is going to have hundreds or thousands of users with a password of “password.” Enforcing simple strength requirements on passwords can go a long way to protecting your application. You will have to determine what level of strength your application's passwords require. Some systems may only need to restrict dictionary words while other may wish to force users to select passwords with upper-case letters, lower-case letters, numbers and symbols. Alternatives to implementing strength requirements on passwords include locking out accounts after a small number of consecutive failed login attempts and expiring passwords after a certain length of time (say, 180 days).

6. Parameterize Your Data Access

SQL injection plagues many different types of software. With SQL injection an attacker provides input to your application that manipulates your intended SQL query. When a SQL injection is present an attacker can usually get information on your database schema and retrieve or edit data in the database. The easiest and most effective way to defend against SQL injection is to use a parameterized query (combined with stored procedures if they’re supported by your database engine). Never build SQL statements by concatenating strings together with user input. Check the documentation for the database access technology you’re using. Here is a link for ASP.NET developers with some examples:

7. Hide Your Errors

Error messages will not be understood by the common user but to an attacker they are a goldmine. Error messages can be used to gain information about the system and in some cases can be used to enumerate the contents of entire databases. Never display error information to the user.

8. Don’t Write Your Own Crypto

There are plenty of good choices available for cryptography. There is no need to spend time trying to write your own algorithm. The accepted algorithms have been tested and analyzed for years and it is likely that the folks that invented and tested the algorithms are smarter than you. Good choices include triple-DES or AES for symmetric encryption (with a password) and PGP or SSL/TLS for asymmetric encryption (public/private key).

9. Have Someone Else Test Your Code as an Attacker

Consider this: You have written some code and made it as secure as you know how to. You cannot possibly test for the problems you didn’t foresee. Having someone else do the security testing is much more beneficial than doing it yourself. Also, the tester should be testing the software like an attacker might. For example, they should try to access or tamper with data that they shouldn’t have access to.

10. Get Secure Coding Training

If you’re serious about becoming a secure software developer consider getting some formal training. The guidelines I’ve outlined here are a great starting point and by following them you will have an edge on most developers. As you progress in your career and the systems that you work on increase in size and importance it will become necessary to relate your security decisions to the business. More training can give you the details you need to effectively perform a business risk analysis and create an effective threat model.

Where to go for more information:

OWASP - A ton of information for web developers:

Great books:

Writing Secure Code, Second Edition
Hacking the Code