MIDI Programs
MIDI File Player (External Device)
MIDI Destination Pop-Up Button
Other Programs
Cocoa Sample Programs
Syntax Coloring Using Flex
Algorithms
Jazz Chord Analysis as Optimization
A blog where I will write mostly about programming in Cocoa and CoreMIDI, and experiences from my ports of Emacs and XEmacs to the Mac OS.
| Software Protection Literature |
I’ve almost finished adding software protection to my shareware program. Because the security of techniques I’ve used depends on obscurity to a great extent, I cannot really write about specific details. I can however share some of the references to the literature from which I got the ideas to develop them.
I wrote a series of blog entries back in January (from Jan. 9 to Jan. 24) with my commentaries on a number of papers on software protection. I also wrote about the use of public key encryption using elliptic curve cryptography to implement license keys during the week of Nov. 7. I wrote an entry on anti-debugging on Nov. 24.
Last week, I found a web page with references to recent articles on software protection. The problem with academic papers on software protection is that they make many assumptions that aren’t realistic (hey, I know all about making such assumptions :-)). Claims that a certain method is secure because it’s based on the undecidability of alias analysis, for example, are really quite meaningless because they assume a particular method of attack (static analysis). NP-hardness results on code obfuscation also have similar problems because they assume that it is the objective of the cracker to understand an entire program or algorithm. Of course in practice protection of a program may rest on a small section of code that checks the license key, for example. And don’t get me started on code obfuscation: really just a collection of arbitrary and ad hoc tricks, many of which can be defeated by dynamic data-flow analysis tools.
Articles written by crackers (this collection and this other collection, for example) are usually anecdotal: i.e., “this is how I cracked program X”. I also don’t believe the best crackers will give away their most useful techniques. These articles are not always interesting to read because many of them trace through the steps used to crack a program. Most of these articles can be summarized in a few sentences: “the programmer has forgotten to do ...”.
I believe the conclusion one must arrive at after studying the (practical, and not academic) problem of software protection is that the more effort one puts into adding good protection measures into one’s program, the more effort crackers must take to crack it. That’s really the best a program developer can do. And that’s why it has taken me such a long time to work on this part of my program, which I can’t write about...
| Sun | Mon | Tue | Wed | Thu | Fri | Sat | |
| 1 | 2 | 3 | 4 | • | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | ← |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | • |
| 26 | 27 | 28 | 29 | 30 | 31 | ||
| Nov Jan |
Lists
Less-Known Facts About Emacs
Chinese Restaurants in Calgary
Calgary/Banff Tourist Attractions
Top-10 Reason I Stopped Working on Emacs
Misc