this program will self-destruct in 5 seconds...
-
I realize that you said you want something low effort, but breaking that "protection" will take whole 2 seconds. A simple
touch yourappwill give you 3 more days (or whatever). You might as well show a popup asking to kindly stop using the app after X days and it will be the same level of "security".Sorry to be negative about this but I suggest you either treat this seriously and invest in a real licensing scheme or do nothing. Otherwise it's just silly annoyance and code bloat that achieves nothing.
@Chris-Kawa
I had no idea the OP had said this was anything about licensing? I thought he was just looking for a quick & dirty method for some unknown purpose. -
@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 -
@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.
@Chris-Kawa
Ohhhh! I stopped reading when @mzimmers wroteIf 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.
-
@Chris-Kawa
Ohhhh! I stopped reading when @mzimmers wroteIf 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 wroteIf this sounds crazy, ...
Probably should have stopped reading when you saw my name!
-
@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 ;)
-
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 -
So, as long as we're on the subject...can anyone recommend a lightweight license manager?
-
@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.
-
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).
-
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).
@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).
-
So, as long as we're on the subject...can anyone recommend a lightweight license manager?
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.Read and abide by the Qt Code of Conduct
-
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...
-
@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...
@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. :)
Read and abide by the Qt Code of Conduct
-
@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...
-
@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.
Read and abide by the Qt Code of Conduct
-
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.
