I’m looking for some advice with adding security to my script. I don’t want to encrypt a large amount of it as I want it to be open for modifications and for people to add their own custom parts. But I do want to protect the core code and functions I’ve written.
How easy/complex is it to use C++ to house some of the functions so that it’s protected.
Hmm – why not modularize the script and have an encrypted core part whose functions get called via your open, unencrypted parts of the script ?. Other than writing a binary plugin (with all it’s disadvantages) i can’t think of any scenario which would require any C++ coding…
Or are you thinking about an assembly ? Would require obfuscation, otherwise anyone could decompile it with ILSpy or Reflector anyways…
I just want to avoid anyone being able to run a decrypter on a maxscript file to get access to the core code so it’ll be harder to crack.
Maybe a dlx would work ok? I could make an interface class and use that, and put some licensing checks in there no?
I’m diving in at the deep end with all this stuff.
distributing tools with specific DLX is really the pain. today you have to support at least 10 max versions (2009 32 and 64, 2010…, 2011…, 2012…, and 2013…). I’ve never tried but documentation says that plugins for 2011 work for 2012. maybe.
so you have to have all their SDK, both VS 2008 and VS 2010. And of course all these versions of max for testing.
as Denis says it can be a real pain if you want to support the current user base (I’ve kinda settled on 2010 32 bit, it’s nice I like it ). The actual C++ coding can be pretty trivial see the mxs extension thread to see just how simple some of the stuff is (it can be easier than mxs). But nub comes with the steep learning curve on visual studio and creating the intial project, I’ve taken to duplicating existing project I know that work as starting from scratch is very hit and miss sometimes, though that is not without it’s pitfalls (renaming resources within a project what a nightmare !)
also it’s kinda not really what dlxs are for, not saying you can’t do it, but it should be used for stuff that can be used in many scripts… and if you are going to the trouble making a plugin project just for one tool why not make the whole tool a plugin and add function publishing if you want to support mxs ?
Because I’ve got a tool which is 15,000 lines of code long, I don’t want to re-write it all
And I’d like to keep a lot of the UI stuff open for modding.
I doubt that the effort producing a real hard to crack protection mechanism in a plugin would really pay off. Maybe you got some nice new uncommon protection ideas, but in general, if people find your script/plugin interesting enough, they will find ways to crack it…
Maybe compiling some personal buyer info into the binary, encrypt and hide it behind multiple layers of obscurety and scrambling would work., but sooner or later i guess it still would be cracked …
EDIT: just to add
And in case you still want to go the binary plugin route, don’t do it the (legacy) .dlx way. Create a Utilitiy Plugin ( *.dlu ) and use Function Publishing …
Think of it this way: If Autodesk and Adobe can’t prevent their software from being cracked, what chance do you have?
they were cracked with no knowing how they work or maybe more… with no knowing what they do.
i thought about something like:
encrypt some library scripts with your own encryptor written with c++
have a dll or dlx written with c++ and max SDK that can decrypt your encryption and run the code
to get your code a hacker has to disassemble and crack you dll. there several ways how make it not too easy.
It depends what you’re trying to protect here. Do you want to prevent unlicensed use of a product, or do you want to protect against someone revealing your source code? It’s really hard to imagine anyone will bother with the latter.
I was under the impression that decrypting an MSE file was a fairly easy thing to do with the help of Mr. Google.
I know that decrypting MSE’s from old versions of 3dsmax is straightforward, but I’ve never seen a public tool for new versions. Then again, I don’t frequent hacking forums.
My point was that it’s likely people will only bother to attempt to decrypt your code if it is necessary for cracking the software in order to be able to use it without a license, not by other developers who are interested in stealing your code. So the question is are you encrypting it in order to make it a commercial product or only to protect your IP?
Old or new .mse files indifferently, doesn’t matter. I know for sure, It’s a complete disappointment for protection.
But on the other hand, IMO, the most important is to alert the user, ‘the tool is not free’. Autodesk could spend lots of time and money super-protecting their software, but they don’t bother, because it’s products benefit from popularity and dependence.
It comes to my mind FinalRender vs Vray, the former severely damaged themselves, because of their own fears…
I think this is not true … newer encryption is harder to crack. Old encryption was crackable by any process memory editor/viewer, because after they where loaded, the unencrypted script source was fully visible somewhere in the 3ds Max memory region. AFAIK that’s not the case any longer with the new encryption introduced with 3ds Max 2008
It’s hopefully (I say so because the plans to release it aren’t firm), going to be released as a commercial product and whilst I know it can never be secured against Piracy, I wanted to make sure that it wouldn’t be a quick easy hack to bypass the security.
I can easily write the code to check MAC addresses etc just like PEN’s licensing system does, and I guess that will have to do.
I thought the same. But the fact that the new mse is harder, doesn’t make it more secure in the end. not at all. I did some tests in the past. I was about to give up but before that I understood…
Anyway and despite of that, I don’t see it as a severe problem for most scripted tools.