libhasp: Repurposing a copy-protection dongle for general-purpose data storage

Way back in 2004, I spied an offer in Circuit Cellar magazine for a free evaluation kit from Aladdin Knowledge Systems (AKS), manufacturer of copy protection tokens. These are the little gadgets that you often need to plug in to your computer to prove that you ”really” own the particularly expensive application you’re trying to run.


The goods

Anyways, the offer boasted…

  • A HASP HL “Time” dongle with built-in AES, host-accessible 4kB EEPROM, and “tamperproof” real-time clock (RTC).
  • A cross-platform SDK with libraries and example code in C and a handful of other languages.
  • Printed API documentation.

After pestering them with a few emails over the course of a week, AKS sent me the kit and it arrived just in time to distract me from the first round of exams during my Senior year `X|`

The SDK includes a demo application which can…

  • Read/write the token’s EEPROM.
  • Ask the token to encrypt/decrypt data with its key.
  • Read the RTC.

The hack

To prevent its use in a commercial setting, AKS hard-codes the encryption keys on its evaluation kit tokens.

So, I set out to make use of one of the ”un-crippled” features: the on-token EEPROM. Claiming 1,000,000+ read/write cycles, it seems like a nice place to store ”my own” encryption keys or perhaps store two-factor authentication data.

At the time, Miklos Szeredi had just released his Filesystem-in-userspace (FUSE) framework thus extending the Real Ultimate Power(tm) of the *NIX “everything-is-a-file” paradigm to mere mortals1.

I hacked up the demo application to implement a bare-bones FUSE filesystem – one which provides a single file, `hello`, backed by the token’s EEPROM. I call the result “haspfuse“.

Here are its limitations. See the haspfuse code for details.

  • The filesystem only supports a single file. This wouldn’t be too bad if you were to stack a fuse-zip or archivemount-based tarball-backed filesystem on top. Don’t even think about JFFS(2) or ext2 – they each require more than 4kB for a single block.
  • The single file has a fixed size of 3584.
  • No operation besides: `getattr`, `readdir`, `open`, `read`, `write`, `truncate`, and `chmod` is supported.
  • The filesystem probably isn’t “eject-safe”. See FUSE’s `direct_io` for a starting point.

The blob

Additionally, a proprietary blob “driver” named `aksusbd` and a static library from the SDK named `libhasp_linux.a` are required. I had trouble with version 3.5.0 so I included v1.8.1 with the haspfuse code.

`aksusbd` is a userspace driver that employs usbfs to interact with the token. Unfortunately, the deprecation of usbfs is apparently now complete with the release of the Ubuntu kernel. This means that the old standby methods for re-enabling it no longer work.

You’ll need to use a custom kernel with usbfs support, or better yet, develop an open source driver for these tokens!

The latter approach would be especially helpful because my friend Bob claims that “`aksusbd` is setuid root and full of vulnerabilities”. But that’s another story…

Be aware that various AKS licenses and draconian US laws may prohibit you from reverse engineering `akusbd`.

What Bob and I learned

  • Filesystem design for severely space-constrained storage devices.
  • How to build a virtual filesystem using the FUSE C API.
  • Methods for rebuilding ELF symbol tables and the idiosyncrasies that result when the binary is dynamically-linked and uses the Native POSIX Thread Library (NTPL).
  • The software tools available for USB protocol reversing.
  • The myriad sorts of implementation failures that lead to “cracked” hardware tokens.

Further reading

  1. Well, mortals too squeamish to run Plan 9 as their every-day operating system ;] []

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Be the first to leave a comment!