0

I have a .so file (ELF 64-bit LSB shared object, x86-64, dynamically linked, no section header) with an embedded Cython program. To run the program inside the .so file there is a single python3 program that imports the .so and calls its main method. This method just asks for an input and checks it against an internal string, informing the user about the comparison. I want to know if it its possible to decompile the .so file in order to obtain the original Python source code using an intermediate uncompyle6 or similar apps (from .so --> python byte code --> uncompyle6 --> python source code). I have tried some tools (meliae, uncompyle6, pyRETic...) to no avail.

If decompiling is not an option, I wonder if a debugging session with Ghidra, radare2 or GDB would help me to reverse engineer the code (the main goal is to obtain the string that this app expects from the user). I tried to launch the main app and attach radare2 to the process (when the app asks for the user input). I found some of the strings that the binary is using for informing about wrong or good inputs and tried to set some hardware breakpoints when accessing those strings, just to know which is the address where the program compares to a right or wrong input. But I haven't been able to grok it.

Another attempt has been to set a breakpoint in the PyEval_EvalFrameEx instruction (trying to obtain the byte-code step-by-step), but I don't know if this is a viable option.

Any recommendation about how to reverse engineer this kind of Cython binary shared objects would be greatly appreciated.

  • Did you ever manage to decompile it? I've got the same requirement right now. – Stjubit Apr 17 at 18:37
  • No, it was impossible for me, but IIRC, it was part of a CTF and got the Python source code from an open Github repo ¯_(ツ)_/¯ – Juanan Apr 17 at 22:55
  • Have found any solution ? Thanks in advance – Chouaib Chaoun Sep 4 at 13:48
  • No what you want is not possible at the moment. You can disassemble or decompile the .so with the standard tools, but turning this code back into Python code (or the overlapping subset between Cython and Python to be precise) will be impossible. Unfortunately this question is pretty much useless by now because the file in question isn't known and so it wouldn't even be possible to get back to the core routine or demonstrate anything. – 0xC0000022L Sep 5 at 19:02
-1

In general the .so objects that you import from python are basically regular libraries that you can RE with any framework, in fact, a lot of libraries in python use that concept of having the specific libraries on another language that is not python (numpy for example) or any program that needs to execute code on C/C++ for example.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.