Question: dis module & pyretic

[dkullmann]

You mentioned in the README that:
Conventional tools to reverse-engineer python application won't work, pyREtic might still work for if scrambled-opcodes is the only technique used.

We have a question here and we appreciate your support. We know that pyretic works with the dis module (built-in in python) and compares the generated dis of an scrambled opcode with the generated dis of a normal opcode. Won’t that be avoided if the dis module is removed after the python installation? Or that is just naïve thinking?

Also, pyretic needs to know the exact python version that is being used in order to make a successful reverse-engineer? Could that be hidden as well.

Of course an attacker can load the dis.py and our custom compiler will compile it to dis.pyc. So, any compiling build-in functionality has to be removed. Like compile_py, and compileall .. etc.

[omab]

If the solution is just to scramble the opcodes, then yes, the dis module can be used to remap the opcodes from the custom interpreter to the default one.

My guess is that any tool that works on the opcode level directly depends on the python version since opcodes changes are introduced per release. But even if the version was hidden by modifying the Include/patchlevel.h module, it won't be hard to check against major versions of python, specially since Python 2.7 is very popular and still common these days.

Removing the API to compile modules could be checked, but that also implies that no .py files can be used at all, which means that a distribution of the application must also include the pre-compiled .pyc files for each dependency used.

To properly disable the dis module, the better option is to disable access to the co_code property, this isn't exampled in this repository, but it's a valid option. Something interesting to do is to leave the co_code property in the structure, but introduce a new one real_co_code, not accessible to the python modules, only at the CPython level, that way any tool relying on co_code will fail because there's nothing in there.

[khaledsobhy4gtss]

It's true. That is a great idea. I was able to disable dis by Removing access to co_code in the interpreter (delete the reference to co_code in the code_memberlist array declaration in Objects/codeobject.c of the interpreter). real_co_code can be done as well.

I think removing all compilers will be an extra thing to do.

[workingenius]

Disabling co_code is a great idea, but I'm afraid it would bring some stability issues, considering that some tricky third party packages may depend on it. Even some packages in standard library use dis (as far as I know, modulefinder).

That means a well-tested project with standard python interpreter would possibly crash in a subtle way when codes are protected.