0

I'm writing a C# Windows Forms application and will have Trial and Full versions. For the Trial version, I would like to provide the end users daily usage credits (i.e. 3 credits to use particular functions in the app per day)

I have seen numerous articles and discussions to prevent system date tampering, but all of them I've seen were for providing Trial periods; against altering the system date to a previous date. Here are some:

https://www.codeproject.com/Articles/1101956/Check-for-Clock-Tampering-to-Extend-Licence-Durati https://stackoverflow.com/a/16530146/3350921

But in my case, I have opposite business case. If the user tampers system date by fast forwarding to a future day, then might easily gain usage credits just by changing the date. And obviously, I don't want this.

Would you have any recommendations as a rule of thumb how to check date tampering in a C# Winforms app, not only for backwards but also in forwards direction?

Ps. I need to achieve this completely offline. NTP or an external API call would be a good solution, but this app will probably be used mostly in offline clients.

Ps2. I was thinking to check "last modified time" property of a particular system file of Windows OS. For example, if there's such a Windows system file that gets its "last modified time" updated each time Windows is reboot, then I feel like I can recognize the system date fast forward. Any thoughts with this?

saygley
  • 430
  • 7
  • 12
  • Instead of checking against a clock you could perhaps create an internal timer for the time it's used? If someone leaves the application on while afk you might want to add some kind of pause function while it's not being actively used. – Vinnie Novido Jan 27 '20 at 15:18
  • @saygley, interesting, you can implement your own timer, which is based out of system.time during installation. When your app is closed it can write the last time to a registry in encrypted format, and when your app is launched again decrypt and read from it and resume the timer – Clint Jan 27 '20 at 15:19
  • 5
    Unless you can check an authoritative time source online, it's going to be impossible for you to differentiate between the case where the user turns off the computer for two weeks, and the case where they reboot to the BIOS and set the clock forward two weeks before rebooting. – Matthew Watson Jan 27 '20 at 15:21
  • 2
    @saygley there's a reason all copy-protection systems get broken. If you can't store license status yourself, the end users can *always* break it. File modification dates don't change unless the file is modified. You can keep your own timer and encrypt it, but a savvy user could use eg ProcMon to see what the application does when it starts up. You could obfuscate this by doing various random operations, modifying multiple files etc. but .... so did games in the 1990s and 00s and they were still broken. – Panagiotis Kanavos Jan 27 '20 at 15:22
  • 1
    Someone can always use a decompiler to see how your protection code works. You can obfuscate this, perform lots of random operations but again, so did games in the past. Besides, obfuscation often introduces its own, hard-to fix bugs. – Panagiotis Kanavos Jan 27 '20 at 15:24
  • It's simply impossible if the program has to ru completely offline, as the user always can modify everything in their own systems. You can add some validations, but even using online checks you can't ensure your copy protection won't be bypassed. – Alejandro Jan 27 '20 at 15:26
  • @All, thanks for the points, but I don't look for an "unbreakable" solution. I am aware of obfuscation, licensing and other aspects. I just need to see different perspectives how such sort of mechanism could be. I don't need a perfect system. – saygley Jan 27 '20 at 15:43
  • 3
    Then your question is a classic opinion-based one. There's no end to inventive ideas to implementing DRM/copy protection, also no end to people with opinions on it. The quality of each method is strictly relative to how well-known it is and how well-motivated the people are who want to circumvent it. As a first rule of thumb, a user who is an administrator on an offline machine is in complete control, and your software is not, and will lose. Be as clever as you feel comfortable with (as in, "surely they won't do THIS"). Who knows, you might even be right. – Jeroen Mostert Jan 27 '20 at 15:51
  • @JeroenMostert I'm okay with "that much" of breaking. – saygley Jan 27 '20 at 15:54

1 Answers1

1

Many of the comments say that managing it locally is not fool-proof, by that analogy so is any software that is developed however I have to admit that things are not so easy when you're sandboxed to a local pc that user has complete control over.

The question here is how many layers are you willing to add to make it difficult to break. And what's the software's tolerance to environment modifications, which comes with cost of UX. With many layers of security and least tolerance. With that you have hardened it pretty well.

Some of the Security layers I can think of :

  • Encrypting the timer logic in a Registry hive as Binary value.
  • Look for events in the event viewer for any specific change that you suspect relates to tampering of a system property. (Changes to system date can be caught here)
  • Implementing a service that auto starts (If you want to monitor something)
  • Watch out for decompilers and terminate license, invoke auto-delete if necessary
  • MacAddress of known PC's that have been suspected to breach the software (this can be stored and sent back to the remote server when internet connection is next established)

You can set the tolerance level which is how your app responds to suspected manipulations.

Example: If you suspect that there was an attempt to stop your service or manipulate/delete registry, you can either warn or terminate license or what ever counter measure you want to perform.

Disclaimer : Some of it can be intrusive, that's the trade off you have to sacrifice

P.S:

I'm sure there are more ways of hardening it, what are your thoughts

Community
  • 1
  • 1
Clint
  • 6,011
  • 1
  • 21
  • 28
  • Your answer assume what software does changes to the system. Taking snapshot of system before installing software, then using it, then restoring - now if you run software it behave like it was never been here.. – Sinatr Jan 27 '20 at 16:05
  • Any layer on its own is not of much help to impact the over all security, its when they act in tandem they realize the potential – Clint Jan 27 '20 at 16:08
  • Dear @Clint, first item of your list would be the most cost/benefit efficient way for my need. The question I couldn't solve is how I should build such "timer logic". Obviously, I should depend on datetime values stored in the computer; and I was thinking the most reliable values would be the "created / last modified" info of files used by Windows OS, maybe for its boot process. **I don't look for a "perfect" / over-engineered solution, I just need some logic that is difficult enough to break for many of the regular users.** Of course, I'll encrypt / obfuscate relevant data / code after all. – saygley Jan 27 '20 at 18:59
  • @saygley, you can let me know here once you have posted the exact question for **"Detecting datetime using values stored in the computer by windows OS"**. And if you think the answer on this post has given you an over view, you can mark it as answered so it serves as a reference for others in the community with similar question. – Clint Jan 29 '20 at 06:06
  • Hi @saygley, Is there any edit you want me to make to this answer to make it answer your question better, let me know I would be interested to know – Clint Jan 30 '20 at 18:09
  • Hi @Clint, thanks for being nice and your efforts to answer my question. Nevertheless, this specific answer unfortunately does not answer my question. I need specific advise how to build such logic, using the Windows specific files used in boot process. Maybe your point is correct, I should create a new question on that; but I don't want to do that as of now. – saygley Jan 31 '20 at 13:00
  • Hello, okay yea no probs – Clint Jan 31 '20 at 13:19