I don’t want to shame or accuse anyone of using encryption … let’s just say it makes life easier and instills confidence in the security of your intellectual property. But this is an illusion, as I have explained many times.
On the other hand, all the malicious examples I know of in MAX are somehow related to MSE, directly or indirectly.
Too simple and easy to find …
I can write a CA that will not be seen by any scene exploration tools, but will come with the scene and will be saved with all other scenes loaded and saved after.
However, if there was a max file parser, then my CA could not be hidden. Therefore, I wrote to the Security Tools developers that they should look for the problem not after loading the scene, but while reading the contents of the file. …Although this does not guarantee success.
This can be a problem in the case of using encrypted scripts.
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.
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?
- Scripted controllers
- Scripted custom attributes
- Persistant callbacks
- 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).
- 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] sourcedrag the point Z up/down
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.
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>
Thanks to the list you posted in another thread I managed to gather all the posts from 2003 to 2020, parse them and organized.
Check your PM.
Can I have the e-variant of the book, please?
@aaandres, are you in the 3d world?
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.