This one... this one's gonna be fun. For obvious reasons, I need to keep this pretty generic due to things I've worked on in the past that utilize this hardware. Will it help you further work with those? Probably...
Right now, I'm looking at three parts for this one - the first part is going to be an overview concluding with our first exploit. Okay? Let's dive in!!!
The SafeNET Microdog (originally owned by Rainbow China) is a usb and LPT based hardware dongle pretty popular for low cost and its wide range of cross-platform/language capabilities.
To summarize the hardware:
- 200 bytes of flash memory that a dev can read/write.
- Password to set read only modes.
- Timeout for anti debugging
- Unique Serial Numbers
- Unified ID numbers from the factory (to ensure a dongle only works with its libs)
- Embedded Cryptoprocessor (contains special hashing program)
- Multiple dongle daisy chain (cascase system)
There are 3 Parts:
The dongle is accessed via either USB or LPT through a driver or user space daemon (depending on version). Payloads are sent to the dongle after authenticating to ensure only trusted sources communicate to it. The transaction passes data between the dongle and the driver/daemon.
Older versions of the Microdog SDK (version 3.4) use a kernel module (usbdog.o/ko) for linux that makes calls to the hardware, decrypts transactions from the client library in the program, sends data back to the program, etc.
Newer versions of the Microdog SDK (version 4.0) decided that only having certain kernel modules compiled for certain kernels was a horrible idea (as SafeNet/RC don't make the source code for their driver available for obvious reasons). As a result, they now use a user space daemon that communicates with the program via unix domain sockets and the dongle via standard usb control messages.
Windows has always done the driver route and doesn't appear to change.
Protocol of the packets to the driver are unchanged regardless of the version (we'll get into that in a later part).
The Client Library
The main point of entry for a developer. Basically, you get a .h file (gsmh.h) and a mhwin.lib/mhlinux.o file to compile with your program. No source is included (obviously) and is basically set up like a black box. From this library, you can change the password, write to the dongle's flash area, get the manufacturer serial number, get the vendorID of the dongle, or (what most people do with it) convert any stream of bytes to a 4 byte response.
Basically, the main purpose of the dongle for obfuscation is DogConvert() - a function that hashes input data with its cryptoprocessor into a 4 byte response. Obviously, 32 bits isn't all that secure and Microdog expects you to do something else with such a primative, but I digress.
So, where do we begin with exploiting this thing? Let's start with the client library :)
Hacking the Client Library
In normal operation, you can't use any old Microdog with a particular program. Also, you can't simply use any dongle with any client library - you need the client lib from the manufacturer when you set up the dongle originally. Let's change that so we can use any Microdog (given a program it was used for and any client library).
By comparing these two client libraries that have been initialized, we can see the only difference is this block:
This is called the DataPool in unstripped libs - it contains encrypted metadata about the dongle (VendorID, internal IDs, etc). By copying this data over a program in the right spot (it's pretty easy to find in something compiled with the client lib), the target should now communicate with the dongle (although no converts will work right unless the last 4 bytes of the internal memory are the same as that determines the hashing algorithm).
Just copying it isn't interesting, however - let's actually decrypt it and see what's up:
As a note - mhlinux.o normally has the key located at 0xB500 for MD4.0 libs.
Essentially, it's a 112 byte sequence where the first 16 bytes are an IV, then 80 bytes of cipher, and 16 bytes of a key. Ripping through the client lib will pull up a number of functions that look suspiciously like Rijndael signatures - that's because it is. Basically, all these 16 byte rows are AES encrypted - decrypting them gives the plaintext that was embedded from the dongle at setup. From here, we can see the vendorID (the only value we need to make the dongle think we come from a trusted program).
This leads to another exploit - if we call the device descriptor of the dongle, we can get this vendorID - by replacing this value and then re-encrypting, we can use a dongle with any program without having a program it was originally used in.
In short, we can now talk to any dongle we have around with a generic client library which will come in handy when we start talking to dongles to emulate them and use them for other exploits soon :)