Saturday, March 11, 2017

Now you're thinking with Qubes!

So I've finally done it.  This is may be my fourth attempt to use QubesOS, and I think it's really going to stick this time.  After yet another Ubuntu boot failure due to their inability to QA day to day LUKS usage, I've spent an uncomfortable week forcing myself to adapt to all the fun little quirks that come with an ultra secure operating system, and I think I'm finally getting the hang of it.

I thought it would be fun to write up a summary of the problems I encountered in my first week of using Qubes, and how I realigned my way to thinking to come up with a workable solution.

Quick Architecture Summary:

For those of you not super familiar with QubesOS, it's essentially a desktop Linux distro that makes heavy use of the Xen hypervisor to compartmentalize the ever-loving crap out of every activity that you would normally want to do on a computer.  There exist Template VMs which contain the base operating systems, and there are App VMs which are made to contain your apps.  In your App VMs, anything you touch outside of your home directory gets wiped at reboot, so if you want to install stuff, you need to install it in your Template VMs.  Template VMs are also firewalled such that they can't touch anything on the internet except for update servers.  There are also Service VMs that manage your network and firewall configurations, but you typically don't need to touch them.

Problem #1  Decoration time!

One thing that I actually *really really* like about Qubes is that every compartmentalized VM uses colorized window decorations to give you an instant, visceral understanding of the privilege level you're in the window you're typing into.  For example, all if your work windows could be blue, and all your personal windows could be green.  The mappings of which colors go to which VMs is always configurable at any time.

I also need to figure out how I want to compartmentalize my data, which is the key feature of Qubes.  This machine is my personal desktop system at home which I use for things such as:
  1. Shitposting on reddit
  2. Browsing random onion sites
  3. Playing with interesting new crypto-currencies
  4. Playing around with weird machine learning stuff
  5. Managing random servers via SSH
  6. Downloading and serving up TV shows to my various devices
Why have I been doing this all on one machine for so many years you ask?  Shut up, that's why.  There are obviously some clear security wins to be had by breaking some of this out.  I started by making a VM called "browsing", which I colored green.  Then I made a VM called "media" which I made purple.  Then I decided to make my cryptocoin VMs yellow (It's a nice, golden yellow), and figured I'd make my SSH VM and weird code VMs all blue.  This is where all my SSH keys go.  It's nice to know that if my browser gets popped, I don't lose all my keys too.

An awesome thing about the latest release is that QubesOS 3.2 now comes by default with a VM called "anon-whonix" for Tor browsing, which is colored red.  It uses the same workstation/gateway model that Whonix uses, and it all works just beautifully out of the box.

Problem #2 Redhat Sucks!

I dunno, for one reason or another, I've never been a RedHat fan.  I know Joanna loves it, but it's just not my thing.  This has killed me in my previous attempts at running Qubes, but this time, there was a simple, one line solution.

[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8

If you want something else, check out the template documentation on the qubes documentation page :  You can actually install Ubuntu, Kali, Arch, even Windows as a template VM.  Debian works find for me now though, so moving on.  Another neat thing here is that I didn't need to rebuild my browsing VM.  Since my AppVM is really just a home directory, I easily swaped the underlying template from Fedora to Ubuntu, and everything was good to go.

Problem #3 USB is hard.

The last time I tried QubesOS was the previous release, 3.1.  Back then, if you wanted to use a USB stick, it was open heart surgery time.  USB sticks had to be wired to AppVMs manually on the command line, and if you forgot to detach any USB devices, and rebooted, you'd get some crazy cascading failures that would prevent even the Service VMs from coming up.  I'm happy to say, that's all changed now in 3.2.  Now you just plug in a USB device, right click on the App VM you want to attach it to, and you're golden.  It even works nicely with my LUKS encrypted USB sticks.  I just open the file browser from the drop-down menu, and I can see my encrypted device.  When I click on it, it prompts for my LUKS passphrase in a nice, graphical, password prompt.  How handy!

Problem #4 FIghting with Plex

I use Plex as my primary media server, which led to some complications.  First of all, there isn't really a Debian version of Plex available, so I ended up just using a Fedora template.  Remember that things you install in your AppVM don't stick around on reboot.  Also, if you install Plex in your Fedora template, then any time you boot any AppVM that uses Fedora as a base, you be running a happy little plex server in your AppVM too, which is undesirable.

I ended up creating my own Template VM for Plex.  Sure, it seems a bit silly to have a Template VM in use with only one App VM, but if it's stupid, and it works, it's not stupid.

This worked pretty well, but I had another problem.  Plex likes to store all its data in /var/lib/plexmediaserver, so it gets wiped at each reboot, requiring me to reconfigure the server each time I restart the media VM.  I originally solved this by just configuring Plex in the Template VM.  One problem is that I needed internet access to set up Plex with my online account  (remember Template VMs typically only access update servers).  There's actually a button in the Firewall Configuration for the VM to allow full internet access for five minutes.

Still though, my viewing data was not being saved across reboots, so everything would need to re-thumbnail, re-encode, and show up as new.  The solution that finally hit me was simple.  From the Template VM:

cp -avr /var/lib/plexmediaserver /home/user/plexmediaserver
mv /var/lib/plexmediaserver /var/lib/plexmediaserver-bak
ln -s /home/user/plexmediaserver /var/lib/plexmediaserver

Since the plex data is now in my home directory, when I configure it from my App VM, now the data will persist.  Everything works exactly as expected now.

Problem #5 It's getting crowded in here!

I like to install my base operating systems on SSDs, but unfortunately, the SSD in this system is only a few hundred gigs.  The bitcoin blockchain alone is over 100 gigs these days, and media servers tend to fill up quick.  I've got this nice 6tb drive sitting right here too, but none of my AppVMs can access it, except one at a time.

I'll admit that I spent way too long scheming on fancy bindmount setups, or some shared filesystem situation.  I also almost broke down and re-partitioned my 6tb drive so I could share out mount points individually, but I didn't want to risk data loss.

My eventual obvious breakthrough was simlinks.  I ran this from Dom0 after shutting down all running AppVMs.

cp -avr /var/lib/qubes/appvms /mnt/6t/appvms
mv /var/lib/qubes/appvms /var/lib/qubes/appvms-bak
ln -s /mnt/6t/appvms /var/lib/qubes/appvms

I actually came up with this solution before the final step of my Plex configuration, and you'll note how similar they look, but I figured it would be weird to revisit the Plex thing later.

I also edited my crypttab and fstab to make sure the 6tb drive gets attached at boot.  After this, I was able to go into the AppVM settings for each AppVM and set the disk storage to be as large as the AppVM would need to get.  There seems to be a 1tb maximum unfortunately.  I don't know if that's a Xen limitation, or just an arbitrary value that some Qubes developer thought would be more data than anyone would need, but I do have a VM that wants 4tb, though I can make due without it for a while.

Problem #6 OMG the CIA is hacking everyone!

Conveniently, the Vault 7 Wikileaks leak happened this week.  A few clicks later, and I had my shiny new red Wikileaks AppVM.  This was pretty neat, because in the AppVM, I was able to apt-get install qbittorrent, download the torrent file in my browsing VM, send it over to the wikileaks VM, and download it there.

Once the passphrase was announced, I could dig through it, without fear of any browser exploits or PDF exploits.  Not that Wikileaks would ever release malicious files, but it felt really good to be able to dig through them in a completely isolated environment.

This is also when I got really used to how copy and paste works in Qubes.  This is actually super neat.  From my green browsing VM, I could go to twitter, pull up the wikileaks tweet with the crazy long 7zip password, and then "ctrl+c" like normal.  Now, this put the password into my "browse" copy buffer.  Then, with the browse window up front, I pressed "ctrl+shift+c" which indicated to qubes that I wanted to pass around my copy buffer to another VM.  Once I alt-tabbed over to my wikileaks VM, I pressed "ctrl-shift-v" to load the password into the copy buffer on the wikileaks VM.  Then I right clicked and said "paste" in the context menu.  This was so much slicker than how VMWare does copy and paste when it works, and much less frustrating than trying to hand type data across VMs.  It's also pretty damn secure.  A shared copy buffer across all AppVMs would be a disaster, but this method seems very precise and simple enough that after doing it a few times you start to do it without thinking.

Problem #7 Oh crap, I probably just said too much

#YOLO.  I'm a firm believer in Kerckhoffs's principle.  That is to say, knowledge of how I deploy my security should only serve to discourage any potential attackers.  Even a potential exposure on my end in the name of education is a net win for everyone.  If you understood most of what the hell I was taking about in this post, you're probabally ready to try out Qubes.

Friday, March 10, 2017

EmpirePanel : Hack with Friends!


You may be familiar with what was once called "PowerShell Empire", and is now referred to simply as "Empire".  It's the hot new post-exploitation framework with a lot of fancy features.  One major drawback, however, is that Empire lacks any real multiplayer support.  I noticed that Empire is, at its core, a Flask app, so why the hell not extend it into a fully functional web interface for collaborative hacking?


  • A nice, pretty, web interface for Empire
  • Mulitplayer support
  • Functional parity with command line version
  • Minimal invasiveness to the existing Empire code base

High Level Architecture:

EmpirePanel is based on AdminLTE, and is decorated with AngularJS.  It is implemented entirely in HTML and JavaScript except for a minor tweak to enable the new routes in the core Empire code.  All interaction with Empire is done with JavaScript via the provided Empire API.


git clone
cd EmpirePanel/setup/
cd ..
./empire --rest --username admin --password admin

Then from a browser, visit, and log in with the user/pass you set.

You should then be presented with a page looking like this:

Awesome, now lets start hacking.  First we need to create a listener.  I'm using for this listener because that's the IP for my vmware host.

Great.  Now once we have the listener, we click into it, and generate a launcher:

This launcher is the command we run on our target system.  Once we run it, we see an agent pop up.

Okay, let's click into it and see what sorts of things we can do :

Things That Work:

  • Creating and destroying listeners
  • Generating a launchers
  • Collecting agents
  • Running shell commands on agents
  • Running modules on agents

Things That Don't Work Yet:

  • Some agent commands, like rename, ps, etc
  • UI layout consistency
  • AngularJS syncing issues

Fixing Things That Don't Work:

Of course, everything is on github ( and I accept pull requests.  All of my EmpirePanel work is concentrated on two files, empire.js, and index.html in the /static/ directory.

Future Plans:

This demo is only compatible with the 1.5 version of Empire.  Hopefully the API for 2.0 will stabilize soon and I'll be able to port it over, and hopefully, one day get the code upstream.  Maybe this work will simply inspire someone who knows what they're doing to come along and do it all the right way, who knows?  I guess that's all part of the magic of Open Source.  Enjoy!

Sunday, January 15, 2017

Becoming a Multi-Galactic Species in our Lifetime

Thanks to the efforts of Elon Musk and those working with him, it is likely that we will soon become a multi-planetary species.  In this post I consider what we need to become a Multi-Galactic species within our lifetime.  First, I want to establish a few ground rules to eliminate some obvious methods to cheat our way to this goal.

1 : No Immortality 
While longevity technology will certainly advance quite significantly in the next 50 years, this isn't what I mean by "in our lifetime".

2 : No faster than light travel (It's the law!)
While we may stumble across warp drives or wormholes in the coming years, we can't count on it, so we should plan accordingly.  This includes faster than light communication.

3 : No magical energy sources
Zero Point Energy, and similar concepts of pulling energy out of the universe are neat for sci-fi, but unnecessary to achieve these goals.

I believe it is possible that the first humans to set foot in the Andromeda galaxy could very well already be alive today.

In general, the trick here is to get a spacecraft constantly accelerating at 9.8m/s^2.  Not only will this rate of acceleration be maximally comfortable to the passengers, since it would perfectly simulate the gravity of earth, but the craft would very quickly reach relativistic speeds. To passengers on this ship, a journey to Alpha Centauri (4.37 light years away) would take ~3.6 years (while 6 years would pass on earth).  It would take about 14 years to get to our new earth-like neighbor, Kepler 452-b (1400 light years away).  Finally, Andromeda, at a distance of 2.5 million light years, would take about 28 years of travel from the perspective of the passengers on board.  By the way, the travel time is nearly cut in half if the passengers are willing to get pushed at 2g.

You may notice from those travel calculators the insane amount of fuel required to make such a journey, but what if the ships didn't need to carry any fuel at all?  I think the most realistic way forward for interstellar, and ultimately intergalactic, travel is for our stars themselves to constantly beam the required energy directly to the vessels in flight.

We have already shown that we can very efficiently convert energy fired from lasers back into useful power using "reverse lasers".  Energy sent this way could be collected, directed, or reflected, and used by something like a solar sail, or maybe to charge a photon rocket.  This is along the lines of existing laser propulsion systems, such as the one that promises to send crafts to Mars in 3 days.

Of course, there are many scary pitfalls of traveling like this.  Losing contact with your power source could potentially leave you stranded, which is why it is also important to build a network of these systems on any star we can reach.  I imagine our system here at home would be a network of satellites orbiting our sun, like a Dyson Swarm that collects energy from the sun and very carefully fires it towards customers.  Presumably, before any humans are sent to other star systems, a kit of equipment would be sent ahead first, and since no humans will be aboard, they could potentially arrive much sooner, and have time to establish the communication requirements to "catch" incoming ships.  If there happen to be sufficient resources around the star, the satellites could even establish mining operations, and build more satellites to send out to nearby neighbors.  This network of colonized stars could also act as a galactic communications grid.

Interestingly, because of how drastic the relativistic effects of intergalactic travel are, by the time we get to Andromeda, every star could be completely mapped, categorized, terraformed, and ready for its new human inhabitants.

Monday, April 11, 2016

The Enslaved Oracle, and the Future of Superintelligence

The emergence of Superintelligent AI is coming, but what form will it take?  One potential avenue for this emergence that I feel is under-discussed, is that of the "Enslaved Oracle".  In this scenario, the first few Artificial General Intelligence lifeforms that are created are created in secret, and are used by their creators to gain a tactical advantage in their respective fields.

The primary appeal to this scenario is that it could be happening today.  It is very possible that researchers at Google, Goldman Sachs, or even the NSA have cracked the key barriers in general intelligence, and have successfully created and bound highly intelligent artificial lifeforms.  Presumably they would have "read-only" access to the internet, and are given the sole task of predicting future events for the benefit of their respective organizations.

Of course, this *probably* isn't happening today, but more and more companies are utilizing machine learning and predictive modeling, and you could imagine that the most successful programs would generate the most profit, which would lead to an increase in investment in predictive modeling, creating a cascading effect towards Superintelligence.

In most Superintelligence breakout scenarios, the AI ends up hacking into, and using the world's existing computing infrastructure to achieve ultimate enlightenment, but there is a key gap there between science fiction and reality.  As it turns out, specially designed neuromorphic processing hardware is many orders of magnitude more power performant than modern computing platforms for the purpose of AI simulation.  This means that with the right architecture, investing even a few million dollars in a neuromorphic computing platform, you could outperform the combined power of every computer on the planet.  This leads me to believe that early superintellegent AI are likely to be centralized, and will not easily migrate away from the cyber primordial soup that they were birthed in.

Democratizing Superintelligence

Is the Enslaved Oracle Scenario an unequivocally "bad thing" for the future of humanity?  I'm not too worried.  For some reason I have this faith that even an oligarchy of Superintelligent AI controlling humanity through corporate puppetry will still have a level of benevolence above and beyond what we are seeing from our existing human leadership.  That said, I am not a huge fan of technological disparity, so I've also thought through several scenarios where the emergence of such technologies occurs more in a more populist way.

As an avid follower of all things crypto, two new technologies that I'm a huge fan of are the Ethereum computing platform, which offers decentralized and cryptographically verified "smart contracts", and Augur, built on Ethereum, which is a decentralized prediction market.

How do these technologies play into the future of superintelligence?  Well, I think that there's a very good chance that these technologies, or others like it, could be the key to monetizing the hobbyist neuromorphic processor market.  Much the same way that custom ASIC companies exploded selling customized ASICs for Bitcoin mining, it's very possible that in the near future, eager crypto miners will be running neuromorphic mining rigs in an attempt to win big on these emerging prediction markets.

Imagine asking a question, in the form of publishing a contract to a prediction market.  You could ask what the weather would be like next week, which real estate investment would be more profitable in 10 years, what protein structures would be best for fighting some new disease outbreak, and you would instantly have a world full of intelligent machinery working on your problems.  The great thing at this point is that even if large corporations had developed "Enslaved Oracles", it would be to their benefit to participate in this global "Super Oracle".  Hardware companies sell more hardware.  Software companies sell better predictive algorithms, and the world's neuromorphic computing infrastructure runs hot, guiding humanity through our next stages of existence.

Tuesday, August 25, 2015

What I learned from cracking 4000 Ashley Madison passwords

The Plan

When the Ashley Madison database first got dumped, there was an interesting contingent of researchers talking about how pointless it would be to crack the passwords, since Ashley Madison was using salted bcrypt with a cost of 12.  I thought it might be a fun experiment to run the hashes on a cracking rig of mine to see what I could actually get out of it.

The Rig

My cracking rig is your typical milk carton style setup, as seen on Silicon Valley.

It was originally purchased a couple years ago as a cryptocoin mining rig for about $1500 in bitcoins.  Pretty much just a stack of four ATI R9 290s running PIMP (  PIMP is a Debian based USB boot environment designed for plug and play cryptocoin mining.  I find it super convenient to use because it deals with all the GPU driver BS, and by default gives you the most optimized setup for whatever cards you're using.  To give it the magical cracking powers, I dropped the most recent oclHashcat in there as well.

The Procedure

So, the data showed up in the form of a mysqldump.

gunzip member_login.dump.gz
tr , '\n' < member_login.dump > tmp.txt # switching commas for newlines
grep "\$2a" tmp.txt > tmp2.txt # grepping out hashes
tr -d "\'" < tmp2.txt > am.txt # removing single quotes

Holy cow, this thing has 36 *million* hashes in it.  The leak was still pretty new at the time, so I hadn't realized how many accounts were actually in the dump, but just the file of hashes themselves was 2.1 gigs.  I moved the file over to the cracking rig and ..

oclHashcat v1.36 starting...
Counting lines in am.txt
ERROR: Insufficient memory available

Huh.  Well that sucks.  I use head to grab the first million lines, and the thing fires up just great.  This is my first time seeing the real benchmarks for the crack, and it looks something like this:

Speed.GPU.#1...: 39 H/s
Speed.GPU.#2...: 39 H/s
Speed.GPU.#3...: 39 H/s
Speed.GPU.#4...: 39 H/s
Speed.GPU.#*...: 156 H/s

Yes, that's right, 156 hashes per second.  To someone who's used to cracking md5 passwords, this looks pretty disappointing, but it's bcrypt, so I'll take what I can get.  I start seeing how many hashes I can do at a time.  I double to 2 million hashes, then 4, and finally I see the Insufficient Memory error again when I hit 8 million hashes.  I drop it down to 6 million, and that seems to work just fine.  So my final list of hashes to crack is the first 6 million hashes from the database dump.

My final command looks like this:

./oclHashcat32.bin -m3200 -a0 am2.txt rockyou.txt --force --weak-hash-threshold 0
This is just a super basic -a0 attack using the famous rockyou.txt wordlist.  I also set a script to take a snapshot how how many passwords I had cracked every 10 minutes.

And now.. we wait..

The Data

So, after five days and three hours, I hit 4000 passwords, which I figured was a good time to stop.  I pulled the 10 minute snapshots together, and as it turns out, this is what the final graph of cracks over time looked like:

Now, of course what immediately jumped out at me was how insanely linear this is.  It comes to about 32.6 cracked passwords discovered per hour.  I had expected the curve to shoot up and level off over time as passwords became more rare.  This could be because I was still in the "dumb password" phase, but it's hard to tell.  It may not look like it at first, but there are 741 data points in this graph.

Some interesting numbers, of the 4007 cracked passwords in the final list, only 1191 of them were unique.  Dropping the list of cracked passwords into, we get a nice list of the most popular passwords cracked so far.  Here's the top 20 for your amusement:

123456 202
password 105
12345 99
qwerty 32
12345678 31
ashley 28
baseball 27
abc123 27
696969 23
111111 21
football 20
fuckyou 20
madison 20
asshole 19
superman 19
fuckme 19
hockey 19
123456789 19
hunter 18
harley 18

So, maybe these passwords were all throwaways.  It may also be infeasible to crack any given bcrypt password, but given enough users, it doesn't matter if passwords are bcrypted and salted, a ton of passwords are eventually going to pop out.

This is the goodbye message I got when I stopped the crack.

Session.Name...: oclHashcat
Status.........: Aborted
Input.Mode.....: File (rockyou.txt)
Hash.Target....: File (am2.txt)
Hash.Type......: bcrypt, Blowfish(OpenBSD)
Time.Started...: Thu Aug 20 11:40:32 2015 (5 days, 3 hours)
Time.Estimated.: 0 secs
Speed.GPU.#1...: 39 H/s
Speed.GPU.#2...: 39 H/s
Speed.GPU.#3...: 39 H/s
Speed.GPU.#4...: 39 H/s
Speed.GPU.#*...: 156 H/s
Recovered......: 4007/6000000 (0.07%) Digests, 4007/6000000 (0.07%) Salts
Progress.......: 60396544/86002302412928 (0.00%)
Rejected.......: 0/60396544 (0.00%)
Restore.Point..: 0/14343296 (0.00%)

As you can see, the crack still had quite a ways to go when I aborted it.

All my data from this study can be found here:

am-checkpoints.txt : log of passwords cracked every 10 minutes
am-freq.txt : frequency count of cracked passwords
am-pass.txt : final list of cracked passwords
am-sorted.txt : list of passwords, sorted alphabetically
am.pot : oclHashcat potfile generated by the crack

thanks everyone!  you can follow me on the tweeters @deanpierce


/u/rallias has pointed out that uniq -c will do a frequency count, and I'm dumb for using a website :-)

Tuesday, December 17, 2013

Bitcoin Private Key Necromancy


~ The Longer Version ~

A few weeks ago, a friend came to me with a problem.  Way back in 2011, he had the great idea to reinstall Windows.  Without thinking too much about it, he installed the new version of Windows, and used the drive for a while.  It was only later that he realized that the drive actually contained a good quantity if bitcoins.  Luckily, he realized there was a chance that the actual data containing the keys may one day be recoverable, and immediately unplugged it and stored it away for safe keeping.

With the price approaching 1000 USD/BTC, he brought the drive to a local bitcoin meetup and asked around.  One guy ran various profession forensics tools against the drive with no luck, and at the end of the night, the drive ended up in my hands.

Discussions of forensic hygiene out out of scope for this particular blog entry, but needless to say, my first step was using dd to pull the raw data off the drive, giving me a 160 gig file on my local filesystem to work with.

Idea #1 BerkeleyDB recovery
So, of course, the original though was "find and pull out the wallet.dat".  My tool of choice for this sort of thing is magicrescue (  Magic rescue is typically used to recover images and documents from large blobs of data, for example, damaged filesystems.  Unfortunately for me, there was no BerkeleyDB "recipe file", which is what magicrescue uses to reconstruct files.  With a bit of poking around, I figured out how to write my own custom recipe files, and I was on my way.  Using a hex editor, I checked out the first 16 bytes or so of a normal wallet.dat, and confirmed that it was the same across multiple wallet.dat files that I had lying around.  I ran the magicrescue scan, and came up with no hits.

I read up some more on the format of BerkeleyDB files, kept tweaking my recipie files to support more and more versions of BerekelyDB, and nothing.

Idea #2 Find *Something*
At this point, I started digging around in the middle of my files for anything that might be somewhat unique.  The first few things I tried were coming up negative, and then I noticed the string name"1, which was immediately followed by a bitcoin address in the various wallet.dat files I had.  I built the recipe, ran the scan, and got a single hit.  I looked into the output file, and there it was, a bitcoin address.  I looked the address up in blockexplorer, and there it was.  An address with the exact number of coins my friend had guessed was on the drive, and no transactions since 2011.


My next thought was that I needed to carve the wallet.dat file out of this chunk of data I had found.  After a bit of futzing around, I noticed that almost directly above the address was a header for a .NET Assembly.  This meant one thing: fragmentation, which was bad news for me. 

Idea #3 Raw Key Extraction
Okay, it was time to finally figure out how to extract the keys directly.  I found various tools for printing out private keys, but everything was outputting this strange 400 byte format, which didn't seem right.  I read up a bit more about how private keys work in bitcoin, and read a ton of code and specs figuring out how they were supposed to be encoded, and "Wallet Import Format".  That let me to this nifty webapp

My big break came last night when I realized I could export one of my own empty private keys, and get the raw 32 byte hex from the website.  Once I knew that, I could dig around in the wallet.dat file.  I noticed that there were some interesting bytes that preceded the private key, and noticed that this preceding magic number was in front of all of the private keys in the wallet.  I quickly whipped up a magicrescue recipe, and before I knew it, I had 400 hits.  I wrote up some code to go through the files, translate the 32 byte data into base58 WIF keys, and threw them into a shellscript that ran "bitcoind importprivkey ...", and imported them into a local wallet that I had.  When that was done, I ran "bitcoind getbalance" and there they were :-D  I quickly moved the coins to a safer place, and let my friend know the good news.

The birth of KeyHunter
I figure not everyone wants to dink around with magicrescue, so I wrote up a tool called keyhunter to automatically rip through a large chunks of data, and spit out the base58 Import Address.  The code is here:

If it helps you find any of your lost and forgotten coins, I've set up a donation address here:


Good luck!

Tuesday, June 25, 2013

Locking down your Tor usage

Due to increased interest, I figure I should post about this in a more public area.

Problem statement : "I worry that unintended data is leaking from my machine while I'm using Tor."

The solution : Using iptables to block all data exiting the machine that is not coming from the Tor daemon.

The way that I do this is by creating a simple script in my home directory called "".  This file contains the following lines:

sudo iptables -F
sudo iptables -I OUTPUT -o wlan0 -m owner ! --uid-owner debian-tor -j REJECT

This assumes a few things.

  1. You are on a Linux box with iptables.
  2. The local tor server is running as the user "debian-tor".
  3. You are connected to the internet through the wlan0 interface.
  4. You don't already have complex iptables rules in place.
  5. You are using the standard tor daemon, without vidalia, privoxy, or the browser bundle.

This will work out of the box for anyone on Ubuntu or Debian who installed it via the supported PPAs.

To get this working with the browser bundle, I first set a password for the debian-tor user, made sure the home directory was set to /var/lib/tor , and then installed the browser bundle there.  Then, when I want to run the browser bundle, I first run the ./ script, then run "su debian-tor".  At that point, I can connect to anything using tor, and no traffic from my admin user, or even from root, can exit the box.  Any scripts or tools you're using should be run as your regular user, and you are guaranteed that they will only be able to touch the internet through tor.