Quote from rufus_4000:
First of all, very few things would stop a very determined technologist from reverse engineer the strategy if you provide any executable to them. But never the less, there are some approachs for the paranoid.
1) Write your software that require the presence of a physical key (i.e., a secure USB dongle), and then *take* the dongle back after 30 days. This can still be spoofed via virtual device drivers that just records the challenges, and play it back. And it is a huge pain to code to any GSS-API based token library. I have something like this for my own system, but I don't even distribute any part of the object code.
2) Write your software that require the user to be online, so that the software need to contact your "mothership" server everyday upon startup for "challenge", if it does not challenge successfully, then intentionally corrupt the executable (!). Similarly, this can be defeated via properly analyzed spoofing.
3) Probably simpler, just load up your software onto a laptop, lock down the laptop (no CD access, no usb access, all network ports except the permitted ones), give them the laptop, and then only give them a low acces level login (password set to expire). Again, this can be defeated via just a standard O/S attack, possibly via network scanning and stack breaking.
Basically, this just makes the effort of breaking your system harder, it doesn't make it impossible.
Interesting post. Is this valid for any operating system?