Bitlocker Drive Encryption Guide

This is a short guide with pictures that will hopefully explain how to set up Bitlocker drive encryption for your Windows system, and get you on your way towards a more secure computer.

Bitlocker allows for full system encryption or just a partition to be encrypted. It uses AES 128bit by default but we can move it to AES 256bit. Let me just say that 128bit is entirely sufficient, and there is very little reason to use 256bit as it can cause performance issues.

Setting AES 256bit

If you’re dealing with highly classified information or your systems performance is not of concern you can change Bitlocker settings to use 256bit AES. 256bit mode will also increase the rounds used from 10 to 14. To implement AES 256bit we type the following into our search:


Hit enter.

The path is:

Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption

 “Choose drive encryption method and cipher strength”

Set this value to Enabled and then choose the strength you want.

Setting Up Bitlocker Without TPM
Many systems don’t have TPM so we can disable the requirement for one. After doing the above you can go to “Operating System Drives”.
Go to “Require additional authentication” and disable.
Set Up Of Bitlocker
Restart the system if you’ve done either of the above. Now we get to the set up of Bitlocker itself. It’s very simple:
First we choose the drive to encrypt.
You can encrypt your OS or any other partition. For the most security you’ll want the OS encrypted, this will prevent attackers from manipulating an offline machine.
Once you choose the drive it’s time to set a password.
Remember, a good password will have at least one of every character type: lower case, upper case, symbol, number (aB#4). Do not use special ASCII characters – Bitlocker lets you enter them but won’t let you use them at boot up – you’ll be locked out.
You will be asked to save a recovery key. This is very dangerous. You have three options if you want to be secure:
1) Print the key and hide it well. My least favorite option.
2) Save the key to a file and keep it on a separate USB, which you can hide or encrypt.
3) Safe the key to a file and delete that file after a reboot.
Now you choose whether to encrypt the full partition or just the used space. If you choose to skip encryption of free space an attacker may be able to gain valuable information. I highly suggest you encrypt the full partition.
Bitlocker Should Be Set Up
If you’ve followed these steps Bitlocker should be set up properly. For the average user performance hit (with default settings) should be very little.
It’s important to state that Bitlocker is only good for preventing access to your information while the system is off. If the system is on you are vulnerable. It will not prevent keyloggers, viruses, or any type of malware – all it prevents is tampering of data on the device.

Hardening Ubuntu Linux

I’m going to keep some tips here for users looking to improve their security, when I update it I’ll tweet about it, so feel free to follow me @insanitybit. This is aimed at desktop users but naturally lots of it can apply to a Linux server. Some of this will be simple, trivial, and some of this will be quite a bit more difficult. I’m focusing specifically on Ubuntu but other distros will have similar features (replace Apparmor with SELinux). I will try to make this as comprehensive as possible, though I’m specifically avoiding items like Fail2Ban as it’s not really useful for users. You can consider this an extension of my ‘definitive guides‘ – The Definitive Guide For Securing Linux Ubuntu.

A lot of users believe that a distro such as Ubuntu will be so much more secure than Windows, purely through virtue of obscurity. As Linux popularity continues to grow you’ll see attackers begin to take notice. Just because attackers don’t care to hack Linux desktop systems does not by any means imply they aren’t capable of it, or ready to when it seems profitable.

Thankfully, Linux is really easy to secure. Despite some problems there are a lot of powerful projects that give users the power to secure themselves against many threats.

Securing Your Browser

First I’d like to start by linking to my guides for locking down Chrome and Firefox As a user your most exploitable area is your browser, it’s constantly taking in untrusted content, often over an insecure connection. I personally love Chrome’s Linux sandbox, but Firefox with NoScript is very powerful as well – I leave it to you to decide between the two based on your needs.

Enabling Ubuntu’s Firewall

Ubuntu comes with a firewall utility called UFW, but it isn’t enabled by default. The reason is that, by default, Ubuntu doesn’t have any open ports open (except for system services that are typically necessary for the average user). So is a Firewall strictly necessary? Well, if you’re behind a NAT router not so much, any open ports will expose you to local attacks, but you’re ‘hidden’ from the internet. Still, if you’re looking to secure your system you can simply run this command:

ufw enable

ufw default deny incoming

And it should prevent inbound access. You can create complex rules via iptables to restrict or relax your rules. You can also check out GUFW for a graphic interface to UFW. GUFW makes everything very easy to use.

You can use UFW/GUFW to create outbound rules for applications. Due to the amount that applications within a user ID can interfere with one another I do not feel that an outbound firewall is worthwhile for security, and it can be quite a bit of a pain. If you’re serious about setting up an outbound firewall I suggest you make strict use of user separation and apparmor, though even then the benefits are questionable (there is a reason programs like Comodo on Windows bundle their firewall components with strict HIPS software).

See this guide for further information on setting up firewalls. Courtesy of a very smart guy, Dangertux.

Run a Program As A Separate User

While the simplest way to restrict a program is AppArmor (see below) you can also make use of the native user/group Linux permissions in order to run an application as a different user. I’ve written a guide with Pidgin as the example. Separated programs will have less access to one another and they’ll live in a different user directory, with access only to that directory.

By separating a program to a new user we can also write more powerful firewall rules, as the program won’t be able to bypass an outbound rule as trivially.

For a risky program that doesn’t need to access other programs this may be a very viable option. For example, I run Xchat, which hasn’t been updated in about two years. For a program like this throwing as much security as possible at it isn’t a bad idea, since it doesn’t get patches, doesn’t use modern security techniques, and is internet facing.

Restricting DMESG

By default unprivileged users can read a lot of your systems logs. These logs can contain critical information for an attacker hoping to exploit your system further.

This is useful for debugging, but you’re not likely to have to do that. Running this command will prevent access by unprivileged users:

echo kernel.dmesg_restrict = 1 >> /etc/sysctl.conf

This feature is also included in the Grsecurity patch.


DNSCrypt is a DNS resolver that encrypts the content of your request between you and the first level resolver. It prevents an attacker from hijacking or viewing your DNS resolution and the program itself is hardened quite a lot.

For a guide to install.

For a guide to harden further.

Removing Attack Surface

One of the first steps to harden any operating system should always be disabling unnecessary programs/ services. Desktop operating systems don’t come “default secure” they come “default compatible” and that means meeting the needs of every person, generically. So while John may use his network printer Jane may not, but Jane’s system still comes with all of the attack surface necessary for network printing.

The network printing service is cupsd. It comes, by default, in an Apparmor profile, so it’s not like you should be incredibly worried about being exploited. And if you’re behind NAT you’re only exposed to local attacks. But, if you’re like me, you don’t print over a network and you have no need for this service. Are you likely to be attacked over it? Maybe, maybe not, but it’s not needed. So go ahead and remove that service.

You can check for programs listening on your system with the following command:

netstat -tulnp

Look up any services and carefully consider the benefit/ necessity of them. If you don’t need them or want them, remove them.

Another tip is to use Run the following command: (You must first set the file as executable)

./ –proc-all

It will provide you with a list of running services along with information about their security – whether they use NX, stack canaries, and if they’ve been compiled as Position Independent Executables (PIE). This may help you make a more informed decision about removing a service.

Mount /tmp With noexec,nodev,nosuid

Many programs require read/write access to /tmp but, for the most part, no programs actually need to be able to execute from there. Mounting this area with the noexec, nodev, nosuid can provide some level of security. Rather than creating a new partition for /tmp I find it’s just easier to use RAM (it expands as needed and doesn’t require partitioning , one benefit being a (potential) performance increase, though I wouldn’t bet on it.

Copy the following into your /etc/fstab file.

tmpfs /tmp tmpfs mode=1777,nosuid,nodev,noexec 0 0

If you want to create a new partition for /tmp you can find a guide online for that. It’s kinda a pain. The downside to running it in RAM is, obviously, you lose some RAM. If you want to limit the amount of RAM it can use (tmpfs expands as needed) you can change the line to (for 512M):

tmpfs /tmp tmpfs size=512M,mode=1777,nosuid,nodev,noexec 0 0

I recommend that if you follow the above you make use of AppArmor to improve the level of security this adds. If you use /tmp in RAM one benefit is that, in your AppArmor profiles, you should be able to remove map rules for some programs that map /tmp for performance reasons.


AppArmor is the Linux Security Module of choice for Ubuntu. It implements Mandatory Access Control on a per-process basis. It’s very simple to learn how to use AppArmor and I’ve written a guide. In the guide I provide tips for creating strong AppArmor profiles and avoiding potential pitfalls.

A program like Pidgin has a lot of access to your system. It runs as the same user as many other programs on your system and therefor is granted a fair amount of control over them. It can read many areas of the system that it doesn’t need to read, it can write to quite a few too. AppArmor restricts it to only the resources it needs, making both remote and local privilege exploits more difficult to pull off.

I’ve written a few very strict AppArmor profiles myself that you’re welcome to use as a starting point. [Xchat][Pulseaudio] [Java]

32bit users will have to adjust as needed, though it should be as simple as replacing the x86_64 with i386 (I’ll add variables for this at some point so you won’t have to).

Every internet facing program deserves an AppArmor profiles. It’s the simplest way to implement least privilege on a per application basis.

PaX and Grsecurity

PaX and Grsecurity are patches for the Linux kernel (the Grsecurity patch contains both, don’t just use PaX). PaX and Grsecurity have been at the forefront of security for more than a decade, bringing some of the most important security mitigation techniques to systems today, such as Address Space Layout Randomization (ASLR). ASLR is a great example of a mitigation technique that doesn’t have a great implementation in typical vanilla systems. The ASLR in your average distro, like Ubuntu, introduces far less entropy into the system, which degrades its use. The ASLR is also missing critical features, such as brute force deterrence, among others. PaX and Grsecurity bring these features and many many others to Linux. No operating system has as complete ASLR as PaX and, really, nothing else compares.

Not all of these features are compatible for desktop users, or even necessary, but a number of them will work on an Ubuntu desktop. You can see my guide for patching and compiling a Grsecurity Linux kernel, with notes about compatibility issues for desktop users.

Many of these security features directly relate to desktop security. Many applications and services use chroot to run programs in a separate environment. Chroot is incapable of restricting programs that can run as root, multiple bypasses are possible. Chrome is one such program, along with many other services (like avahi-daemon), so using the chroot hardening features of Grsecurity will provide a considerably more secure environment.

PaX and Grsecurity can be implemented with very little performance overhead, and very few stability issues if configured properly. If you’re really looking to secure your Linux system and you’re willing to take the time to compile it you should give it a try.

Learn how to compile your own Grsecurity Linux kernel here.


None of the above will make up for a system that is out of date and unpatched. If you’re using an older kernel and userland applications an attacker will be able to chain together enough exploits to bypass any restrictions/ measures you’ve taken, no matter how powerful. Make sure to stay up to date for all applications.

You can push patch time further by hardening the system – time to develop an exploit for a hardened system is longer. This does not mean you can postpone indefinitely, it just buys you time to test patches and improve your patch management.

Something To Keep In Mind

This all works best in conjunction. Grsecurity and PaX are honestly the best security software there is, in my opinion, but they can’t make up for a completely insecure userland. If you’re running programs that opt out or don’t make use of modern technology there’s only so much they can do. It’s very unfortunate but, even on 64bit, Ubuntu ships with a lot of services not using Position Independent Executable code – at this point it’s necessary to harden the programs in other ways.

And the same goes both ways. If you’re not using Grsecurity and PaX then your kernel is less secure, meaning that even if you harden a userland application with apparmor an attacker will have a much easier time exploiting the kernel and escaping the profile.

If you’re annoyed about your distro coming with insecure settings email them about it. You can reach Canonical:

 you have suggestions for or, please email us or

And if you have any suggestions for this guide please let me know in a comment. I’ll happily include any relevant information.

Follow me @insanitybit for updates and more articles like this.

Speeding Up Unity On Ubuntu With ATI Cards

I use Ubuntu 12.10 with Unity and I run a mid range ATI 5000 series GPU. Performance was surprisingly good in 12.10 after a fresh install (upgrade made performance horrible) but while playing Flash/HTML5 video things slowed down considerably, and using Super + W (expose) was much slower.

I searched around for some quick tips and found two that have apparently improved things significantly.

sudo apt-get install compizconfig-settings-manager

Then go to the CCSM and the OpenGL plugin and disable “Sync to Vblank”.

Go back to CCSM and then the Composite plugin. This time disable the “Check refresh rate”.

Expose is now much quicker/ smoother. Noticeably so – even while I’m playing video in Chrome. The difference is like night and day – I can reload pages/ tabs alongside the video and move windows around and it’s all smooth.

Make sure you’re on the latest ATI drivers. Due to Valve pushing for better Linux drivers the most recent versions (12.8/12.9) feature vastly improved performance.

Padding Passwords For Security

Common attacks on passwords involve bruteforcing and using pre-computed ‘rainbow tables’. Avoiding both of these attacks is fairly trivial – for both it’s a matter of length and an uncommon password. The issue is that remembering many different long passwords is difficult, which is where password padding comes in.

Password padding just means that you take your password and add one or two characters repeatedly. For example:

Password: Ninja

Padded Password: !!!Ninja!!!

Ninja is an incredibly common password, a dictionary attack will probably try it immediately. You’d be cracked in seconds. By adding !!! to both ends we’ve made a dictionary attack less likely, bruteforcing will take significantly longer, precomputed hashes are less likely to work, and it’s as easy to remember as Ninja.

Of course !!!Ninja!!! is still not a very secure password. While that padding is great for avoiding attacks it would still be susceptible to dictionary attacks if they decide to bruteforce the padding.  But attackers don’t get points for “close” – they can be one character away or a million and have no idea which.

Take any of your passwords and consider putting some padding on them. It’s a very simple way to improve password security without having to resort to memorizing incredibly long passwords.

Using Your Android, iOS, Or Blackberry Device To Secure LastPass And More

In a blog post a while back I wrote about LastPass, a sophisticated password manager that provides an incredibly secure way to sync all of your passwords across various browsers and computers. In the guide I walk you through how to set LastPass up and set your PBKDF2 iterations to whatever number you like. This post will deal with setting up Two-Step authentication via Grid or Google Authenticator, and I’ll cover a few more minor features.

Grid Multifactor Authentication

In your LastPass settings panel under the Security tab you’ll find the option to enable Grid Multifactor Authentication.

When you enable MultiFactor Authentication you’ll be presented with two options.

1) Allowing mobile and bookmarkets to bypass grid authentication (NOT recommended, I have it checked there but I shouldn’t)

2) Allowing offline access (I personally wouldn’t use this, but it can make things easier, it just means an encrypted container will be kept on the system)

You should immediately copy, print, and store the grid somewhere secure. Ideally you would keep it printed on paper and carry it with you. This is less than ideal as it could easily be torn. My preferred method is to keep the grid on a USB drive (or two) although I don’t use Grid MultiFactor Authentication.

Your grid will look something like this:

Yours will have different numbers and letters and yours won’t repeat – I have quickly obfuscated my grid by copy/pasting one portion over the entire thing (and then i got lazy and blotched two areas out, poorly). I actually just reset my grid anyways so I don’t know why I bothered… moving on!

When you try to log into an account from a device that hasn’t been whitelist you will be met with a prompt, asking you to fill in coordinates. It will say something like “B9, z7, 4A” and you’ll pick it out form there. There’s a massive combination here.

An attacker who has somehow compromised your password would also need either physical access to your vault or they would have to somehow guess your grid, which is statistically unlikely.

It’s important to note that while your password encrypts your vault the Grid is only a method of authentication, it will not encrypt your passwords. If an attacker has physical access to the vault they will effectively bypass this authentication.

Google Authenticator

This is my personal choice for security, the Google Authenticator. I have an Android device on me at all times (my Galaxy Nexus) so it’s ideal for me.

Google Authenticator, like LastPass, is a way to only allow access to your account by someone with physical access to a key that remains separate from your password. In this case the key is generated every 30 seconds as a 6 digit code, which you then enter in when you wish to log into your LastPass account. As with the Grid Authentication an attacker will need physical access to the device or to your vault as well as already having your password in order to compromise your account.

You can set up Google Authenticator in less than two minutes by installing the app from the Google Play Store and using it to take a picture of your QR code. The QR code would be where my very poor representation is.

Other Features

There are a few other features you may want to check out on the General Tab:

1) Only login from selected countries.

This seems like it would probably be quite simple to bypass, but if you aren’t one to travel outside of the country you can always enable this without worry. Or if you use a proxy to log in you can enable the country it resides in.

2) Disable logins from the TOR network.

The TOR network is built to be completely anonymous. It’s incredibly slow, making it completely unlikely to be used for a bruteforce attack, but some other attack may be possible despite high latency and low bandwidth, so disabling the network is a good idea anyways.

If you set up two factor authentication and follow my guide for creating strong passwords and increasing LastPass iterations you’re going to make your LastPass account incredibly secure, beyond practical attack. In the first guide we make bruteforcing the database impractical, and now we’ve made accessing the database impractical.

3) Check Insecure Logins – Under LastPass Settings, Advanced

LastPass will warn you when you’re filling in a form that’s considered ‘unsafe’.  I’m assuming it checks to see if any encryption is used to hash your password or some such thing.

Get Free LastPass Premium (for both of us!) for one moth with this link: 

Move Chrome’s Cache To RAM (Guide For Linux Users)

Browsers will keep ‘pieces’ of a webpage in what’s called a cache. This cache allows them to quickly pull files from the disk (which is quite somewhat quick) instead of having to redownload them (which is slow). Your system’s RAM is even faster than your disk, hundreds of times so, and keeping a file in RAM means accessing it will be nearly instant. Browsers are going to load up these files to RAM regardless but we can speed up writes to the cache and improve privacy by having the entire cache kept in RAM from the beginning. To do so we’ll be creating a RAM disk and then telling Chrome to use it.

Remember, your cache is deleted every time you shut down your computer if you follow this guide. It will get rebuilt the next session.

First off we’re going to create a directory in /tmp/ , which we’ll call ccache.

mkdir /tmp/ccache

Then we need to open up /etc/rc.local. The commands in /etc/rc.local are run whenever the system starts up. Enter the following line, which tells the system to mount the RAM disk at /tmp/ccache/. You’ll see size=700M. Keep in mind that this is in Bytes and it’s how much RAM you’re allocating to the new filesystem. You can change that size to whatever you want but I don’t think anyone’s going to be using much more than 300MB, but I keep some extra room in there.

mount -t tmpfs -o size=700M,mode=0744 tmpfs /tmp/ccache/

We now set the permissions on /tmp/ccache (recursively) to 777. For some reason 777 is all that’ll work for me.

chmod 777 /tmp/ccache/ -R

Now that’s all set up we need to create a Chrome desktop shortcut. However your distro lets you do that, just drag it wherever. Right click it, properties, and add the following (word press messes up double -‘s. You’ll have to type those out).

–disk-cache-dir=”/tmp/ccache/” –disk-cache-size=600000000

Now when you launch Chrome from that shortcut it’ll use the disk cache we’ve set up.

Now, in terms of privacy what we’ve done is eliminated the ability for an attacker with access to your system to view your cache/ try to see what you’ve been up to *except* for that session. Every time you shut your system down you lose the cache, as such no one can see where you’ve been.

If you were on some dodgy site or doing something sensitive or whatever all you have to do is restart the system and there will be no trace left (in the cache at least).

It may or may not be worth the trouble to you. Since Chrome’s already mapping this stuff to RAM anyways you shouldn’t expect any major performance improvements. But those who fear micro-writes to their SSD can use this to prevent wear/tear.

Creating A New User Account For Pidgin

This post will be dedicated to showing you how to run Pidgin in a separate user account. You can apply this to other programs as well. I’ll be adding a bit later for setfacl and allowing for shared files between user accounts.

Why Are We Doing This?

There are three main benefits to running programs in a separate user account.

1) The Linux ACL system is user/group based therefor one user account is largely limited in its interaction with another.

2) The X11 system allows for key passing between all applications in a user group. You can restrict X11 access to specific users so, for a program that doesn’t need X11 access (ie: some service) we can run it in a separate user account and prevent keylogging through X11. Pidgin uses X11/ needs access so it unfortunately will not benefit from this.

3) IPTables can work as a group. While an outbound Firewall may be virtually useless for a typical system if you were to separate each application into its individual group you would essentially create an application firewall, allowing only specific groups to use specific ports. This is far better than the typical outbound Firewall setup that allows all applications to use any outbound port.


If I use ‘<username>’ I’m talking about your default username. If I use <username.program>’ I’m talking about, in this case, username.pidgin.

If you run your Pidgin as another user and someone links you to something and you click it the browser will open up under that user. There is likely a way around this by using setfacl but I haven’t gotten to that yet.

If someone sends you a file it will be in the other user accounts folder.

There is a distinct hit to your basic user convenience for the benefit of a potentially more secure system. If you are not looking for a hit in convenience I suggest you set up a comprehensive apparmor profile instead.

It’s quite easy to undo everything in this guide. You simply remove the user and use your old shortcut.

Let’s Get Started

The first thing we do is actually create the user. This is simple.

sudo adduser –force-badname <username.pidgin>

It doesn’t have to be username.pidgin it can be just pidgin or it can be ‘koala’ I really don’t actually care what you name it and neither does Linux. It’s purely organizational.

We need to give Pidgin X11 access, it’s a graphic program after all.

sudo xhost +SI:localuser:<username.pidgin>

If you ever want to remove that simply turn the + to a -.

This only gives access until a reboot. Anyone know how to make it permanent? Other than rc.local.

Now we create a shortcut to this new Pidgin. Open gedit and enter the following

[Desktop Entry]
Exec=gksu -u <username.pidgin> pidgin

Save it as pidgin.desktop. Make this file executable and put it somewhere safe. Add it to your launcher.

Now if you click that you’ll be prompted with a safe gksudo prompt for your password. If you don’t like this there’s a simple way around it.

EDITOR=nano visudo

Add the line:

<username> ALL = (<username.pidgin>) NOPASSWD: /usr/bin/pidgin

Now when you launch it there should be no password.

That’s it.

You can now create IPTables rules for this usergroup

iptables -A OUTPUT -m owner --uid-owner <username.pidgin> -j REJECT

And you should recreate your Apparmor profile for Pidgin as well. I highly recommend you still make use of Apparmor.

Allowing For Mutual File Access

I’ll write about setfacl here. I’ll get to it another time. Hopefully this will allow me to (safely) execute Google Chrome in a separate UID.

Removing User Account

To remove a user account just use deluser <username>


Most of this comes from ( – great guide for doing this to Dropbox.

Securing My Verizon Galaxy Nexus

So I got an Android phone and I think it’s only fair to write up a few things to secure it.

1) I Rooted My Phone

Rooting your phone and unlocking the bootloader doesn’t actually make it more secure. You take your security out of the hardware and you rely on the kernel instead. That’s actually really crappy, but it’s necessary for almost everything else you’ll want.

2) Custom ROM

I’m running a custom operating system on my device. It’s Android, it’s just not the Android that came with it. Specifically the Verizon Galaxy Nexus (as of 07/27/2012) comes with Ice Cream Sandwich (ICS). ICS is the first Android OS to incorporate Address Space Layout Randomization (ASLR) but the ASLR is really weak and preliminary. Jelly Bean, Android 4.1, has full ASLR with Position Independent Executables, hardening against information leaks, full RELRO support for most of the OS, and it’s basically just a whole lot better on the ASLR front.

So moving to Jelly Bean is recommended.

3) Passwords / PIN/ Face Unlock

In terms of security it goes (greatest to least) Password -> PIN -> Face Unlock. Anyone with a Facebook picture of you or some photograph can access your phone if it uses Face Unlock. The feature is really cool and I’d love it if it paired with voice recognition or something (this way the attacker needs your face, your voice, and the phrase) but right now it’s nothing special. PINs are too short, useless against anyone but a friend who wants to mess with you. Passwords are pretty much where it’s at – you’re limited to 16 characters but that’s more than enough.

If you’re not using encryption it actually doesn’t really matter that much – they can get in anyways. But still, always good to go for a password.

4) Encryption Of Home

Android now allows you to encrypt the entire data partition with 128bit AES. I have personally opted out of this function as it’s kind of a pain in the ass – flashing ROMs with it isn’t easy. If I weren’t rooting and doing all this stuff I’d encrypt but for now it’s not worth it.

5) Disabling NFC

NFC allows your Android device to connect to others in short range and transfer information. It’s not good for security. It’s come up multiple times as a potential attack vector and I have no use for it myself.

Settings -> More… -> NFC

Uncheck the box.

If you don’t use it then… don’t use it. There’s no reason to leave it on.

6) Where’s My Droid

This is less of a security app and more of a “oh shit I lost my phone” app. Where’s My Droid is a free app that allows you to send key phrases via text to your phone and have it either ring or send you back a GPS coordinate. It also has a web interface that allows you to get details on the whereabouts of the phone.

If you use Where’s My Droid I highly suggest you make use of the “whitelist” and set it so only a few phones can send the message.

Setting Up EMET 3.5 Tech Preview

Update: EMET 4.0 Beta Is Available


I’d like to start off by saying that this new version of EMET is a Tech Preview – it’s not necessarily ready for release, I can’t guarantee stability.

Step 1: Download EMET 3.5 Tech Preview

To install the Tech Preview you must first remove any previous EMET installations. After you do that you can grab the Tech Preview (3.5) here:

Run the installer and open up EMET.

Step 2: Configuring System Settings

You should see something similar (but not exactly the same) to this picture.


Go ahead and hit “System Settings” and you should see something similar to this:


My recommended settings:

DEP: Opt Out

SEHOP: Opt Out (Vista users can choose Always On)

ASLR: Opt On

For a significantly more secure (but potentially less stable) system you can use these settings:

DEP: Always On

SEHOP: Opt Out (Or Always On for Vista Users)

ASLR: Always On

To learn how to enable ASLR Always On click here.

Step 5: Import all.XML

Click the “Configure Apps” button (at the bottom of the EMET User Interface) and you’ll see this page (but without all of these items in it):


Go to File -> Import -> Navigate to all.XML (in your EMET folder) -> Open.

EMET should import all of the settings for the typical ALL.XML but there won’t be any active ROP mitigation techniques, so make sure you enable them manually.

Restart your system for the full effect.

Setting Up DNSCrypt By OpenDNS On An Ubuntu 13.04 System

So I’ve just spent the time getting DNSCrypt working on my system. It was a bit of a pain but now that I got it done it shouldn’t be hard to recreate. I thought I’d write up a short guide explaining how to get it done.

Note that all double “-“s are turned into single ones. This is a WordPress issue. You’ll have to manually type them in, sorry.

Step 1: Setting Up A DNSCrypt User

sudo adduser --system --quiet --home /run/dnscrypt --shell /bin/false --group --disabled-password --disabled-login dnscrypt

That’s all one command. This is so that DNSCrypt can run as another user with no rights, and chroot itself into the directory.

Step 2: Install DNSCrypt

Find the right DNSCrypt version for you at this link:

You’re going to have to unzip it and compile it. Traverse to the folder you’ve just unzippzed and run the following commands:

  • ./configure
  • make
  • make install

I personally have to run “make install” twice. No clue why.

Step 3: Configure DNS

Change your DNS settings to in your network manager. Click the “wifi” area in the top right corner wifi and go to “edit connections”.  Select the network, and hit ‘Edit…’ then go to IPV4 Settings.

Make sure the Method is “Automatic (DHCP) Addresses Only” and set DNS Servers to

Step 4: Run DNSCrypt

Run the following command

dnscrypt-proxy --daemonize --user=dnscrypt

Step 5:

You can add the above command to /etc/rc.local so that it runs at bootup. You should also add the following command:

mkdir /run/dnscrypt

That way there’s a folder to move to.

That should be all it takes. Let me know how it works.


edit: You may need to install libsodium in newer versions, info here: