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

mzimmers

I forgot to mention, this needs to run on MacOS.

JonB

@mzimmers
Let me get this right. You want a way to know the datetime when an executable was built, in as simple a way as possible? Approximate will do. We don't want to put a timestamp into the code at build time. So what about just looking at the last-modified time of your actual executable application file at runtime?

mzimmers

@JonB that should work!

QDateTime QFileInfo::lastModified() const

Thanks.

JonB

@mzimmers
Yes, it's pretty simple if it suffices. I forget which call, but Qt library I think can give you full path to currently running executable for passing to QFileInfo.

mzimmers

@JonB oh that would be nice...it would save me the trouble of passing argv[0] into the widget, and needing a delegate c'tor and other stuff. I'll look for that, and post it here if/when I find it.

EDIT:

QString QCoreApplication::applicationFilePath()

Let it never be said that Qt does not rock.

JonB

@mzimmers
argv[0] can be changed, does not have to be path. This function tries a bit, be aware of:

Warning: On Linux, this function will try to get the path from the /proc file system. If that fails, it assumes that argv[0] contains the absolute file name of the executable. The function also assumes that the current directory has not been changed by the application.

May use a native call under Windows, I don't know.

Chris Kawa

I realize that you said you want something low effort, but breaking that "protection" will take whole 2 seconds. A simple touch yourapp will 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.

JonB

@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.

Chris Kawa

@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.

mzimmers

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

@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.

mzimmers

@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!

Chris Kawa

@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 ;)

mzimmers

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

JonB

@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.

JonB

@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?

mzimmers

@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.

JonB

@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.

Chris Kawa

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).

kshegunov

@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).