Keygens, Protection, Encryption Panel Software Protection Methods (SIC ‘2004)

1. Keygens, Protection, Encryption PanelSoftware Protection Methods (SIC ‘2004) Chris Thornton Thornsoft Development, Inc. chris@thornsoft.com www.thornsoft.com/sic.htm

2. Anti-Piracy Concerns • The crackers will still crack you. That’s just the way it is. • Strong encryption helps - but a dedicated, skilled cracker can eventually get in. (We used to be cracked within days of a new release - now it’s months.) • Use secondary defenses (integration) with any wrapped solution. • With strong encryption, expect to see more CC fraud, and keys passed around on the net.

3. Strategy • Use blacklisting to lock out stolen keys. • Use Partial Key Verification to detect forged keys. (Absolutely necessary if you don’t use strong encryption.) • Look for keys that seem “odd”. • In any case, don’t simply quit the program. You’ve got a potential customer here - try to sell them. • Goal: Make the crack experience less enjoyable, and use the opportunity to make contact with a potential customer.

4. Blacklisting

5. Piracy Marketing • DaRkAnGeL appears in 4 threads on usenet. • 17,000 visits to my “naughty pirate” in last 6 months. I assume avg of 3 hits per user until they “get it”, so that’s 5666 users. • We tracked 409 of those visits to the order page, using cookies. Conversion rate of 2.3% - 7.3%. Pretty good! • 100 “sorry, won’t do it again” testimonials logged into our FAQ/Comment system. • The “error 411” page is currently ranked #1 out of our about 90 FAQ pages, with about 4000 hits.

6. Partial Key Verification • Don’t give the cracker enough information to build a complete key. • They can only build a keygen against what they see in the program. So, leave some of the checks out, and add them back into future releases. • Each release only checks part of the key (Details on next slide) • Each release of your software requires crackers to make a new keygen. • Users aren’t impacted, as their keys have all correct digits.

7. Example of obsolete keygen.

8. The Mechanics • I use “If SampleKey = UserKey then Registered=True” algorithm. (standard stuff) • To generate the SampleKey, first, I generate 10 “decoy” digits, from the user’s name. • Ex: for i := 0 to 9 do RegKey[i] := (Ord(CleanString[i]) * 2) Mod 10; • Then, in the positions that I’m actually checking, I overwrite the decoys with digits generated by the actual algorithm, leaving decoys in the unchecked digits. • Ex: RegKey[7] := ((Ord(CleanString[1])*3) - Ord(CleanString[4])) Mod 10;

9. Mechanics (cont) • In the previous example, the middle 5 digits are not checked. I don’t check the decoys. • In the next release, I’ll add another digit, and take one more away. Forged keys can now be detected. • Forged keys launch an URL to our “error 511” page, which logs their IP address, the name/key that was used, and the date/time. • But my customer’s keys, generated with all correct digits, will be just fine.

10. PKV with Strong Encryption • Strong encryption (RSA, Armadillo, ASProtect, etc.) usually encrypts some information about the user, hardware, etc. • Add another “layer” inside, so that in case the “main gate” is breached, you still have your secondary “key within a key” to use with PKV. Like an “onion”.

11. PKV Example • my_pkv(“chris thornton”) = 10011101 • Encrypt (“chris thornton” + “10011101”) with strong encryption (RSA, ARM, ASProtect, etc.) • In the program, you have the whole 10011101 sequence - but only check a couple of the digits. • Next version, check another digit. Now you’ve got PKV within a stronger package, and the cracker can never build a complete keygen without a crystal ball.