Skip to content
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

Libvmi driver for remote debugging with GDB #4

Open
Wenzel opened this issue Mar 16, 2019 · 3 comments
Open

Libvmi driver for remote debugging with GDB #4

Wenzel opened this issue Mar 16, 2019 · 3 comments

Comments

@Wenzel
Copy link

Wenzel commented Mar 16, 2019

Hi !

I wanted what are the plans for the future of ramooflax ?

I would be interested in an integration with Libvmi, in order to use ramooflax with a debug stub to analyze the bios and the OS boot sequence with my favorite GDB frontend.

I have been working on a GDB stub on top of LibVMI: pyvmidbg

would you be interested in such an approach ?

Thanks !

@sduverger
Copy link
Collaborator

Hello,

I wanted what are the plans for the future of ramooflax ?

Not working on it for a long time :(

I would be interested in an integration with Libvmi, in order to use ramooflax with a debug stub to
analyze the bios and the OS boot sequence with my favorite GDB frontend.

From what i understand in your pyvmidbg project, you implement the GDBserver stub in userland and provide a glue through libVMI with the VMM.
Ramooflax implements a very basic GDB stub, but this is something you would get rid of ?

This is pretty interesting to interface with standards such as libvmi. Do you have some pointers to the API i need to conform to in ramooflax, kind of "debug_ops".

I can find some time to implement that, or if the force is with you you can provide me with a PR.
Let me know and thanks for your suggestion.

You can also write me at firstname.lastname at gmail

@Wenzel
Copy link
Author

Wenzel commented Mar 19, 2019

From what i understand in your pyvmidbg project, you implement the GDBserver stub in userland and provide a glue through libVMI with the VMM.

Yes the main goal is to provide a set of debugger stubs, supporting multiple protocol, and therefore multiple frontends, on top of libvmi.
I'm not providing the glue to the hypervisor, that's the job of Libvmi and the drivers.

Ramooflax implements a very basic GDB stub, but this is something you would get rid of ?

I read that you had a remote control python API, not a GDB stub, that's why I asked.
Although, I aim to develop a standard and unified debugging interface accross hypervisors.

Do you have some pointers to the API i need to conform to in ramooflax, kind of "debug_ops".

Libvmi lacks a bit of developer oriented documentation.
Reading the source code is the best option.
I can point you to a driver made by a GSoC student for Bareflank
libvmi/libvmi#693

I can find some time to implement that, or if the force is with you you can provide me with a PR.

I won't have time to work on this anytime soon either.
My focus is on pvmidbg ATM.
But I wanted to know how it could be used on top of ramooflax or PulseDBG in the future :)

Thanks !

@sduverger
Copy link
Collaborator

sduverger commented Mar 19, 2019

The python API is an extension of the GDB protocol to inspect the VM with super powers :)
However it was only designed for ramooflax (not via gdb "monitor" command)

Although, I aim to develop a standard and unified debugging interface accross hypervisors.

Perfect, once ready you will be able to tell me what i need to add to ramooflax to get access to registers/memory/events. The internal mechanic is already present: soft/hard breakpoints, memory monitoring, cr3 tracking, events redirection/injection/interception, system registers access.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants