views:

66

answers:

3

Hi, I have a DLL which I intend to send to a 3rd party and I'd like to protect it by restricting it to run only if a specific USB device is connected. I'm using the setupapi to get the device's serial number (by calling SetupDiGetDeviceInstanceId()).

I would like to make the verification hard to track in case someone disassembles the DLL. for example, a simple call to SetupDiGetDeviceInstanceId is trackable and if someone wants to use my DLL without the proper serial from the USB, he could easily look for my strcmp in the assembly code and change if(strcmp(...) == 0) to if(strcmp(...) == 1).

What would be a good (and preferably "easy") approach for protecting my code against reverse engineering? Is there maybe a different API (other than setupapi) I could use that would take care of that?

Thanks in advance!

A: 

In my opinion it cannot be easy for you and hard for the 3rd party. An id check is too easily found and disabled. I would try to move some essential, hard to figure out computation of your DLL into the external device.

Peter G.
+2  A: 

I find restricting software like that usually comes and bites you later. The work of finding a way to implement it in a "fool proof" manner is often underestimated and could also unintentionally cripple the product in the end annoying legit customers. Better to instead to provide good support and do frequent updates. Any protection can be circumvented so I wouldn't spend too much time on that.

Anders K.
Though I answered as the OP asked I have to agree with Anders. We had a commercial SAN which only failed because the licensing USB key failed. Of course we had no replacement key at hand.
Peter G.
+1  A: 

You clearly cannot just read the serial number and compare to a known-good value -- that's trivial to find and remove.

To make things a bit more difficult, use a cryptographic hash (e.g., SHA-256) of the serial number to a cryptographic hash of the correct serial number. Make sure the code for the hash is generated inline, so you a fairly large mess of "stuff" between reading the serial number and doing the jump based on the comparison of the hash value. This won't stop a determined attacker, but it'll stop most people who just glance at the code in a debugger and aren't willing to spend a lot of time on reverse engineering it.

If you want to make things more difficult still, store some of your code in encrypted form, with the correct serial number as the key. At run time, read the serial number and use it to decrypt the code. If it's wrong, the result will be bad code, which you can either execute as is (knowing it will quickly crash and burn) or you can do some sort of checksum to verify the result, and fail a bit more gracefully (i.e., display an error message and die) if the code didn't decrypt correctly.

Jerry Coffin