Mounting Encrypted Volume on Mint 19

As I tried to upgrade Linux Mint from 18.3 to 19, all went kaboom and I was forced to decide if I want to reinstall OS from scratch or go and try to fix it. Since I was dealing with virtual machine, reinstalling it from scratch seemed like a better idea.

Once all was installed, I wanted to copy some files from the old volume. As full disk encryption was present, I knew a bit more complicated mount is needed. In theory, it should all work with the following commands:

sudo cryptsetup luksOpen /dev/sdb5 encrypted_mapper
sudo mkdir -p /mnt/encrypted_volume
sudo mount /dev/mapper/encrypted_mapper /mnt/encrypted_volume
sudo cryptsetup luksClose encrypted_mapper

In practice I got the following error:

sudo mount /dev/mapper/encrypted_mapper /mnt/encrypted_volume
 mount: /mnt/encrypted_volume: unknown filesystem type 'LVM2_member'.

Issue was with volume manager’s dislike for both my current installation and previous one having the exactly same volume group name - mint-vg - and thus refusing to even consider doing anything with my old disk.

Before doing anything else, a rename of volume group was required. As names are equal, we will need to know UUID of the secondary volume. The easiest way to distinguish old and new volume is by looking at Open LV value. If it’s 0, we have our target.

sudo cryptsetup luksOpen /dev/sdb5 encrypted_mapper

sudo vgdisplay
  --- Volume group ---
  VG Name               mint-vg
  Cur LV                2
  Open LV               ^^0^^
  VG UUID               ^^Xu0pMS-HF20-Swb5-Yef3-XsjQ-9pzf-3nW4nn^^

sudo vgrename Xu0pMS-HF20-Swb5-Yef3-XsjQ-9pzf-3nW4nn mint-old-vg
  Processing VG mint-vg because of matching UUID Xu0pMS-HF20-Swb5-Yef3-XsjQ-9pzf-3nW4nn
  Volume group "Xu0pMS-HF20-Swb5-Yef3-XsjQ-9pzf-3nW4nn" successfully renamed to "mint-old-vg"

sudo vgchange -ay
  2 logical volume(s) in volume group "mint-vg" now active
  2 logical volume(s) in volume group "mint-old-vg" now active

With the volume finally activated, we can proceed mounting the old disk:

sudo mkdir -p /mnt/encrypted_volume
sudo mount /dev/mint-old-vg/root /mnt/encrypted_volume
sudo umount /mnt/encrypted_volume
sudo cryptsetup luksClose encrypted_mapper

PICkit 4

If you are already using PICkit 3, the first thing you’ll notice about PICkit 4 is increase in thickness and width alongside additional 2 pins on it ICSP connector. Finally PICkit can program (and debug) both PIC and Atmel microprocessor family. So let me compare it against it’s predecessor…

As far as I can deduce, there are two reasons for increase in thickness. First one is button/LED mechanism that actually takes quite a lot of space in front of the board. Old system of having button just stick through the plastic allowed shell to get closer to PCB while LED pipe and internal button simply need more space. That said, although I was skeptical about the button and accidental presses, it seems to work fine for now - whether it’ll age well remains to be seen.

The other reason for the thickness is addition of the SD card slot intended for use with programmer-on-the-go functionality. I say “intended” as functionality is still not available, continuing Microchip’s tradition of removing functionality with the new PICkit only to return it slightly worsened later. As an optimist I will assume this will allow for storing of multiple firmware images (for both PICkit and device). User interface will be hell with only a single button and RGB LED but it would make some sense.

However, assuming functionality ends up working as on PICkit 3 with the only one firmware image, I’ll consider it to be over-engineered nonsense. A few hundred kilobytes required for a single firmware image could have been stored on internal memory chip probably even cheaper than what SD card slot costs.

Looking inside, I was surprised to see Atmel ATSAME70Q21 as the main chip (PICkit 3 was using PIC24FJ256). I find the change neither good or bad on it’s own but such completely different platform might justify abandoning updates to PICkit 3 sooner than expected.

Despite the wider ICSP connector, I saw no obvious reason for device to get wider either. PCB is not really densely populated and I could bet engineers could have fit all in PICkit 3 case with a bit of effort. That said, I must admit that I like the look of new PICkit better. And yes, new shape is a bit less comfortable on hand, but I could live with it. New looks with the old case size, now that would be something. :)

The first 6 pins of the new connector are fully compatible with the old PIC ICSP and that means you can still directly connect it to any of your old board (assuming PICkit can still fit). If you are using pogo pins you can opt to get a wider (8-pin) pogo connector or just continue using the existing 6-pin one if you don’t need Atmel.

Microchip opted to use micro-B USB connector and I hate them for it. While I would understand PICkit 3 coming with the same, in 2018 Microchip should have used USB type C. It’s about the same size as micro-B but it allows for orientation agnostic plugins. With PICkit 3 it was less of a trouble as mini-B is bit and visible connector but with the new PICkit there is always a need for the three-way handshake.

I love the reset button next to USB connector but not for it’s reset functionality. Who’s gonna search for a paperclip to reset the device when unplugging/plugging into USB will do the same? I love it because you can see the main LED through its hole. If you are programming board with your PICkit in vertical position, you will get used to looking at LED from above instead of craning your neck on the side. This is probably the best addition there is.

Experience from MPLAB is pretty much the same as it ever was. You still need to download image into programmer for every damn PIC you use. When you switch between projects there is always a wait and need for Internet connection as it was with PICkit 3. Programming experience itself is similar to PICkit 3 and slightly faster.

All in all, if PICkit 4 was a straight upgrade from PICkit 3, I would hate its bulkiness much more as it does feel more unwieldy than PICkit 3. However, considering PICkit 4 is a single programmer allowing for both Atmel and PIC microcontrollers to be programmed I do think of it as a step forward.

Attacking WPA2 PSK And Mikrotik Fix

With everybody awaiting WPA3, it’s easy to miss improved WPA2 attacks. Up until recently cracking the WPA2 with pre-shared key required online attack. Well, not anymore.

This new attack doesn’t even require waiting for 4-way handshake - essentially all you need is a few minutes of passive traffic, minimal amount of luck, and a bit of alone time to crack the key - offline. If you are willing to go active capture time goes down to a second and no luck is involved. The only real challenge is offline cracking - and there is no time pressure here.

Without going into too many details, issue is in optional PMKID field that does come in handy for roaming support. Unfortunately, for most routers, PMKID gets sent even if roaming option is off.

There are two “fixes” for this. The obvious one is to increase complexity of your pre-shared key while avoiding ones present in the precalculated SHA-1 tables. We are still talking about brute forcing SHA-1 hash - a non-trivial task if you have long and random password.

Second approach is to disable PMKID field and that would require you to upgrade router’s firmware. Fortunately for me, Mikrotik already has a fix available and thus avoiding it as easy as selecting to Disable PMKID.

Mind you, that’s not absolute protection as weak passwords are still vulnerable no matter how you cut it. But this does prevent offline attack.

Seattle Code Camp - Cryptography Failures

As you read this another Seattle Code Camp talk is behind me and its time to share the slides.

Due to way how I structure my presentations, just slides alone will probably not work for you. However, if you still want to proceed or you were at presentation and you want slides for links and resources contained within, feel free to download them here.

Image.FromStream Doesn't Always Preserve Exif Data

Reading Exif files within C# is easy. For example, if you want to know camera model, it is enough to simply loop through image’s properties and read it:

private static string GetCameraModel(Image image) {
    foreach (var property in image.PropertyItems) {
        if (property.Id == ExifTag.CameraModel) { //0x0110
            return ASCIIEncoding.ASCII.GetString(property.Value).Trim('\0');
        }
    }
    return null; //no model found
}

However, if you want to do anything with the file you cannot simply load it with Image.FromFile as .NET keeps image open all the way until disposal. Easy enough, just load image with Image.FromStream, like this:

Image image;
using (var stream = new FileStream(this.File.FullName, FileMode.Open, FileAccess.Read)) {
    image = Image.FromStream(stream);
}
return GetCameraModel(image);

Image loaded in this manner will not contain any Exif - just the image data. The default stream loader just tossed everything that’s not picture away. If you want to preserve picture, you need to explicitly tell it:

Image image;
using (var stream = new FileStream(this.File.FullName, FileMode.Open, FileAccess.Read)) {
    image = Image.FromStream(stream, useEmbeddedColorManagement: true, validateImageData: true);
}
return GetCameraModel(image);

Now you can read all the Exif data you can handle. :)

PS: Interestingly, it seems that on Windows 7 it works either way.