Kindle auto-updates

This blog has moved

Just got an email from Amazon saying if I turn my Kindle on and leave it connected to WIFI for a few minutes it'll automatically download and install the latest firmware update.

Be careful with your jailbreak!

Kindle firmware 3.1

This blog has moved I've been doing some playing about with the recent kindle 3.1 firmware release. The salient points are:
  1. The jailbreak can no longer be installed because Amazon have patched the busybox tar exploit which allowed unrestricted writing to the root filing system. Keep an eye on this thread over at mobileread for information on 3.1 jailbreaking progress.
  2. Homebrew can no longer be installed (or deinstalled) because Amazon have patched the  /usr/sbin/otaup script to only use Amazon's keys when verifying software updates: the extra one installed by the jailbreak (and used to sign homebrew updates) is ignored.
  3. If you installed the jailbreak and then the usbnet patches (or any other homebrew) under <= 3.0.3, and then updated to 3.1, they should be left intact.
  4. You can't downgrade to an older firmware release since Amazon's binary patch update format does not support this (it could be done manually if you already had root shell access though).
So, as long as you installed usbnet previously, you should still be able to ssh into the kindle and gain a root shell.
If you look at a diff of the old vs the new /usr/sbin/otaup script, they have changed the line:

KEYFILES=$(ls /etc/uks/*pem)

to:

KEYFILES="/etc/uks/pubprodkey01.pem /etc/uks/pubprodkey02.pem "

The jailbreak key is called "/etc/uks/pubhackkey01.pem. Therefore, as long as you have a root shell, you can simply manually rename them. In fact, I've decided to disable the Amazon keys by default to avoid any unwanted future updates they might automatically push to me:

mntroot rw
cd /etc/uks
mkdir AMAZON
mkdir HACK
mv pubprod* AMAZON
mv pubhackkey01.pem HACK/pubprodkey01.pem
mntroot ro

Then, when you want to install/deinstall a homebrew app:

mntroot rw
cd /etc/uks
cp HACK/* .
mntroot ro

And for an Amazon firmware update (you might want to remove their keys after the update again to  disable pushed auto-updates):

mntroot rw
cd /etc/uks
cp AMAZON/* .
mntroot ro

Finally, the good news is that they haven't changed the signing of Kindlets, so as long as you've got my devkeys installed, they'll work as previously.

Interestingly, they have a new Kindlet API jar, version 1.2. I'm going to analyse it and describe what is new in a later post.


Note that this all worked fine on my and another test Kindle; please don't blame me if it bricks/disables homebrew on yours.

Pickit2 Logic Analyser in pypickit

This blog has moved I've finally got round to implementing this in pypickit.

The Microchip Pickit2 device has a built in logic analyser mode available in its Windows application. I've implemented support for it in my pypickit project, here. The program is called "analyser.py".

I didn't want to have to deal with drawing bitmaps or anything in a library designed to be as simple as possible, so I've decided to output the traces vertically in a simple text file. This actually is quite handy as you can just annotate  them in a text editor, and use standard tools such as "less" to page through it. A sample screenshot of the output is (click for larger):





 

Merging developer keystores on the Kindle

This blog has moved

It is obvious that more than one person will want to  write homebrew for the Kindle. However, with my (now defunct) adqdevkeys-0.1 package, it just copies the file over whatever is already there, so we can only have one set on a device at one time. Annoying!

Therefore, I've just written a small Java program which can merge two keystores together. The source is available here. I've also just released a new key package for my keys using it here; I hope others will do the same!

For non-developers: there's no real need to upgrade to my new keystore release as the keys are the same and provides no new functionality to my apps.

For developers: It assumes the keystore and keys all have a password of "password". The command syntax is:


mergekeystores <dest keystore> <merge keystore>


This will merge keys in <merge keystore> with those already in <dest keystore>, or create a new <dest keystore> if one does not already exist. All you need to do is create a keystore of your own, with your own unique alias string, and create an update package for them.

Switching to Virtualbox and getting Snow Leopard to work in a VM

This blog has moved

Originally I had been trying to get Snow Leopard to work in qemu-kvm, and it kind of does; I had even thought of contributing to that project to make it work even better (e.g. the e1000 emulation does not work under Mac OS X). However, I decided that I simply don't have the time: I had submitted a patch to their developer list fixing SCSI MMC passthrough, which allows things like clonedvd, or CD burning to work from inside a VM. I never received a response to the final patch (not even a NAK), which discouraged me from spending much more time on it.

Anyway, now, a few months later, I've been playing about with VirtualBox. Frankly it just works a lot better; there's a nice management GUI, 2d/3d acceleration, nice modular source code, command line management tools, and you can easily host VMs on a remote machine and manage them using the excellent phpvirtualbox if you want. I've converted all my VMs to it and zapped qemu-kvm completely.

Interestingly, it also supports Snow Leopard (mostly) out of the box without any faffing about with bootloaders. I had followed these instructions, but I ran into various problems:



CPU Incompatability

I installed it on an older Core 2 Quad based machine, and the installation worked perfectly fine. However when I tried it on my Core i5 laptop, the infamous AppleIntelCPUPowerManagement kext told me I had an "Unsupported CPU". So I need to kill that prior to the install.

I needed to modify the snow leopard installation ISO prior to installation. Apple's installation media are slightly odd: they have a normal ISO9660 filing system, which contains various drivers for windows. However, they also have a legacy "Apple Partition Map" partition table which has the actual installation filing system on it. Assuming you can mount it under linux, this makes it dead easy to customise as it is a full read/write filing system, unlike ISO9660.

I'll want to loopback a specific partition from the image, which tends to be tricky under linux. However I recently found a useful tool, "kpartx" in the multipath-tools suite. It uses the linux device mapper to create devices for each partition in an image, which you can then mount normally.

It goes like this (as root of course):
modprobe dm_mod
LDEV=`losetup -f -v snowimage.iso | sed "s/Loop device is //"`
kpartx -av $LDEV

This should create a number of new entries in /dev/mapper of the form "loopXpY", where X is the number of the /dev/loop device created by losetup above, and Y is the partition number. We want partition 3, and we can now mount it with:
modprobe hfsplus
mkdir /tmp/snowmnt
mount /dev/mapper/loop0p3 /tmp/snowmnt


You can now simply remove the kext with:
rm -fr /tmp/snowmnt/System/Library/Extensions/AppleIntelCPUPowerManagement.kext
And finally, unmount the image:
umount /tmp/snowmnt
kpartx -d snowimage.iso
losetup -d snowimage.iso


After this, you should be able to do a normal install on even modern CPUs.

Oh, once you've installed it, it will, of course, have installed a new copy of AppleIntelCPUPowerManagement.kext on your local disk; just boot up off the install DVD again, and use the Terminal app to:

rm -fr /System/Library/Extensions/AppleIntelCPUPowerManagement.kext

and reboot.


100% CPU Use on older CPUs

If you're installing on an older CPU, and didn't need to remove AppleIntelCPUPowerManagement.kext, I found the VM used 100% CPU all the time. This is apparently well known, is due to the VM not implementing the hardware that kext requires, so it sits in a tight loop spewing errors. I'd recommend just:
rm -fr /System/Library/Extensions/AppleIntelCPUPowerManagement.kext

as root from an existing Mac OS X installation, and reboot.


Upgrading kills the installation

So, once I had it all installed, I naturally wanted to upgrade it to the latest point release. I duly downloaded it, and set it installing. It seemed to work, but right at the end, somewhere during the "Moving files into place" stage, Mac OS crashed, with a  "You must press reset on your machine" message. After that, the image was completely screwed and will not boot.

So, one reinstall from scratch later, I took a snapshot of the VM (yet another feature of virtualbox which is much easier than qemu). Interestingly, I remembered I had tried this on the older machine, with AppleIntelCPUPowerManagement.kext still in place, and it worked fine. During the upgrade, a new version of that kext is installed. I wondered if Mac OS X was then immediately loading it, which would then kill the machine.

So, I downloaded a copy of the NullCpuPowerManagement.kext from here. This is designed to override AppleIntelCPUPowerManagement.kext, and just do nothing at all. I installed it into /System/Library/Extensions as normal, and rebooted. I checked it was definitely being loaded by running:
ioreg | grep Power

under Mac Os X and I could see it was. I started the installation again, and this time it worked perfectly right to the end! 

However, after a reboot, it failed at AppleIntelCPUPowerManagement.kext again. Obviously NullCpuPowerManagement.kext can prevent any new power management kexts being loaded, but if both it and the original are there, mac os x will choose the original. Not a problem really; I simply reset the VM and booted it back up off the snow leopard DVD and deleted AppleIntelCPUPowerManagement.kext again using the Terminal. Rebooted, and its working perfectly at 10.6.6.

It is slightly annoying I still have to modify the image slightly, but at least you can do it with an absolute minimum of changes.

UPDATE: On a hunch, I wondered if perhaps Mac OS X enumerates the drivers in /System/Library/Extensions in alphabetical order (AppleIntelCPU.... is before NullCPU.... obviously). So I restored AppleIntelCPUPowerManagement.kext and renamed NullCPUPowerManagement.kext to be before it with:

cd /System/Library/Extensions
mv NullCPUPowerManagement.kext AAANullCPUPowerManagement.kext


And rebooted. Guess what, it works!

HTC Desire HD

This blog has moved My wife bought a new phone the other day, an HTC Desire HD, which means she now has a better phone than I do, grrr!

Anyway, within a few hours of receiving it, I had rooted it, removed the security checks, and installed an engineering HBOOT thanks to the helpful instructions over at Cyanogen's wiki. Annoyingly, its all been broken already, I didn't even have to disassemble the baseband firmware this time!

Oh, I then built a cyanogen gingerbread build for it. It worked but had no sound. However, using one of the cyanogen nightlys had working sound. The phone needs various binary blobs copied from an existing firmware, and I had just used the ones supplied by Orange. The blobs in the nightly are different, so I suspect Orange had just messed things up as usual. Its now working perfectly.

Anyway, its great improvement over the Hero! 

ipsec-tools / racoon support for Checkpoint VPN-1 proprietary XAUTH authentication

This blog has moved I posted about this a while back, and submitted a patch to the racoon developers list. However, I never heard anything back about it (despite other people asking about it now and then). Is that project actually dead or something?

Anyway, since nothing seems to be happening there, I've just packaged it up into an AUR build for arch linux, available here.

As I mentioned before, they've just copied XAUTH exactly, but changed the packet codes so they conflict with other message types.

There is one extra thing though: I've not implemented XAUTH_CPSC_CHALLENGE as that would require calling out to an external program to ask the user to enter a dynamic challenge password in the middle of the IPSEC negotiation. You can set Checkpoint up to SMS such a code to them on the initial connection to the VPN server, and it will require it during authentication.

Oh yes, in future when I'm trying to track down why my VPN connection drops after 10 minutes (I was looking at packet traces and everything!), I really should make sure I haven't included an option like "lifetime time 10 minutes" in the config file. I find that tends to make it drop the connection after 10 minutes.

redbus update

This blog has moved Did a spot of redbus development this evening, one politeness fix, one bugfix and one really annoying thing.
  • Politeness:  silence the stop data update alarm. It'll still warn you when updates are available, but it shouldn't make a noise/vibrate/blink lights etc.
  • Bugfix: Searching for locations from the map view now works again.
  • Really annoying thing: Lothian's website no longer supports future departures beyond the current day. You can still submit the URLs (e.g http://www.mybustracker.co.uk/display.php?clientType=b&busStopCode=36242497&busStopTime=23:00&busStopDay=1 ), but you never get any results if busStopDay is > 0. Quite annoying actually, as that feature was quite useful to check timetable times in advance. :(