Notifications
Clear all

[Closed] MSE again

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.

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.

-Eric

2 Replies
(@denist)
Joined: 10 months ago

Posts: 0

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

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

(@denist)
Joined: 10 months ago

Posts: 0

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!

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

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?

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#

1 Reply
(@denist)
Joined: 10 months ago

Posts: 0

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.

1 Reply
(@martinb)
Joined: 10 months ago

Posts: 0

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.

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?

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.

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?”.

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.

Page 3 / 4