After FASTA, I got interested in gff3. The link to the grammar for this file is here: antlr/grammars-v4. You can read about gff3 here.

I’ve bee hacking away trying to set up Crochet-BSD to build boot images for Wandboard.  Wandboard uses Cortex A9 processor, so it’s ARM.  The linux distros for it use U-Boot, so that seemed like a likely place to start for FreeBSD. Looking at the Wandboard Wiki, there is an article on U-Boot which explains how to build U-Boot for Wandboard.   Firstly, download the October 2013 release of U-Boot here.  If you are building on FreeBSD, you’ll need this patch to the Makefile to include libc. Then, build U-Boot for wandboard: make wandboard_quad_config make and copy the imx file to the sd card sudo dd if=u-boot.imx of=/dev/mmcblk0 bs=1 seek=1024 This writes the imx file 1K into the disk; which is where the i.mx6 processor expects to find the U-boot image.  The processor manual is here.  It specifies offset 0x400 as the Program Image start on the SD card.  The U-boot startup looks like this: CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: Wandboard DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning – bad CRC, using default environment In: serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 1 0 mmc0 is current device SD/MMC found on device 0 Keep in mind that the default serial protocol for Wandboard is 8n1 and 115200. Once U-boot is started, you will need to boot the FreeBSD kernel.  My disk image is partitioned with a FAT partition on which I have kernel.bin, and a UFS partition which is the FreeBSD root file system.  kernel.bin is the raw kernel.  The partition table looks like this: Disk: /dev/rdisk1 geometry: 3880/255/63 [62333952 sectors] Signature: 0xAA55 Starting       Ending #: id  cyl  hd sec –  cyl  hd sec [     start –       size] ———————————————————————— *1: 0C    8   5   1 –   58  29  63 [     16443 –     102375] Win95 FAT32L 2: A5   58  30   1 –  992   1  63 [    118818 –    1881180] FreeBSD 3: 00    0   0   0 –    0   0   0 [         0 –          0] unused 4: 00    0   0   0 –    0   0   0 [         0 –          0] unused You should notice that the FAT partition starts at 16443.  I’ve moved the start of the FAT partition further into the disk to accomodate u-boot at disk offset 0x400. Once you’ve got an SD card with u-boot and kernel.bin on it, and you’ve booted to u-boot, you’ll want to start the kernel.  At the u-boot console, load the kernel.bin into memory at address 0x12000000. fatload mmc 0:1 12000000 kernel.bin The address 0x1200000 is specified in the FreeBSD ARM configuration for Freescale.  Check here. Once the kernel is loaded, go ahead and start it: go 12000000 This will start FreeBSD: KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r259276: Thu Dec 12 17:20:23 MST 2013 tom@bernice:/storage/home/tom/crochet/crochet-wandboard/crochet-freebsd/work/obj/arm.arm/storage/home/tom/crochet/src/FreeBSDHead/head/sys/WANDBOARD-QUAD arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Preloaded elf kernel “kernel” at 0xc24afdac. CPU: Cortex A9-r2 rev 10 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled In my case, I’ve run into a kernel crash starting the kernel, so I don’t have a fully working system yet, but I do have a working boot loader.  The Crochet-BSD code to build an image file containing USB, a partitioned disk image, kernel.bin and the userland is here:

I’ve been reading lots of interesting information about iTunes and IOS, so I thought I would investigate, just what is in an iTunes backup.  Typically, on OS X, you can find your iTunes backup here, under the appropriate OS X user profile: /Library/Application Support/MobileSync/Backup When you look at the backup, it’s a giant list of 40 character hexadecimal file names.   After doing some quick reading on theiphonewiki.com, those file names are SHA-1 hashes.  Each of the files, is a backed-up file from the iPhone.   The problem of restoring the file system then is that we need to find the original file names from the hashes. Luckily, Apple provides an index.  There is a file called “Manifest.mbdb” which is a binary index of all the SHA-1 files.  There is a pretty good description of the format of that file here.   After reading the Manifest.mbdb into memory, we have enough information to generate all the SHA-1 hashes.  From there, we can match the generated hashes to the filenames on the file system, and we have enough information to regenerate the backed-up filesystem. Once we have the file system, it’s interesting to look around and find out what information was actually backed-up.  Here’s some highlights: SMS messages:  “Library/SMS/sms.db”.  This is a sqlite database. Address Book: “Library/AddressBook/AddressBook.sqlitedb”.  sqlite database. Notes: “Library/notes/notes.sqlite”.  sqlite database. Call History: “Library/CallHistory/call_history.db”. sqlite database. Photos: “Media/DCIM/”.  File systems of JPG files. SMS photos: “Library/SMS/Attachments”. File system of JPG files. Safari bookmarks: “Library/Safari/Bookmarks.db”.  sqlite database. I have working proof of concept code, however, in the interest of being a good guy, I’m keeping it private.