-
-
Notifications
You must be signed in to change notification settings - Fork 741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[target-remote] Basic support for the target remote
command
#1020
Conversation
🤖 Coverage Update
To this point, this PR:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea. We will want to remove the warning when using target remote
I'm not sure if we really want to remove the warning, since the initialization is partial (we don't initialize the |
Oh and btw, do you want me to implement the same thing for |
🤖 Coverage Update
To this point, this PR:
|
|
🤖 Coverage Update
To this point, this PR:
|
I'm not sure if I broke the pipeline ? The errors do not seem to be related to my code, but apparently it appeared just after my last commit ? |
CI is broken because of it installing python3.12 and that changing some stuff. We will get it sorted. Sorry for the slow work on this PR. Holiday time can be busy. |
If you rebase onto main after #1022 the tests should pass. |
🤖 Coverage Update
To this point, this PR:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @ValekoZ
This look just great to me! Thanks for the contribution!
Do you mind adding a simple test (for instance in https://github.com/hugsy/gef/blob/main/tests/commands/gef_remote.py) for it? It'll help making sure we don't break anything in the future.
Also a note in the docs mentioning we override the native target
commands. I'm normally not a fan of overriding native commands, but I think it's fair that target remote
is special. So just having a doc explaining it gives us a quick answer when people asks why it acts differently.
After that, it'll be good for merging.
Maybe we should add an option to disable the post-hook for those who want the default behavior ? |
🤖 Coverage Update
To this point, this PR:
|
Probably a good idea now that you mention it. Don't worry about the error from the coverage message, seems like a Github issue. |
🤖 Coverage Update
To this point, this PR:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 , tests are passing too (ignoring the CI failure, my fault)
LGTM, thanks for your patience @ValekoZ
I think it's ready to merge, any pending request on your end @Grazfather ?
Description
As mentioned in Gallopsled/pwntools#2264, gef does not work properly with many tools that rely on the
target remote
command.In this PR, I propose a fix that uses a remote posthook in order to instantiate and setup the GefRemoteSessionManager after the connection being established.
Note that this isn't a perfect solution since we do not have all the information needed for a proper instantiation of the GefRemoteSessionManager, but it seems to be a good workaround in order to make tools like
pwntools
work correctly with gef.