I spent the July 4, 2009 weekend here.
Photos here
Suffice to say it was an awesome time. The folks who put on Toor Con (never been to one) hosted ~150 (?) hackers, scientists, artists, and other creative types at a Titan I Missile Silo outside of Moses Lake Washington for 3+ days of astronomy, radios, kites, computer security and other general mayhem. I found the event via happenstance, and jumped at the chance to attend the first stateside analogue of the CCC events in Germany I'd been envying for some time. Equally I jumped at the opportunity to see a missile silo, as I love exploring, and did not know where else I might find one.
Environment:
This was my first visit to Washington state. I flew from a nondescript location in Iowa to Seattle, then made the last leg of the journey by car. I didn't see much on the outbound trip but the views coming back through the Cascades, ending in a Seattle sunset were spectacular. The digital camera had eaten all of its batteries by that point, so no pictures. The area around Moses Lake is full of irrigated farmland - good quality alfalfa hay, wheat, potatos and sweet corn under center pivot irrigation.
The camp site was hot, dry, and covered in light, powdery dust. It flew up at each step, it got into everything, it fed the dust devils that frequented the camp. USGS maps indicate the site had ash deposits from Mt. St. Helens. I got a look at the underlying structure in a cut half full of scrap and the remnants of a crane. Unsure whether the strata were undisturbed or backfill.
The dust was held by sagebrush, dotted with a few wildflowers. The ground between was littered with a dessicated moss the made the light dust look gray/black. A drop of water would open and green up the tendrils of a handful of the stuff. The dramatic transformation and the tactile sensation produced became the subject of frequent impromptu experiments.
Daily temperatures were in the 80s down to a very comfortable 60s at night. I found it pleasant compared to my usual midwestern humid summer. The direct sun was the hard part, blaring like Armageddon across the tents at dawn with heat soon to follow. The constant sun and dust meant constantly drinking water to avoid sunstroke.
Our hosts had provided us with a water truck which supplied drinking taps, sinks, and cold water showers that drained to an evaporation pool. Portable toilets, regular food service, medical support, ice - Toorcon's infrastructure generally did very well.
Events:
Upon arrival, guests were given shirts, an RFID badge kit, and hardhats. Drive in slow to minimize the dust and find a campsite. Half a dozen geodesic domes spread around the site, along with a pyramid of tarps, wood, and shipping containers.
Thursday afternoon and evening were a series of short talks (~20 minutes) and shorter ignite talks (5 minutes). Schedule ran over
and was frequently rearranged, a theme that would continue throughout the weekend.
Friday - two tracks of full hour talks, plus ongoing confusion about the schedule. One track was relocated after a dust devil wrecked a geodesic dome. Much gossip and grumping about the silo situation.
Site is owned (leased?) by a company called Levitate, with plans to put a datacenter in the silo complex. Owner has a related company, Levitate Energy, which he just started, to supply portable green generators. After making arrangements with Toorcamp organizers, Levitate attempts to piggyback its own event - a "green energy concert" with bands from Seattle and vicinity. Bribes Toorcamp participants with (previously promised) silo access in exchange for attendance at concert.
Some were annoyed with the Levitate Energy dust-up. In true hacker spirit, they dealt with it in creative ways. Hard hats, costumes, a V mask or two, and lots of photos of the diesel powering the "green" event. I spent my time amused by the reactions, and the spectacle of an entire conference worth of hackers getting social engineered into a startup company video.
Saturday - workshops, above and below ground. Silo tours! Endless earthworks and steel and concrete - a monument to the paranoia and threat of the cold war, a testament to those, like me, too young to remember. Evening speeches by Kaminsky, Emmanuel Goldstein, monochrom's hugely funny Soviet act, fireworks visible from town, DJs (dancing on concrete til bruised feet), and a random parade/dance to
the locked gates - it felt like the world had ended.
Sunday - more tours and workshops. Gave an impromptu speech on urban exploration to an audience that knew more than I did. Closing in the powerdome with two musical performances to take advantage of the unique acoustics - a homemade didgeridoo, and a duet of keyboard/electronics+stage sound exploring the site's original purpose.
Drive back to Seattle, take a real shower, enjoy a full night's sleep, then fly back.
Much is left out of the above: all the content of the talks, workshops, conversations, etc. Writing to steer my own memory. The rest of
you will just have to come out next time, I certainly intend to.
Wednesday, July 29, 2009
Friday, August 3, 2007
Random Recap
I'll return to the Zune posts in ~2 weeks with some info on the ROM files, and changes between versions. Eventually, I hope to have a profile of every chunk of code on that system available for reference. I'm also working on a little thing for my car, may put details of that up, to.
Some random thoughts before then:
Zune-linux.com died again - very strange, and now the zune hack scene appears even more dead than before.
This crackdown on console mod chips is revolting. The car analogy is appropriate here: this is akin to raiding the garage that installs aftermarket parts in your car.
Some random thoughts before then:
Zune-linux.com died again - very strange, and now the zune hack scene appears even more dead than before.
This crackdown on console mod chips is revolting. The car analogy is appropriate here: this is akin to raiding the garage that installs aftermarket parts in your car.
Wednesday, June 13, 2007
Corrupting pmcstore
Using the same procedure as before, I changed the first byte of the pmcstore.edb file. Upon reboot, the zune works, and I browsed the system settings. Shut it off, look at the db file again - we have the first 4 bytes changed. No verification? I don't know, and want to find how badly I can break this file (and in what ways) before it stops working. It would be easier if I knew the format for this db. EDB is a common extension - exchange uses it, as do several 3rd party vendors.
Side note: I'm trying to keep up with the various zune forums, rockbox, libmtp, and of course, http://zune-linux.com/ (I post as 'cross' there). Other handy reading material on msdn, and xda developers forum.
Side note: I'm trying to keep up with the various zune forums, rockbox, libmtp, and of course, http://zune-linux.com/ (I post as 'cross' there). Other handy reading material on msdn, and xda developers forum.
Wednesday, May 9, 2007
Zune hard drive and boot-up details
None of what follows is new, this is just my 'lab notebook', posted here for my own benefit, and maybe other zune modders.
I've taken apart my zune, per the guide at rapidrepair.com. With some adapters, I can mount the zune hard drive in my choice of OS. The device has two FAT32 partitions, one for media, and the other a 'system' partition of ~150 Mb. The sys partition (shows up with label 'TFAT' in Explorer) contains:
nk.bin, eboot.bin, recovery.bin, pmcver.dat. and pmcstore.edb, which is a database of the user settings (radio presets, theme, etc.)
The media partition contains: drmstore.dat, MediaLibrary.edb, MediaLibrary_thumbs.edb, devcert.dat, and a directory for your content.
With direct access to the system files, I tried the following. First, power on zune with no hard drive connected. The Zune logo appears, and then a graphic of a zune, a yellow circle with the number 5 (a status code, I assume), and "Contact Support" printed in three languages. Using the XVI32 hex editor, I changed a single bit in eboot.bin. Put the hard drive back in. The results: Zune logo, progress bar with status code 3 and "Please Wait". The device appears to restart (screen blanks briefly) and we see status code 1, "Connect Zune to your PC".
I shut it off, and put the hard drive back in my pc. The system partition was blank. So I copied the original files back over to it. Now it works like new. I did the same procedure three times with each bin file, and with the same results. The second trial, I switched the zune off the moment I saw the "Please wait" screen. It had already wiped the partition. The last time, I left nk.bin broken and changed recovery. Why I did this is explained below.
My assumption of how things go:
1. The CPU loads a copy of eboot from the flash ROM, checks it for errors, and runs it. (This is probably when the zune logo first appears)
2. Eboot checks the system partition for errors. If everything's fine, it loads nk.bin from the hard drive and boot proceeds normally. (I'm guessing this is the progress bar)
3. If Eboot finds a problem (signatures don't match), it wipes the system partition and reboots Recovery.bin from flash ROM. I'm not sure how this happens, but the Recovery file on the hard drive is not loaded at reboot (or it wouldn't have rebooted in experiment 3)
4. Recovery looks for zune pc software and reloads the OS (I haven't tried the 'approved' way of doing this, copying the files back seems to work fine)
Further directions:
I know a little bit more about the boot process now, but there are still lots of questions. My next attempts will be at corrupting the edb databases - I'm not sure if anything beyond the bin files is checked or not.
I've taken apart my zune, per the guide at rapidrepair.com. With some adapters, I can mount the zune hard drive in my choice of OS. The device has two FAT32 partitions, one for media, and the other a 'system' partition of ~150 Mb. The sys partition (shows up with label 'TFAT' in Explorer) contains:
nk.bin, eboot.bin, recovery.bin, pmcver.dat. and pmcstore.edb, which is a database of the user settings (radio presets, theme, etc.)
The media partition contains: drmstore.dat, MediaLibrary.edb, MediaLibrary_thumbs.edb, devcert.dat, and a directory for your content.
With direct access to the system files, I tried the following. First, power on zune with no hard drive connected. The Zune logo appears, and then a graphic of a zune, a yellow circle with the number 5 (a status code, I assume), and "Contact Support" printed in three languages. Using the XVI32 hex editor, I changed a single bit in eboot.bin. Put the hard drive back in. The results: Zune logo, progress bar with status code 3 and "Please Wait". The device appears to restart (screen blanks briefly) and we see status code 1, "Connect Zune to your PC".
I shut it off, and put the hard drive back in my pc. The system partition was blank. So I copied the original files back over to it. Now it works like new. I did the same procedure three times with each bin file, and with the same results. The second trial, I switched the zune off the moment I saw the "Please wait" screen. It had already wiped the partition. The last time, I left nk.bin broken and changed recovery. Why I did this is explained below.
My assumption of how things go:
1. The CPU loads a copy of eboot from the flash ROM, checks it for errors, and runs it. (This is probably when the zune logo first appears)
2. Eboot checks the system partition for errors. If everything's fine, it loads nk.bin from the hard drive and boot proceeds normally. (I'm guessing this is the progress bar)
3. If Eboot finds a problem (signatures don't match), it wipes the system partition and reboots Recovery.bin from flash ROM. I'm not sure how this happens, but the Recovery file on the hard drive is not loaded at reboot (or it wouldn't have rebooted in experiment 3)
4. Recovery looks for zune pc software and reloads the OS (I haven't tried the 'approved' way of doing this, copying the files back seems to work fine)
Further directions:
I know a little bit more about the boot process now, but there are still lots of questions. My next attempts will be at corrupting the edb databases - I'm not sure if anything beyond the bin files is checked or not.
Saturday, April 14, 2007
Zune Hacking
What I know:
Zune boot process:
imx31L loads Eboot.bin from ROM to protected on-cpu memory
Strips Verisign certificate, decrypts SHA-1 hash of image with on-cpu public key
computes SHA-1 of loaded image, compares to above.
If equal, Eboot loads NK.bin from system partition of HD
If not, Load Recovery.bin*1, whose only functionality is to connect (sync?) to pc, and
reload valid firmware.
Update Process:
I'm not clear if any verification happens when updating or not. Does the pc side check? The device? Both? Does the device verify before writing updates, or let the boot-time check catch
unauthenticated code?
Notes:
*1: I'm not clear on what gets loaded from where. Eboot is on the flash ROM. But where is Recovery.bin? One reference has it in ROM, the other says hard drive.
References:
Hardware info from
http://www.bunniestudios.com/wordpress/?p=131
http://forums.rockbox.org/index.php?topic=6848.0
Info on the imx31L ( the security features pdf is specially recommended)
http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=02XPgQ821729733642&tid=WMSG200506VANITYIMX31
Info on boot process and hard drive
http://zunerama.com/forum/index.php?&topic=1273.0
http://www.zuney.net/zune-hacks-mods/258-bad-news-firmware-hacking.html
Zune boot process:
imx31L loads Eboot.bin from ROM to protected on-cpu memory
Strips Verisign certificate, decrypts SHA-1 hash of image with on-cpu public key
computes SHA-1 of loaded image, compares to above.
If equal, Eboot loads NK.bin from system partition of HD
If not, Load Recovery.bin*1, whose only functionality is to connect (sync?) to pc, and
reload valid firmware.
Update Process:
I'm not clear if any verification happens when updating or not. Does the pc side check? The device? Both? Does the device verify before writing updates, or let the boot-time check catch
unauthenticated code?
Notes:
*1: I'm not clear on what gets loaded from where. Eboot is on the flash ROM. But where is Recovery.bin? One reference has it in ROM, the other says hard drive.
References:
Hardware info from
http://www.bunniestudios.com/wordpress/?p=131
http://forums.rockbox.org/index.php?topic=6848.0
Info on the imx31L ( the security features pdf is specially recommended)
http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=02XPgQ821729733642&tid=WMSG200506VANITYIMX31
Info on boot process and hard drive
http://zunerama.com/forum/index.php?&topic=1273.0
http://www.zuney.net/zune-hacks-mods/258-bad-news-firmware-hacking.html
Subscribe to:
Posts (Atom)