Notifications
Clear all

[Closed] Security of encrypted scripts

Someone says that encrypting in max (EncryptScript) is not a panacea. That algorythm is not so complex, that its obfuscation rather than encrypting actually.
So the questions are:

  1. can someone see my encrypted script in max memory – decrypted for execution?
  2. can someone see my variables via maxscript listener – global and local from utilities and rollouts?
  3. can someone decrypt my script at all and see source – even with var1,var2…varN and fn1, fn2 … fnN (after obfuscation)?
  4. maybe someone can see via Visual Studio (for example) debugger memory, using by maxscript – and maxscript holds it’s vars and code in obvious format so anyone can understand what is what (i.e. map of keys and values)
  5. can someone see, what utilites is loaded (not in utility panel, but only declared in script and having variables and rolouts in it closed so far)? Is there some list of utilities, currently loaded. I mean can someone do something like:
    for u in utilities do
    for v in u.vars do
    print v
    If not – do I only must name variables weirdly and pray that hacker will not guess right the name?

SO: how to effectively protect script (even encrypted), what to draw attention to?

By the way, does new encryption (max9sp1+) is really better?

13 Replies

In summary: It can’t be done. Write a plugin instead.

See also the other thread you posted in:
http://forums.cgsociety.org/showthread.php?f=98&t=638998

I’ll address some of the specific questions here though…

  1. Don’t know. The key to unlock your script has to be, at some point, somewhere though. And the problem with this, in 3ds Max, is that if any EncryptScript-encrypted script gets hacked, -all- of them are effectively hacked. That’s why you should use further encryption further down if you really want things to be more secure.

  2. global, yes – since 3ds Max 2008, and in earlier versions with the AVGuard extension. local variables, no – but they could brute-force it if they’re bored. If they can get at your rollout, they -can- get the controls in that rollout, of course. So none of your code should rely on, say, whether a checkbox is checked or not to see if it’s okay to run (external applications can also change a checkbox state, obviously).

  3. In versions of 3ds Max prior to 3ds Max 9 – yes, easily. 3ds Max r9 and later use a different encryption key (and possibly method), but I’m sure that could be found if the hacker was sufficiently interested in doing so.

  4. Only if they have a debug version of 3ds Max; regular max doesn’t like debuggers. The rest of your question ties into question 1.

  5. using ‘apropos “*”’ you can get everything that’s declared in 3ds Max and MaxScript. Getting their class types will easily yield what is a utility / etc. From there on other methods can be used to get at further information. Again, though, I don’t think that local variables can be listed – but I may be wrong in that.

” SO: how to effectively protect script (even encrypted), what to draw attention to?”
‘effectively’? See the other thread. Hacker-proof? You can’t.

“By the way, does new encryption (max9sp1+) is really better?”
Yes – if nothing else, it’s not nearly as trivial to get the decryption key.

If there is a means of determining what Global Variables are in use currently during a session I’m all ears. Forget hacking that would be incredibly useful while working in Max and accidentally typing in a variable to test a small block of code and it persisting for a few hours only to discover you never declared it anywhere in your code the next day.

master your variables, my man

Anyway, here you go… since 3ds Max 2008 – or using the AVGuard extension:


-- collect all the global variables
globalVariables = globalVars.gather()

-- warning, there's a lot
(globalVars.gather()).count
4453

-- go get coffee!
print (globalVars.gather())

Note that the variables returned are in no particular order.

There’s some other functions in that struct, some useful (determine if something exists as a global variable or not; impossible to do with “var == undefined” as that could just mean that it is declared… just that its value is undefined), some pretty weird to have.

thanks! didn’t even know what a lamer i am!

i undestand that can’t protect from haker at all, but some silly things now i won’t do

and – what means “master your variables”?

my “globals” are in utilities – so in real globals – are only utilities itselves. can someone get list of some utility variables? i.e. –

 
utility myutility ""
(
 local var1 = ""
 local var2 = ""
 local var3 = ""
)

--and hacker types something like this
for v in myutility.varnames do print v
>var1
>var2
>var3

That just made my day. I’ve been asking about something like that for the last year and nobody knew of anything like it.

EDIT: oh but it includes system varaibles…
What happens if I set allll of them to undefined? Does the world explode or does it only clear my global vars?

yep – so you might want to stick a call to it in a script that runs before your scripts, then you can filter those out later.

As for setting system globals undefined – no idea, I’m not that adventurous

There is, however, a big fat warning without further explanation for one of the methods within that struct… the method which destroys a global variable outright. I suspect that one’s best left untouched entirely

Good idea. I assume those variables don’t change from session to session so a script could return everything back to a “clean” state without restarting max.

If not – do I only must name variables weirdly and pray that hacker will not guess right the name?

SO: how to effectively protect script (even encrypted), what to draw attention to?

This may off topic, but I really dont like (and many around here I think) the idea of encrypted script.

What other people will learn, ? modified script to suite their needs, you can not say your work flow is exactly other so modified script is sth flexible and suitable for anyone, even without a programer.

So best way to encrypt your script: never share and keep it save on your own HDD and protect it with password

Just a 2 cent of thoght

Well an encrypted script paves the way for a commercial approach, hower low, by charging for additional features. If the script can be modified by just anybody, then you’re not likely to get very far as somebody will just point to the script on here and ask the hundreds of bored scripters to take a stab at adding the functionality. Which is all good and well if it is licensed in such a way, but not so good for the author who might have wanted to take a commercial approach with it; so they’d be better off encrypting it.

I’ve never bothered encrypting my scripts – it’s too much hassle and too easily defeated (especially given the need to support older max versions), but I don’t fault people for wanting to encrypt them – for whatever reason.

Page 1 / 2