Anti-anti-trial-period
I've built a prototype of a trial-period system for a shareware. It refers to a certain hidden file to check its valid range of date.
Here's the problem: Is there any way for regular users to track down to the hidden file by analyzing the file access behavior of the program? If so, where can I find/how can I build a PoC for it? My project is for Mac OS Xs.
By the way, I Googled these combinations: "mac file access debug" "mac monitor application behavior" "mac file access monitor" "mac program track file access"
I don't know any debuggers other than gdb. If you can introduce me some other good debuggers, I'd appreciate it.
Thanks in advance.
Using a hidden file to track validity is not the way to go. you need to hard code in a variable that carries the installation date and the expiration period. The "hidden file" can be easily modified. Then again, the shareware date bit can be as well. However, this is far more secure than a simple file. That is just my opinion, lets see what others have to say.
quiet interesting thoughts, storing them online would mean someone could access it too perhaps set up a hosts file and run a local validater.
In unix( mac is unix like) lsof shows all open files, not to mention someone could just do a directory listing showing hidden files?
This seems ott maybe, but how about using RSA to encrypt the information from a server, then it couldn't be simulated offline. Unless you changed the programs public key…. idk I'm not very good at this.
Thank you all for the replies. I guess I'll stop going after the system time as MoshBat mentioned - it's way too simple.
Validating via the network is deceivable, like always.
I might try to hardcore it into the program.
Case closed, but any more thoughts are welcome.
Oh, and Wolfmankurd, thank you very much pointing out the "lsof" command. it was VEEERY helpful.
Surely it would be easier and better to allow the program to be started a certain number of times?
Failing that, the hidden file idea could work, just as long as you use a hash function to validate integrity. You could use a unique, hardcoded variable, along with some other program data and the expiration date, and hash them. Put that value in the file, and check it on launch. You can even make it visible, it doesnt matter if a 'hacker' can see it, what matters is that they can't change it without corrupting the hash check. If a hash doesnt check out you can just exit the program. Job done :)
Of course, bypassing most protections is possible with apps, but it's not like a network solution is any safer, or easier to implement, what it the user wants to use a program when they're not connected to the internet?
The effort should only justify the value, theres no point building mad security for a $20 program.
jjbutler88 wrote: Of course, bypassing most protections is possible with apps, but it's not like a network solution is any safer, or easier to implement, what it the user wants to use a program when they're not connected to the internet?
Activation via telephone.
The effort should only justify the value, theres no point building mad security for a $20 program.
There is. Code is reusable, recyclable. You're not building "mad" security for a twenty dollar program, you're just building "mad" security that can be implemented with any number of programs.
So you would have users of a $20 program call a number every time they start a program?? That's lunacy, plus the cost of keeping something like that running. It makes no sense, and costs loads of cash. Back to the drawing board mate.
If you are building something modular and reusable, then perhaps using asymmetric encryption is the best way, just include a signed certificate in the program.
However, I suspect you will not want to set up a PKI, and will opt for a local mechanism. If it were for widespread commercial use, then the asymmetric option becomes more feasible.