4

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.

Improve this question
6
  • Did you ever manage to decompile it? I've got the same requirement right now.
    – Stjubit
    Commented Apr 17, 2020 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
    Commented Apr 17, 2020 at 22:55
  • Have found any solution ? Thanks in advance
    – Chouaib Chaoun
    Commented Sep 4, 2020 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 ♦
    Commented Sep 5, 2020 at 19:02
  • 1
    I think I could write a decompiler for this or get pretty close. At least at a rough level I've worked out how this might work. However it is a lot of work - the kind that would require something like full-time attention, and something I'd only consider if I were paid for the effort. I'm not a businessman though and have never been able to figure out how to make enough money to live on to support this kind of effort. So for now, I am happy to sit back and watch how others tackle the problem.
    – rocky
    Commented Mar 21, 2021 at 9:46

1 Answer 1

Reset to default
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

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