this program will self-destruct in 5 seconds...
-
@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. :)
-
@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...
-
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.
-
@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.
-
As an inept apology for my usual tangential missives I tried to summarize your options:
I see only three things you can do:
- Convince the client, the boss or whoever it is that requested the DRM that they don't need it. (Optimal in my eyes)
- 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)
- 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.
-
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.
-
I am not spending some 120 EUR on AAA titles
(yes, I mean CD Projekt's Witcher 3) last yearLook: 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...
