I’ve already pushed this topic at least three times… Do we really need MSE?
The matter is that I am ready to publish on this forum free decryption of ANY NEW version of 3DS MAX mse encryption. I want people to forget about the inviolability of the scripts, having in mind MSE protection.
Just some guys who encrypt their scripts are forcing me do it…
I will tell my story a bit later (I am really pissed off now), but want to know now – DO WE NEED MSE?
I can understand your frustration and share the same thoughts, mostly because the LIE behind what the MSE encryption is and what it does. The encryption itself wouldn’t be so bad if there wouldn’t be a public decryption solution, except that Autodesk always had the decryption algorithm, meaning they have been able to decrypt every single script out there since the beginning, which is at best unethical.
Now, things would have been different if Autodesk stated from day one something like:
“You can use MSE encryption to protect your scripts from most users, but we have the code to decrypt them, and so does many of our past, present and future employees. It is up to you if you use it or not.”
Of course, that would never happen because it would be illegal to decrypt and encrypted script and Autodesk (or any employee) would not assume they would do such a thing, wouldn’t they?
The truth is that a good solution can be coded in any language, the biggest difference between them is mostly performance, but anyone could have a Nobel algorithm coded in MXS and someone have always had access to it, in the shadow. That is not a good thing at all.
C’mon guys, not even the comments are removed from the original code, seriously?
Being said that, if you decide to make the decryption algorithm available to everyone, you should know that you are damaging no one but the developers’ community, and I don’t think you want to do that. You know that many of us could make the same decision, but none has moved that far.
I think, if you really want to discourage developers using MSE encryption, you could:
- Make a thread to prove them how useless the MSE encryption is by offering to decrypt any script they decide to put on the thread, but if you succeed the whole decrypted script will go public.
- Make a free robust alternative to MSE, and of course don’t keep the keys with you. The ideal tool should be able to use fixed or dynamically generated keys and protect them as hard as it could be. This would definitely be the best alternative.
An even better alternative would be a MXS compiler. Protect and boost performance in one click, wouldn’t it be wonderful?
To answer your question “DO WE NEED MSE?”, not as it is.
I think yes, encryption is necessary and I wish Max would have better.
Some people may do this for fun or because they want to learn, but others may see it as a means to generate at least a bit of income if they sell the scripts via gumroad or other places and would like to protect their work.
And even if people would like to take a look at other scripts to learn, there are enough ressources out there how to decrypt mse files.
So why force it?
I’m interested in your story and WHY you want to to this but there are reasons why encryption is needed.
I know that the decryption is possible for quite a while and that’s what nearly forced us to stop developing tools for the community. We programmed SnowFlow (the MaxScript version) several years ago which took lots of effort. The sales nearly stopped when the cracked version was spread all across the web.
The whole industry and I think nearly everybody outside the CG industry thinks the world is for free. We are used to free services, free software, free everything. If someone like us is developing software and sells it, people think “wow, a million dollar company has created this tool!” but in fact we are just a two men company that wants to earn some money for us and our families to live. If you have two versions of the exactly same software, one for free and one for some money, people will ALWAYS take the free version, regardless of the money and effort others placed in developing it.
Being able to protect software is needed because not doing so leads to thousands of illegal distributed versions in just a matter of seconds. Protection stops this not for infinity but for lots of more copies that individuals and small companies need to pay their bills and maybe develop the tools any further.
MaxScript is not a million dollar industry. It’s a world of small helpers and software that saves people some extra hours of work. Our goal with SnowFlow was to sell it for about the price of one or two working hours but for the benefit of saving two or much more hours. People liked this! After cracked versions where all over the place and noone bought it.
You should not play your fight with the “guys” in public. Decrypt the scripts if you think it makes sense, but why would you endanger the work of other developers because of your anger? Do you hate all developers or what drives you? I know you are helping a lot here in the forum but between the lines I keep reading out the “arrogance”. You always try to provoke. Before your time here in the forum, there was “Bobo”. We all know him. Like you, he tried to answer ALL questions and help wherever possible. His style, however, was not marked by arrogance and “I’m the best” affectations. Should you actually consider publishing such a tool, that would confirm my assumptions and you probably would have the majority of the MaxScript developers, at least here in the forum, against you.
Those are some written statements of mine in loose sentences. Feel free to do whatever you want with them…
I personally can’t imagine any use of .mse in its current state. Well, maybe just as an additional layer of obscurity and not as a protection of source code.
What I do not understand is why helping those lazy and ignorant ones to get into someone’s already ‘encrypted’ source codes? No one will benefit from such move.
Sorry, I don’t understand this reasoning. Firstly, Autodesk has to be able to decrypt .MSE in order to execute it within max. Secondly, what would bind Autodesk (legally) to not decrypt their own proprietary format? It would make zero sense for them to ever enter into that kind of agreement with end users.
That is an architecture decision, it could be different (better), or simply do not offer the script encryption option. At least (as I stated before) there should be a very clear disclaimer, which I couldn’t find.
You probably missed the sentence where I said:
“…Now, things would have been different if Autodesk stated from day one something like:…”
Does that mean that Autodesk also has the right to Decompile or Disassemble any plugin created with their SDK? Or even Microsoft?
Also, is there any purpose to encrypt the code comments that I am not aware of?
What would happen if suddenly, a secret tool that was hidden for years comes to the light and it is able to reverse any C++ to the original source code including all the developers’ comments in it?
Honestly, I do not think the average MaxScript user realizes that someone (except hackers or crackers) will be able to read their MSE scripts just as they wrote them. Mostly because MXS is a language intended for artists, not programmers, and an artist do not necessarily need to understand (not even know) what Encryption means.
When I did read this, it made me feel pretty safe:
“The encryption uses a fixed hidden key that lets it run on any 3ds Max system, but effectively hides the source of the script.”
Perhaps the MXS help should go into a more technical explanation and let all the users understand the differences between encryption, obfuscation, compilation, assembly, low and high level, etc, so just then they would have enough tools to make a decision?
Isn’t it better to let the ignorance make you feel warm, cozy and safe?
someone above said that using MSE helps him to make his business. fine…
Here is my story…
I spent last two weeks to make my tools work on client’s machines. The tools works fine on mine, an on all machines in my office. But didn’t want to work on client’s. It tried everything, debugged the code many times. Nothing helped. And unfortunately the error message I had didn’t make any sense.
Finally I asked full image of client’s MAX and MAX user’s directories. I found some third-party MSE files. I never look in anyone else encrypted files. It’s not because I can’t decrypt them. It’s because I see that an author closed it for public and don’t want to share the code. Which is fine, and I understand it.
But in my situation him (they) left me no other chance.
What did I find? I saw not only a practically meaningless and an illiterate code, but also with children’s mistakes, like the common names declaration is as global, inappropriate use of free objects, using of gc () . Of course I didn’t fix that code, I just asked to delete these files from the system. That my client did, since he had no idea how these files got to him, and what they do.
My point about MSE…
The only reason I see is by encrypting files you say that “I don’t want to share my solutions”.
But 90% of encrypted files are encrypted to hide embarrassing code behind.
Some “developers” have not yet learned how to write code, they did not understand the 3ds max system, but they already know how to encrypt scripts. And do it…
And YES, I think that so simple (by action) encryption must be same easy decrypted. Otherwise, it practically closes the question of the possible use of third-party scripts (tools) written on MXS.
The using of any MSE tools was strictly forbidden by me wherever I had sufficient power to make such a decision.
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?
NameSpaces?
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 already told in other threads that only commercial tools might be encrypted and protected anyhow from viewing. Every free scripts must be opened!
For many years of my practice I met 100% my code is being simply copy-pasted into someone’s else without any credit to me. I saw commercial plugins with exactly same class IDs (!!!) what I gave to my plugin examples posted on public forums. It could happened only because a simple possibility to hide the code under MSE
Hum… those are indeed interesting points everyone brings to the table. Let a newbie give 2 cents as well.
I’ve made (very) few scripts in the past. I’ve always released them 4 free and always let them open (never bothered to encrypt). Why? Because that’s how I learned to script, by looking at other’s codes (and of course giving credit as much as possible). The script I’ve made that reach some success (if you can call that a success) was the SlateConnector, and I did give full credits, both on video form and on the script itself, to anyone who I did talk to or that gave any hint on it, even if just suggesting “do this instead of that”.
Now, about people getting codes from other people, wrapping them and selling, that’s just unethical. Sure it is, but we’re not the police! You can expose them (and should), but give the sheer amount of mse files around, it’s virtually impossible to go through everyone of them and seek for stolen code (or un-credited code). The solution proposed (deploy a tool that de-crypts everything) seems far too disproportional in my view, and bound to hurt people who are not guilty of anything and try to protect (even if in a lousy way) their IP or make a small business out of it.
What I mean is, doing so, you’re most likely making a lot of collateral damage, and diving into potential illegal behavior… all in order to counter others illegal behavior!
The argument of people hiding bad code by using MSE, yeah, I guess many people do, but the harm they do (morally speaking) is much less than people who are stealing code from others. I can surely understand that those have the potential to be a much greater pain (as you did experience recently), but their annoyance is not at least legally or morally reprehensible. They’re just bad coders, that can make your life harder because of their bad work.
So, the solution for the latter is better education, push better practices, open and explain why doing stuff one way is better than the other. This takes time, and money from their side, in order to learn how to properly write code. Heck! If you look at my stuff you’d probably flip, I’m sure! But I don’t sell, and I whole heartily admit my code IS bad, and people use it on their own risk! No one I know was born knowing the best practices on code writing. This took them time, effort, practice, and realistically, not many ever go that far.
For the first batch of people. Well, those should be exposed, and legally bound for the damage and stealing of ip they make. This is a much harder, and stressful task, since it involves confrontation, and must be carefully thought out what action is worth. But you can’t guide your actions by the wrongdoings of others.
About the other comments, about ADSK being unethical about they being able to decrypt, I guess I fall more in line to what Tyson said – the format is theirs, the software belongs to them, and it is something that is entirely up to the user to use it or not. I believe I heard some users who devised their own way to encrypt/obfuscate their scripts, or used other ways to enforce their scripts are properly licensed to users, so it’s not like MSE is the “only” way, it’s just the cheapest/easiest, and is offered just as that.
Anyways, though discussion. But I’d say you should give this some serious thought and time, Denis, and not take any action on the heat of the moment. You are hired and get paid on the TD world (among other things) because you’re a problem solver, capable of understanding and dig on the problems of the clients. Maybe you should add a new clause on your contracts that specify clearly that you’re not liable if your tools do not work properly because of improper installations or tools that are causing compatibility problems with your own. Or add some extra money clause for extra work needed to clean and fix the client’s machine in order to make it work properly.
If somebody wanted to be malicious… they could do great damage to a user’s computer by hiding malicious code in an .MSE file.
EDIT: …and there is no good way to “scan” an .MSE file for malicious code. But I suppose malicous code could also be packaged in a C++ plugin.
You are absolutely right in your thoughts. I can put everything malicious in my DLL, DLE, etc. But it’s a different level. Doing it I throw my reputation on the table… The MSE encrypting is so simple and too easily offered by Autodesk to every MSX coder.
some scripts (tools) developers can say “this is my script, all ideas and algorithms belong to me”. True? Yes. It’s absolutely true.
“I encrypted the code because I don’t want to share it”. It makes sense again.
But … Autodesk can decrypt any script and gain access to all your “treasures.”
Does it mean that Autodesk has exclusive right to everything written on MXS and encrypted to MSE?
You can say “I trust Autodesk”. But do you automatically delegate all your copyright to Autodesk? Probably not…
If Autodesk will try to disassemble any of my c++ code to get access to my ideas, algorithms, they will be convicted of hacking.