Open Cnly opened 1 month ago
Why does this directory already exists? If it's a correct behavior to mkdir
this directory multiple times, then I guess your fix should be good :)
@ValekoZ So I spent some more time digging around and found this line
https://github.com/hugsy/gef/blob/1b6f46a0054eb2600919ffde4d930319452d9fe4/gef.py#L6247
where session.connect()
sets up a remote_objfile_event_handler
which self.sync()
s the remote file to local on gdb.events.NewObjFileEvent
. This creates the directory in question. Later, session.setup()
calls self.__setup_qemu()
which contains code to copy the executable to the same location, causing the error.
It seems to me a better fix would be to replace these lines
https://github.com/hugsy/gef/blob/1b6f46a0054eb2600919ffde4d930319452d9fe4/gef.py#L11480-L11482
with a simple self.sync()
call. Is this doable? Is there any reason / specific case where we would need the copy2()
instead of the remote get
gdb command as used in sync()
?
In this case, in your command you specify a qemu-binary manually, so we want to copy it instead of just syncing using gdb remote get
, so as far as I understand this code, it is fine like it is currently so that if we can't sync using gdb's features we can do it manually, but then we should accept that the directory already exists so your fix should be fine imo.
@hugsy maybe I'm wrong, could you double check? I never really checked how the qemu
part works :sweat_smile:
Hmmm, just to add some info here, the docs instruct users to
Use
--qemu-user
and--qemu-binary /bin/ls
when startinggef-remote
And if the binary is not manually specified, it seems it's still automatically set by the code:
https://github.com/hugsy/gef/blob/1b6f46a0054eb2600919ffde4d930319452d9fe4/gef.py#L6232
GEF+GDB version
Operating System
Kali Linux
Describe the issue you encountered
When I try to use
gef-remote --qemu-user --qemu-binary ~/Desktop/<executable> localhost 1234
, the command fails with the errorwhich seems to be a result of this
exist_ok=False
flag: https://github.com/hugsy/gef/blob/1b6f46a0054eb2600919ffde4d930319452d9fe4/gef.py#L11481I also tested with the main branch (674c74d) and the problem still exists. Setting the flag to
True
solves the problem. If this is the correct fix, I'm happy to open a PR from my fork.Do you read the docs and look at previously closed issues/PRs for similar cases?
Yes
Architecture impacted
Describe your issue. Without a proper reproduction step-by-step, your issue will be ignored.
qemu-arm64 -g 1234 a.out
gdb-multiarch -ex 'gef-remote --qemu-user --qemu-binary /path/to/a.out localhost 1234'
Minimalist test case
Additional context?
No response