Category Archives: Virtual Machines

Arch and Virtualboxing

Today after upgrading Virtualbox on my Arch host I found that I could no longer run Virtualbox.

$ virtualbox
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
available for the current kernel (4.4.3-1-ARCH) or it failed to
load. Please recompile the kernel module and install it by

sudo /sbin/rcvboxdrv setup

You will not be able to start VMs until this problem is fixed.

As told I could not boot any of my VMs.

It was not possilbe to run sudo /sbin/rcvboxdrv setup, all I got was another error message:

Unloading modules:
Loading modules: modprobe: FATAL: Module vboxnetadp not found in directory /lib/modules/4.4.3-1-ARCH
modprobe: FATAL: Module vboxnetflt not found in directory /lib/modules/4.4.3-1-ARCH
modprobe: FATAL: Module vboxpci not found in directory /lib/modules/4.4.3-1-ARCH
modprobe: FATAL: Module vboxdrv not found in directory /lib/modules/4.4.3-1-ARCH

After banging my head and reinstalling Virtualbox I found out that the problem is that virtualbox-host-modules package were simple removed. I suspect the dependency became broken when installing either the new arch kernel or the new Virtualbox package.

Solution:

Simply reinstall the host modules again

# pacman -S virtualbox-host-modules

You will need to manually load the modules the first time:

# modprobe vboxdrv

or reboot.

 

 

Breaking that virtual machine

Have you ever forgotten your root password and thought about ways to recover it? It is possible to change it but that also means it’s possible to hack your computer. In this post we take a look how to use a live USB and chroot to gain root access.

Table of content:

Introduction


All modern distros comes with a live version, where you don’t need to install the OS but are able to run Linux directly from CD/USB. This is perfect when you need to emergency repair your main OS. However if you are able to boot from another device you  can also access the files on any available hd. This can be used to change password on an installed Linux, for good or bad.

I was surprised how easy this was to boot up from a live USB and then just use chroot to be able to use passwd to change the  and from now on I will make sure to protect my machine better. Is it possilbe to break a VM with the same method? Of course! Let’s get started.

 

0 – Installing the tools


First install a guest that you want to break into. See previous post Let’s call it Guest A. In this guide I’ll use Lubuntu* and like for most Ubuntu clones it means there’s no root password, but all we need is a admin password. If you use another distro you probably just want to change the root password. Don’t add any encryption or UEFI support (we talk more about this later).

* I found out that Lubuntu got problem to add encryption, so you probably don’t want to use it. A good alternative is Xubuntu.

Next we want a Linux live USB. You can skip this step and boot from the Lubuntu CD, our VM will always have a CD drive but some real world machines doesn’t these days so it’s a good exercise to practice with a virtual USB. An option to create a virtual USB is that you use a real USB and add a filter for it under USB settings.

Add a new HD to Guest A.

Go to Storage and click on the hd with a green plus. Create a 8 Gb drive and check the “solid state drive” and “hot pluggable” check boxes. I have named it liveusb.vdi as seen below.

create_hd

Keep the live CD and boot up (either live or Guest A).  Use lsblk to check what hd’s we have:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0 20,5G  0 disk
├─sda1   8:1    0 16,5G  0 part /
├─sda2   8:2    0    1K  0 part
└─sda5   8:5    0    4G  0 part [SWAP]
sdb      8:16   0    8G  0 disk
sr0     11:0    1  744M  0 rom  /media/zabbat/Lubuntu 15.10 amd64

As we can see, sda is for Guest A , sdb is our new hd for the live usb and sro contains the Live CD. Let’s copy the CD to sdb using dd. I know dd is synonym for disk destroy, but that’s why I like VM, the damage is at least restrained to your guest OS.

#dd if=/dev/sro of=/dev/sdb

lsblk should now show sdb as:

sdb      8:16   0    8G  0 disk
├─sdb1   8:17   0  744M  0 part
└─sdb2   8:18   0  2,2M  0 part

1 – Booting Up


Now let’s boot from the live USB. There’s two ways you can make your system boot from it. You can either mash F12 at VM start up and select the drive. Other wise you can assign the hd to the lowest SATA port number of your hard drives from the storage menu. In the real world boot menu might be locked, but in virtualbox it’s not possible to do so.

Start the live USB without installing, then open a terminal.

Mount Guest A’s root partition to /mnt. In our case you could see that only sda1 can possible be a root partition, sda2 is too small and probably reserved for boot record and sda5 is 4 GB swap.

#mount /dev/sda1 /mnt

then let’s change the fs root:

#chroot /mnt

Now you have root privilege in Guest A’s file system.

In ubuntu clones you normally don’t have a root user. To find the user name you want to change password for check either /etc/passwd or /etc/group. Let’s open group and see who’s in admin or sudo group.

#vi /etc/group

my file says something like:

sudo:x:30:zabbat

So let’s change zabbat’s password to 123456:

#passwd zabbat

We’re done! Exit from chroot and reboot. Remember to change back the boot order.

When Guest A promts to log in, select zabbat as user and 123456 as password.

2 – Protection


Since you are mounting the file system you can protect it by encrypting your drive. It is not enough to choose “encrypt my home folder” that is a popular choice for ubuntu clones. Your home folder is quite unintresting when it comes to getting your password. Depending on your distro and partition set up it varys what folders you need to encrypt. Don’t take any risk, encrypt everything, since chroot will make it possible to read and edit sensitive files. For an example, one could go to your /etc/passwd and change so that root do not require any password at all.
VirtualBox_un_ubuntu_16_12_2015_15_01_57
A note, while I was creating an ecrypted installation of Lubuntu I noticed that there’s a bug that stops you from encrypting. I tried Xubuntu instead as seen above and it worked.

Conclusion


If some one has physical access to your computer it is incredible easy to hack it. If you have a laptop there really is no excuse for not encrypting your drives, if you loose it without encryption you can assume they break into it.
For VM there’s no need to have physical access to the computer. Someone could SSH into the host and break your guest OS. All they need is permission to edit the VM so that it boots from a live CD/USB, or perhaps from the network.

“Where’s my phone” flowchart

When you are setting up your android development environment it’s common that you can’t detect you USB device. The following flowchart is to make troubleshooting easier. The environment is Linux host with virtualbox installed and a Linux guest. If you are not using a virtual machine you can go directly to “Does guest ‘lsusb’ detect the device”

 

usb

Worst case scenario is to not finding the device on neither host or guest.

virtualbox – OS development and debugging

The Debugger for virtualbox is somewhat unknown. There are not a lot of resources online about it and it is not even visible by default. However it is a really powerful tool that makes the sensitive and low level implementation of OS much easier.

See my earlier post how to enable the debugger on a windows host.

Introduction

I have followed the code in the little book of OS development and reached chapter 5 about segmentation. Segmentation is a low level task that is best suited for pure assembler which makes it very difficult to know if you did anything wrong. Or more precisely, it is difficult to know what you did wrong, since an error will generate a crash. Logging or printing to the screen will often not help you.

The debugger gives you a tool to observe your system from the outside, relatively immune from the crash and with plenty of command to show low level info such as registers and address locations.

Writing “help commands” will give you a huge list of debug commands. You can see more info about the separate commands by typing “help <command>”

Finding points of interests

The first thing to do is to find where in memory interesting code is. Looking for hex pattern is quite difficult. A better option is to look for strings used by the OS. For an example, I have the string “Good bye sir” once the kmain function is done, before the infinity jmp loop (see the OS Development).

Searching for a string can be made by sa <range> <pattern>.

If you have a string, let’s say “Good bye sir” you can search for where it is in memory with:

>sa 0 “Good bye”

The output should be something like:

VBoxDbg> sa 0 “Good bye”
%%000000000010054a: 47 6f 6f 64 20 62 79 65-20 73 69 72 2e 0a 00 00 Good bye sir….

Next we would like to see what else there is in the memory next to the “Good bye string”. Displaying byte info about a memory area is done by db <address>

Usually your code is in the nearby of strings if you have made a small assembler program for booting (but it is certainly not true for larger programs).

VBoxDbg> db 10054a
%000000000010054a: 47 6f 6f 64 20 62 79 65-20 73 69 72 2e 0a 00 00 Good bye sir….
%000000000010055a: 00 00 02 b0 ad 1b 00 00-00 00 fe 4f 52 e4 b8 be ………..OR…
%000000000010056a: ba fe ca bc 04 18 10 00-e8 89 fa ff ff eb fe 00 …………….
%000000000010057a: 00 00 14 00 00 00 00 00-00 00 01 7a 52 00 01 7c ………..zR..|
%000000000010058a: 08 01 1b 0c 04 04 88 01-00 00 1c 00 00 00 1c 00 …………….
%000000000010059a: 00 00 64 fa ff ff 64 00-00 00 00 41 0e 08 85 02 ..d…d….A….

There are no more strings after that line. Then the data below might be executable instructions. You can show what the hex is in assemble by  u32 <address>

If we take a look at the memory address we got above:

VBoxDbg> u32 10055a
%000000000010055a 00 00 add byte [eax], al
%000000000010055c 02 b0 ad 1b 00 00 add dh, byte [eax+000001badh]
%0000000000100562 00 00 add byte [eax], al
%0000000000100564 fe 4f 52 dec byte [edi+052h]
%0000000000100567 e4 b8 in AL, 0b8h
%0000000000100569 be ba fe ca bc mov esi, 0bccafebah
%000000000010056e 04 18 add AL, 018h
%0000000000100570 10 00 adc byte [eax], al
%0000000000100572 e8 89 fa ff ff call 000100000h
%0000000000100577 eb fe jmp -002h (000100577h)

As you can see, there is the “cafebabe”, a call to where we placed our kernel (“call 000100000h”) and the endless jump loop in the end “jmp -002h”.

We want to pause the program so we need to add a BP. There are several options for this. I use br <address>

I’m not sure about the  the difference between bp and br. However my system crashed if I try to use bp. I suggest that you try both.

>br 100577

If you want to see all your BP use bl

VBoxDbg> bl
0x4 e 1 r 0000000000100577 0000 (0000 to ~0)

Now we have paused our program. If we would like to execute the next command/trace we can do that by t

VBoxDbg> t
dbgf event: Single step! (rem)
eax=00000000 ebx=0002cd80 ecx=0000000d edx=0000001b esi=0002cef0 edi=0002cef1
eip=00100577 esp=00101804 ebp=00067ee0 iopl=0 nv up di pl zr na po nc
cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 eflags=00000046
0008:00100577 eb fe jmp -002h (000100577h)

Perhaps not a very useful BP since it is in the jmp loop.

There are plenty of nice dump commands, example to check your GDT like you set up in chapter 5 you can use dg

VBoxDbg> dg
0008 CodeEO Bas=00000000 Lim=fffff000 DPL=0 P NA G BIG AVL=0 L=0
0010 DataRW Bas=00000000 Lim=fffff000 DPL=0 P NA G BIG AVL=0 L=0

 

A problem when debugging is that you often need to set a BP before  the OS boots up, because the OS won’t halt and you will miss the code execution point. For a simple OS you can often reuse the same memory address, like 0x100577, and if you followed the OS book then 0x100000 will be the C code entry. The VM will start in a paused state, so add the BP and then resume.

virtualbox – The Little Book About OS Development

Since I want to learn more about Linux  Device Driver development I need to learn more how the OS work from scratch. There are many tutorials about the Linux kernel, but they are often too heavy. I need a guide that show me in small steps how to set things up. There is a one great tutorial:  The little book about OS development. I am really happy that the authors put up all the effort to write this and publish it for free! It is not Linux but it is still based on the same problems that most OS has to deal with during boot up.

Note that it is a bit “old school”, some techniques are not well suited for developing a real OS, how ever if you like me want to get a better understanding of multitasking, virtual memory IRQ and such it is perfect. IF you plan to make a real OS you should read beginners mistakes at the Osdev wiki, quite a lot of these faults are in the little book. Another thing to keep in mind is that most links are outdated, I found this tutorial to be very well written (down to explaining the chip architecture!)

I am a big fan of virtualbox so I decided to update the tutorial with how to use it instead of the brosh emulator that is used in the book.

You could either develop directly on a Linux host. This will save you time. However I’m on a windows host and I will use a Linux Guest to develop on. If you use Linux as a host you can skip the part about exporting the iso-file.

Preparations

Let’s follow until the first step of the book: hello CAFEBABE

We need to create a guest OS that will run the compiled OS. Let’s call it guest C (as Compiled or CAFEBABE). You can optionally develop from a guest Linux OS. If you are on a host Linux this is not needed. Let’s call this OS guest L.

First create guest C:

  • No EFI ( let’s not make it complicated)
  • Don’t create any HD. We will boot from the ISO.

Optional. Set up Guest L:

  • Add a shared folder and name it osdev. Enable auto mount.
  • In guest L, add your user to vboxfs group: $adduser $USER vboxfs. Reboot.

Let’s make an export script*. Create a file create_iso. Add the gensioimage command and copy the iso to the shared folder:

#!/bin/bash
genisoimage -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -A os -input-charset utf8 -quiet -boot-info-table -o os.iso iso
#copy iso to shared folder
cp os.iso /media/sf_osdev

This is a very simple script. You should probably add some error handling if an iso couldn’t be created.

*In later chapters we will use a make file. I suggest to add the cp line in that make file:

os.iso: kernel.elf
cp kernel.elf iso/boot/kernel.elf
genisoimage -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -A os -input-charset utf8 -quiet -boot-info-table -o os.iso iso
cp os.iso /media/sf_osdev/

Running the guest and debugging

Once you got the iso (if you exported from guest L it will be in osdev folder on your host) you can add it to an optic drive on your C guest. Running it is not very fun, since you can’t see any registers – we need to enable debugging.

By default debugging is disabled, see the manual. There are a couple of options to enable it. For Linux it is quite easy since it is a command line friendly OS. If you use Windows as host the easiest will be the following option (quoted from the manual):

“Set the VBOX_GUI_DBG_ENABLED or VBOX_GUI_DBG_AUTO_SHOW environment variable to true before launching the VirtualBox process. Setting these variables (only their presence is checked) is effective even when the first VirtualBox process is the VM selector window. VMs subsequently launched from the selector will have the debugger enabled.”

In Windows this is done by opening a command promt and entering the following:

>xset VBOX_GUI_DBG_ENABLED true
>xset VBOX_GUI_DBG_AUTO_SHOW true

Restart virtualbox and start guest C.

It is paused by default, so press ctrl  p. You will see info that the kernel is loaded. To see the 32 bit registers use the debug command: rg32:

 

debug

As you can see there’s a CAFEBABE in eax.