NextBase 212 Dash Cam



Since the area just outside the hospital is becoming notorious for road rage and insurance scam attempts, I figured that investing in a dash cam was a good idea.

The Hardware
The NextBase 212 is a very basic camera and it’s not as compact or discrete as others on the market – it doesn’t have GPS, night vision or speed display – but it does the job. In the box there is the camera, the windscreen mount, data cable and power cable. The microSD card isn’t included.


The camera operation is straightforward. Switch it on, press the record button and you’re good to go. When installed, the device starts recording when the vehicle starts. Recordings are made in blocks of 2, 3 or 5 minutes, with the oldest block being overwritten when the storage is maxed out. According to the manual, the current recording is protected from deletion if the device detects a sudden deceleration or the red button is pressed, but it seems to do this randomly anyway.


Battery life sucks on the camera, so it will need to be installed by running the supplied cable from the windscreen mount to the cigarette lighter port. Fortunately this is easy in the Renault Clio, as the cable can be hidden under the entire length of the door seal and fuse box on the passenger side. The camera is easy to detach from the mount.


Picture Quality
Although the device produces decent quality videos, enough to show which vehicle caused an accident, number plates are only readable at very short distances. The night footage is fairly clear also, but is dependent on ambient lighting.


Transferring Files
When plugged in, the device could be used as a mass storage device or an attached camera, just like the average smartphone. The recordings can be copied over as .MOV files. The average file size for a 5 minute video is 250MB. Of course, the microSD card can be inserted into an SD adaptor.

VPN – Is this the Ultimate guide to a VPN 2016?

University of South Wales: Information Security for Privacy

As you know, I adore accomplished VPN providers, particularly as the UK keeps trying to promote the “Snoopers Charter”.  Today I discovered someone has been researching the VPN market, and provided an extended set of results, with a traffic light colour coding.

I’m not recommending any VPN here, just asking that you choose a VPN that will keep you safe.

VPN Providers – Simple Results

vpn simple comparision 1

Filtered by 1. Logging and 2. Security

Results in 14 VPN providers being identified

vpn filtered by logging & security

You really do not want a VPN provider that logs your connection.  The server needs to be configured not to keep logs or the active wiping of any logs every few minutes needs to be in effect.Keeping the logs in RAM, rather than to disk is also important.

For instance if server logs were only wiped once a week, then a court order could obtain all your connection records.  If a server is seized…

View original post 304 more words

Persistent Data (BleachBit and bcrypt)


, , , , , , , , , ,

After I got curious about bcrypt, I wanted to determine whether the plaintext would still be recoverable using forensics software. If I wanted to recover the contents of an encrypted file, this is how I’d go about it.

So, here I used a 1GB USB drive that is a couple of years old, just because it’s quicker to image and recover files from. The files I copied onto the USB drive were three JPG images, each marked in a way that I could later tell which were erased by bcrypt and BleachBit. The files had an average size of around 720KB.


Wiping the Files
First file was straight-up deleted, and I emptied the ‘recycle bin’ just to be sure. This file I expect would be recovered later. The second one I ‘shredded’ using BleachBit. The third one I encrypted and erased using bcrypt.

I made sure the file erasure operations for BleachBit and bcrypt were completed before proceeding.

All that’s visible in a file manager is an encrypted .jpg.bfe file, and the data recovery software should only discover another file called ‘std-delete.jpg‘.
Of course, in the real world where the device is used afterwards, we’d expect all three files to be completely overwritten as the device is filled with new data. If anything’s recovered, it’s largely because the blocks weren’t properly overwritten.

Imaging the Volume
Before imaging the volume, we need to determine its mountpoint and filesystem blocksize, so first I used the ‘df‘ command. This revealed the mountpoint as /dev/sdc1.

Now I need the blocksize, just to ensure the image is a bit-for-bit clone that includes the slack space:
#blockdev --getbsz /dev/sdc1

The command returned the value ‘512’, which is used for imaging the volume using dd:
#dd if=/dev/sdc1 bs=512 of=/home/michael/bcrypt-bleachbit-test.img

Autopsy found the image name and metadata for the deleted file, but couldn’t display the image itself. As you can see in the screenshot below, Autopsy also managed to read most the unencrypted data that should have been erased by bcrypt.
If this was a document, the full plaintext content would easily be accessible.


What Autopsy didn’t discover was the file ‘shredded’ by BleachBit.

[Update: The Windows version of Autopsy recovered the BleachBit file, and most the bcrypt file’s content.]

File Carving
Everything that was deleted from the device in the past, and the file erased by BleachBit were recovered using foremost. The bcrypt plaintext file wasn’t recovered.


Again, EnCase recovered most the unencrypted content that was erased by bcrypt. I half-expected this result, as EnCase recovers files by their metadata, which BleachBit modifies before overwriting the file’s space. Although I couldn’t view the file as an image, most the data could be read, and again this would have been enough to determine the content of a document file.


An important thing to note is I’ve only demonstrated that it’s possible to recover the data with software tools under certain conditions – it was a USB storage device that wasn’t used after the files were erased. What I have demonstrated, though, is that it’s dangerous to assume that BleachBit or bcrypt will make a file unrecoverable. Both tools are good for hiding data, if your adversary isn’t likely to spend 24 hours imaging the drive, piecing together wiped data and sifting through thousands of files.
If there is a real motivation to recover the data, you’re better off encrypting the entire device/volume, and physically destroying it when no longer required.

The Algorithm Behind bcrypt


, , , ,

Not to be confused with BeCrypt or the password hashing algorithm of a similar name. This is a different utility that I noticed in the Linux package repo that uses the Blowfish cipher for its file encryption and wipes the unencrypted data with three random bit passes. It got me wondering whether this method is more secure than doing the same with GPG’s implementation of AES and cleaning up the unencrypted files with BleachBit.

Blowfish is a symmetric encryption algorithm published by Schneier back in 1993 as a substitute for DES, before the Rijndael algorithm became the Advanced Encryption Standard choice, and before Schneier followed up with the Twofish algorithm.

Although a 446-bit key size might appear impressive, an algorithm’s security depends also on other factors. The main (and the only?) disadvantage of Blowfish is its 64-bit block size, making it potentially weaker against cryptanalysis when dealing with relatively large amounts of data – the danger lies in the probability of two ciphertext blocks being identical, which increases, of course, with the number of blocks – obviously there’d be more blocks in encrypted data of a given size if the block size is smaller. Such an attack was demonstrated quite recently (they call it ‘Sweet32’), but you’d expect this attack to be less practical than straight up bruteforcing anyway.

It turns out that key changes in Blowfish are computationally expensive, making the algorithm intrinsically resistant to bruteforce attacks. To quote Schneier’s 1993 paper, ‘[…] time-consuming subkey-generation process adds considerable complexity for a bruteforce attack. The subkeys are too long to be stored on a massive tape, so they would have to be generated by a brute-force cracking machine as required.‘ The paper mentions that 521 or 522 iterations are required to test a single key.
Multiply that delay by something like 2^112 (112 bits being the entropy value of a typical 14-character password). Probably up to 86 million years to bruteforce, if each iteration takes a nanosecond, unless my mathematics is way off. And that’s assuming the key is dependent on the password being used.

So, if I wanted to recover the unencrypted data, I’d focus my efforts on recovering the original unencrypted file, perhaps using foremost, Sleuthkit or EnCase.
Unlike GPG file encryption, bcrypt wipes the plaintext copy by overwriting the filespace with random bits. Compare this with encrypting a file with GPG and using BleachBit to overwrite the plaintext with 0 bytes. GPG can provide stronger file encryption, and BleachBit’s file shredding feature is (according to the developer’s docs) enough to make a file unrecoverable on a modern hard drive using software-based tools. It also renames the file then gives it a shorter name, just to mess up the file’s metadata before wiping. I’d like to do a comparison of BleachBit and bcrypt’s file shredding features for my next post, to see whether this is the case.

Getting OpenVPN Set Up on Windows


, ,

This works best when the browser has AdBlock and Ghostery installed, and geolocation is disabled, if you’re installing this as a privacy tool.

You’ll find the OpenVPN client installer under the Community Downloads section. Setup is straightforward, but make sure the option for installing the OpenSSL Utilities is checked.


After it’s installed, there’ll be an OpenVPN folder with several sample configuration files, each representing a service the client might connect to. This is where we can drop other configuration files for whatever services we might use.
Running OpenVPN won’t bring up a GUI, but instead a small icon in the system tray, and it’s activated/decativated by right-clicking that icon and selecting options from its context menu.


Adding the VPN Service Provider
The VPN client creates the virtual tunnel interfaces on the local system, but they wouldn’t be of any use without a VPN service.
The service provider I’ve chosen here is VPNBook. The ‘bundles’ posted on VPNBook’s site are .zip archives of configuration files – download whichever one, and extract it to the OpenVPN config directory.


With these files in place, the connections should appear in the context menu for the OpenVPN icon.


Be aware that whichever port you select, it will only tunnel traffic for that port. Everything else will bypass the virtual tunnel interfaces and get routed as normal.
Now enter the login and password provided on the VPNBook site.


Checking the Connection
How can we be certain our browser traffic is going through the VPN service? We can check by finding the IP address we’re using at or A reverse whois query using domaintools should reveal the IP address is assigned to the VPN service. Also, the browser shouldn’t throw SSL/TLS certificate errors if the traffic is being tunnelled correctly.