Tag Archives: hack

IKEA Hackers: LackRack

Among the hundreds of hacks from the fantastic website IKEA Hackers, one is particularly interesting.

How to build a rack with an IKEA lack table worth less than 10 euros?
Well, with this manual:

The best of the LackRack (after its price) is that its construction is modular and you can grow it with your needs:

5x LackRack

The LackRack is the ultimate, low-cost, high shininess solution for your modular datacenter-in-the-living-room. It is said that Google engineers were the first to explore the idea of using lack tables for data centers. The LackRack is so famous that even has its own website: http://lackrack.org/ 😀

Unlocking a LUKS encrypted root partition remotely via SSH

If you are thinking on sending a new server to a remote datacenter for colocation or you have rented one or more servers in the cloud, probably you have thought that you would like to encrypt your server’s hard disk.

The problem is that if you encrypt the whole hard disk (the root partition) you will need some kind of KVM to type the password remotely every time the server is restarted … sure??? No!

Thanks to this nifty trick, you can enter the password remotely during the boot process. The trick involves embedding a small ssh server (dropbear) in the initramfs that allows you to enter the password remotely for the root partition at boot time.

For those who are lucky enough to use Debian, the procedure is so simple and easy as ::

1) Install your server with the root partition encrypted.

2) Install the required packages:

apt-get install openssh-server dropbear busybox

3) Copy the SSH key that has been generated automatically

scp root@my.server.ip.addr:/etc/initramfs-tools/root/.ssh/id_rsa ~/id_rsa.initramfs

4) If your server gets the IP address automatically (DHCP) ignore this step, otherwise you have to specify the IP configuration at the Kernel boot line. To do this edit the file /etc/default/grub and define the line:


Using the format specified in the file Documentation/nfsroot.txt of the Linux kernel documentation. For example:


Reload the grub configuration


5) Reboot


6) And unlock remotely!

ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" \
	-i "~/id_rsa.initramfs" root@my.server.ip.addr \
	"echo -ne \"MyS3cr3tK3y\" >/lib/cryptsetup/passfifo"

And for those not lucky enough to use Debian, and also for those who have such luck, but want more details on this procedure, I am pasting here the archive cryptsetup/README.remote from Debian that I am sure that you will find very useful :)

$ zcat /usr/share/doc/cryptsetup/README.remote.gz

unlocking rootfs via ssh login in initramfs

You can unlock your rootfs on bootup from remote, using ssh to log in to the
booting system while it's running with the initramfs mounted.


For remote unlocking to work, the following packages have to be installed
before building the initramfs: dropbear busybox

The file /etc/initramfs-tools/initramfs.conf holds the configuration options
used when building the initramfs. It should contain BUSYBOX=y (this is set as
the default when the busybox package is installed) to have busybox installed
into the initramfs, and should not contain DROPBEAR=n, which would disable
installation of dropbear to initramfs. If set to DROPBEAR=y, dropbear will
be installed in any case; if DROPBEAR isn't set at all, then dropbear will only
be installed in case of an existing cryptroot setup.

The host keys used for the initramfs are dropbear_dss_host_key and
dropbear_rsa_host_key, both located in/etc/initramfs-tools/etc/dropbear/.
If they do not exist when the initramfs is compiled, they will be created
automatically. Following are the commands to create them manually:

# dropbearkey -t dss -f /etc/initramfs-tools/etc/dropbear/dropbear_dss_host_key
# dropbearkey -t rsa -f /etc/initramfs-tools/etc/dropbear/dropbear_rsa_host_key

As the initramfs will not be encrypted, publickey authentication is assumed.
The key(s) used for that will be taken from
If this file doesn't exist when the initramfs is compiled, it will be created
and /etc/initramfs-tools/root/.ssh/id_rsa.pub will be added to it.
If the latter file doesn't exist either, it will be generated automatically -
you will find the matching private key which you will later need to log in to
the initramfs under /etc/initramfs-tools/root/.ssh/id_rsa (or id_rsa.dropbear
in case you need it in dropbear format). Following are the commands to do the
respective steps manually:

To create a key (in dropbear format):

# dropbearkey -t rsa -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear

To convert the key from dropbear format to openssh format:

# /usr/lib/dropbear/dropbearconvert dropbear openssh \
	/etc/initramfs-tools/root/.ssh/id_rsa.dropbear \

To extract the public key:

# dropbearkey -y -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear | \
	grep "^ssh-rsa " > /etc/initramfs-tools/root/.ssh/id_rsa.pub

To add the public key to the authorized_keys file:

# cat /etc/initramfs-tools/root/.ssh/id_rsa.pub >> /etc/initramfs-tools/root/.ssh/authorized_keys

In case you want some interface to get configured using dhcp, setting DEVICE= in
/etc/initramfs-tools/initramfs.conf should be sufficient.  The initramfs should
also honour the ip= kernel parameter.
In case you use grub, you probably might want to set it in /boot/grub/menu.lst,
either in the '# kopt=' line or appended to specific 'kernel' line(s).
The ip= kernel parameter is documented in Documentation/nfsroot.txt in the
kernel source tree.


Don't forget to run update-initramfs when you changed the config to make it

Collecting enough entropy for the ssh daemon sometimes seems to be an issue.
Startup of the ssh daemon might be delayed until enough entropy has been
retrieved. This is non-blocking for the startup process, so when you are at the
console you won't have to wait for the sshd to complete its startup.

Unlocking procedure

To unlock from remote, you could do something like this:

# ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" \
	-i "~/id_rsa.initramfs" root@initramfshost.example.com \
	"echo -ne \"secret\" >/lib/cryptsetup/passfifo"

This example assumes that you have an extra known_hosts file 
"~/.ssh/known_hosts.initramfs" which holds the cryptroot system's host-key,
that you have a file "~/id_rsa.initramfs" which holds the authorized-key for
the cryptroot system, that the cryptroot system's name is
"initramfshost.example.com", and that the cryptroot passphrase is "secret"

-- <debian@x.ray.net>, Wed, 30 Sep 2009

Workaround for the time drift issue on Xen: keep your guests synced

Suppose that you want to keep the clock of one or more Xen guests synchronized with a NTP server and the Xen Host has the clock desynchronized. Also to screw things more you don’t has access to the Xen host so you can’t simply fix the clock of the Host. What can you do?

In order to be able to change the clock time of your guest you need to activate the independent_wallclock bit , and then you will be able to sync it.

echo 1 > /proc/sys/xen/independent_wallclock

But if you left this bit enabled soon you will notice some weird problems:

# ping google.es
PING google.es ( 56(84) bytes of data.
Warning: time of day goes back (-21us), taking countermeasures.
Warning: time of day goes back (-23us), taking countermeasures.
64 bytes from lhr14s02-in-f104.1e100.net ( icmp_seq=1 ttl=47 time=0.000 ms
Warning: time of day goes back (-21us), taking countermeasures.
64 bytes from lhr14s02-in-f104.1e100.net ( icmp_seq=2 ttl=47 time=0.000 ms
Warning: time of day goes back (-21us), taking countermeasures.

# date; date; date; date; date
Wed Sep 29 19:04:06 CEST 2010
Wed Sep 29 19:04:05 CEST 2010
Wed Sep 29 19:04:06 CEST 2010
Wed Sep 29 19:04:06 CEST 2010
Wed Sep 29 19:04:05 CEST 2010

Amazing huh?? looks like the Xen project is developing in secret the time travel algorithm.

The trick is that you must disable the bit independent_wallclock as soon as you has your clock synchronized and everything will work as expected.

echo 0 > /proc/sys/xen/independent_wallclock

Obviously this issue will prevent you to use a NTP daemon like ntpd / openntpd. So the simplest solution is to deploy a cron job that will sync your clock with ntpdate.

So, here is my cron.daily script to keep in sync the clock of the xen guests:

#! /bin/bash
# This is a DIRTY hack to allow have time settings correctly on Xen guests
# clopez@igalia.com
echo 1 > /proc/sys/xen/independent_wallclock
ntpdate -b pool.ntp.org 0.debian.pool.ntp.org hora.roa.es
echo 0 > /proc/sys/xen/independent_wallclock

If your Xen guest is proxied and don’t has direct access to Internet then you can use htpdate

#! /bin/bash
# This is another DIRTY hack to allow have time settings correctly on proxied Xen guests
# clopez@igalia.com
echo 1 > /proc/sys/xen/independent_wallclock
htpdate -s -P IP.ADDRESS.OF.PROXY:PORT www.linux.org www.google.com www.debian.org www.redhat.com
echo 0 > /proc/sys/xen/independent_wallclock

Hope this help you and you don’t have to waste your time thinking about how to fix the time as I did 😉

War Games

I have discovered a funny and didactic online game where you can test and improve your hacking skills. The objective of the game is to hack a Linux server and scale user privileges.  You start with user level1 and you must exploit several bugs on the system to get access to the highest levelX that you can achieve.

There are various game servers each one with different bugs that you can exploit to level up. When you get access to a level you can leave your firm on the server.

For example you can try the game blowfish that I love (currently I am stuck at level5 )

Telnet to blowfish.smashthestack.org port 6666 to recieve an encrypted passwd.
#decrypt it and log in to level2 (If you are too lazy to decrypt it google can help you)
ssh level2@blowfish.smashthestack.org -p 2222
#follow the hints and try to get access to level13

Your mission is not to get root (but if you do you would win the medal of honor 😉