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 (
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.