Preventing sharing of commercial GDL objects

[BenjiDev]

An author of a GDL object might want to sell it while also preventing buyers from sharing it with others. How is it done?

A GDL object cannot make HTTP requests and, to my knowledge, does not have access to any crypto libraries.

I have some ideas, but there may exist simpler solutions already:

The GDL author creates a C++ Add-On and sets up a license server. The sole purpose of the Add-On is to communicate with the license server, since the GDL object itself cannot make HTTP requests.

The flow:

1. A GDL object is placed, and the Add-On gets notified through ACAPI_Notify_CatchNewElement.

2. The Add-On queries the license server using:

   • a unique ID for the GDL object (essentially a product ID)
   • the Graphisoft user ID

   The server responds with a signed license (for example containing expiry date etc.). The important part is that the license is signed with the license server’s private key (for example using RSA).

3. The Add-On writes the license as a string parameter into the GDL object.
4. The GDL object verifies the license signature internally using the public key of the license server, validates the contents of the license, and disables itself (for example by not drawing any geometry) if the signature or contents are invalid.

Since a GDL object can be password protected, a user would not be able to simply remove the license check from the script itself. And you cannot easily edit the GDL code outside of ArchiCAD either.

The problem is step 4.

How would you realistically verify RSA signatures inside a GDL object? It does not seem very feasible to implement RSA verification manually in GDL.

The simpler alternative would be to let the C++ Add-On perform the license validation and then simply write an is_valid parameter into the GDL object. However, that seems insecure because someone could create a fake Add-On that just writes is_valid = true without checking any license.

Operating system used: Windows

[Patrick M]

TBH, I've never made enough $ from selling my objects to care much about who's sharing them. In fact, when a firm pays me to build a custom template, I often just load the embeded library with a bunch of the more useful objects.
I think you'd need to get into an add-on/plug-in that ties to a given GS license/GSID... similar to cadimage. Maybe buy a c/i seat and reverse engineer how they did it?

[Lingwisyer · Accepted solution]

https://community.graphisoft.com/t5/GDL/Cloud-Licensing-and-GDL/m-p/589158#M6356

You can request the UserID & OrganisationID so you can just hardcode in a check value against one of those. I think Ben's library has a seperate licencing object which all of the others reference that contains this check as well as an expiry date.

Ling.

[BenjiDev]

Thanks for the link, that looks like a good and simple solution. If i understand it when a user makes a purchase you encode that user id into the GDL object? I wonder if it is possible to automate. 

And if you want a recurring subscription model using only a GDL object the user would have to manually renew it after expiry date?

[BenjiDev]

Thanks for the tip, at least if you want automated recurring subscription model you probably need an Add-On to make web requests to a license server.

And I'm not 100% sure but I think GDL datetime uses the system clock which can be changed by the user. If that is the case then using it for expiry checking might not be suitable.

[Piotr Dobrowolski]

The drawback is that the OrganisationID which is better in such cases will load all organizations that the user is a guest, so there can be cases where the object will work for the "guest", and it is impossible to lock parameters with this request, as it was with old "req" command.

[BenjiDev]

Before you could make specific GDL add-ons in C++:

https://archicadapi.graphisoft.com/downloads/gdl-development-kit

So you could maybe have created a GDL add-on for license checking (using a C++ RSA library) with the public key of the license server embedded. 

Perhaps you could even have created a GDL-addon that made web requests.

But looks like they don't work for AC versions above 23:

https://community.graphisoft.com/t5/Archicad-C-API/Why-there-is-no-forward-version-of-GDL-Developmen...

I cannot find much information about it.

And I'm not sure if it would be more secure/better compared to a normal C++ Add-On because the GDL Add-On could perhaps also be replaced. 

[runxel]

The GDL add-ons are formally discontinued.

I wrote about how to make one a long time ago along with a template. But I'm pretty sure that will not compile anymore for newer versions.

I think that the "modern" way is the other way around: You make an add-on that injects data into an object, instead of having the object requesting it. But for that type of convo @BerndSchwarzenbacher is better equipped in knowledge.

[BenjiDev]

Thanks for the links and context.

Alright, yes I know you can inject data through parameters. But it feels complicated for a license as there are no crypto functions in GDL. A "license checker" Add-On could do the license check and write "is_valid=true" to a parameter but that could be written by a fake Add-On too. This parameter could be hidden/obfuscated of course. But this requires an Add-On that exists purely to verify licenses...

Encoding the customers GSID into to GDL object maybe is the best solution, what Lingwisyer mentioned. Perhaps it could be automated with the converter tool  https://gdl.graphisoft.com/tips-and-tricks/how-to-use-the-lp_xmlconverter-tool/ by keeping the GDL source as XML and inserting the customer GSID on the correct line, and converting it back to .gsm before sending it to the customer, no C++ Add-On needed. I have not tried it so I'm not sure the tool works like that though, especially if the GDL object is password protected.

[runxel]

Making a central macro that checks for the correct ID is exactly what I would do honestly. The only tricky part would be an automatic generation of that object. Otherwise your customer needs to wait for you to make it.