Can a software compiled with Nuitka be decompiled easily?

[brupelo]

Hi everyone!

Offtopic: First of all, congrats to the Nuitka team... my favourite python tool is becoming better and better gradually and getting more and more traction and that's just superb :)

Bit of background first, one of the things I liked the most about Nuitka vs freezing tools from the very beginning since I've discovered Nuitka was the ability Nuitka had (theorically) to obfuscate python code nicely as pe/elf code... that was a great feature indeed (at least to me) as it offered an extra layer of source code protection you wouldn't have when using all existing python freezers, it's a well known fact there are available decompilers for all python freezers so I've never truly understood really the real value of this type of software actually :/

Anyway, it seems when you compile source code as a module with Nuitka you're basically offering the source code of such modules quite easily as inspect.getsourcelines will work flawlessly.

Here's my question, let's say you then don't compile your modules as .pyd to avoid this exploit so instead you decide to embed that code in the exe... if that was the case, how hard would be for somebody to use inspect.getsourcelines and reveal your source code?

First of all, I'm truly aware the only way to protect your source code is by not giving away any form of executable but I'd like to know in this case what's the level of difficulty for crackers to break software built with Nuitka.

Assuming crackers could inject some code in the exe itself to use inspect.getsourcelines... would there be a good way to avoid inspect.getsourcelines working?

For instance, when you try to use inspect on some Sublime builtin core modules you'll get a nice crash, ie:

>>> inspect.getsourcelines(sublime_api.window_views)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "./python3.3/inspect.py", line 715, in getsourcelines
  File "./python3.3/inspect.py", line 551, in findsource
  File "./python3.3/inspect.py", line 435, in getfile
TypeError: <built-in function window_views> is not a module, class, method, function, traceback, frame, or code object

Which it's great, as SublimeHQ has been concerned about source code protection from the very beginning and they did a great job in that area :)

Regards!

[JorjMcKie]

I think the answer to your question is the same as for this one:
"Can a compiled C program be decompiled easily?"

When compiling with Nuitka, you have the option to include bytecode, however. If you do this, then decompilation for the respective parts is as easy as it always is for Python bytecode. That would then be your own fault.

Some special packages make no sense to be compiled as C programs (eg. tensorflow and gevent on Windows) and those parts (only) will be integrated as bytecode. But that applies to that package - not your app code.

[kayhayen]

Closing answered questions, and tagging them as question, for people to find them if they follow the link in the docs or google search.

[LeonardoRick]

Awesome discussion here! I'm not a pro on the compiler area, so would be nice if you guys make the final conclusion more specific with all use cases. Thank's, guys

[kayhayen]

I am editing the question heavily, as the quality of responses is too mixed. False assumption in the question were not answered, the next one to ask, is going to get a better answer. Basically in accelerated mode, the original source is referenced, and that's OK, in standalone mode, no source code is included or even used, except for standard library, where bytecode is used. So no source code is usable.

[iPurya]

reverse engineering nuitka is so hard with ghidra. its mixed with python codes.
is there better way to reverse engineering nuitka compiled files ?

[kayhayen]

@iPurya thanks for confirming my selling points :)

[m2acgi]

How about onefile mode? Thanks.

I am editing the question heavily, as the quality of responses is too mixed. False assumption in the question were not answered, the next one to ask, is going to get a better answer. Basically in accelerated mode, the original source is referenced, and that's OK, in standalone mode, no source code is included or even used, except for standard library, where bytecode is used. So no source code is usable.

[kayhayen]

The --onefile mode packs the standalone folder into an SFX, which may then statically exist on the disk (cached mode), or as a temporary folder, which gets deleted. It adds no "protection" at all to what standalone has, and writing an unpacker for it, is not only trivial, the program itself does it, but you get a the protection of not having the source included at all.