good idea, Gustaf.
I’ve implemented it lie this now:
import imp, os, sys
supportedMagicNumbers = ['03f30d0a','d1f20d0a']
magicNumberOfThisVersion = imp.get_magic().encode('hex')
if magicNumberOfThisVersion in supportedMagicNumbers:
pathToThisVersion = "./version_"+magicNumberOfThisVersion
nuke.pluginAddPath(pathToThisVersion)
Cheers,
MAthias
On 09 Mar 2014, at 22:08, Gustaf Nilsson <gus...@laserpanda.com> wrote:
> wouldnt the simple and pythonic way of loading the correct .pyc be:
>
> try:
> import script_build_25
> except ImportError:
> import script_build_26
> except ImportError:
> import script_build_27
> except ImportError:
> print "wow. such error"
>
>
> On Fri, Mar 7, 2014 at 8:20 AM, Mathias Möhl <i...@mamoworld.com> wrote:
> Thank you all for this detailed feedback!
>
> Yes, I am aware of the decompilers and the pyc format is not the only level
> of protection that I am relying on.
>
> But it looks like having 3 different pyc files for Python 2.5, 2.6 and 2.7
> and implementing some logic that loads the correct one automatically is a
> reasonable amount of effort for a basic level of protection.
> In case anybody is interested: I think automatically loading the correct pyc
> file could be based on the imp.get_magic().encode('hex')
> idea sketched in the second answer here:
> http://stackoverflow.com/questions/2263356/are-python-2-5-pyc-files-compatible-with-python-2-6-pyc-files
>
> Cheers,
> Mathias
>
>
> mamoworld.com
> simplify your cgi
> Dr. Mathias Möhl
>
>
> Marlow 52 , 18551 Sagard, Germany
> Phone +49 (0)38302 - 88 75 61
> i...@mamoworld.com
>
>
>
> On 07 Mar 2014, at 00:34, Ben Dickson <ben.dick...@rsp.com.au> wrote:
>
>> Yep, pyc files can be converted back to Python relatively easily
>> http://stackoverflow.com/questions/5287253
>>
>> ..but FWIW, here are the Python or GCC changes throughout Nuke:
>>
>> Nuke 5.1v4, 64 bit, built Apr 3 2009.
>> 2.5.1 (r251:6028:6057M, Mar 14 2008, 16:54:54)
>> [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)]
>>
>> Nuke 5.2v1, 64 bit, built Aug 25 2009.
>> 2.5.1 (r251:13849M, Dec 2 2008, 17:16:32)
>> [GCC 4.1.2]
>>
>> Nuke 6.2v1, 64 bit, built Dec 17 2010.
>> Licence expires on: 2014/4/10
>> 2.6.5 (r265:30763M, Dec 8 2010, 09:13:05)
>> [GCC 4.1.2]
>>
>> Nuke 8.0v1, 64 bit, built Dec 2 2013.
>> 2.7.3 (default, Sep 18 2013, 15:32:05)
>> [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]
>>
>>
>> Based of the Linux version. Didn't check if the Python UCS version
>> changed at all, but I doubt it
>>
>> On 07/03/14 06:38, Nathan Rusch wrote:
>>> Trying to protect "IP" written in pure Python is a losing battle. If
>>> you’re really paranoid, consider implementing parts of your code in C.
>>>
>>> As far as versions go, it should be safe to assume that all versions of
>>> Nuke 8.0 will use Python 2.7. I believe Nuke 6.2 was the first version
>>> to use Python 2.6, but that’s going purely on memory. Prior to that, it
>>> was 2.5.
>>>
>>>
>>> -Nathan
>>>
>>>
>>> *From:* Mathias Möhl <mailto:i...@mamoworld.com>
>>> *Sent:* Thursday, March 06, 2014 11:35 AM
>>> *To:* nuke-python@support.thefoundry.co.uk
>>> <mailto:nuke-python@support.thefoundry.co.uk>
>>> *Subject:* [Nuke-python] python versions used by NUKE
>>>
>>> Hi everyone,
>>>
>>> I want to distribute some NUKE python script as pyc file to protect my IP.
>>>
>>> As pyc files are not compatible among different python versions, I need
>>> a different pyc file for each version of python that is used by NUKE.
>>>
>>> Is it save to assume that
>>> NUKE 8 always uses Python 2.7,
>>> NUKE 7 always uses Python 2.6,
>>> and which other Python versions do I need to consider for earlier NUKE
>>> versions?
>>>
>>> Cheers,
>>> Mathias
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *mamoworld.com <http://mamoworld.com>
>>> simplify your cgi*
>>>
>>> Dr. Mathias Möhl
>>> Marlow 52 , 18551 Sagard, Germany
>>> Phone +49 (0)38302 - 88 75 61
>>> i...@mamoworld.com <mailto:i...@mamoworld.com>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> Nuke-python mailing list
>>> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>>>
>>>
>>> _______________________________________________
>>> Nuke-python mailing list
>>> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>>>
>>
>> --
>> ben dickson
>> 2D TD | ben.dick...@rsp.com.au
>> rising sun pictures | www.rsp.com.au
>> _______________________________________________
>> Nuke-python mailing list
>> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
>
>
> --
> ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
mamoworld.com
simplify your cgi
Dr. Mathias Möhl
Marlow 52 , 18551 Sagard, Germany
Phone +49 (0)38302 - 88 75 61
i...@mamoworld.com
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
