Time for a challenge

I’m creating a challenge on github. I’m explicitly not going to say much about it, because that wouldn’t be any fun. Try your hand, take a crack, who knows, maybe you’ll figure it out?


  • I plan to make it less opaque as time goes on
  • Do not read too much in to the git log
  • Surprise!

Open a Pull Request or reach out to me with questions.

I think it will evolve quite a bit as time goes on, but I can’t reveal too much.

Here’s a hint:

The greatest improvements in the productive powers of labour, and the greater part of the skill, dexterity, and judgment, with which it is anywhere directed, or applied, seem to have been the effects of the division of labour.

Should you Mine for Litecoin in the Amazon?

By now everyone knows what bitcoin is. Almost as many people know you can mine bitcoin with your computer.

Like any good mining rush, some early adopters made it big and everyone else has been chasing the ghosts of a fortune.

Infinite Scale

If you could mine a crypto currency in the cloud for less than the cost of renting those servers, you could scale up nearly instantly and make a similarly sized pile of money.

Using the cloud for crypto-currency mining has long been the dream of miners, but it never really works. Forget that, let’s throw caution to the wind and see for ourselves. A couple of factors led me to experiment if it would work again with the following considerations:

  1. Litecoin is based on scrypt, this means that, unlike Bitcoin, special built hardware had not yet hit the market and is harder to make
  2. Google, Amazon, and Microsoft are in a race to the bottom in cloud pricing
  3. The most competitive tier is the lower powered virtual machines, that Amazon is even willing to give away for free
  4. The low powered tiers have processing power but cannot leverage GPU advantages, meaning Litecoin is a good fit for them.


Once the CUDA machine was up and running with CudaMiner it was time to get it benchmarked:
Then it was time to let it go:

It wasn’t always super reliable:



When discussing the price of crypto-currency, we nearly always determine effectiveness against the current price for them or running price. However their fluctuation means that if you believed there would be a change in price in the future of these prices you might be willing to invest more mining them. I believe that is the reason mining crypto currencies has continued to be popular.

Looking at how slow these miners were though, you would have to expect orders of magnitude increases in prices for it to be worth it.

Step-by-step AWS CUDA litecoin Mining

If you’re so inclined, here’s a snap of the history that it took to get running:

Does it make sense?


If we’re getting 260khash/s and AWS costs $.65 per hour for a GPU instance, plugging those numbers into current value calculator, we get a value of $.001 per hour.


I also tried using the free tier as I had originally thought this could be a good avenue. It was more than an order of magnitude slower, meaning that you would be pulling in less than $.0001 per hour (and there is no cloud space even close to that cheap).

Exponential Growth

If you look at a graph of the difficulty of litecoin:

You’ll immediately notice insane growth in difficulty. Basically, starting in May, Litecoin has turned into the arms-race that directly mimics what happened with Bitcoin.

TL;DR: It might have made sense in early spring this year to attempt to mine Litecoins with either a CPU or desktop GPU, this is no longer true. Barring huge decreases in difficulty and increases in prices, this is unlikely to reverse.

The state of Proxmark

What is the Proxmark3?

The Proxmark3 is fascinating, it has the ability to read and write a wide range of RFID cards, both low-frequency (typically things like door access) and high-frequency (more advanced cards, transit, credit cards, etc). It can also be frustrating, largely due to:

  1. Inconsistent support across OSes
  2. Unclear documentation about identifying RFID cards you find


Mac OS X Mavericks + Proxmark3 == sadpanda

TL;DR: don’t try to work with proxmark3 in OS X, it has just enough support to keep you trying, without enough to actually help you excel

There are no official binaries, and no unofficial binaries for OS X so that means we must to go the source.

To compile make sure you have what is in the COMPILING.txt, some of these are more obvious than others.
For example, libreadline:

brew install readline

This however will not link because some conflicting library is installed with XCode. You want to hijack that, use

brew link readline --force

The ARM compiler is easy to install (according to this thread) via github.com/jsnyder/arm-eabi-toolchain. That thread also advises you to use

brew install libusb libusb-compat --universal

for libusb.

Once you’re pretty confident you have most of these dependencies installed, you can attempt to make the project. If it works, good for you. If not, you’ll spend a bunch of time googling. You will almost certainly have to modify the CXXFLAGS, and QTLDLIBS in client/Makefile. There are a few recommendations as to what these should, it’s unclear which of these which is best.

Hopefully, at this point, you can compile the application. it is run from the client directory via

./proxmark3 /dev/ttysXXX.usbXXXX

Unfortunately, if you’re like me, you won’t have any such devices.

To further compound matters, there is a decent chance that your proxmark3 is actually running old firmware and needs to be updated. There was a pretty big shift in the firmware, it used to use libusb but now registers itself as a COM port. I think these were for performance related; but the result is that older firmware can’t use newer software and vice versa. Flashing the old to new requires a little bit of a hybrid approach combined with witch magic.

It’s all about the Kext’s

There is also another issue looming that you might not realize. OS X is going to hijack your usb connection and not let you use it. The proxmark3 app will complain about not being able to claim the device.
Allegedly, you can use what is called a “codeless kext” to force OS X to ignore a device. That is what is hoped to be achieved with make install_kext. This didn’t seem to work for me. I tried poking around for a bit, Apple has this concept of “VendorSpecificDriver” that is meant to allow you to disable OS X from claiming the device before you can. kextutil will become your friend to get this debugged as you attempt to combine this “VendorSpecificDriver” code with the kext created by the Makefile, in a sweet Frankenstein attempt. As far as I can see, this approach no longer seems to work.

In researching this kext, you may see a bunch of things about requiring signing for codeless kexts. I don’t think this is true, in both this story and my own experimentation, using the /System/Library/Extensions/ folder, you are able to load an unsigned kext. However, I was unable to actually get the kext working with my Proxmark, so maybe there is something else I was missing. I also tried a documented alternative approach to unload the kext that Apple was using: kextunload -b com.apple.driver.AppleUSBCDC (You’ll notice CDC which is the “old” style of communication for Proxmark). No luck.

Stop paddling upstream

It was at this point that I decided I should reassess my approach. It turns out that in this thread, there are pre-compiled binaries for proxmark3 for windows. Awesome.

There are even instructions included about updating from the old firmware, which involves lots of holding the proxmark button down while interacting with the device from the computer. I had to flash the update to the new COM style bootloader and also the “bootrom”, “fullimage”, and “OS”, before the device would be probably recognized even with the new driver.

Installing the drivers was again a bit of a pain, but not too bad.

What does this signal mean?

Once the hardware is setup and you’re in action you’re likely to encounter another problem. How do I read this card and make any sense of it? Unfortunately, the answer doesn’t seem to be super simple. Some LF cards are labeled with things like “HID” or “Indala”, which tells you right away what to use. There also seem to be a lot of cards that qualify as “em4x”, particularly “em410”. There’s a good chance you’re trying to read one of these three, but if it’s not your best bet is to turn to the forums or look for any sort of labeling that can help you.

Here are a few of the commands I seemed to use most:

hw tune
hw version
hw tune
lf read
data samples 5000
lf hid fdskdemod


Be ready for a bit of flakiness, you might have to restart your computer occasionally, or re-plug in the proxmark (frequently). Once it’s reading though, it seems to do it pretty consistently.


Cloning cards is a whole new beast. It seems that many cards are not re-writable, or if they are you can’t use the standard cloning provided by the proxmark software. Again, this is a shame because you will see reference to “t55x7” cards, unfortunately it doesn’t seem possible to easily know what card type you have in your hand.


Generally, the Proxmark3 concept is great. I know how difficult it is to foster a good community that can work across the range of software and hardware necessary for a good Proxmark experience, so I applaud the effort. I hope the tools continue to improve.

I’d really like to see a bit more consistency around OS/driver support, and documentation to aid in identifying RFID cards. Hopefully, I can find time to figure some of this out and put in pull requests to the Proxmark3 repository and help the community.

Do you have experience with the Proxmark3? Does it match mine?

Mymail-Crypt Version 26

I have (finally) pushed a new version of Mymail-crypt for Gmail to the Chrome store (and github).

The extension visually appears and functions very similar to what you’re used, however, it’s got a hugely updated encryption engine underneath.

We’ve been refactoring and improving the Openpgp.js project significantly over the past year. In this version of Mymail-Crypt, I’m incorporating these changes for a better experience.

  • Support for more OpenPGP clients keys — great news if you’ve had trouble with other peoples keys in the past.
  • Better signature verification. There is now a “Verify Signature” button for messages that are signed but not encrypted. If a message is both encrypted and signed, Mymail-Crypt will attempt to verify the signature when you use the “Decrypt” button.

Really, there are a ton of improvements in the encryption library, but most of them are transparent. Now that this has been shipped, there are a number of other visual items and cleanup I’m hoping to turn my attention to.

Let me know if you have trouble migrating, or using the new extension!

Mymail-Crypt for Gmail, version 24

I’ve finally pushed out a new version of Mymail-Crypt for Gmail. It has been a long time coming, but I was able to accomplish a number of the things I’ve been hoping to get finished for awhile.

Major Changes

  • Revived support for disabling drafts. It should work currently under the “New Compose” experience. It is still EXPERIMENTAL, but feel free to give it a go. Note: It won’t work if you pop the compose window out of the browser
  • Re-architected the plugin to provide a cleaner break between the front-end Gmail interactions and the back-end cryptography.
  • New version of OpenPGP.js. This includes a handful of updates. Notably, it bumps up the default Hash function to SHA256.
  • Upgraded to jQuery 2.0. This drops support for old browsers and certain function calls.

It is live in the Chrome Webstore, but should update automatically for you.

Please let me know if you have any issues, or post them to github. Thanks!