formulamonks / python-obfuscation Goto Github PK

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.

line 125 in ihook.py causes script to stop on windows with following error:
WindowsError: [Error 183] Cannot create a file when that file already exists.

to bypass this I've just commented the line out for now.

https://github.com/citrusbyte/python-obfuscation/blob/master/custom_interpreter/opcodes/scramble-opcodes.py#L14

fix_offests(...) -> fix_offsets(...)

Love this repo. Am trying to work with it, but am seeing behavior in importing files that I cannot explain.
The simplest way to explain it is this: Consider a minimal set of 3 modules, say main, foo, and bar
main:
imports ihook.py
sets the import hook
imports foo
imports bar

foo:
imports bar

Now if the files are all unencrypted, what I see happening (with a print statement in the Finder function), is that the system tries to find foo, then since foo imports bar, it imports bar from foo. The behavior of this is different when the file is encrypted vs. when it is not.

If the files foo and bar are not encrypted, the Finder shows the calls to be:
Find (foo)
Find (bar)
if the files foo and bar are encrypted, the Finder shows the calls to be
Find (foo)
Find(foo.bar)
This lands up loading bar as foo.bar inside foo, which is a different instance of the module than the one that the main program loads when it imports bar.

What am I missing here. Why is the behavior different between loading the modules encrypted or unencrypted?