Python Source Protector: Can it be called via CLI?

m_adam

Hi just to get back on the topic, do you have any special requirement for it or does a configuration variable(see CONFIGURATION - Definition) to set like g_encryptPypFile=YourPathToAPypFile;AnotherPathToAPypFile is enough?

Cheers,
Maxime.

kbar

That should work fine for my purposes. I just need to pass in the file to get encrypted and have it write the result to the same directory. But then C4D should quit afterwards. Would be amazing if this was possible.

If this was added to S22 ( or S23 ) then would the resulting pypv files also load in R20 and R21?

fwilleke80

Sounds like a good solution to me, too!
And I second Kent's question about the compatibility of encryptet pyp files.

m_adam

Thanks for your feedback, and yes regarding the compatibility this would produce the same as the one produced from the UI.

In any case, I can't give you an estimate about when it will be implemented.
Cheers,
Maxime.

baca

Hi C4D team.
Is that functionality still under development?

m_adam

Hi sorry to net get back to you in this topic.

This feature was added in R23 and can be used like so g_encryptPypFile="PathToPypFile"
You can pass one or multiple pyp file, they should be separated with ;.

Cheers,
Maxime.

a_block

Hi,
sorry, to hook onto this topic. Since the command line option got added, do we also have an option to call the command in a way, that it does not open a file requester? So that we could script our own source protection mechanisms?
Or could we achieve the same in Python shell (I mean the Python executable delivered with C4D) outside of C4D? Is it anything else than creating byte code?
Cheers,
Andreas

ferdinand

Hello @a_block,

Since the command line option got added, do we also have an option to call the command in a way, that it does not open a file requester? So that we could script our own source protection mechanisms?

I am not sure how you mean that, g_encryptPypFile will not open any dialogs. What is a "file requester"? Sorry when I am overlooking here the obvious ...

Or could we achieve the same in Python shell ...

Yes.

Is it anything else than creating byte code?

It is fundamentally different. A Python code execution chain is something like this:

[Python Code] --- Python Compiler ---> [Python Byte Code] --- Python Interpreter (VM) ---> [Machine Code]

The source protection does not do anything about this chain (opposed to .pyc files for example, which indeed cut out the step of compiling human readable instructions into byte-code). It instead just puts a step in front of this chain:

[Protected Code] --- Cinema 4D ---> [Python Code] --- Python Compiler ---> [Python Byte Code] --- ...

The files are protected with AES, so cracking the files itself will be (almost) impossible. But since decomplication from byte code is easy in Python, and stuff must reside in memory at some point, "source protection" should be treated more as "source obfuscation". It will not be a hurdle for anyone dedicated to finding out what your code is.

Cheers,
Ferdinand

a_block

Thanks for the explanation.

@ferdinand said in Python Source Protector: Can it be called via CLI?:

I am not sure how you mean that, g_encryptPypFile will not open any dialogs. What is a "file requester"? Sorry when I am overlooking here the obvious ...

No need to feel sorry. But in this case the obvious is, I would need to close C4D and start it with this command line option only for this specific purpose. And since there is no more -parallel option, I assume that I can't do this in parallel to a running instance. And within the running instance my only option seems to be the command, which opens a file requester.

ferdinand

Hello @a_block,

ah okay. Well that is true. I assume you want some kind of batch operation here, right? Using c4dpy in the manner I did demonstrate will not bring you any further in this case, as it will replace just one window with another one. But you could pass in a dummy script, e.g., something like this:

Which won't cause the call in a shell script to c4dpy the shell script to halt, as calling c4dpy without a script will launch the live interpreter, while calling it with a script will only execute the script (i.e., the same as the Python binary of vanilla CPython behaves). The content of dummyScript.py is irrelevant, it could be the empty file. With that you could chain multiple calls to c4dpy in a shell script together and execute them in one go, without you having to close the windows.

Cheers,
Ferdinand

a_block

Thanks, Ferdinand! Much appreciated. I always forget about c4dpy and that it can still be run in parallel to a running C4D instance.
Thanks.