softwarebakery.com

Persistent Kali Linux in DriveDroid

frozencow@gmail.com (FrozenCow) — Fri, 06 Mar 2015 11:31:00 +0000

Using Linux Live ISO images is convenient. Easy to install and always have the same environment each time you use it. However, it doesn't save your changes between uses. Sometimes you want to install additional applications and use it each time your boot. This is called a persistent live USB.

Kali Linux is a Linux distribution used primarily for penetration testing. It comes with various tools that are useful to test your networks and applications for vulnerabilities. It also has good support for persistence.

In this tutorial we will show how set up persistence for Kali Linux that is running from an Android phone using DriveDroid.

Requirements

A Linux installation with gparted
A paid version of DriveDroid (for resizing images)
An USB cable

Downloading Kali Linux

First go to DriveDroid on your Android phone. Press the + button in the bottom of the screen and choose 'Download image...'. In the list of distributions choose 'Kali Linux' and choose a non-mini Kali Linux image that fits your needs. The mini images are not suitable for live environments and are just to run the installer. For this example we used kali-linux-1.1.0-amd64.iso. Wait for the download to complete.

Resizing the image

The image that we just downloaded barely fits the basic installation of Kali Linux. To install extra software we need some additional space. This is why we need to resize the image.

Go back to DriveDroid and long-press kali-linux-1.1.0-amd64.iso. Choose 'Resize image...' and enter a bigger size for the image. For this example we used 3GB. Wait until the image has been resized.

Creating the persistence partition

The image now has some free space where we can create a partition that will be used for persistence.

In DriveDroid press kali-linux-1.1.0-amd64.iso and choose to host the image as an writable USB drive. Connect your phone to your PC and start gparted (sudo gparted).

In gparted find the disk that your phone is hosting. In this example it should show up as a 3GB disk. Do note the name of the disk, since we need it later. In this example it is named /dev/sdX. After selecting /dev/sdX, you should see that the disk has a bunch of unallocated space; the space we created by resizing the image.

Next add a new partition. Use 'ext4' as the file system and 'persistence' as the label. Press 'Ok' and see if the partition indeed fills the unallocated space. After that press 'Apply' and close gparted.

Configuring Kali Linux

Now that we have a partition where Kali Linux can store extra applications and files, we need to configure Kali Linux to actually use that partition.

First make sure you're root:

sudo su

We will make a temporary directory where we can mount the configuration partition of Kali Linux:

mkdir -p /tmp/kalilinux

Next, we mount the partition:

mount /dev/sdX3 /tmp/kalilinux

We add the persistence configuration file that Kali Linux will use when booting:

echo "/ union" > /tmp/kalilinux/persistence.conf

Lastly we unmount the partition:

umount /tmp/kalilinux

The image should now be good to go. Reboot your PC and boot from your phone to check the results.

Increase the persistent space

If you ever find out that you run out of space in Kali Linux, you can still increase the size of the persistence partition.

Go to DriveDroid and long-press kali-linux-1.1.0-amd64.iso. Choose 'Resize image...' and enter a bigger size for the image.

Now host the image by pressing kali-linux-1.1.0-amd64.iso and choosing a writable USB drive. Open up gparted and choose the disk like before.

Instead of adding a partition like we did before, we will change the size of the already existing persistence partition. Right click on the persistence partition and choose 'Resize/Move'. Increase the new size so that there is no free space left. Press 'Resize/Move', hit 'Apply' and close gparted.

Your image should again be ready to go with more space for your applications.

Building the Android kernel on Linux

frozencow@gmail.com (FrozenCow) — Fri, 19 Dec 2014 14:30:00 +0000

When you want to add extra functionality to your kernel, you want to develop your own functionality or just want to have your own version of the kernel, you will want to build kernel code.

In this tutorial we will go through the whole process of retrieving, compiling, (optionally) patching and flashing kernels that are based on AOSP. As an example we will use the kernel of the Nexus 5 (hammerhead). We'll presume this is all done on a Debian or Ubuntu machine, since that is most popular while still practical.

Requirements

On Debian/Ubuntu you need the following packages:

git
build-essential
abootimg
adb and fastboot

Install these using:

sudo apt-get install git build-essential abootimg

And install the Android SDK as described here to get adb and fastboot.

Retrieving the kernel

Check what kernel your phone needs on https://source.android.com/source/building-kernels.html.

In this example we'll build the kernel for the Nexus 5. The code-name of the Nexus 5 is hammerhead, which is listed in the table under 'Figuring out which kernel to build'. Take note of the 'Build configuration' (in this example: hammerhead_defconfig) and 'Source location' (in this example: kernel/msm). We see these coming back in later steps.

Next we look up what exact version of the kernel we want to retrieve. We open up Google's git repository of your device online by going to the following URL:

https://android.googlesource.com/kernel/msm

Note that you need to replace kernel/msm with the 'Source location' of your device.

On that page you can look under 'Branches' to see the different versions available. In this example we will be using android-msm-hammerhead-3.4-lollipop-release.

Next we retrieve the kernel from Google by using the following:

git clone https://android.googlesource.com/kernel/msm --branch android-msm-hammerhead-3.4-lollipop-release linux

Note that you need to replace kernel/msm with the 'Source location' of your device and replace android-msm-hammerhead-3.4-lollipop-release with the branch of your device.

This retrieves all source code (and its history) from Google and places it all under a new directory called linux.

Patching the kernel

This step isn't needed if you just want to build your own kernel. Continue with [Compiling the kernel](#Compiling the kernel) if that's the case.

A note on patches: patches come in all kinds of forms. There are files (.patch or .diff) that simply contain changes to certain lines in certain files. Patches are also embedded in version control systems, like Git. There are different ways to retrieve them and different ways to apply them.

Secondly, patches won't always fit perfectly onto your current code. When a patch cannot be applied to your kernel means that there have been changes made in sections that the patch also touches. These are called conflicts. These conflicts must be solved by the user. We will not cover conflicts in this tutorial, but you can find more information on conflicts on Github.

In this example we will apply a patch that was submitted to CyanogenMod to add CD-rom functionality to DriveDroid on Nexus 5 devices/kernels. The patch can be found on CyanogenMods code reviewing system: http://review.cyanogenmod.org/#/c/57792/

First change the current directory to the kernel:

cd linux

Now we can apply git commands on the source code of Linux.

On the page of the patch on CyanogenMods code reviewing system you'll find a few options to download the patch: checkout, pull, cherry-pick and patch. We will use the cherry-pick option, since it is most straight-forward for our purpose. Click cherry-pick and copy the command that shows up under it. In this example the command is the following:

git fetch http://review.cyanogenmod.org/CyanogenMod/android_kernel_lge_hammerhead refs/changes/92/57792/2 && git cherry-pick FETCH_HEAD

Execute this command. It results in the following output:

From http://review.cyanogenmod.org/CyanogenMod/android_kernel_lge_hammerhead
 * branch            refs/changes/92/57792/2 -> FETCH_HEAD
[android-msm-hammerhead-3.4-lollipop-release 3f1a563] usb: gadget: mass_storage: added sysfs entry for cdrom to LUNs
 Date: Thu Jul 4 12:36:57 2013 +0200
 2 files changed, 42 insertions(+)

This means the patch has been applied. Change the current directory back to the parent to continue the tutorial:

cd ..

Compiling the kernel

Since most phones and tablets run on an ARM processor, we need a compiler that targets ARM. It's best to use the exact same compiler Google uses, so we'll retrieve that using the following:

git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6 arm-eabi-4.6

Next we need to instruct the build process to use the compiler:

export PATH=$PWD/arm-eabi-4.6/bin:$PATH
export ARCH=arm
export SUBARCH=arm
export CROSS_COMPILE=arm-eabi-

Now we need to configure Linux, like what modules it should include. In this case we want just the default configuration for the Nexus 5 (hammerhead):

make -C linux hammerhead_defconfig

Finally we can compile the kernel:

make -C linux

This will take a while. When compilation has finished, the kernel is available under linux/arch/arm/boot/zImage-dtb.

Preparing a boot image

We have the kernel. Next we need to package it up into a bootloader image. A bootloader image usually consists of:

A kernel image
A ramdisk image
A kernel command-line

We already have the kernel image, but the ramdisk and kernel commandline are also required. These are dependent on the rom you're using. So, we use the same bootloader image from your rom and replace the kernel.

First retrieve the factory image from: https://developers.google.com/android/nexus/images

You can use your own methods to download and extract the image. In this example we use command-line tools to do this.

In this example we'll presume you're using hammerhead-lrx21o-factory-01315e08.tgz. To download it use:

wget https://dl.google.com/dl/android/aosp/hammerhead-lrx21o-factory-01315e08.tgz

Next extract image-hammerhead-lrx21o.zip from hammerhead-lrx21o-factory-01315e08.tgz:

tar xfz hammerhead-lrx21o-factory-01315e08.tgz image-hammerhead-lrx21o.zip

And now extract boot.img from image-hammerhead-lrx21o.zip:

unzip image-hammerhead-lrx21o.zip boot.img

We have an Android boot image which contains a stock kernel, ramdisk and command-line. We extract all of these using:

abootimg -x boot.img

This results in the following files:

bootimg.cfg: configuration with addresses, sizes and the kernel commandline.
zImage: the stock kernel
initrd.img: the stock ramdisk

We will use the same configuration file and ramdisk.

We do need to make a small change to the configuration though. I found that my compiled kernel image was bigger than the stock kernel. The size of the kernel is set in the configuration file (bootimg.cfg) to the size of the stock kernel, so this needs to change. Since aboot can determine the size itself when it's packing everything up, we can just remove the bootsize from the configuration. Open bootimg.cfg with your favorite editor and remove the line with bootsize =. Alternatively use the following line to do the same:

sed -i '/bootsize =/d' bootimg.cfg

Now we can create our custom boot image. We name it newboot.img using the following line:

abootimg --create newboot.img -f bootimg.cfg -k linux/arch/arm/boot/zImage-dtb -r initrd.img

Yay, we now have an image that we can flash onto the phone/tablet.

Boot using boot image

To try the boot image and kernel you need to reboot into your bootloader on your phone/tablet (aka fastboot mode). You can usually do this by shutting down your phone and holding down Volume Down and the power button. Alternatively you can use:

adb reboot bootloader

You should see some lines of text starting with FASTBOOT MODE. Now you can boot your phone with your new boot image:

fastboot boot newboot.img

Try whether things work correctly. If it does, you can make the boot image permanent by flashing it onto your phone.

Flash boot image

To make the boot image permanent you can again reboot to your bootloader:

adb reboot bootloader

And flash the boot image:

fastboot flash boot newboot.img

The next time you reboot your phone it'll start using your own compiled kernel. Have fun!

Boot Windows 8 from DriveDroid

frozencow@gmail.com (FrozenCow) — Fri, 21 Nov 2014 11:31:00 +0000

In previous tutorials we've seen how to write a Windows installation ISO to an USB drive. This allowed you to start the Windows installer from your phone. What if you could run Windows itself from your phone instead of just the installer? That would make it possible to have an installation of Windows always with you. This is what we'll show in this tutorial.

First off, many thanks to xyancompgeek for his post on XDA-developers. It is what I'm basing this tutorial on.

Requirements

DriveDroid v0.7.0+
5.5GB free space on your Android phone
A phone that supports files greater than 4GB (most Android 4.1+ phones)
A PC with Windows 7 or 8
WimLib
A Windows 8 installation ISO

Note that at this moment Windows 8.1 installation ISOs will not work. This is because your phone is recognized as a removable drive (like an USB stick) whereas Windows 8.1 requires its drive to be non-removable (like a harddisk). Windows 8 does allow removable drives. If you have a Windows 8.1 ISO, you might want to get a kernel that supports emulation of non-removable drives.

Image creation

First hook up your phone to your PC using a USB cable.

Next we'll have to create a blank image on your phone. On this image we will eventually store the installation disk. In DriveDroid we go to the + button and choose 'Create blank image...'.

Choose a filename like 'windows8.img' and choose 5500MB as the size for the image. You can uncheck 'Partition table (MBR)' and choose 'None' for the filesystem. Now hit the 'Create' button on the top-right.

As a side-note, we choose to not create a partition table and filesystem here because DriveDroid does not support formatting NTFS filesystems. NTFS is required and Windows does a good job creating a partition table and formatting the NTFS filesystem, but we'll get to that.

This will create the image file in the background. Open the notification-bar to see when the image creation is finished.

Your phone probably has a hard time while it's allocating the file, so it's best not to do anything else while it's working.

Once the image is created go to DriveDroid.

Partitioning and formatting

Select the image in DriveDroid and click the option that says 'Writable USB'. As soon as we have done that, Windows will find a new USB drive.

Go to start and type cmd.exe. Right-click 'Command Prompt' and choose 'Run as Administrator'.

Start diskpart by typing diskpart.

Show the connected disks by typing list disk.

You will see that the image you just created in DriveDroid is listed here as a disk of 5500MB. In this example it is listed as Disk 3.

To work on disk 3, we need to select it by typing select disk 3.

First we remove anything that's already on the disk (if any), by typing clean.

Now we can create a partition by typing create partition primary.

The partition doesn't have a filesystem yet. For the Windows 8 disk we need a NTFS filesystem. We can format a NTFS filesystem on the partition by typing format fs=ntfs quick.

Now we have a partition table, partition and filesystem. We only have to mark the partition as 'bootable' to be able to boot from it. We do this by typing active.

Finally we leave diskpart by typing exit. You can close the window after that.

Now we have a disk that has a filesystem. We should be able to see the empty disk in Windows Explorer. In this example it is disk F:.

Remember the drive letter 'F:'. We need it later.

Optionally we can make sure the disk compresses all files. This will potentially make some more room for files.

Right-click the drive in Windows Explorer and choose 'Properties'.

Next check 'Compress this drive to save disk space' and hit 'OK'.

Copying files

The necessary files are on the ISO in a file called 'install.wim'. We will use WimLib to extract this file to the new filesystem.

First go to your ISO and double-click it in Windows Explorer. It should open up the ISO and show the contents.

Notice that it also created a drive letter for the ISO. In this example it is 'G:'. Remember this drive letter.

Next we need WimLib. Download and extract it to a location that you can easily access. For this example we extracted it in 'C:\WimLib'.

Use the same Command Prompt as before to navigate to the WimLib directory.

Next we extract the contents from 'install.wim', which is on the ISO, to the disk. Here we need to use the drive letter of your phone (F: in this example) and the drive letter of the ISO (G: in this example). We instruct WimLib using wimapply G:\sources\install.wim F:\ --strict-acls.

After quite a while it has placed all the necessary files onto the drive.

Next we will make sure we can boot from the drive using bootsect /nt60 F:.

And make sure the necessary files for booting are also there bcdboot F:\Windows /s F: /f ALL.

All done! Now do make sure you safely remove the USB drive from Windows and unplug the USB cable.

Booting Windows

Plug in the USB cable into the PC where you want to boot. Start the PC and make sure your phone is used as the boot device.

Next Windows 8 will load and will do some initial setting up. After it has done this, it'll reboot. Make sure you are again booting from the phone.

Booting a second time will actually bring you to Windows and you can configure it to your liking. Have fun!

Custom repositories in DriveDroid

frozencow@gmail.com (FrozenCow) — Sun, 31 Aug 2014 09:00:00 +0000

In recent versions of DriveDroid, custom download repositories were added. This means that, in addition to the standard set of freely available images that are already downloadable through in DriveDroid, you can add your own. Basically this is a way to add images to the download list and share them. This can be useful for organizations to share images in their team. In particular images that aren't freely available or images that has very specific custom tools or applications. Examples include:

Windows installation disks
Non-free recovery and backup tools
Bios flashing utilities
Custom built images

Requirements

DriveDroid needs two parts:

The images you want to share
The repository file

Both of these need to be hosted on a HTTP(S) webserver. However, you may host them on separate webservers.

If the images are already hosted on a HTTP(S) server (and directly linkable), you only need the repository file to direct DriveDroid to them.

If you have small images that you want to share with a set number of people you can use easy hosting solutions like Dropboxs public folder.

However, large images or ones that are going to be downloaded often will need your own webserver. That said, no special settings are required for this to work.

In this article we will assume you have an image called mycustomimage.iso and you've placed it on your webserver.

Repository file

The repository file is a JSON formatted file that links to the various images that you want to see in DriveDroid. The structure is as follows:

[{
    "id": "mycustomimages",
    "name": "My Custom Images",
    "url": "http://www.my-custom-images.org/",
    "imageUrl": "logos/mycustomimages.png",
    "releases": [{
        "version": "1.0",
        "url": "images/mycustomimage.iso",
        "size": 4194304,
        "arch": "amd64"
    }]
}]

This represents a list of distributions. Each distribution has the following properties:

id (required): a unique lower-case alphanumeric identifier of the distribution
name (required): the name (or title) of the distribution
url (required): a URL to the website of the distrution. This is will show a website-button in the actionbar when the distribution is selected.
imageUrl (optional): a relative or absolute URL to a logo for the distribution. The file should be a 48 x 48 PNG.
releases (required): a list of the releases that the distribution has.

A release is essentially an image with some metadata. Each release has the following properties:

url (required): the relative or absolute url where the image is located.
size (required): the size of the image in bytes. This is shown as KB/MB/GB/TB in the image download list.
version (optional): the version of the release.
arch (optional): the architecture of the release.

Note that version and arch aren't shown anywhere in the GUI. At the moment they are only used for sorting (first by version, then by architecture).

The imageUrl of the distribution and the url of a release can both be relative as well as absolute. That means you can conveniently refer to logos/mycustomimages.png, which is be relative to the repository file, instead of using the full URL.

If no imageUrl is given, DriveDroid will take logos/{id}.png as the imageUrl by default. So in the example above, leaving imageUrl out would've had the same effect.

Directory structure

Although you're free to use any structure, the example above assumes a structure like:

myrepository.json: the repository file as described above
logos/mycustomimages.png: the logo for "My Custom Images"
images/mycustomimage.iso: the image

Let's say you're hosting this on http://www.my-custom-images.org/, then the URL for the repository would be http://www.my-custom-images.org/myrepository.json. This is what you'll configure DriveDroid with.

Configure DriveDroid

To add the new repository to DriveDroid, you would do the following:

Go to Preferences
Go to Image repositories
Press +
Enter a name of your choice, for example "My Custom Repository"
Enter the URL of your repository, for example http://www.my-custom-images.org/myrepository.json
Press ✓ (Save)
For demonstration purposes disable "DriveDroid main" and "DriveDroid syslinux"
Done

To view your new repository:

Go to DriveDroids main screen
Press +
Press "Download images..."

Now you should see "My Custom Images" listed.

Examples

The example above is also available at http://softwarebakery.com/apps/drivedroid/repositories/mycustomrepository.json.

For bigger examples, you can have a look at the official repositories that DriveDroids ships with:

These files were generated using distscraper, a tool that runs periodically to scrape the various distributions for new images.

The logos for these repositories are in the logos subdirectory, for instance logos/debian.png.

Using Rufus to create bootable USB images

frozencow@gmail.com (FrozenCow) — Fri, 05 Jul 2013 18:10:00 +0000

Rufus is a seemingly simple, but very excellent tool for Windows that handles a lot of work formatting USB drives and making them bootable. Most notably it can burn most ISO files to USB very efficiently. This makes it a very valuable tool for DriveDroid users.

The features of Rufus I liked most:

Burns any Windows ISO (XP, 7 or 8)
Burns any Linux-based ISO (ArchLinux, Ubuntu, Knoppix, etc)
Burns a number of handy ISOs (Hiren's Boot CD, FreeDOS, BartPE, Ultimate Boot CD)
Handles UEFI as well as legacy booting
Handles GPT as well as MBR partition tables
Open source

This post will go through the steps of creating an image in DriveDroid and burning an ISO to that image using Rufus.

Requirements

Rufus 1.4.9 or higher
Android phone with DriveDroid
USB cable

Creating a blank image in DriveDroid

The first step is creating a blank image in DriveDroid where we will burn our ISO of choice on. You will find the option 'Create blank image...' under the + menu in DriveDroid:

Next choose a filename and a size for the image that is appropriate for the ISO you're burning. Also uncheck 'Partition Table (MBR)' and set filesystem to 'None', since Rufus will handle this for us later:

In this example we have used 1000MB to burn Windows XP. Generally you should choose a tad bit more than the side of the ISO you want to burn.

Once image creation has finished you can select the image in DriveDroid.

DriveDroid will pop up a dialog asking how to host the image. Choose the first option to host the image as a writable USB drive:

Now plug in your phone into your PC and start Rufus.

Choose the USB device that corresponds to your phone. This is shown as NO_LABEL in Rufus.

Note that when the USB device is not showing up in Rufus, click on the white triangle next to 'Format Options' and check 'List USB Hard Drives'.

Check 'Create a bootable disk using:', choose 'ISO Image' from the dropdown box and click the CD-rom icon to choose the ISO you want to burn. Once the ISO is scanned by Rufus, it will fill in other options automatically.

Press 'Start' to let Rufus burn the ISO to your phone and make it bootable.

Once Rufus is finished you can reboot your PC and choose your phone from your bios to boot off of your newly burned ISO. Enjoy!

Copy running Linux systems to other machines over network

frozencow@gmail.com (FrozenCow) — Thu, 20 Jun 2013 14:30:00 +0000

Sometimes you want to upgrade your system to a new machine. The new machine has a new (bigger) disk, different hardware, maybe you even want a different partition layout. For these purposes it isn't sufficient to make a byte-for-byte backup, since the disk has a different size. A file-based copy is needed.

In this tutorial we will do the copy over network where both the source and destination machines are connected to. We do this while the source machine is still running. That way existing processes, like apache/nginx/samba, will not get interrupted. With gigabit network cards this should also be more efficient and less time-consuming than copying disks on the same machine.

Requirements

A recent ArchLinux LiveCD (tested on archlinux-2013.05.01-dual.iso)
A running Linux system (source)
Another machine that has nothing installed (destination)
rsync installed on the source machine

This tutorial will also presume the destination machine will have a basic partition layout with one disk and one ext4 partition and no swap partitions. For other partition layouts you will need to deviate from this tutorial.

General process

We will use the ArchLinux LiveCD on the destination machine to have a capable Linux system where we can setup partitions, setup ssh, login to from the source system and copy files from the source system to the destination system. Lastly we will configure the system using the tools like arch-chroot and genfstab. This may seem ArchLinux-focused, but the tools can be used to copy any other distribution as well.

Boot from LiveCD

First boot the destination machine from the ArchLinux LiveCD. Choose the architecture of your destination machine.

Setup partitions

Once booted, we'll setup the partitions on the destination system using cfdisk:

# cfdisk /dev/sda

Create one partition, make it bootable, write your changes and exit.

Now we'll format the new partition with ext4:

# mkfs.ext4 /dev/sda1

Next we'll mount the new partition so that we can later write files to it:

# mount /dev/sda1 /mnt

Setup SSH

First we want the target system to be accessible through the Live environment so that we can copy files over from the source system. We need ssh and some way to login as root.

First we set a password for root using:

# passwd

Next we enable sshd

# systemctl start sshd

We should now be able to connect through SSH from the source system to the destination machine.

Check the IP address of the destination machine using:

# ip addr show

We'll presume in the rest of the tutorial the IP address of the destination machine is 192.168.1.101.

Copying files

Go to the source machine and make sure you're logged in as root.

Next we will copy all files of root / from the source machine over to the new partition on the destination machine 192.168.1.101 mounted at /mnt.

Before copying files you might want to set the root partition to be read-only. That way files will not be changed while we're copying files. This step is optional, in my experience it does not matter much, however it's still recommended to do:

# mount -o remount,ro /

We use rsync since it includes a lot of nice features to do such a copy operation easily and fast:

# rsync -xa / root@192.168.1.101:/mnt/

Accept the key of the destination PC when asked by typing yes. Type in the password you chose when using passwd before. rsync will now copy all files, directories, permissions and owners over to the destination machine. It also skips all files and directories that are not on the root filesystem, like /dev/, /sys/. If there are filesystems that are mounted separately on the source machine and your want those copied too, use rsync again on those mountpoints too.

After a while rsync will finish and the files are be copied.

As a rudimentary check to see whether rsync copied everything you can use df -h to see how much space is used on the root partition. Use the same command on the destination machine and the used space should be the same as the source machine. Be sure to not confuse / on the source machine and /mnt on the destination machine.

Now you can make the root partition writable again, so normal processes can continue again:

# mount -o remount,rw /

Setup booting

Go back to the destination machine.

Since the destination machine presumably has a different disk and maybe even a different disk controller we will need fix a few things before we're able to boot on the destination machine. These are:

GRUB
/etc/fstab

Installing and configuring GRUB

First we will install GRUB and regenerate GRUBs configuration. We do this using system we just copied over by chrooting. ArchLinux has a convenient tool that handles chroot safely:

# arch-chroot /mnt

From here we can use the tools just like we would use them on the source system. First we will regenerate GRUBs configuration:

# grub-mkconfig | tee /boot/grub/grub.cfg

Next we will install GRUB to the boot sector:

# grub-install /dev/sda

Now leave chroot by pressing Ctrl+D or typing exit.

Generate fstab

The ArchLinux liveCD also comes with a handy tool called genfstab that can generate /etc/fstab for you. It'll detect what partitions are mounted and will lookup their UUID. This step should be easy:

# genfstab /mnt | tee /mnt/etc/fstab

Now everything should be setup correctly.

Unmount the /mnt partition using:

# umount /mnt

Booting

Before rebooting the destination machine a few notes of precaution:

If you used a static IP address for the source machine, this same address will be used for the destination machine. Shut down the source machine just to be sure or change the IP address of the source or destination machine.

Now reboot your destination machine and remove the ArchLinux LiveCD.

Differing disk controller

If the destination system cannot find the root partition upon booting, you will likely have a (very) different disk controller compared to the source system. Most often you will not find problems with this, so only follow this part of the guide if this is indeed the case.

Support for the specific disk controller of the system is baked into initramfs: the part of the boot process that, among others, finds and mounts the root partition. The initramfs needs additional modules baked in, so we need to regenerate initramfs. This will detect what modules are needed and place those into the new initramfs.

To do this we need to start with the ArchLinux LiveCD again. Mount the root partition and use chroot to get into the system:

# mount /dev/sda1 /mnt
# arch-chroot /mnt

Now we can use the utilities of the source system again. Which utility we need to regenerate initramfs depends on the distribution that was copied.

For Debian-like systems you can use:

# update-initramfs -u

For ArchLinux-like systems you can use:

# mkinitcpio -p linux

Exit chroot again using Ctrl+D or by typing exit. Unmount /mnt again:

# umount /mnt

And reboot the machine. It should now be able to find the root partition again.

Install Hirens Boot CD on DriveDroid

frozencow@gmail.com (FrozenCow) — Mon, 22 Apr 2013 20:30:00 +0000

In this tutorial we will go through the process of installing Hirens Boot CD on a DriveDroid image. This is very similar to the process of installing other systems. The steps are as follows:

Create a blank image in DriveDroid of reasonable size.
Select the image in DriveDroid, so that it becomes available on your PC as an USB drive.
Follow the instructions at Hirens Boot CDs page on how to install Hirens on a USB drive.

This also applies to other systems, but for those systems the instructions on how to install them to a USB drive will, of course, differ. In this article we will focus on install Hirens Boot CD.

Requirements

A phone with DriveDroid installed
An USB cable
A PC with Windows installed
7-Zip
Hirens.BootCD.15.2.zip from hirensbootcd.org
USBFormat.zip from hiren.info
grub4dos.zip from hiren.info

Creating a blank image in DriveDroid

The first step is creating a blank image in DriveDroid where we will install Hirens Boot CD on. You will find the option 'Create blank image...' under the + menu in DriveDroid:

Next choose a filename, set the size to 650MB, uncheck 'Partition Table (MBR)' and set filesystem to 'None'. It should look like:

Next hit create and wait for the creation process to complete. This usally takes at least a minute.

Now we have a blank image. It is time to use it. You should be able to see the image in DriveDroids image list. Tap the newly created image:

A dialog will popup where you can select in what mode to host the image. Your dialog might differ, but the options are from left to right:

Writable USB-disk
Read-only USB-disk
CD-rom disk

On my device I have two host-devices, so I see two rows. For our purposes we want to create a USB-disk and we need the PC to be able to write to it, so we choose the first option:

A USB-disk should now popup on your PC. From here on we can loosely follow the tutorial on how to install Hirens Boot CD to an USB-drive that is found on their site.

Installing Hirens Boot CD

From their tutorial we can see that we first need USBFormat. Download and extract the zip and run USBFormat as an administrator. Next look for the USB-disk in USBFormat. For me it shows up as 'Linux File-CD', but that may differ on your phone/rom/kernel. Once you have the USB-drive selected use the following settings to format the disk:

Once USBFormat has finished, you'll notice that the disk now becomes available on Windows and allows you to put files on it.

For the next step we need to use grub4dos. Download and extract the zip and run grubinst_gui.exe as administrator. Look for the USB-disk by looking for the correct size (around 650MB) and use the following settings to install Grub4Dos onto the USB-disk:

Next, copy grldr and menu.lst from grub4dos.zip to the USB-drive.

Now it's time to put the rest of the files of Hirens Boot CD onto the USB-drive. First download and extract the file Hirens.BootCD.15.2.zip from their download page. You should see an ISO file named Hiren's.BootCD.15.2.iso. We will use 7-zip to extract the files from the ISO to the USB-disk. Click with right mouse on the ISO, choose 7-Zip and 'Extract files...':

Next enter the location of the USB-disk (use Browse if you aren't sure). Extraction will take several minutes.

When the extaction process is finished you should have the following files on your USB-disk:

Finally, make sure to safely remove the USB-disk from Windows. This is to ensure all data is being written to the disk (which is usually cached by Windows for a while). After doing so, open up DriveDroid on your phone and tap the image again. Now instead of using the first option, choose the USB-disk in read-only mode (the padlocked USB icon). This will ensure the USB-disk cannot change whenever the image is hosted in this mode. If you ever want to write some files onto the disk, choose writable USB-disk-mode.

Now reboot your PC. It should now be able to boot Hirens Boot CD from your phone. Enjoy!

Shrinking images on Linux

frozencow@gmail.com (FrozenCow) — Thu, 21 Feb 2013 14:53:00 +0000

When creating images from existing ISOs you often need to allocate a number of MB for the image to at least fit the files that are in the ISO. Predicting the exact size of the image is hard, even for a program. In this case you will create an image that is larger than actually needed: the image is much larger than the files on the image are combined.

This post will show how to shrink an existing image to a more optimal size. We will do this on Linux, since all required tools are available there: GParted, fdisk and truncate.

Requirements

A Linux PC
Some knowledge how the terminal works will helps
The unoptimal image (myimage.img in this example)

Creating loopback device

GParted is a great application that can handle partition tables and filesystems quite well. In this tutorial we will use GParted to shrink the filesystem (and its accompaning partition in the partition table).

GParted operates on devices, not simple files like images. This is why we first need to create a device for the image. We do this using the loopback-functionality of Linux.

First we will enable loopback if it wasn't already enabled:

$ sudo modprobe loop

Now we can request a new (free) loopback device:

$ sudo losetup -f

This will return the path to a free loopback device. In this example this is /dev/loop0.

Next we create a device of the image:

$ sudo losetup /dev/loop0 myimage.img

Now we have a device /dev/loop0 that represents myimage.img. We want to access the partitions that are on the image, so we need to ask the kernel to load those too:

$ sudo partprobe /dev/loop0

This should give us the device /dev/loop0p1, which represents the first partition in myimage.img. We do not need this device directly, but GParted requires it.

Resize partition using GParted

Next we can load the device using GParted:

$ sudo gparted /dev/loop0

This should show a window similar to the following:

Now notice a few things:

There is one partition.
The partition allocates the entire disk/device/image.
The partition is filled partly.

We want to resize this partition so that is fits it content, but not more than that.

Select the partition and click Resize/Move. A window similar to the following will popup:

Drag the right bar to the left as much as possible.

Note that sometimes GParted will need a few MB extra to place some filesystem-related data. You can press the up-arrow at the New size-box a few times to do so. For example, I pressed it 10 times (=10MiB) for FAT32 to work. For NTFS you might not need to at all.

Finally press Resize/Move. You will return to the GParted window. This time it will look similar to the following:

Notice that there is a part of the disk unallocated. This part of the disk will not be used by the partition, so we can shave this part off of the image later. GParted is a tool for disks, so it doesn't shrink images, only partitions, we have to do the shrinking of the image ourselves.

Press Apply in GParted. It will now move files and finally shrink the partition, so it can take a minute or two, most of the time it finishes quickly. Afterwards close GParted.

Now we don't need the loopback-device anymore, so unload it:

$ sudo losetup -d /dev/loop0

Shaving the image

Now that we have all the important data at the beginning of the image it is time to shave of that unallocated part. We will first need to know where our partition ends and where the unallocated part begins. We do this using fdisk:

$ fdisk -l myimage.img

Here we will see an output similar to the following:

Disk myimage.img: 6144 MB, 6144000000 bytes, 12000000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ea37d

      Device Boot      Start         End      Blocks   Id  System
myimage.img1            2048     9181183     4589568    b  W95 FAT32

Note two things in the output:

The partition ends on block 9181183 (shown under End)
The block-size is 512 bytes (shown as sectors of 1 * 512)

We will use these numbers in the rest of the example. The block-size (512) is often the same, but the ending block (9181183) will differ for you. The numbers mean that the parition ends on byte 9181183*512 of the file. After that byte comes the unallocated-part. Only the first 9181183*512 bytes will be useful for our image.

Next we shrink the image-file to a size that can just contain the partition. For this we will use the truncate command (thanks uggla!). With the truncate command need to supply the size of the file in bytes. The last block was 9181183 and block-numbers start at 0. That means we need (9181183+1)*512 bytes. This is important, else the partition will not fit the image. So now we use truncate with the calculations:

$ truncate --size=$[(9181183+1)*512] myimage.img

Now copy the new image over to your phone, where it should act exactly the same as the old/big image.

Windows installation on DriveDroid

frozencow@gmail.com (FrozenCow) — Fri, 25 Jan 2013 11:31:00 +0000

Update: Rufus is now the recommended to write Windows installation ISOs to DriveDroid and other USB drives. Please refer to Using Rufus to create bootable USB images. The tutorial below still explains in more detailed steps how the same thing is done using more low-level tools.

In version v0.7.0 of DriveDroid (Free) and DriveDroid (Paid) a feature has been added to create blank images that look like normal USB disks. This allows you to use tools on your PC to fill the blank USB disk with whatever you want.

In this post I will show how to create a Windows 7 installation disk that can be booted from your phone with DriveDroid. The disk will be made using files of the official Windows 7 ISO.

Requirements

DriveDroid v0.7.0+
4GB free space on your Android phone
A PC with Windows 7 and 7-zip installed
Diskpart utility (installed by default on Windows 7)
A Windows 7 installation disk or ISO

Note that on some systems diskpart is not installed. I installed it seperately using the diskpart setup.

Image creation

First hook up your phone to your PC using a USB cable.

Next we'll have to create a blank image on your phone. On this image we will eventually store the installation disk. In DriveDroid we go to the + button and choose 'Create blank image...'.

Choose a filename like 'windows7.img' and choose 3500MB as the size for the image. You can uncheck 'Partition table (MBR)' and choose 'None' for the filesystem. Now hit the 'Create' button on the top-right.

As a side-note, we choose to not create a partition table and filesystem here because DriveDroid does not support formatting NTFS filesystems. NTFS is required for the Windows 7 installer to work. We will partition and format the image from your PC in Windows, but we'll get to that.

This will create the image file in the background. Open the notification-bar to see when the image creation is finished. Most time will be used by 'Allocating file...', which creates a 3500MB file. This can take half an hour or so on most devices that have a FAT-32 filesystem on their SD-card, other filesystems do not seem to have this problem and will finish almost instantly.

It is recommended not to do anything else on your phone while the image is being created. At the moment the image creation process can be killed by Android when there isn't enough memory available on the device to launch other applications. I still need to figure out how to avoid this.

Once the image is created go to DriveDroid.

Partitioning and formatting

Select the image in DriveDroid and click the option that says '(read-write)'. As soon as we have done that, Windows will find a new USB drive. A window will popup in Windows asking to format the drive.

Choose 'Cancel': this method of formatting is not compatible with a Windows 7 install disk, since it'll not create a partition table and bootsector. Thus it will not boot using this option. We will partition and format the disk properly using diskpart.

Go to start and type cmd.exe. Command prompt will open.

Start diskpart by typing diskpart.

Show the connected disks by typing list disk.

You will see that the image you just created in DriveDroid is listed here as a disk of 3500MB. In this example it is listed as Disk 3.

To work on disk 3, we need to select it by typing select disk 3.

Next we create a partition table and fill the bootsector by typing clean.

Now we can create a partition by typing create partition primary.

The partition hasn't got a filesystem yet. For the Windows 7 install disk we need a NTFS filesystem. We can format a NTFS filesystem on the partition by typing format fs=ntfs quick. This will take a few seconds to a minute or so.

Now we have a bootsector, partition table, partition and filesystem. We only have to mark the partition as 'bootable' to be able to boot from it. We do this by typing active.

Finally we leave diskpart by typing exit. You can close the window after that.

Copying files

Now we have a disk that has a filesystem and can be booted from. We should be able to see the empty disk in 'My Computer'. In this example it is disk G:.

Next we need to copy files from the official Windows 7 installation CD to the USB drive. If you have the CD at hand, you can just copy those files over.

However, since I only have an ISO file I need to extract the ISO to the USB drive. We can do this using 7-zip. Go to the Windows 7 ISO using Windows Explorer. Right click the ISO file, choose 7-Zip and choose Extract files....

Choose G:\ as the destination to extract the files to and hit OK.

Extracting the files will take a while.

Once the files are extracted the contents of your disk should look similar to this.

We are finished. The disk should be usable and is stored in windows7.img on your Android phone. If you want to try it on another PC, first safely remove the disk by left clicking the icon in your system tray.

And choosing your phone from the menu. In my case it is GT-I9000 (Samsung Galaxy S).

Unplug your USB cable and plug it in a PC where you want to install Windows 7. Make sure you still have windows7.img selected in DriveDroid.

Boot the other PC, go to the bios and put your phone as the first boot device.

Save the changes and reboot. The PC should now boot the Windows 7 installer from your phone.

DriveDroid 0.7.0 released

frozencow@gmail.com (FrozenCow) — Sun, 20 Jan 2013 21:01:00 +0000

Version 0.7.0 of DriveDroid (Free) and DriveDroid (Paid) is just released. This version comes with quite a few changes. Here is the changelog:

Added 'Create blank image' to create an empty/FAT32 disk-image
Improved USB Mass Storage option
Improved support emails
Option to check for USB Mass Storage
Changed menu structure for creating/adding/downloading images
Added support for HTC Sensation, Samsung GT-S5360 and HDC i9300
Fixed crash when going to preferences without root

Create blank image

The biggest feature is the ability to create blank images from within DriveDroid. You can specify the size that you want the USB-disk to have and DriveDroid can format a FAT-32 filesystem on it (big thanks to fat32-lib). Once you select the image you'll see an empty USB-disk on your PC where you can store files.

One advantage of this system is not just being able to store files, but to be able to use any tool on your PC to create bootable USB drives. In the past a number of ISOs were not loadable by DriveDroid, because those weren't USB compatible. Now you can use tools like Windows 7 USB/DVD download tool, UNetBootin, Image Writer or just dd to write images or ISOs to a disk you created+hosted using DriveDroid.

Compatiblity

I've also tried to support devices that do not have USB Mass Storage by default. Use the 'USB Mass Storage (UMS)'-option in the preferences of DriveDroid to enable UMS. It will use the normal way of enabling UMS, but will try to detect whether this does not work and use other methods to enable it. Hopefully this will work for some devices.

For anyone who still has trouble, please send me a support email through the preferences of DriveDroid. Support emails now contain more information, so it should have a better chance of solving the problem.

DriveDroid 0.6.2 released

frozencow@gmail.com (FrozenCow) — Sun, 09 Dec 2012 21:13:00 +0000

Since the first release of DriveDroid (version 0.5) much has changed. This post summarizes the changes from 0.5 till 0.6.2.

Distributions

A number of new distributions are now available in the downloadlist:

Arch Linux
Crunchbang
Debian
Fedora
FreeBSD
GeeXboX
Gentoo
Grml
OpenSUSE
SliTaz
Tails
Ubuntu

For a recent list of distributions take a look distscraper, which retrieves the different downloadable image-urls.

The downloadlist now also includes logos of the distributions. The logos are retrieved and slightly altered using a script in distscraper.

Compatiblity

Support for the different devices has been improved greately by adding support for hosting iso/img files for 5 new devices/ROMs. There were also a lot of different little incompatiblities between the different Android versions, which now show appropriate messages when a particular feature is not supported on the device.

Paid version

Last but not least, there is now a paid (no-ads) version available on the Play Store. No extra features are added to the paid version at the moment, though it always helps development.

DriveDroid 0.5 released!

frozencow@gmail.com (FrozenCow) — Mon, 12 Nov 2012 19:13:00 +0000

DriveDroid allows you to boot your PC from ISO/IMG files stored on your phone. This is ideal for trying Linux distributions or always having a rescue-system on the go... without the need to burn CDs or USB pendrives.

DriveDroid also includes a convenient download menu where you can select a popular distibution to download and use.

How do you make this work?

Connect your phone to your PC using an USB cable
Download an image file (.iso or .img) through DriveDroid or download them manually
Select the image file in DriveDroid to let your phone 'host' the file over USB
(Re)start your PC and make sure the correct boot priority is set in the bios
The image should now be booted on your PC

Requirements

Root
USB cable (from phone to PC)
USB Mass Storage-support should be enabled on your ROM (being able to mount SD card)

Notes

Some .iso files do not support being booted over USB, but most popular distibutions are. All images that are downloadable through DriveDroid are supported.
All .img files should work fine.
It is recommended to download distributions over wifi: those files are big!
Do NOT use DriveDroid while your SD card is mounted (being used on your PC). This can cause loss of data.

The downloads that DriveDroid provides are gathered using distscraper. If you want other distributions to be includes in the list, please open up an issue or do a pull request.

Recovering commits with Git

frozencow@gmail.com (FrozenCow) — Fri, 13 Jan 2012 20:42:00 +0000

Git is pretty powerful. With this power it allows you to do amazing things. Recently I've come to realize that you can hurt yourself pretty badly with its powers. Operations like resetting and fast-forwarding are dangarous and should be used with care.

Today I did not handle them with care and commits seemed to be lost. Luckily I found that Git does not delete commits. My lost commits were just not referenced by any branch or tag, but were 'dangling'. The problem is finding these commits back.

I found two possible commands that helped me find my lost commits: git reflog and git fsck --lost-found.

Reflog

This command shows the history of operations you have done on your repository. Each operation is shown with the hash of the commit that it results in. As an example we will create a repository, commit a change, 'lose' the commit and find it back using git reflog.

First we create a test repository:

$ mkdir myrepo
$ cd myrepo
$ git init

Next we'll commit a file with some text:

$ echo some text in a file > file
$ git add file
$ git commit -m "My first change"

Now we'll make a change to the file:

$ echo other text in a file > file
$ git commit file -m "Another change to file"

You can see the current commits in the log:

$ git log --oneline
fd9e098 Another change to file
98b88cc My first change

Now we make our mistake and reset to the first commit:

$ git reset --hard HEAD~1

Our second commit is now 'lost'. We can see that the file does not match the latest change we made and the log does not show our latest commit anymore:

$ cat file
some text in a file
$ git log --oneline
98b88cc My first change

Presume we haven't done the previous logs and don't know the hash of the latest commit that we have done. We can see the operations we did using reflog:

$ git reflog
98b88cc HEAD@{0}: reset: moving to HEAD~1
fd9e098 HEAD@{1}: commit: Another change to file
98b88cc HEAD@{2}: commit (initial): My first change

Two commits and a reset, that seems to fit with what we did. Commit 'fd9e098' seems to be the one we're missing. We can take a look at the history of that commit to get a better understanding whether it really is the right one:

$ git log fd9e098 --oneline
fd9e098 Another change to file
98b88cc My first change

This seems to be in line with what we previously saw, so now we want to get back that last commit. We have the option to just reset our history to that commit by using git reset --hard:.

$ git reset --hard fd9e098

The history is now the same as before:

$ git log
fd9e098 Another change to file
98b88cc My first change

If you weren't sure it was the right commit yet, you can do a checkout of the commit before resetting to look at its files more easily:

$ git checkout fd9e098

Though do remember to checkout to your previous branch when you're done going through its files:

$ git checkout master

Lost and found

Instead of using git reflog to find your lost commits, you can also use Git's fsck to find 'dangling' commits for you. If we go back to our example we can do a reset again to 'lose' our latest commit:

$ git reset --hard 98b88cc

Now if we issue the lost and found command. It'll return the dangling commit(s) that were lost:

$ git fsck --lost-found
dangling commit fd9e0982eaf3d8589aac26f0c6a52be5741ee8f7

We can do the same as before and reset to that commit:

$ git reset --hard fd9e0982eaf3d8589aac26f0c6a52be5741ee8f7

Now the history is restored and the files are of the latest commit.

Garbage collection

Even though the dangling commits exist at this time, they will be removed after a garbage collection. Git automatically does this for files that are 2 weeks old. Garbage collection can also be disabled by using the configuration value gc.auto:

$ git config --global gc.auto 0

To do garbage collections manually you could use:

$ git gc

More information on this can be found on git-gc manual page.

Setting up an infinote server with PAM

maato@softwarebakery.com (Maato) — Tue, 12 Jul 2011 20:42:00 +0000

Gobby is a multi-user text editor. It allows editing text files by multiple persons, while all of them can see and edit in real-time. It is a great tool for online collaboration, like making todos or even coding a program collaboratively.

Gobby connects to an infinote server. The server keeps track of the different users and documents.

On Ubuntu 10.04 infinoted 0.4.1-1 is already in the repository and it is easy to set up. However, such a setup does not include username and password authentication, an automatic startup using a init-script and a separate user under which the process should run. Authentication using PAM, and thus username and password, is only available since 0.5.0.

This post contains all of the steps required to run infinoted 0.5.0 on Ubuntu 10.04. This includes compiling, creating the user, init-script and configuration necessary to run infinoted in a proper way.

Compiling infinoted with PAM support

Since PAM is an optional dependency for infinoted you should make sure that libpam-dev is installed before compiling. The configure script does not provide you with any notification of its absence (this will be fixed in a later version). You should also make sure libdaemon-dev is installed, otherwise the initscript will not work properly. After that, compilation is rather straightforward:

$ apt-get install libxml2-dev gnutls-dev libgsasl7-dev libglib2.0-dev libpam-dev libdaemon-dev
$ wget http://releases.0x539.de/libinfinity/libinfinity-0.5.0.tar.gz
$ tar xfvz libinfinity-0.5.0.tar.gz
$ cd libinfinity-0.5.0
$ ./configure --prefix=/usr
$ make
$ make install

If you are on Ubuntu and want to make a deb package, you can replace the last command (make install) by checkinstall and answer the questions that follow. Make sure you install checkinstall first:

$ apt-get install checkinstall

When you've created the package, you can install it using:

$ dpkg -i infinoted-0.5.0-1.deb

Configuring infinoted

We'll run the server as a seperate (less privileged) user instead of as root, so we start by creating a new user. The user's home directory will be /var/infinote.

$ useradd --home-dir /var/infinote --user-group --shell /bin/false infinote

Before we can start the server we have to create a home directory, a place to store the documents and its configuration. The server looks for the configuration file $HOME/.config/infinoted.conf. We create the directories and set the appropriate permissions on them using the following commands:

$ mkdir /var/infinote/{,root,sync,.config}
$ touch /var/infinote/.config/infinoted.conf
$ chown -R infinote: /var/infinote
$ chmod -R 0700 /var/infinote
$ chmod 0600 /var/infinote/.config/infinoted.conf

Now we can fill infinoted.conf with the following configuration:

/var/infinote/.config/infinoted.conf

[infinoted] security-policy=require-tls root-directory=/var/infinote/root/ certificate-file=/var/infinote/cert.pem key-file=/var/infinote/key.pem sync-directory=/var/infinote/sync/ sync-interval=60 pam-service=infinote

Generating a certificate

You might have noticed a reference to the cert.pem and key.pem files. These allow the connection to be encrypted. We haven't created them yet, so we'll do that now. The creation of the certificate requires quite a lot of entropy. If your machine runs out of entropy this can make the entire process take a very long time. To solve this you could try to generate more entropy by moving your mouse or typing on the keyboard. On a server which has no such peripherals this will obviously not work, so you might have to create the certificate somewhere else and copy it over to the server. Another thing to look out for is the fact that the certificate (cert.pem) will be bound to a domain name. This is determined by the hostname of the computer generating the certificate, so you might have to change it temporarily.

$ hostname your_temporary_hostname # optional, don't forget to restore afterwards
$ cd /var/infinote
$ sudo -u infinote infinoted-0.5 -k key.pem -c cert.pem --create-key --create-certificate
$ chown 0600 key.pem cert.pem

Authentication using PAM

The documentation of infinoted shows the option to setup PAM but gives no hints on how to do it. There are multiple ways to setup PAM authentication with infinoted. We chose to use the pam_pwdfile authentication module. This allows you to define users and passwords in a flat text file, so that you do not need to create full system users for them. So you need to apt-get install libpam-pwdfile. Since all users that are in this file are solely created for use with infinote we will use the module pam_permit to forgo account management.

We start by creating a new PAM service in the /etc/pam.d/ directory called infinote and use the following as its contents:

/etc/pam.d/infinote

#%PAM-1.0
auth      required    pam_pwdfile.so pwdfile /etc/infinoted.passwd
account   required    pam_permit.so

Now we have to create the file that defines users and their passwords, we have chose to place it at /etc/infinoted.passwd. The file should contain username:password_hash pairs. The password hashes can be generated using any of the following commands:

$ openssl passwd -1 <password>
$ openssl passwd -crypt <password>
$ htpasswd -nbd <username> <password>

Note that both of the available hashing methods are rather weak, so don't count on these hashes to provide you with any security. After having created the hashes for your passwords, your password file should look something like this:

/etc/infinoted.passwd

maato:$1$yII45doY$ZSH/biluHy12zp9KOuEQ9/
frozencow:SiN2d/00c/ubI

Creating an init script

To automatically (and easily) start and stop the infinote daemon, we will need an init-script. We placed the code below in /etc/init.d/infinoted. Make sure to also run chmod +x /etc/init.d/infinoted.

/etc/init.d/infinoted

#! /bin/sh
### BEGIN INIT INFO
# Provides:          infinoted
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts infinoted
# Description:       starts infinoted using start-stop-daemon
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/infinoted-0.5
USER=infinote
NAME=infinoted
PIDFILE=/var/infinote/.infinoted/infinoted-0.5.pid
DESC="Infinote Daemon"

test -x $DAEMON || exit 0

if [ -f /etc/default/infinoted ] ; then
        . /etc/default/infinoted
fi

set -e

. /lib/lsb/init-functions

# Function that starts the daemon
d_start() {
        log_daemon_msg "Starting $DESC" "$NAME"
        start-stop-daemon --quiet -c $USER -p $PIDFILE -x $DAEMON --start -- -d
        log_end_msg $?
}

# Function that stops the daemon
d_stop() {
        log_daemon_msg "Stopping $DESC" "$NAME"
        start-stop-daemon --quiet -c $USER -p $PIDFILE -x $DAEMON --stop -- -D
        log_end_msg $?
}

case "$1" in
  start)
        d_start
        ;;
  stop)
        d_stop
        ;;
  restart)
        log_daemon_msg "Restarting $DESC" "$NAME"
        d_stop || true
        sleep 1
        d_start
        log_daemon_msg "Done"
        ;;
  status)
        status_of_proc -p $PIDFILE "$DAEMON" infinoted && exit 0 || exit $?
        ;;
  *)
        log_daemon_msg "Usage: $NAME {start|stop|restart|status}" >&2
        exit 1
        ;;
esac

exit 0

###Additional information###

pam-pwdfile README

Wii Device Library v1.2 released

frozencow@gmail.com (FrozenCow) — Fri, 01 May 2009 22:00:00 +0000

Here is another release of Wii Device Library. This version fixes even more bugs and adds some more stablity. The major changes:

Balanceboards are now also supported under Windows.
All stacks are more stable (*).
Fixed support for Bluez v3.2.1 on x64 machines.
Fixed some issues for the Windows and Linux GUIs.

(*) You can now (un)plug your bluetooth dongle when running without problems.

You can get the full changelog at Google Code.

The download is available at the project page

Wii Device Library v1.1 released

frozencow@gmail.com (FrozenCow) — Sat, 18 Apr 2009 22:00:00 +0000

We have finally found the time and resources to release a new version of Wii Device Library. This version fixes a lot of the reported bugs and more. Here is a short list of the changes in this version:

Connecting using BlueZ has improved.
Connecting using MsBluetooth has become more stable and faster.
Fixed freeze when connecting to a Wiimote with plugged extension under Windows.
Fixed incorrect behaviour with multiple Wiimotes under Windows.
Fixed a rare bug that occured on some Vista machines.

Several other fixes and changes have been made. You can get the full changelog at Google Code.

The download is available at the project page.

Wii Device Library released

frozencow@gmail.com (FrozenCow) — Mon, 22 Dec 2008 22:00:00 +0000

After working on Wii Device Library on and off for several months we have decided to release our work to the public. This is not the first project we have worked on together, but it is the first project we have actually decided to release. Because of this we wanted to do it right, so we came up with a couple of requirements for the release of the library. In this post we will describe what decisions we made to share this knowledge with others and for ourselfs to look back upon.

Project hosting

As it’s likely we want to release more of our projects in the future, it will be helpful to have a centralized place where we can publish all these projects. That’s why we first started looking into project hosting websites such as SourceForge, Google Code and others. We felt that the projects we would be hosting there would be unrelated to each other and we wanted more control over our content. So, we wanted our own website. But since we were taking as long as we did to publish one project, we also wanted to start as soon as possible with the content. Developing our own website would take too much time. That’s why we chose a CMS, which in our case is WordPress. We chose WordPress because we could test it out on WordPress.com. There we found that it was possible to not only blog, but also create pages. And since we didn’t want to spend a lot of time making a theme, we could easily choose our theme from different theme-galleries. From here, things finally started to get rolling. We quickly found a good webhost and registered our domainname. Here we set up our own WordPress site, added a few plugins and we were ready for the next step.

Version control

We wanted our code to be easily accessable to everyone. For this we wanted a svn repository and an one-click download system. Choosing which svn repository to use was hard at first. There were tons of providers for this, all with different features. We thought about what features we really needed, in the end we just wanted an easily accessable code repository. We have also considered different version control systems. Subversion was more widely used than some of the others (Cvs, SourceSafe and Bazaar), so that was in line with our requirement of keeping everything easily accessable to everyone. Google Code gave us a Subversion repository, was fast and it also allowed people to browse the code online, which was just what we needed.

Download package

The repository was finished, but we still needed a download package, which included the binaries, sourcecode and examples, that had to be a breeze to find, download and extract. For this we have put a large download-button on the project page where a zip file can be downloaded. Other archive formats aren’t that well supported accros platforms, so zip was the only right format for this. We chose to not use external download systems, because this required more searching for mirrors that would like to host our files. Handling our own downloads would result in a fast and reliable user-experience. We only need to be aware of our monthly usage.

Examples

We wanted to make it easy to get started with the library. We found in other libraries and frameworks that the examples are a major factor in choosing the library or not. So we thought about what examples we needed to include. We divided the library in different ascpects. For each aspect we created an example that could be used as a program on its own. This makes it very easy to look into one aspect of the library without getting confused by the previous or next examples.

Go check out the Wii Device Library, and let us know what you think.