plug-in "anti hacking" measures.

86 views
Skip to first unread message

Rudi Hammad

unread,
Aug 3, 2018, 2:00:41 AM8/3/18
to Python Programming for Autodesk Maya
Hello,
although this a C++ question, I think it is okey to post it here since it is Maya's API related.
So, I recently started writing plug-ins in C++ and I am planning on freelancing rigs that use those plugins. Simply put: I want the clients to use the rigs with the C++ plugins nodes, but I don't want them to be able to create the node.
The reason why I want this is because if I spend months or a year of hard work developing a muscle plugin, the client can ask me for 1 rig, and then rip off the plugin and keep it to him self. So without going into license stuff I thought that
maybe in C++ we have more protection measures?

This is what I have done so far to protect the plugin:

1-Build the plug-in in release mode (apparently in debug mode you can hack it somehow, at least that's what a college told me when I was working at MPC)

2-Delete everything in the scene if a disconnection is detected in the node with:
connectionBroken(const MPlug& plug, const MPlug& otherPlug, bool asSrc)

3-Delete everything  in the scene if the node is duplicated with:
::copyInternalData(MPxNode* node)

But the main problem is that you still can simple write cmds.createNode("theNode") to create a new node. So the previous measures are useless.


Any ideas?Maybe doing something after the maya scene was opened and loaded the plugins?
Thanks,

R

Justin Israel

unread,
Aug 3, 2018, 5:29:10 AM8/3/18
to python_in...@googlegroups.com
That sounds really devious to instrument your plugin to destroy the state of someone's work if it thinks certain conditions aren't met. It is borderline virus-like and I think you should avoid that route. What if some connection were deleted by accident? 

I realise you put alot of time into your intellectual property and want to protect it. But this situation is pretty common with commercial products. Safe guards can be hacked and worked around, so it usually comes down to a company wanting to play ball the legit way. That means wanting to ensure the products they are using are licensed, supported, and work reliably for them in production. 

If you don't want to come up with a proper license key solution, maybe there are other ways to deter clients from misusing your technology. I don't have any concrete solutions since I don't write much Maya code these days, but maybe you could think of some way to validate the objects on the other side of the connection to your node? Maybe some type of activation criteria has to be met or else a created plugin node simply won't function. So you could focus less on trying to prevent the creation from happening, and just make it not do anything useful unless it's activated correctly. Maybe that means considering a hash on stuff like the type of the node connecting to your plugins plus some other criteria. Maybe you compile your plugins specifically for each client, with some keys that have to match the rig (c++?) you have given them. 

Im sure others in this forum that write Maya plugins on a regular basis could offer some more concrete criteria to base it on. But overall I just recommend accepting that people can choose to circumvent things but hopefully your clients won't work to circumvent some basic measures that you implement thus making it harder. Just don't delete their stuff :) 

Justin 


--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/64a4e39d-3ea7-495e-9f36-16c734d73faa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rudi Hammad

unread,
Aug 3, 2018, 6:38:37 AM8/3/18
to Python Programming for Autodesk Maya
hey,
I said "delete everything" in the scene has an example. Of course I would try to do something that won't damage anything, but just make the plugin stop working.
The reason why I am so concerned is that I had a very a bad experience a year and a half ago. I trusted the client with my personal work that took me a year of hard work, and he ended up lying to me and giving anyone that he wanted all of it.
That hurt me a lot, and I lost more than 3000 pounds. So I learned from that experience. I think it is important to protect your work.
Thanks for your advice. I 'll try to figure out a clean and none destructive way to do it. If I don't, I`'ll consider a license key solution.

R
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

ha...@haggi.de

unread,
Aug 3, 2018, 7:03:24 AM8/3/18
to python_in...@googlegroups.com

What about a network mask detection?

Most companies have an intranet, so let's say everything in ip range 192.168.9.* is valid all other ip's are invalid. Of course this is not rocksolid, but it it easy to implement and give you good start.

Todd Widup

unread,
Aug 3, 2018, 12:52:27 PM8/3/18
to python_in...@googlegroups.com
a previous company also would ping the world atomic clock website to timebomb the plugin.  if it was past a hard coded date, it would stop working. 
so a combination of that and the IP range would be a great start.  the atomic clock would lock it into a time frame limited run so if the project was to go for 8 months, then it would only run till then.  if they need an extention cause of overrun, then simply charge them for the update

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/b90589675e1c74a088ac088f48132523%40haggi.de.

For more options, visit https://groups.google.com/d/optout.


--
Todd Widup
Creature TD / Technical Artist
todd....@gmail.com

Rudi Hammad

unread,
Aug 3, 2018, 1:30:31 PM8/3/18
to Python Programming for Autodesk Maya
Cool, thanks for the advice.
Sorry, but outside maya I am a bit lost .So doesn't that mean that the client should provide me his IP range. Probably a client would not  be very happy having to deal with technical stuff.
 I guess in the end it is a balance between security & client headache  or risking to "lose" your property in the benefit of the client happiness.
It is good to know thought what you suggest. I'll keep digging.
Cheers,
R

Justin Israel

unread,
Aug 3, 2018, 4:00:28 PM8/3/18
to python_in...@googlegroups.com
You wouldn't need that information to check a time. You would compile a specific plugin for that client with a licensed time range. That particular build of the plugin would expire and you could ship them another one if they paid you to extend it. 

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

Rudi Hammad

unread,
Aug 4, 2018, 3:43:03 AM8/4/18
to Python Programming for Autodesk Maya
Sure that would work fine.Maybe it is a good solution.I guess I would lose clients if rigs expire, but I can have it all.


El viernes, 3 de agosto de 2018, 22:00:28 (UTC+2), Justin Israel escribió:
You wouldn't need that information to check a time. You would compile a specific plugin for that client with a licensed time range. That particular build of the plugin would expire and you could ship them another one if they paid you to extend it. 

On Sat, Aug 4, 2018, 5:30 AM Rudi Hammad <rudih...@gmail.com> wrote:
Cool, thanks for the advice.
Sorry, but outside maya I am a bit lost .So doesn't that mean that the client should provide me his IP range. Probably a client would not  be very happy having to deal with technical stuff.
 I guess in the end it is a balance between security & client headache  or risking to "lose" your property in the benefit of the client happiness.
It is good to know thought what you suggest. I'll keep digging.
Cheers,
R

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

Cedric Bazillou

unread,
Aug 4, 2018, 11:02:53 AM8/4/18
to Python Programming for Autodesk Maya
Im not even sure if its worth the effort:

lets be honest, rigging tool box or plugins are for the most part extremely elementary ( im not even sure how one can talk about intellectual property on something less than original, and for the most part inspired by community effort).
Personally i think the rig is the result produced from some tool, so its not that important: its the way you get to the result which is valuable.

Otherwise you can convert the rig to use factory nodes from maya:( much more difficult to decipher 12000 node network)
if you dont want to distribute plugins you can unpack the code logic into regular nodes (  python have some good abstract syntax tree / ast module and the same concept exists for c++).

Rudi Hammad

unread,
Aug 4, 2018, 2:03:01 PM8/4/18
to Python Programming for Autodesk Maya
Hi Cedric, thanks for sharing your thoughts.

Before writing a plugin, I try to produce the same result using maya's nodes. So I could distribute the rig without any plugins if I wanted, but usually a c++ node, if done right, performs faster than 20 maya nodes network.
Since I want to offer the best to the client, I think rigs with plugins are not a bad idea. Also I find it more interesting from a learning point of view, and you can't do everything with maya nodes.

Now let me ask you something. Imagine that you spent a year developing a muscle plugin system. So you spend a year studying math, anatomy and any other useful resources to finally write your plugin from scratch. Would you not consider that intellectual property? After all,muscles are not original, we have maya cMuscles, Ziva muscles now etc...Also math is not original. But any way, original or not, how would you approach that situation? Would you simply distribute it without any kind of protection?  what if the client ask you to do one rig, and then he rips off the plugin and do 20 rigs using it. or worst, what if the client and resell it?

(Besides, I think protection methods is a very interesting subject on its own.)

Cheers,
R

Justin Israel

unread,
Aug 4, 2018, 4:28:55 PM8/4/18
to python_in...@googlegroups.com


On Sun, Aug 5, 2018, 6:03 AM Rudi Hammad <rudih...@gmail.com> wrote:
Hi Cedric, thanks for sharing your thoughts.

Before writing a plugin, I try to produce the same result using maya's nodes. So I could distribute the rig without any plugins if I wanted, but usually a c++ node, if done right, performs faster than 20 maya nodes network.
Since I want to offer the best to the client, I think rigs with plugins are not a bad idea. Also I find it more interesting from a learning point of view, and you can't do everything with maya nodes.

Now let me ask you something. Imagine that you spent a year developing a muscle plugin system. So you spend a year studying math, anatomy and any other useful resources to finally write your plugin from scratch. Would you not consider that intellectual property? After all,muscles are not original, we have maya cMuscles, Ziva muscles now etc...Also math is not original. But any way, original or not, how would you approach that situation? Would you simply distribute it without any kind of protection?  what if the client ask you to do one rig, and then he rips off the plugin and do 20 rigs using it. or worst, what if the client and resell it?

Don't use that client again. Or sue the client for breaking your contract and reselling your technology?

Consider other commercial applications that use a license key. What if the agreement is that a license is for one seat, but the company just installs it on 10 machines with that one key? It can happen. And a company probably worked very hard on that software. You are hoping to deal with reputable clients that want to pay you to support your products and not act like criminals. It's the same reason you don't put a snack into your pocket and walk out of the convenience store without paying, because it's easy. 

If everything you deliver is in C++ then you can at least make it harder to reuse unless some common hashes match between the plugin and the other custom nodes you write. 


(Besides, I think protection methods is a very interesting subject on its own.)

Cheers,
R

El sábado, 4 de agosto de 2018, 17:02:53 (UTC+2), Cedric Bazillou escribió:
Im not even sure if its worth the effort:

lets be honest, rigging tool box or plugins are for the most part extremely elementary ( im not even sure how one can talk about intellectual property on something less than original, and for the most part inspired by community effort).
Personally i think the rig is the result produced from some tool, so its not that important: its the way you get to the result which is valuable.

Otherwise you can convert the rig to use factory nodes from maya:( much more difficult to decipher 12000 node network)
if you dont want to distribute plugins you can unpack the code logic into regular nodes (  python have some good abstract syntax tree / ast module and the same concept exists for c++).

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/c0f6d7f4-10bb-4ddc-b1bb-9231afcb6fb3%40googlegroups.com.

Cedric Bazillou

unread,
Aug 4, 2018, 4:31:41 PM8/4/18
to Python Programming for Autodesk Maya
I know all too well what you are referring to:
i always though maya strongest point was its nodal nature and strong API ( so obviously all my rig were flatten into custom nodes:  at some point i even combine all  of them into a biped node and question the use of transform hierarchy to interact with it directly with an uber manipulator).

Protection wise its a lost cause ( every drm system by nature only prevent the majority of people from unregistered use of your product: but it wont stop motivated one), 
Its an hyper specialized field of its own, and like everything what are your priorities ?( producing content, extending your client base, providing support, custom solutions etc)

For me the most secured way to protect your plugin is for it to stay on computer/device not connected to the internet...

1 year is such a small amount of time  when you are a working professional and have limited free time + energy to devote to personal projects,you usually can only scratch the surface of one of the fields you mention above.
I value more the learning process than the result of my experiment : like used toys im not attached to my tools/plug-ins but to what they help me achieved.


if your selling a rig  as an asset maybe you can encode the data/mesh and do some check sum on volume / point count / name / hierarchy ?
Maybe some kind of combo with an encrypted alembic file feeding a reader node ( for the validation part ) which then output some mpxdata to your regular node.


Rudi Hammad

unread,
Aug 4, 2018, 5:15:06 PM8/4/18
to Python Programming for Autodesk Maya
Thanks for suggestions guys. I' ll try what you say and keep you posted if it works.

I also thought that I can do something with the  MSceneMessage::kAfterOpen. Maybe something like --> after the scene is opened, make the custom node delete what is selected when it is created? Because when a new node is created, it is automatically selected, so why not just make it delete it self after the scene is opened?

I'll keep you posted on any progress.

R

Alok Gandhi

unread,
Aug 4, 2018, 11:21:06 PM8/4/18
to python_in...@googlegroups.com
you spent a year developing a muscle plugin system. So you spend a year studying math, anatomy and any other useful resources to finally write your plugin from scratch. Would you not consider that intellectual property?
This definitely constitutes an IP.

Not talking about the implementation here, I suggest using some sort of licensing. The Maya node/nodes should be licensed. Licensing term depends on you but from what I understand, in your case, the node is to be used in a rig. The clients should get a license for the node. How they use it depends on them, maybe they use it on the rig you provided or maybe they make their own rigs using the node. You can restrict activation of the node based on the mac address of the machine. This ensures that the node is licensed for 'a' machine. The clients can have as many rigs as they want running on a machine. This will create a problem with rendering on the farm if the client does not use any sort of caching (Alembic or something else) where the mac address is not known beforehand. Either you have to supply license for each rendering machine or you can give an unlimited number of nodes for a reasonable discounted price. Usually, this is not a problem because most modern pipelines use Alembic cache for rendering. So for caching pipelines, you can supply a license for a number of seats. You can even benefit from the floating license schemes, for that, you have to look into license servers. Either way, this simply means that a license is used per machine per Maya session. 

I encourage you to start looking at the licensing workflows, understand them and implement them in your code.

- Alok
Reply all
Reply to author
Forward
0 new messages