Dongles are NOT dead! (programmers: use them!) by Jack of Shadows 21 February 1998 project 3 page
Back to project 3
Fravia, hi! I was stimulated to write you mail while reading the article Dongle Bashing (quite nice, by the way). I must definitely agree with Frog's print that most commercial producers don't use their brain in building the program protection but I definitely disagree with idea that dongles are mostly useless. You just have to use them the right way. So let's take a look at how the dongles could be used correctly. First, I must admit two things. My dongle knowledge is intimately connected to German producer FAST and their Hardlock E.Y.E. (very nice dongle, really). My protection writing knowledge is so far tightly connected to DOS (real and protected mode). I hope that my ideas could be implemented in Win32 (I will found this out in the next weeks ' update follows if you think it will be interesting reading). OK, let's set up some basic rules. I won't talk about time protections etc since mostly anything that could be said about that had already been said. Let's just say that we would like to distribute some crippleware over the Net and be later able to activate its functions with a key. That way we could put a 'fully' function version of our latest program on the net with the only one 'feature' that save, print, export' functions are disabled. Registered users would receive the key which would enable those functions. When designing a protection system I follow the first rule of cryptography: 'System is only secure if you can distribute its source code, operation principles and all knowledge that was build into and still nobody can crack it'. If it is working for cryptography it must work for the program protection also. So let's take a new look at the protection along those premises. Let us assume that cracker will have access to the program assembly code (no problem those days thanks to IDA), could trace the runtime behavior (no problem thanks to SoftICE) and would be able to trace communications between dongle and program (no problem if we use another computer with two parallel ports and appropriate software). If the disabled functions we were talking about before (save, print') are present in the program, we can be sure that cracker will find them and activate them. OK, so they must not be present in a usable form but must be somehow encrypted. And we have a right tool for the job - dongle! As I have said before I don't know other dongles but Hardlock works along quite an interesting principles. Basically it encodes any 8 bytes you send to it and returns 8 encoded bytes. Encoding functions is bijective so we can send resulting 8 bytes to the dongle and receive original 8 bytes. Hardlock can therefore server as encryption function. Even nicer property is that FAST builds into every Hardlock the customer number of its buyer. Keys with different customer numbers behave differently when coding/encoding. So nobody can buy a key at FAST and use it to crack your program. Now you probably have a pretty clear picture what I have in mind. Mark a functions that have to be disabled in source code. Compile the program. Encrypt marked functions with a dongle. Put program on Net. User without a dongle has no way of guessing the code for missing functions. Add a dongle and program becomes fully functional. Probable ways of attack: 1. Guess what first few bytes of a function must be and guess a dongle function. Pretty small chances but maybe possible. Can be easily defeated by prefixing functions to be encrypted with a few random characters. 2. Buy one copy of a program and crack it so you can use it on more than one machine at the same time. Much easier but can still be made a tough problem. Let's see how a fictitious cracker can attack our program. a) Log all communications between computer and dongle. Make EPROM with data/encrypted data pairs. Add a processor and some logic and package it into a dongle. Countermeasure: don't just decode the program through the dongle but keep the constant flow of random data interleaved with the real encryption. Make this data pseudorandom (always use the same seed) so the cracker cannot compare data flow from two program executions and eliminate random data. Remember some of the returned data, send it through dongle later and compare the results with original data. Use your immagination. b) Wait till the program is decrypted and save in-memory copy to the disk. Write a loader for this copy. Countermeasure: don't decode whole program. Decode some parts when you need them and encode others at the same time (remember, decode and encode are really the same function!). Repeat. It is still possible to crack this program since you have to keep track of which part of the program are encoded but the problem is very very complicated. c) Maybe some other form of the attack I couldn't think of' Similar way of crippling the program can be used without a dongle. Encrypt part of the program with cryptographic strong function. Use the key to decrypt the program. Key is never compared to anything which is good but is the same for all users which is bad. Alternatively: user must send you some ID that uniquely represents your computer and which is generated by the program. You return to the user some unlock code. He enters the code, it is in some way combined with the computer ID and the result is decryption key. Program is not saved to disk in decrypted form, of course, only the unlock code is remembered (in open place since it is of no use on the other computer which has different computer ID). Much less safe then dongle since you must hide and protect the mechanism which combines computer ID and unlock code but still pretty safe. If we take this to the limits, the whole program can be encryped. Startup code uses a fixed key to decrypt and run the program every time (resulting program can still use all the tricks mentioned above) so this is no protection in itself but just a weapon against disassemblers. Be that enough for today. Publish if you think this rambling of mine is of any interest to your faithful readers. Jack of Shadows

redhomepage redlinks redanonymity red+ORC redstudents' essays redacademy database
redtools redcocktails redantismut CGI-scripts redsearch_forms redmail_Fravia
redIs reverse engineering legal?