Monday, February 3, 2014

Pwning a SafeNET Microdog Part 4 - Emulating the 3.4 (Part 4 - TheFINAL)



To wrap up our discussion of the Microdog 3.4, I'd like to go over a couple of remaining topics:

-   Client architecture.
-   Rainbow table generation via recording dongle responses (Key Dumping)

[Client Architecture]
Of course, a preloaded shared library as in our previous example is hardly an optimal solution.
This solution involves hijacking the ioctl function calls and also requires that we change the calling
method of our program (we'd need to set LD_LIBRARY_PATH or LD_PRELOAD... blech.)

Let's, instead, do this somewhat of how the actual driver does it.

Sparing you the details of how the driver transaction ACTUALLY works (basically ANOTHER packet protocol where all data is sent to the dongle hardware via usb_control_msg with a shifted RNG nonce), just know that its actual implementation for our purposes is useless unless we were creating a custom driver to interface with a real dongle (we aren't).

Instead, let's focus on a kernel module that acts as an endpoint (just like the real driver does) and, subsequently, forwards that packet to another program via sockets to perform the transaction.
For our purposes, I wrote an analysis hook that talks to a python program via UDP sockets and performs transaction analysis and the rainbow table lookup. Note, although this will KIND of work, it's not perfect (I'll let you think about why a protocol that doesn't favor order might be bad for passing transactions back and forth). Fixing this to either force an order via TCP or supporting Unix Domain Sockets (which Microdog 3.4's successor MD4.0 uses) is an exercise that I'll leave for the reader.


[Key Dumping]

We have a couple of different ways to generate a rainbow table by recording the dongle transactions...

Although we COULD write our own driver (mentioned above)... that's a lot of work and we're about getting things done; not wasting time.

Two ways we could do this practically:
1. Hack up a program that does the transaction for us in an OS with the legit kernel module loaded.

OR

2. Compile our own program with the MD4.0 module and keep things in user space to perform the transaction which would be much easier and the results would be the same.

As we're fully comfortable with extracting the DogID and Dog Serial from any client library, we can easily replace these values in an MD4.0 library file, compile, and use DogConvert() like our previous examples to write our requests and responses to a dog.key file like we did before.

Those were the biggest points I wanted to finish up with for the Microdog 3.4 library.

MD 4.0 will be far more interesting (coming soon).