search

airbus-seclab / ramooflax

a bare metal (type 1) VMM (hypervisor) with a python remote control API
178 stars 35 forks source link

Libvmi driver for remote debugging with GDB #4

Open Wenzel opened 5 years ago

Wenzel commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/libvmi/libvmi/pull/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 commented 5 years ago

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.