Getting todays date in HISE

[ustk]

@LeeC JUCE has different functions for that, like, year, month and day, or even the full date, but also the toMillisecond() time object which returns the number of ms since 1st Jan 1970.
If you don't intend to display the date but just make embedded calculation then the latter is the way to go I think...
The only problem with this approach is, where do you want to store the information? If you dump it to an external file then people just have to open and modify this file to keep the plugin running. So this kind of copy protection is very very weak...

[d.healey]

@ustk

The only problem with this approach is, where do you want to store the information?

Encrypted object?

[Lindon]

@d-healey works until someone works out that all they actually need to do is delete the file completely...

[ustk]

@d-healey But you don't care if the object is encrypted or not if copy paste the entire object, you don't need to know what it contains to paste a previous state of the value (if you saved it at the first opening)

[dejans]

@ustk You can use it to do timed checks for leaked serials or something. There's a great forum discussion on KVR from few years ago about this. Urs from U-HE gave some interesting insight on CP stuff... KVR Page

[ustk]

@dejans I don't know much about protection, this check sounds good I'll have a look, thanks :)

[Casey Kolb]

All you need to do is encrypt a license.dat file using the machine ID. Every time the plugin opens, just check if the file exists, and if it does, attempt to decrypt it using the machine ID. If HISE can't find the file or can't decrypt, don't show the GUI and disable MIDI. This prevents the user from deleting the file, or moving it to another computer because HISE will only be able to decrypt the file on that machine etc.

It's just a few lines:

local data = //whatever you need to store in the file//
local machineId = FileSystem.getSystemId();
local appDateDir = FileSystem.getFolder(FileSystem.UserPresets).getParentDirectory();
appDateDir.getChildFile("license.dat").writeEncryptedObject(data, machineId);

That just stores the file in the directory above the User Presets folder.

Edit: You might be able to make this cleaner if the FileSystem.AppData constant is working now. Haven't checked

[ustk]

@Lunacy-Audio I already use something similar, but this alone does not give any protection since it is generated at the opening. Unless you can generate it only once during the registration phase maybe?

[Casey Kolb]

It's actually not generated at the opening. I only generate it when the user first enters their license key, which I then validate with my website's server. If the server response is successful, then I make the file. Every time after that, just check the file again, but don't regenerate it.

[dejans]

@Lunacy-Audio @ustk Yep, I'm also using this approach but only to encrypt the registration details file. This can be easily decrypted when the machine id generator code is found/cracked. But the interesting and creative part is that you can hide, let's say some kind of token in the license.dat. It can be a single character at a certain place in the serial, for example. Then at certain points, or based on user activity you do checks for that token (f.e. when a user moves a filter cutoff, you check if lfo is active && the plugin is running at least for 2 hours && token is not valid, then trigger a notification, mute the output, delete the license.dat or do whatever... The point is to make a couple of these checks that happen sparsely. Eventually, it'll be cracked, but hopefully, you can delay the crack long enough to convert a number of pirate users to legitimate ones...

[Casey Kolb]

That's interesting for sure. I'll need to dive deeper into that and add some more checks. Thanks!

[ustk]

@Lunacy-Audio I have approximately the same process added with a limited number of activations/machines, machine ID, and strong encryption to generate a license file.
About the time check, I can try to add an API...

[Casey Kolb]

@ustk Would be appreciated!

[LeeC]

@ustk yeah that would be ace... Much appreciated!

[ustk]

Guys, does having the number of days since 1970 fit your needs?

Do you prefer the system date? or anything?

In what format? days, hours, sec, ms, string date...

or an object with everything but I don't know if I am able to do that..

[Casey Kolb]

@ustk I think just being able to grab the current system date and time is super useful. Maybe something like Engine.getSystemDate() returns

{
  year: 2020,
  month: 11,
  day: 19,
  hour: 14,
  minute: 55,
  second: 32
}

But I'm sure there's a better way of returning it. This isn't my forte haha.

[Christoph Hart]

I would suggest to not go down the rabbit hole of trying to outsmart a imaginary cracker. Just make sure your plugin can‘t be copied to multiple machines by a simple user and leave the rest to companies who sell usb dongles for a living...

[ustk]

@Lunacy-Audio The juce Time class allows everything we need so it is just a matter of what we need and I'll find a way to make the API
Currently, I've made one that gives the number of days since 1970. I've just made a simple conversion since it is originally in milliseconds...

[Casey Kolb]

Sounds reasonable

[ustk]

@Lunacy-Audio What sounds reasonable?