MSE again


i delivered more than 300 tools for my clients. the tools were never been encrypted. sometimes my clients asked me, what if we use outsource and don’t want to share code which we paid you…this is not my business.


Based on your story, it seems to me that the problem you faced has nothing to do with MSE encryption but with the MXS architecture and coding habits, and until now, there is nothing we can do except trying to create safer code.

If the scripts that caused you so many problems would had been encrypted with a custom tool, you would have had the same or a much harder time figuring it out.

I don’t know exactly how this could be solved but I think it should be addressed from the inside of the MXS architecture. Surely removing the build-in encryption solves nothing and certainly you can’t expect every developer out there to code the way you think is correct, even if you were right.

Perhaps a new kind of plugin (plugin tool) that keeps everything in its context safe?
A new type of variable superGlobal?

What do you think could be easy to implement without breaking the current architecture?

I wonder what the developers that have access to the code think would be possible without having to re-write the whole MXS core.


the MSE made me a lot problems when I was looking for issue. I saw some suspicies events and callbacks… But could’t identify their sources. I tried to search functions, names and ids in all scripts. But I couldn’t search in MSE files.Problem number two was that the author of that MSE creates another MSE file on the fly and deletes it on MAX closing. So the broken script doesn’t exist on the disk when MAX is not loaded.

So, you are right, the final problem can be in any not encrypted script, but it would be very easy for me to find this script. It is also very possible that “bad code and coding methods” could be found while using the script.


I have encrypted scripts in the past but not anymore. At the beginning to hide my horrible code (yes, I think that’s something every beginner goes through), then because I thought I might, one day, develop it into a commercial tool but release a less feature rich version for free until then.
Quite frankly, mse is more an annoyance than anything else these days, I absolutely agree with that. Someone who can’t script doesn’t care if the script is encrypted or not, someone who can and can’t figure out to get around it is probably rare - so it’s definitely not usable as a copy protection. I don’t really think it would make much of a difference if you would actually post a decryption script here on the forums or not… but that’s not the point.
I try to prevent anyone in the studio to install script without me having a look at it first for the very reasons that were discussed already but I also think that some way of protection can actually benefit the community greatly. Maxscripts are easy and fast to write but you can’t protect them, c++ plugins would be the solution but way to cumbersome to get into (I wanted to get into it for years but all the stories I hear and all the frustration about random sdk behavior very much prevents that, I just don’t have the time for that kinda stuff). This means I just don’t publish any commercial scripts - just free ones and just a fraction of my more useful ones. So unless there is a middle ground solution I don’t see mse going anywhere - even though encrypted scripts are basically pointless.


I like it. Because my learning of scripts is it analysis how other do the things. I’m not coder, mostly I’m artist but some times needs small maxscript tools to achieve a goal.

BTW Spend 5 min in google allows you to find free decrypter for .mse… so, use or not is mostly ethic problem not technical…


A big issue with MSE can be seen with the ALC/CRP “viruses” that self replicate through files. The ALC is attached to MSE and MSEX files.



Oh!!! I know this problem, perhaps better than anyone else :slight_smile:
I specially made startup cleanup script to fight it.

BTW Does anyone know who the author of this rubbish is?


there is another “bad” but commonly had script… many of you can have it in the script/startup:

here is it’s body:

-- Auto assign a proper material while rendering PointCloud
-- NOTE: after each modification, use "encryptScript <filePath> version: 1" to encrypt it as a *.mse and copy the mse file into startup directory.

fn UpdatePointCloudMaterial obj =
    m = obj.material
    if (classof(m) == adsk_Mtl_PointCloudMaterial) do (
        m.rampShader          = obj.baseobject.gradientTexmap
        m.displayTech         = obj.baseobject.displayTechnique
       return true

fn createPointCloudMaterial obj =
   m = obj.material
   mMtl = adsk_Mtl_PointCloudMaterial()
   mMtl.rampShader  = obj.baseobject.gradientTexmap
   mMtl.displayTech  = obj.baseobject.displayTechnique
   assignNewName mMtl
   obj.material = mMtl

as you can see there are two GLOBAL functions which both don’t check an object’s (that passed as argument) type. I met situation when it caused the script crash… It’s Autodesk’s as I understand, isn’t it?

Why is it encrypted? WHAT WAS THE REASON?


The funny story about this issue … I met some also third-party scripts that tried to “fix” this issue. They worked bad and… were ENCRYPTED! :stuck_out_tongue:


mse cannot encrypt your code ,if you want to sell your script , you should find another way , make a maxscript lock in c++ or c#


c# might be decompiled very easy


My .02 on mse:

While it can be decrypted (somewhat) easily by many, it still provides a legal barrier.
Even if the encryption is weak, it is still illegal to break it.

So basically I treat .mse as a flag to indicate ‘you are breaking the law if you decrypt this’.

I actually like the fact that .mse can be decrypted with a bit of effort; at least then we can check code for errors or malicious elements.


i’m not sure that there is any law you break… To exclude this ambiguity, Autodesk must either really protect it by law in the contract, or, providing a public encryptor, should provide the public decryptor as well. Otherwise, Autodesk must be held responsible for any harm caused to its customers through hidden code.


no one will be surprised by the situation when a food delivery company will open containers, transfer food to others containers, perhaps add some ingredients, but do not bear any responsibility for food after that?


At least here in Germany, breaking any mechanism designed to prevent copying/access of/to the raw data is illegal. This applies to CSS in DVDs just like any of the annoying copy protection mechanisms in Audio CDs or ebooks, for example. Some argue that breaking even trivial encryption schemes (e.g. ROT13) is illegal.


i don’t think you are right. It’s illegal to break a copyright protection(!) only. In case of personal use it’s also legal to make a copy (by removing encryption)


but an unreasonable declaration of copyright is illegal in almost all countries.

MSE decryption is a matter of morality, as well as reading other people’s letters. But in our case, the “letter” is addressed to you, only written in the “gibberish” language.


I guess I’m late to this party. :slight_smile:

Considering, I still don’t know how to decrypt .mse.
It might not be completely useless as copy-protection.
I have a few scripts which I personally really wonder “how did he do that?”. :slight_smile:

Also some users has been asking an encryption mechanism for MCG.
So… I guess there are certainly desire to have this.

My vote? Honestly. I don’t know. Both arguments seem to have point.


Hi had to agree with dennisT on this, the protection scheme is pretty weak and very easy to reverse it, even after the “upgrade” they did in Max 9, and most of the time is used to hide bad code practices.
See Maya (mel and python), or even Blender (even the sold scripts are open), they don’t have protection schemes for scripts. On the opposite side, you have Houdini which as the HDA that has protection.
C# is great, but very easy to check the code, of course you can obfuscate it to protected (we do this for our commercial C# plugins).
Protection on MCG would be great, in terms of commercial interest it would give a reason to create commercial tools for it, but it’s just XML with some MXS and probably would end up with a protection like MXS.

In relation to other people using some else code without permission or reference, unfortunately this happen in any language, and it’s not related to MXS only, the only difference is that in MXS and other scripted languages is easier to check and see this.

We do have something for protecting commercial scripts (and dll’s), that also handles part of the licensing in development, but don’t know if there will be enough interest from the community, apart from a few developers that have tried it and liked the direction it was going. We also use it to protect our scripts.


It’s a great tool. I think it can be a sort of standard in the future for maxscript/ dll’s protection. Keep up with it!