this program will self-destruct in 5 seconds...


  • Moderators

    @JonB Well, he said

    If this sounds crazy, I can scrap this idea and tell the customer he needs to buy some license management software for us.

    so I assumed it's suppose to be a DRM type of thing.



  • Hi Chris - yeah, you're right. That's why I was hoping for a timestamp that might be built into the app (and not visible through the file system). This whole thing is silly, but the exercise might at least be useful to someone reading this later on.

    EDIT:
    Your sentiment is still valid, but this might obviate the specific problem you identified:

    QDateTime QFileInfo::birthTime() const
    


  • @Chris-Kawa
    Ohhhh! I stopped reading when @mzimmers wrote

    If this sounds crazy, ...

    Now I notice the thread title... :)

    @J-Hilk indicated that your build system may allow inserting a datetime into C++ code being compiled, or similar. That would be better than file time, but nothing like @Chris-Kawa 's proper solution.



  • @JonB said in this program will self-destruct in 5 seconds...:

    @Chris-Kawa
    Ohhhh! I stopped reading when @mzimmers wrote

    If this sounds crazy, ...

    Probably should have stopped reading when you saw my name!


  • Moderators

    @mzimmers You can heave a timestamp no problem. There are __DATE__ and __TIME__ macros in C++ that will expand to current date/time at compilation moment, but it's useless for this purpose unless you plan to compile a separate executable for each customer right before he starts to use it.

    Just go the whole mile and invest in a licensing app/lib that does encryption, passwords, trials and all the shabang. No need to reinvent the wheel. It won't be that round anyway ;)



  • So, as long as we're on the subject...can anyone recommend a lightweight license manager?



  • @mzimmers
    A file's "birth" (creation) time can be altered just as its last modified time can. Any attribute of the file will not be robust. The compiled-in way is better.



  • @mzimmers
    Just one thing: do you have 100 potential sites/users or 1?

    And the second one thing: is your application in a server environment?



  • @JonB closer to 1 than 100. And, I'm not sure what you mean by "a server environment," but the app might have to run without the benefit of network access, if that's what you meant.



  • @mzimmers
    That's kind of what I thought. On both counts I would politely suggest that going down a licence manager route would be unnecessarily expensive/complex.


  • Moderators

    The last lib I had the displeasure to work with was a couple years ago. Something called Armadillo from Digital River, I think, but I doubt it's still available (was horrible to work with anyway). I have the fortune of not dealing with these things anymore so can't suggest anything current or good, so not to be completely useless I can at least offer some insight on how these things work.
    You can stop reading here if you're not interested ;)

    It's kinda complicated :) The licensing software generates a private app key that is embedded in the executable when the app is built. When you buy an app the store or the license giver generates you a second, "public" key that is some sort of encrypted date of purchase value. The app then takes the embedded private key and the license key and uses them in combination to decrypt that purchase value and check whether it expired or not. To stop you from just disassembling the app and skipping the check or finding out the private part of decryption key the "decryption and checking" part is usually heavily obfuscated and spread out across the whole binary (which sometimes tends to mess with optimization and various compiler flags). It's possible to crack it of course but it takes a lot of determination and time. You can then add to that additional checks e.g. online activation, hardware lock etc. but for the simple case it's like that (which still is a lot of work).


  • Qt Champions 2017

    @Chris-Kawa said in this program will self-destruct in 5 seconds...:

    It's kinda complicated :) The licensing software generates a private app key that is embedded in the executable when the app is built. When you buy an app the store or the license giver generates you a second, "public" key that is some sort of encrypted date of purchase value. The app then takes the embedded private key and the license key and uses them in combination to decrypt that purchase value and check whether it expired or not. To stop you from just disassembling the app and skipping the check or finding out the private part of decryption key the "decryption and checking" part is usually heavily obfuscated and spread out across the whole binary (which sometimes tends to mess with optimization and various compiler flags). It's possible to crack it of course but it takes a lot of determination and time. You can then add to that additional checks e.g. online activation, hardware lock etc. but for the simple case it's like that (which still is a lot of work).

    Yes this is mostly correct. Some more notes: Usually the binary unpacks and decrypts parts of itself at runtime, so it acts as a kind of loader. To make matters harder to dissasemble they usually capture all significant signals and hook up into the relevant interrupts so you are not able to attach a debugger easily. This however is breakable (as is usual) by pre-loading the application with your own custom loader, and hijacking back the interrupt and signal handlers. After you have their loader working under yours, you usually patch the binary directly in memory, as reverse engineering the decryption is not worth it so much (again you do that by means of your custom loader).


  • Qt Champions 2017

    PS:

    @mzimmers said in this program will self-destruct in 5 seconds...:

    So, as long as we're on the subject...can anyone recommend a lightweight license manager?

    None is the lightest weight and most secure. There's not one of these systems that can't be broken, the problem is a person with decent skills and a debugger is like a naughty child with matches in hand - you won't be able to stop them. :)
    My best suggestion is to rely on alternative ways.



  • @kshegunov I believe you 100%. The reason I asked for something lightweight is because I don't think our customer really cares about maximum protection; he just wants to create a discouraging nuisance for the casual would-be offender. This is why I was looking into some kind of a timestamp comparison, but as others have pointed out, this may be a little too easily defeated.

    This has turned into a much better discussion than I originally hoped for...


  • Qt Champions 2017

    @mzimmers said in this program will self-destruct in 5 seconds...:

    The reason I asked for something lightweight is because I don't think our customer really cares about maximum protection; he just wants to create a discouraging nuisance for the casual would-be offender. This is why I was looking into some kind of a timestamp comparison, but as others have pointed out, this may be a little too easily defeated.

    The problem is if you don't do what Chris said (and I added on) cracking it for the causal would-be offender is borderline trivial. In the end the binary is what is executed, so you need to protect the binary from outside intervention, meaning you have to in some fashion discourage people from attaching a debugger (i.e. loading it or parts thereof yourself and disallowing the different debug APIs and/or interrupts and signals) and stop them from patching it directly as it sits on the hdd (i.e. load and decrypt parts of it in runtime). Everything else is either too simplistic or not time-consuming enough. Unfortunately as Chris said, the downside is it bloats the code and makes it run significantly slower. In my mind it's just not worth it ... but then again, some people seem to disagree and stick to it; then they wonder why their releases are cracked in a matter of days and appear on the torrent trackers. :)


  • Moderators

    @kshegunov said in this program will self-destruct in 5 seconds...:

    then again, some people seem to disagree and stick to it; then they wonder why their releases are cracked in a matter of days and appear on the torrent trackers. :)

    I don't think anyone wonders that anymore. I work in the gaming industry so that's something close to my heart ;) Other types of apps have different needs, but for games at least it's not so much important to never be cracked (as it will happen anyway and often sooner rather than later) but to not be cracked long enough for that to matter. The most sales of big AAA games happen in the very short window of few days or weeks maybe and basically that's the target of DRMs these days. If a game is cracked after few months the DRM did its job - it protected the sales in the most vital period. It's common that games come out with a strong and intrusive ugly DRMs just to carry them over that time, after which they switch to something lighter in a following patch (sometimes described as "optimized performance" in the patch notes :P ) or down right drop DRM entirely.

    Just to be clear, I hate those things, as they literally shit all over the carefully crafted performance characteristics of an app without any regard whatsoever, but I kinda begrudgingly understand the unfortunate need for them. Ugh, the world we live in...


  • Qt Champions 2017

    Let me give you the consumer-side narrative then. As I do buy and play games when I have the time to spare.

    It's a vicious cycle, as the more time and effort you put in that DRM the more costly it is, the more costly it is the more you bill for your product, the more you bill for your product the more people (especially ones from my easternly fringes of civilization) have incentive for cracking it; that is they're willing to invest more effort into it, thus they do it rather quickly.

    I can happily say, though, that even slowly the tide is turning somewhat. I can now afford to buy games, in contrast to some shady misspent periods from my youth, and I do understand that developers actually need to eat. I vote with my pocket, however, as the saying goes. I am not spending some 120 EUR on AAA titles. Instead I find a good game from an independent developer and pay them 20-30 bucks for their good product. I have a ton of fun and they have my money to feed themselves. True, it may not be the greatest looking game, but looks is not what makes a good game. Many of them indi devs actually allow for their games to run on Linux (big thing for me) and consequently don't have the DRM in it. So they cut the cost on that level. Additionally not being pulled down by a suffocating millstone of a marketing division, the devs don't need to feed those good-for-nothings too ... ;)

    I would buy AAA games only on massive sales, much, much after their prime sales only. I actually bought one of your countrymen's best (yes, I mean CD Projekt's Witcher 3) last year, and it's a damn good game I admit, but I can't (and will not let myself) afford the insane cost at release.

    Also DRM can kill a game, and even a franchise. If you look at what EA did with the Sim City series ... it was one ungodly mess.


  • Moderators

    @kshegunov said in this program will self-destruct in 5 seconds...:

    If you look at what EA did

    Ugh, don't even start me on EA ;) Yeah, you and I think alike. Unfortunately we're in the percentile of a percentile and that sort of thinking is not what runs this industry. Linux gaming for example, while growing, is an absolute margin that, if disappeared over night, would hardly put a dent.

    I think we sorta hijacked the thread. Sorry @mzimmers , I'll go play some games now :)



  • Heh...no need to apologize; after all this is The Lounge. I'm enjoying the dialog. But...I fear I'm no closer to knowing what to do than I was when I started this thread. But, as the saying goes, even though I don't have a solution, I certainly do admire the problem.


  • Qt Champions 2017

    As an inept apology for my usual tangential missives I tried to summarize your options:

    I see only three things you can do:

    1. Convince the client, the boss or whoever it is that requested the DRM that they don't need it. (Optimal in my eyes)
    2. Get yourself a DRM system from a respectable provider. This is costly but the right thing to do if you really have decided (or someone has for you) on it. (A compromise of sorts)
    3. Write something yourself just to satisfy the requirement, knowing it'd end up as half-botched of a job and I don't mean that as an insult, so please don't take it as such.


  • @kshegunov good advice.

    (Boring details which I originally omitted to follow)

    The customer didn't ask for DRM specifically; he just wants a way to limit end-user access to certain functions. My company makes POS and VOIP products, and we distribute Windows based utilities to our customers for configuring our products. The customers may elect to re-distribute these utilities to their customers (the end users). So, our utilities have three modes of operation:

    • factory (full functionality)
    • customer (can't change MAC address or serial number, etc.)
    • end-user (minimal functionality)

    So...now our customer wants to allow the end user to update some security credentials that are stored in our products. But...he doesn't really want to let them do this; he just doesn't see an alternative. So, we kicked around this idea of giving them a version of the utility that would let them do this for a limited time (like 3 days). So...the purpose of this thread was to explore possibilities along those lines.


  • Qt Champions 2017

    Do your utilities require internet access to operate? If so, offloading some key operation(s) to your server might be a way around. That way you have some control over what can and can't be done by the end user, while you don't need to actually go the extra mile (effort and cost-wise) including a full-fledged DRM. I mean it's not a silver bullet, far from it, and I'm not convinced if it's applicable to your product but it's an alternative of sorts.



  • @mzimmers
    I'll be brief, as I may have missed the point or what I say may not be suitable.

    If you want DRM, or you think customers/end-users will want to hack, or you can do @kshegunov 's server, those are all fine. I'm only offering if you want some possible dirty method to achieve in code.

    If I understand right, you want your software to offer some functionality to an end user for just a few days from a certain date, then it disallows that functionality.

    So, is giving/distributing a "key" to end users viable? I have no idea.

    If so, your software requires a key (set of digits), which they type/put in a file/shortcut/whatever. Your key encodes some bits enabling/disabling various functionalities with bits of the date you want it to start/end whatever, plus obviously some validity checksum bits. You have to generate these keys at your end, or the sub-customer's end. At runtime it reads the encrypted key, compares its date to today's and enables/disables functionalities.

    Like I said, no question it's not "secure", one end user could pass his newer key to another end user. It doesn't scale if you have lots of end users. Etc. etc.



  • @kshegunov

    I am not spending some 120 EUR on AAA titles
    (yes, I mean CD Projekt's Witcher 3) last year

    Look: all I know is Steam says The Witcher® 3: Wild Hunt is currently £7.49 which is like €7.49 these days, so it can't have cost €120, or your €s are different from other peoples' €s! Unless you're not PC but game-station-thing, which I know nothing about...


Log in to reply