UnicornEmulateCommand: "python" should be "python3"

[theguy147]

• Did you use the latest version of GEF from dev branch?
• Is your bug specific to GEF (not GDB)? - Try to reproduce it running gdb -nx
• Did you read the documentation first?
• Did you check issues (including
  the closed ones) - and the PR?

Step 1: Describe your environment

• Operating System / Distribution: Ubuntu 20.04
• Architecture: x86_64
• GEF version (including the Python library version) run version in GEF:

GEF: (Standalone)
SHA1(/home/theguy/.gdbinit-gef.py): 1bcadc4a2cb35354163c45a19316392f6f982108
GDB: 10.2
GDB-Python: 3.9

Step 2: Describe your problem

in UnicornEmulateCommand() gef tries to find the python executable like this which("python") whereas it would be better to search with which("python3") like done in the if __name__ == "__main__" section.

Distros like Ubuntu 20.04 e.g. don't have a python executable if only python3 is installed and other Distros that do usually just symlink python to python3. So using python3 should work on every Distro.

Steps to reproduce

1. Use Distro where only python3 is available (like ubuntu 20.04 without python2 installed))
2. `gdb -q ${which ls}"
3. emu 10

Observed Results

[!] Command 'unicorn-emulate' failed to execute properly, reason: Missing file `python`

Expected results

Something like:

[+] Starting emulation: 0x55555555a7d0  →  0x55555555a7f8
[...]

[hugsy]

This is a local configuration option to each Linux, not a gef issue.
It can be fixed by creating a simple symlink or using update-alternatives. Now that Python2 has been deprecated, Python in GEF means Python3.

[theguy147]

Exactly my point! So why is there an inconsistency in gef.py for this?

EDIT:
To clarify by "exactly my point" I meant that python in gef means python3. So why not use it specifically (especially because gef.py is already doing that at a different place)? And yes the issue can be made a Linux configuration issue but when using a specific major python version one can be exact and as seen with the change from py2 to py3 such lines of code can cause some trouble if and when py4 becomes available (I am aware that this is probably not happening for quite some years, but still...)

[theguy147]

Another option would be to use the recommendation from PEP394: use sys.executable instead of which("python")

When reinvoking the interpreter from a Python script, querying sys.executable to avoid hardcoded assumptions regarding the interpreter location remains the preferred approach.

[hugsy]

Another option would be to use the recommendation from PEP394: use sys.executable instead of which("python")

When reinvoking the interpreter from a Python script, querying sys.executable to avoid hardcoded assumptions regarding the interpreter location remains the preferred approach.

That's a valid point, we may prefer turn into that approach actually.

[theguy147]

Unfortunately I just noticed that gdb behaves very oddly in regards to the used python interpreter and breaks the promise made by sys.executable (as a hack gdb changes its python path at compile-time in these lines)

The result is that sys.executable points to the location the system-wide python interpreter was at the time of compilation. With package managers like apt providing pre-compiled versions this might differ from the local python interpreter.

Therefore the PEP394 recommendation is not always possible here.

I see two possible solutions to this issue:

• use of a little bit hacky fix as well: set sys.executable = which("python3") once at the beginning and then always use sys.executable. The hacky part is the manipulation of that value while the advantage would be to only have one place in the code where this kind of hardcoded assumption is made.
• use the PEP recommendation all the way through but add a check at the beginning to determine if the interpreter at sys.executable can be found and provide a clear error message if that is not the case so the user can "fix" his/her Linux configuration. This solution is probably cleaner and in complete compliance with the recommendations.

[hugsy]

Actually we already defined pythonbin initialized very early during the startup process (see https://github.com/hugsy/gef/blob/dev/gef.py#L10701) which does use python3. Can you update your PR to use that value then? That'll be good enough for now

[theguy147]

ok. I did so and also changed pythonbin to PYTHONBIN to clarify that it is a constant.