added support for remotely specifiying debugee and re-running targets #50
Conversation
| @@ -3246,22 +3246,25 @@ class RemoteCommand(GenericCommand): | |||
| def __init__(self): | |||
| super(RemoteCommand, self).__init__(prefix=False) | |||
| self.add_setting("proc_directory", "/proc") | |||
| gdb.events.cont.connect(self.continue_handler) | |||
There was a problem hiding this comment.
Is there any particular reason you've chosen to add a GDB continue event handler instead of gdb.events.new_objfile?
Not that I care so much about performance, but your handler will be executed every time GDB continues an execution. By the look of your patch, I believe new_objfile would be more appropriate, but maybe there is a reason you did not use it.
There was a problem hiding this comment.
You are completely right, new_objfile is the better solution, I simply overlooked it when reading the docs. I'll fix it today if I have time or else tomorrow.
|
No worries at all. I will review your code when you re-submit. And also, since we are adding a new feature, I would ask you to add the proper documentation about it in the file Cheers, |
|
I played around with This new patch makes it so that all remote features should work even if you manually connect with the What I implemented is dynamic detection of remote debugging and lazy loading + local caching of remote files. For instance if gef tries to access Additionally, I expanded the "download all libs" feature (-A): It previously only downloaded the libraries currently loaded at the time you attach, now it listens on However there is still one major problem which existed before and I didn't fix: /proc/$pid/maps is only fetched once and never updated afterwards. With my patch you could change the "True" in line 1519 to "False" to disable the cache, but I found that |
|
I really like your ideas, but your diff is actually hard to read because it appears that you've manually merged some newly pushed commits, instead of git-rebasing. Can you rebase against the HEAD of the master branch and resubmit a "clean" patch ? Regarding your note on /proc/$pid/maps, I rely on the function |
|
Looks like I got the version of the script I based the changes on mixed up the second time - sorry for that! Regarding the def __call__(self, *args):
if args not in self.cache:
value = self.func(*args)
self.cache[args] = value
return value
return self.func(*args)The last line is probably supposed to be Is the user supposed to reset the cache manually with |
|
I've updated the For the moment yes, the user manually resets the cache, but in real life I never had to call it. I believe a better approach would be also to add a Thanks for your feedbacks to make gef better! Cheers, |
|
Why not use the built in memoizer, lru_cache? |
| It is possible to use `gef` in a remote debugging environment. | ||
| It is possible to use `gef` in a remote debugging environment. Required files | ||
| will be automatically downloaded and cached in a temporary directory (`/tmp/gef` on most | ||
| Unix systems). Remember to manually delete the cache if you change the target file or |
There was a problem hiding this comment.
Can't it use the info file information or something to at least get the binary name, and not sure an old binary ?
There was a problem hiding this comment.
I believe it is better to rely on gdb.events instead. That is the only way to trigger some actions when the target binary has changed, and only when it has changed.
|
|
|
Ah that makes sense. Hopefully the memoization fix will speed gef up noticeably. |
|
@Grazfather : Yeah me too 😄 I don't know when the first version of the @jr64 : I'll definitely have a look in the next few days at how to use a |
|
@hugsy : Great to hear, I'm looking forward to it. |
… new_objfile to detect when cache should be resetted
|
Hi @jr64 From all the tests I did, now Cheers, |
|
Hey @hugsy For instance, if you have a breakpoint before and after mmaping a file, those new changes will not be reflected in In my opinion, the best solution would be to explicitly invalidate the Imho accurately displaying the memory-layout at all times is really important, especially for exploit development and well worth the little bit of overhead. |
|
Hey @jr64 I totally agree, having an accurate view of the process memory layout is primordial. Waiting for the user to re-type Refreshing the cache at breakpoints might do the trick. Need more tests... |
|
@hugsy I meant resetting the cache when executing If you don't want to do that, I think documentation should be more clear - most users probably wouldn't expect that |
|
It's not so much that I'm against implementing it, I just don't think it is the best approach. Need more time to think about it though. I would prefer an automated approach, preferably based on events or something similar. In any case, yes I'll add a note on the |
|
I think you are right, hopefully you can find a more "complete" solution to the problem. Anyways, I fixed the merge conflict, looking forward to your review. |
|
iz all guud 😄 thanks for your contrib ! |
|
And the note regarding the cache was added in commit c842e4c. |
|
Great to hear, thank you very much! |
ghost
mentioned this pull request
…d and new_objfile to detect when cache should be resetted
added support for remotely specifiying debugee and re-running targets
Hi, I've added a new option to gef-remote so you can tell the gdbserver which executable you want to run. Additionally this patch allows you to restart processes and specify arguments (when you are connected in extended-remote mode).
Example (server started with
gdbserver --multi 0.0.0.0:1337):And (
gdbserver 0.0.0.0:1337 /bin/ls):This works by adding a hook to gdb that downloads the remote info each time "continue" is executed and the PID has changed since the last time.
One thing I had to change to make this work is that in extended-remote mode,
setup_remote_environmentno longer uses thefilecommand on the local, downloaded file because then the nextrunwould start the local file instead of the remote one. I hope this doesn't break anything in the other commands.