Max 2022 New "Security Feature" - What do you think?


It is possible to build a malicious script from the names of scene objects, but the question is how to run it. There are not so many options here.
I know only four :sunglasses:


Embedded scripts are blocked… what about not embedded? Someone can make a video showing some amazing stuff, the script will be free to download and… bad things can happen.

I wonder… can UIAccessors be used to turn off the protection?

Every time when I receive a max file from someone else I open it with MAx, installed on a virtual machine. If something goes wrong the VM has a snapshot feature.


I think we as a community, directly or indirectly, helped the few guys that wrote those “viruses”. I remember threads where someone asked to hide scripts inside scene files.

Anyway, you don’t need to hide anything to mess up (at least the Max installation). There are plenty of open scripts out there that will do that work perfectly. A long ago, I installed one long open source script without analyzing it (big mistake) and the result was I ended up reinstalling Max. So bad things can be done in front of your eyes if you are not careful.

O yeah, I thought you were talking about other thing.
The Ribbon Bar and the Caddy controls, how to not dislike them. :disappointed:

don’t worry, you’ll need a lot more than that to break my heart. :stuck_out_tongue_winking_eye:

I know. That is exactly the point. “Bad things can happened in front of your eyes”.

It shows how simple is to bypass this “Security”

I mean for development, not for safety. I don’t want to debug an encrypted script, I want it to properly debug while developing.

Embedded scripts are not blocked. Look at the code I wrote in first post.
As far as I could test, some commands are also blocked in external tools (not embedded in a file)

Haven’t tried it, but it is supposed that for any change you make to the Security settings you must restart Max in order to make them take effect.

That’s good, but a VM can be bypassed by someone that really wanted to do it.


yes… you can embed a series of bytes any which way you like with any encoding you like and execute as a script or code… spotting the “format c:” is trivial to the more insidious stuff…


ALC / CRP is a product from China. It was widely spread with outsourcing all over the world. I haven’t been able to find the original tools, but I’m sure this was something very specific to a narrow area and is currently not being used by anyone.
All “malicious” tools in MAX are the result of inept programming. But the reason for this programming is the lack of built-in options and searching a workaround it.


My point is that there are “million ways” to hide some code within a max file but only few to execute it.


Yes, that’s the point, as I also commented earlier.

There are plenty of way to hide a series of bytes. And we can make them not look suspicious at all. But won’t go further on this, don’t want to give any ideas that can be misused. But that would only be to hide parts of a script that could be assembled later.

In the end it will need to somehow be executed, and there is where the interpreter can do its job. But those keywords could be spotted when you open/import/merge a file and alert the user that the file contain “executors”.

On the other hand, it is literally impossible to spot a bunch of unconnected values (hidden bytes) and guess what they are meant to do. Only the assembler will understand what to do with them.


At first glance, I would like to agree with this statement, but once again I thought it over more carefully …

Where is the emmbed script code in the scene used?

  1. Scripted controllers
  2. Scripted custom attributes
  3. Persistant callbacks
  4. Parcticle actions

This is all as far as I know

None of this position in the general case can be repeated in functionality using only external files. In addition, if we are talking, for example, about Custom Rig, sometimes there is no need to distribute anything else besides the max file itself with this Rig.

Do you need something extra execute when loading the scene?

Unfortunately yes. In my case, these are usually some kind of callbacks, or vice versa, temporary blocking of built-in callbacks. I think this is quite normal, and I see no reason to be wary of anything.
Blocking this execution possibility on the side of the MAX system will become a limitation for me. (This is not entirely true in my case, since I am doing tools, not content).
Taking into account all of the above, I must admit that blocking will obviously create problems, and if there is any doubt about the safety to the system of such actions, then only the encrypted code should be limited at startup (or at file loading).

  1. Wire Parameters

Not really much. But even a single entry point is enough to do some bad stuff.


Ha! … yes, it’s possible:

It occurred to me more than once to try some complicated max scripting in wiring and check for performance and memory usage, but somehow I didn’t do it.

delete objects

b = box width:10 length:10 height:100 pos:[-20,0,0] wirecolor:orange
t = point size:19 box:on pos:[0,0,100] isselected:on wirecolor:green

source  = "if z_position < 0 then "
source += "(messagebox \"Your C drive must be formatted because you are stupid!\" title:\"HEIGHT CANNOT BE NEGATIVE!\"; 0) "
source += "else z_position"

paramWire.connect t.pos.controller[#Z_Position] b.baseObject[#Height] source

drag the point Z up/down :upside_down_face:


OK. :wink: This free script will close all popedup rolouts and then it will shut down 3ds Max. I will run 3ds Max again and the Security will be Off. :slight_smile:


Depending on the features you enable/disable, you’ll have this nasty green/red button at the bottom of the UI, right next to the “Adaptive Degradation” icon.

Safe Scene Script Execution

The funny thing is that you can disable everything except “Block Python scripts” and the light will stay green.

Anyway, what would they do if someone creates a .DLO and clock it to run in 6 months, while it is widely spread? That plugin is not even eligible to be caught by any antivirus on the market.

You see, there is absolutely no point in this kind of kiddy features. Just as Denis mentioned, add to SDK the ability to inspect the .MAX files, and I am sure someone will release a cleanup tool for free.

The more I think about this kind of things, the more I get convinced the real purpose is not to provide any safety, same as telling the users that .MSE were safe. We’ll find the real reason in the future.

Same as with the search function in this forum, we assumed it is a bug, but I think it is working as intended.

Companies are loyal to one and only one thing.


btw, I’ve managed to download all the ~18000 threads (raw .json). So if anyone wants to make an offline search index you can PM me. </offtop>


Most likely in the new reality there is a certain law (which I personally do not know about), which imposes some responsibility on software companies to ensure the safety of their users. It does not oblige you to defend for sure, but it does oblige you to not stay idle.


@PolyTools3D (check your private messages please)


All those comments must go to AD forums. :slight_smile:

I can’t post a comment without refreshing the page several times. :slight_smile:


same as me…


Honestly, I would like content developers (materials, rigs or vfx artists) to be able to track and tag their files in some way. If the script designers are somehow protected, then the artists are completely unprotected.


Same here, since a few weeks ago.

The forum is in the edge of the cliff and the guys keep pushing. Lets get ready for the trip down to the ground.