Determining IPv4 Broadcast Address in C#

When dealing with IPv4 network, one thing that everybody needs sooner or later is a broadcast address based on IP address and its netmask.

Let’s take well known address/netmask combo as an example - 192.168.1.1/255.255.255.0. In binary this would be:

Address .: **^^11000000 10101000 00000001^^ 00000001**
Mask ....: **11111111 11111111 11111111 00000000**
Broadcast: **^^11000000 10101000 00000001^^ !!11111111!!**

To get its broadcast address, we simply copy all address bits where netmask is set. All remaining bits are set and our broadcast address 192.168.1.255 is found.

A bit more complicated example would be address 10.33.44.22 with a netmask 255.255.255.252:

Address .: **^^00001010 00100001 00101100 000101^^10**
Mask ....: **11111111 11111111 11111111 11111100**
Broadcast: **^^00001010 00100001 00101100 000101^^!!11!!**

But principle is the same, for broadcast address we copy all address bits where mask is 1. Whatever remains gets a value of 1. In this case this results in 10.33.44.23.

As you can see above, everything we need is simply taking an original address and performing OR operation between it and a negative netmask: broadcast = address | ~mask. In C# these steps are easiest to achieve if we convert everything to integers first:

var addressInt = BitConverter.ToInt32(address.GetAddressBytes(), 0);
var maskInt = BitConverter.ToInt32(mask.GetAddressBytes(), 0);
var broadcastInt = addressInt | ~maskInt;
var broadcast = new IPAddress(BitConverter.GetBytes(broadcastInt));

Full example is available for download.

Windows Store App Doesn't Start on Virtual Drive

As I went to update my Resistance Windows Store application, I stumbled upon unexpected error while trying to run it. Message was quite generic “This application could not be started. Do you want to view information about this issue?” and application would stay stuck on the startup screen.

Details were not much better. It was essentially the same error message: “Unable to activate Windows Store app ‘47887JosipMedved.Resistance_805v042353108!App’. The Resistance.exe process started, but the activation request failed with error ‘The app didn’t start’.” As error messages go, pretty much useless.

I was thinking that I broke something with changes so I reverted to my last known good configuration - one that is actually currently deployed in the Store. Still the same error.

It took me a while to notice that, once project is copied to the other drive, everything would work properly. A bit of back and forth and I believe I found the issue.

I keep all my projects stored on a virtual disk. While everything else treats that disk as a real physical thing, Visual Studio sees the difference but only when dealing with Windows Store applications. It just wouldn’t work.

As you can guess it, solution was to copy project on a physical drive and work from there. Easy as solutions go but definitely leaves the bitter taste. Lot of wasted time simply because of a lousily written error message. A bit more clarity next time?

Beware of Magic in AES CBC

In case of encrypted text I commonly see “magic” footer being used as a sole verification method for AES CBC; i.e. assumption is that, if last bytes were decrypted correctly, all previously decrypted bytes are valid too. However, that assumption can fail horribly.

Once case when it fails is when configurable IV is used. You can have nonsense for a IV vector and decryption will succeed. Even worse, while first few bytes will be invalid, 8-byte blocks following it will look just fine. If you validate content only by last few bytes, your program might happily continue to work without any issue.

But lets assume you have static IV and that this issue doesn’t affect you. And you are worried only about stream errors anyhow. Well, I hate to inform you but CBC mode is self-synchronizing, i.e. any recoverable errors in one block will go away after certain number of blocks. For example, if you have an error in first byte of a stream, next fifteen bytes will be corrupted but rest of stream (including your footer) will look just fine.

Corruption in the middle of stream will cause exception most of the time, but not always. If it passes unnoticed you can have valid header, valid footer and garbage in between.

As you can see from the two examples above, you cannot rely purely on fact that some stream bytes were decrypted as a proof that some other part of stream is not corrupted. Only way to be sure about stream validity is to use hash/CRC functions that were actually designed to detect corruption.

Example of both these behaviors is available for download. Below is example output with both valid and invalid decryption having a same footer (FF-FF-FF-FF):

Decrypted (OK) ..........: 00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10-11-12-13-FF-FF-FF-FF
Decrypted (invalid IV) ..: FF-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10-11-12-13-FF-FF-FF-FF
Decrypted (invalid input): 31-33-7C-D9-A9-91-47-DD-52-3A-64-08-FD-2F-D4-C8-1D-11-12-13-FF-FF-FF-FF

Visual Studio Community 2013

A bit over a week ago a new Visual Studio edition has appeared pretty much out of blue. For all practical purposes you can look at it as a cross between Visual Studio Professional (has same features) and Express editions (it’s free).

Unlike Express editions, Community can only be used by an individual developer, for open source, for learning/teaching, and in a small non-enterprise settings. If you are working for enterprise company, you’re out of luck.

Since Community is essentially the same as a Professional edition, there is not much new things that can be said about it. It can slice, it can dice, and it is an almost perfect development environment. Yes, there are Premium and Ultimate and they do offer some advantages (e.g. IntelliTrace is a gem) but most of the time one can live without those features just fine. Unlike with the Express editions you won’t feel constrained with the Community.

Surprisingly you cannot really install Community edition side-by-side with any other paid Visual Studio. Official explanation is that this is because Community is the part of a same line as other editions but I still find it an unfortunate decision. Developers wearing two hats in BYOD scenarios (e.g. enterprise by day, open source by night) might get into some conflicting situations. Side-by-side with the Express editions will still be supported so not all is black.

Speaking of Express editions, it is not really clear to me what is their destiny. Currently they do stand together with Community but they do overlap quite a bit. If we learned anything from the past, their days are numbered. I would like to be wrong since I do love them. Even with all their shortcomings, I can still see them useful in multiple scenarios (mostly due to their quite permissive licence). I will miss them.

If you currently don’t have anything better than Express on your machine and you fit into the restrictions, it is definitely worth checking out.

What Every Developer Has To Know About IPv6

Today I gave a talk at the Seattle Code Camp. Wonderful atmosphere, excellent organization, and a plenty of fun. Only bad thing was that it ended too soon (single day only).

My session was mostly geared toward the beginners and it covered just the basics of IPv6 and how we can use it from C#. I can only hope I lit some IPv6 fire in the great crowd that came.

I went to many other sessions myself and, while they did vary in quality, there was not a single bad one. My day was definitely fulfilled.

Feel free to download slides and examples.

Creating the Self-signed Key for the TLS

In my last post I described how to do the client-authenticated TLS and one of magic ingredients there was a certificate with the private key in the form of .pfx files.

Server and client certificates are essentially the same but I’ll show creating of both anyhow. For this I will assume that your Windows SDK files are in the C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\ and that we are storing files in the root of the drive D:

cd "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\"

makecert -n "CN=MyServer" -r -sv D:\server.pvk D:\server.cer
 Succeeded

makecert -n "CN=MyClient" -pe -r -sv D:\client.pvk D:\client.cer
 Succeeded

pvk2pfx -pvk D:\server.pvk -spc D:\server.cer -pfx D:\server.pfx

pvk2pfx -pvk D:\client.pvk -spc D:\client.cer -pfx D:\client.pfx

DEL D:\client.cer D:\client.pvk D:\server.cer D:\server.pvk

This results in the server.pfx and client.pfx files. We can opt to import them into the Windows Certificate Store (also possible with makecert command) or to use them directly as in this example.

Client-authenticated TLS in C#

Thanks to NSA, most probably every developer is aware of the HTTPS and the underlying TLS (or older SSL). While most scenarios involve authentication of a server, authentication of a client is often overlooked.

If you wonder what you gain, just be reminded of key-based authentication in the SSH. No need to exchange username/password with every client. You just exchange a (safely stored) key and you know who is on the other side.

Distribution and a safe storage of the client certificate is a non-trivial problem but easily handable on a smaller scale. Windows certificate store is not too bad and the client authentication makes it easy to block keys that aren’t trusted any more.

Here is the example code of a simple TLS encrypted TCP client/server with a self-signed certificates. Of course, one would expect proper certificates to be used in any production environment, but these will do in a pinch.

First we need to setup a server using just a standard TCP listener with a twist:

var serverCertificate = new X509Certificate2(ServerCertificateFile);

var listener = new TcpListener(IPAddress.Any, ServerPort);
listener.Start();

while (true) {
    using (var client = listener.AcceptTcpClient())
    using (var sslStream = new SslStream(client.GetStream(), false, App_CertificateValidation)) {
        sslStream.AuthenticateAsServer(serverCertificate, true, SslProtocols.Tls12, false);

        ``//send/receive from the sslStream``
    }
}

Client is equally simple:

var clientCertificate = new X509Certificate2(ClientCertificateFile);
var clientCertificateCollection = new X509CertificateCollection(new X509Certificate[] { clientCertificate });

using (var client = new TcpClient(ServerHostName, ServerPort))
using (var sslStream = new SslStream(client.GetStream(), false, App_CertificateValidation)) {
    sslStream.AuthenticateAsClient(ServerCertificateName, clientCertificateCollection, SslProtocols.Tls12, false);

    ``//send/receive from the sslStream``
}

Only trick in validation is to allow certificate chain errors. That is needed for self-signed certificates to work:

bool App_CertificateValidation(Object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) {
    if (sslPolicyErrors == SslPolicyErrors.None) { return true; }
    if (sslPolicyErrors == SslPolicyErrors.RemoteCertificateChainErrors) { return true; } //we don't have a proper certificate tree
    return false;
}

It is really this simple to convert any TCP socket code into the encrypted TLS.

Full example is available for download.

Scaling Toolstrip Images With DPI

Cheapest way to make high-DPI application is just to specify it as such in manifest and let font auto-sizing do the magic. Final result is more than acceptable and it definitely beats blurred fonts you would have without it.

However, this method doesn’t scale toolstrip icons (usually 16x16 pixels). They remain at same pixel size as before. If your monitor is 192 DPI, icons will look half their size. As monitors get higher and higher DPI situation just gets worse. Only proper solution would be to check system DPI and load higher resolution icons.

However, cheating a bit is ok too. Instead of having multiple sets of icons with different resolution each, we can resize ones that we already have. Yes, result will be a bit ugly, but not worse than Windows built-in scaling would do. All that can be achieved by having simple code in form constructor:

internal partial class MyForm : Form {
    public FilesEditForm(TabFiles tabFiles) {
        InitializeComponent();
        this.Font = SystemFonts.MessageBoxFont;

        using (var g = this.CreateGraphics()) {
            var scale = Math.Max(g.DpiX, g.DpiY) / 96.0;
            var newScale = ((int)Math.Floor(scale * 100) / 50 * 50) / 100.0;
            if (newScale > 1) {
                var newWidth = (int)(mnu.ImageScalingSize.Width * newScale);
                var newHeight = (int)(mnu.ImageScalingSize.Height * newScale);
                mnu.ImageScalingSize = new Size(newWidth, newHeight);
                mnu.AutoSize = false; //because sometime it is needed
            }
        }
    }
}

First variable simply contains scaling factor current monitor has compared to standard 96 DPI one. For example, 120 DPI monitor would cause variable’s value to be 1.25.

Next we try to determine how much we should magnify icons. In order to avoid unnecessary small adjustments, new scale is then calculated and rounded to .5 increments. If scale factor is 1.25, it will round-down to 1; scale of 1.6 will round-down to 1.5; scale of 2.2 will round-down to 2 and so on.

Check is made whether there is scaling to be done and, if needed, we simply calculate new image width and height using current size as a template. Assuming that icons were 16x16, scale factor of 1.5 would cause them to be 24x24.

Latest order of business is to turn off auto size. On most forms this step might be skipped without any issue. However, some stubborn forms will have their menu stay the same size as long as AutoSize is turned on (at least on .NET Framework 2.0). If you are on latest framework and/or your forms don’t misbehave, you can skip it safely.

PS: To have .25 increments, just swap 50 for 25; to have only whole number increments, swap 50 for 100.

Why I Don't Loop Through Dispose

Quite often graphical classes have a lot of disposing to do, e.g.:

public void Dispose() {
    foreBrush.Dispose();
    backBrush.Dispose();
    someBrush.Dispose();
    …
}

One might be tempted to optimize that a bit:

public void Dispose() {
    foreach(IDisposable element in new IDisposable[] { foreBrush, backBrush, someBrush, … }) {
        element.Dispose();
    }
}

I personally find this code a bit easier to maintain and it serves same purpose. But I never really use it due to one serious drawback - it is not recognized by code analysis.

Code analysis that is part of Visual Studio Professional (and higher) does not recognize operation of this loop and thus it reports CA2213: Disposable fields should be disposed violation. While it is clear that violation is invalid, it still means that our loop goes completely unchecked.

If we add one more disposable field to class at some future time, first scenario would give us notice and we would be aware of forgotten dispose. After quick check we add dispose of that field and all is nice.

In second case we have taken responsibility of disposal ourselves and Visual Studio is not capable of checking the loop. There is nobody to check that all fields are disposed and if we forget to dispose it, it will be up to garbage collection to do it.

This will usually not be a major issue because resources will be released at some time. If we take some OS resource (e.g. file handle) it might be a bit annoying for rest of system but again nothing critical.

However, under rare circumstances, it might become important. Call me lazy, but I would rather have a bit uglier code that is automatically validated than have beautiful code that I need to check myself.

Variable Parsing Au Bash

Every command-line processor has a way to allow for embedded variables. Those familiar with DOS will recognize percent encoded variables, e.g. “echo I am %USERNAME%”. Those more familiar with Unixoids will be more relaxed around dollar variables, e.g.: “echo I am $USERNAME”. Either way gives possibility to combine fixed text with some external value. I personally prefer bash-style so I will continue with it.

If we try to parse “User $USERNAME is working on $OS using $NUMBER_OF_PROCESSORS processors.”, this is really easy for human to tackle. Even on first glance, we know that result should be “Joe is working on Windows NT using 1024 processors.”. Making computer recognize that is a bit more involved.

Well, generic solution is really simple. Just make an function that will extract all variables from string and ask us what values might those be:

string ParseVariables(string text) {
    var res = ParseVariablesStateMachine(text, **delegate(string variable)** {
        **return Environment.GetEnvironmentVariable(variable);**
    });
    return res;
}

As you can see from above code, we call into ParseVariablesStateMachine method giving it whole input text alongside with a callback delegate. Function will take care of parsing variables out and ask us what each value should be via delegate function. In our example we do simple environment variable lookup but this can be modified to return almost anything.

This delegate will return value back into calling method and that method will continue string processing until next variable comes along. At that time it will repeat call to our delegate; rinse and repeat. At the end it will return value composed of all these variables in one nice string.

One way to tackle this problem is by using a simple state machine (yes, name was kinda giving it away). We definitely have starting state, we have state where we found inner variable, and state where variable is being processed. Code may look something like this (heavily redacted):

string ParseVariablesStateMachine(string text, Func<string, string> variableCallback) {
    var state = ParsingState.Default;
    for (int i = 0; i < text.Length; i++) {
        switch (state) {
            case ParsingState.Default:
                if (text[i] == '$') { state = ParsingState.VariableStart; }
                break;

            case ParsingState.VariableStart:
                state = ParsingState.NormalVariable;
                break;

            case ParsingState.NormalVariable:
                if (!char.isLetterOrDigit(text[i])) {
                    variableCallback.Invoke(text.substring(variableStart, variableLength));
                    state = ParsingState.Default; //search for next variable
                }
                break;
        }
    }
    return parsedString;
}

Full example source is available for download.

Modifying ParseVariablesStateMachine mathod to parse DOS-style variables is exercise left to a reader. It is actually simpler than bash-style parsing because we know when variable ends based on closing percent sign.

PS: Full example also covers extended variable style (e.g. ${USERNAME}.).