How to make Trial Plugins for 10 days

[hisefilo]

@Natan thanks! It's hard to believe a huge company as Ableton can't figure out how to avoid piracy

[Lindon]

@hisefilo -- one approach I designed for a server check-in system included a challenge response , so the plugin has a set (of say 500) challenge/response pairs, so it sends the server its "is this registered?" type message along with one of the challenges, and gets back a yes/no and a response, if the message returned from the server is "this plugin is OK " then the plugin looks up the response to make sure its correct for the challenge it sent....

The idea being its pretty hard for the pirates to have a system that fakes the server AND fake the challenge/response when there are 500 different options it would need to cover......

[d.healey]

@Lindon said in How to make Trial Plugins for 10 days:

The idea being its pretty hard for the pirates to have a system that fakes the server AND fake the challenge/response when there are 500 different options it would need to cover......

If they are able to find the flag in the binary they could just set it to 1 and bypass the server calling altogether. This is the problem with all solutions that don't use a dongle or a live connection.

[Lindon]

@d-healey -- go read Urs Heckmans commentary(KVRAudio DSP forum) on how to build effective authorisation systems - he has a way around this issue.

[d.healey]

@Lindon Interesting, I shall go and look it up

[Lindon]

@d-healey - in the right thread now:

https://www.kvraudio.com/forum/viewtopic.php?f=33&t=523031&p=8235873&hilit=Urs#p8235873

[d.healey]

Part of the problem I think with Urs idea is he is expecting the cracker to look for the point at which the app performs a delayed check. If I was trying to crack software of this kind I wouldn't bother at all with when the software wants to perform a check. I'd look for the if statement that enables the functionality I want since that can't be delayed. If I have a valid license the software must do what I want when I want it, I compare this against an unlicensed version and find out where the restriction has been placed.

As an example, let's say the app goes silent for 1 second every 30 seconds, well I search for that functionality in the code and disable it. The delayed checker can carry on happily doing its thing, in the meantime I'll just enable all the functionality I want and tell it to ignore any signals that it may receive from the license checker in the future, whenever or however they may be delivered. It still comes down to swapping some boolean tests. The delayed checker is only a block if your plan of attack is to nutralize the checking mechanism, but you can just sidestep it.

In his example there is a message "this demo has expired". All you have to do is find that text string in the binary (of course it could be obfuscated but you can still find it). And then change a boolean value and that message will never appear.

The idea is certainly a valid additional tool to include though. One possible scenario is the crackers don't even notice the check, they think the software just works fine with or without the license, and only end users who've downloaded the app and don't have a valid license discover the security limitation after they've been using it for a while, and that may prompt them to purchase a license.

[Lindon]

@d-healey - yes all valid.

On another track...its interesting to download my cracked software, as @Natan says it includes a Keygen program - which I cant get to work by the way... but still it means the pirate has worked out what the approach is I'm using - which surprises me - yes each product uses the same approach - however the approach itself uses a secret key as part of the authorisation system - so the inputs and outputs to the authoriastion system have to be different for each product , and they've hacked them all - so either they've spent time on each one - and I think it would be considerable time - or they have some way of "seeing" into my product script code... and reading my approach and my secret keys...

[d.healey]

@Lindon said in How to make Trial Plugins for 10 days:

they have some way of "seeing" into my product script code... and reading my approach and my secret keys

I would guess that this is what they've done.

[Natan]

@Lindon Yeah they have the Knowledge of reverse Engineering the code, Removing / Adding / Changing The code and Do compile it again and Bringing it into the Warez World.

They didn't Patch your Dll Files, they just Opened and Read the code, and Made the small Keygen which generates The Serial Codes.

same Scenario with Orange stuffs too. ‍️
I didn't try but i know how Keygen works.

You better to Send new Serials Out and revoke the old Ones Or Change the formula or the Curent keygen Made By R2R will Unlock all your Demo Plugins from now.

[Lindon]

@d-healey said in How to make Trial Plugins for 10 days:

@Lindon said in How to make Trial Plugins for 10 days:

they have some way of "seeing" into my product script code... and reading my approach and my secret keys

I would guess that this is what they've done.

if thats so then theres really nothing I can do in HISE to make this even partly defensable

[orange]

@d-healey said in How to make Trial Plugins for 10 days:

@Lindon said in How to make Trial Plugins for 10 days:

they have some way of "seeing" into my product script code... and reading my approach and my secret keys

I would guess that this is what they've done.

What I've done was to write a complex serial number formula checking system, and it is impossible to find it by trying each combination.

But as @Lindon said, I can definately say that, they can look into the any source code clearly and replicate the exact system with in just one day.

But they don't manipulate the code of the plugin, instead of doing it, they replicate the validation method such as keygen, fake server response...etc. If they want, of course they can manipulate the code but this time the plugin couldn't pass the macOS notharization system.

[d.healey]

@orange said in How to make Trial Plugins for 10 days:

but this time the plugin couldn't pass the macOS notharization system.

I don't think people using cracked software care about that

[orange]

@d-healey said in How to make Trial Plugins for 10 days:

I don't think people using cracked software care about that

I think the macOS security checks will be much more hardened in the near future. Windows also need a similar notharisation system to macOS too.

[Natan]

@orange They Ship the original Installers of your plugins ( Untouched )
And Keygen just Generates new Serials Based on Your Formula. ( it is Complex for You but easy For them )
And notarized Isnt a Thing, You just need another App To Make Serial Codes.

They cracked ILok,Output Arcade Server, And Things You wont believe. I also read They cracked cubase and Uad Stuffs and protools. But Not released it yet because of their Relationship With Stienberg and Avid And Uad.

The formula Protection = Keygen
And Keygen = Can Make serial Codes for All your Plugins Life time

[Lindon]

@Natan said in How to make Trial Plugins for 10 days:

@orange They Ship the original Installers of your plugins ( Untouched )
And Keygen just Generates new Serials Based on Your Formula. ( it is Complex for You but easy For them )
And notarized Isnt a Thing, You just need another App To Make Serial Codes.

They cracked ILok,Output Arcade Server, And Things You wont believe. I also read They cracked cubase and Uad Stuffs and protools. But Not released it yet because of their Relationship With Stienberg and Avid And Uad.

The formula Protection = Keygen
And Keygen = Can Make serial Codes for All your Plugins Life time

How though are they "doing" this? How are they looking inside the plugin to see the formula?

[Christoph Hart]

@Lindon said in How to make Trial Plugins for 10 days:

if thats so then theres really nothing I can do in HISE to make this even partly defensable

That's not something limited to HISE - the bottom line is whenever somebody that knows how to reverse debug a binary lays his hands on your software, it's game over. It's a little bit easier to extract the string of the HiseScript code than checking the actual binary code (however I'm surprised that they do this as it deviates from their standard cracking procedure which I hoped gives us a little bit more time). But that means only that it will take them 30 minutes to crack instead of 2 hours.

[Lindon]

@Christoph-Hart said in How to make Trial Plugins for 10 days:

@Lindon said in How to make Trial Plugins for 10 days:

if thats so then theres really nothing I can do in HISE to make this even partly defensable

That's not something limited to HISE - the bottom line is whenever somebody that knows how to reverse debug a binary lays his hands on your software, it's game over. It's a little bit easier to extract the string of the HiseScript code than checking the actual binary code (however I'm surprised that they do this as it deviates from their standard cracking procedure which I hoped gives us a little bit more time). But that means only that it will take them 30 minutes to crack instead of 2 hours.

so we are all screwed.

[Natan]

@Christoph-Hart @Lindon
Yes, they can Read the binaries.
As long As we work on Development they work on Cracking side. And we Grow with Each Other ‍️

[Lindon]

@Natan said in How to make Trial Plugins for 10 days:

@Christoph-Hart @Lindon
Yes, they can Read the binaries.
As long As we work on Development they work on Cracking side. And we Grow with Each Other ‍️

except we dont grow - we wither and die. If it takes me a month (at the insanely best) to make a plugin and it takes them a day to crack it - then I have lost every time.