I apologize for taking this long to post this! I’ve been busy non-stop since 27c3 and never got a chance to get around to it. Finally, though, here it is: the description of the Mark 1 laser projector that I use with OpenLase.

But wait, there’s more! If you don’t have the hardware and don’t want to build it, or you want to try out OpenLase, or you want to be able to mess around with it on the go, you can now do that. There’s a new OpenGL-based simulator in the OpenLase tree. It works off of the JACK data (so you still need JACK) and it tries to simulate the dynamics of my laser scanner, including brightness effects and some of the physical limitations of the galvos. Here’s a comparison of the simulator vs. the real thing:

I’m aware that documentation on the software is still sorely lacking. Please bear with me while I get my act together and write that up

Or how to practice Safe Hex

Ah, the world of computers. Thanks to the wonderful world of bits and bytes, we can experiment with any application, file, driver, or even the core operating system. Rip them apart, change things, put them together, and if it doesn’t work, just try again. At worst, you’ll have to wipe your hard drive and start over. If you somehow manage to destroy a computer purely through bad software, that’s considered a design problem and a true feat to pull off. Just think about it: what other profession or hobby lets you experiment as much as you want and make as many mistakes as you want without having to spend a cent if you do something wrong?

Unfortunately, things have changed. Ever since the advent of embedded devices with upgradable firmware, people have been trying to modify and hack them. These devices are usually a lot less resilient than their bigger, older siblings. Many of the new shiny gadgets that we use every day are internally fragile and a slight software mishap can render them non-functional, a “brick”.

This is a guide for developers and hackers who work on system firmware for embedded devices.
Read the rest of this entry »

As you probably already know, libgpod has included support for Apple’s iOS 2.x hash for a while now. With their new devices, Apple changed the hash again, but for some reason the change only applies to new devices – old devices running iOS 4.x still work. However, if you have a new device (iPad, iPhone 4, or iPod touch 4G), music sync does not work.

If your device is not jailbroken, you’ll have to wait until the new hash is reverse engineered. However, if your device is jailbroken, you’re in luck. As it turns out, the old DBVersion trick once again works to convince those devices to use the previous hash method.

In a nutshell, log in to your device via SSH, edit /System/Library/Lockdown/Checkpoint.xml, find the DBVersion key, change its value from 5 to 4, and finally reboot your device. This has been successfully tested on an iPhone 4, but I assume it will work for the others too.

Caveats regarding the iOS 2.x hash still apply. Specifically, libgpod needs some information to generate the hash. It can gain this information from a prior sync with iTunes, though this probably won’t work unless you sync again after changing DBVersion, and this hasn’t been tested. Alternatively, you can use this page to generate a HashInfo file for your device and manually copy it; this should always work.

Update: see this post for hardware info and also a new GL laser simulator for those without hardware.

First of all, as I’m sure everyone knows by now, I’ve been working on hacking the Kinect and writing open drivers for it. There’s a website for the community and a Git repo with the code, and it’s working fairly nicely by now.

With that out of the way, here’s a project that I’ve been working on on-and-off for the past year or so. I’ve been interested in laser scanning and DIY laser projectors, but I couldn’t find any good open source software to drive them. Specifically, I was interested in the realtime aspect: rendering and showing dynamically generated images and responding to events, not just making and preprocessing laser shows. So I set out to write my own set of software to do real-time rendering. This was the result:

Read the rest of this entry »

As most of you will probably already know, I’ve been working on a project recently which aims to run Linux on the PS3 (including the PS3 Slim) using the PSJailbreak exploit, effectively replacing GameOS on the fly. I think it’s gotten to the point where it’s useful enough for other people to be interested, so here’s something resembling an official announcement.

Obligatory demo video:

Read the rest of this entry »

Linux has a tweakable knob called laptop_mode which is meant as an energy saving tool for laptop users on battery: it basically says “try not to touch the disk for X minutes at a time, unless you really need to, and once you do, do everything that you’ve been piling up all at once”. It’s great for laptop users, and doubly so for things like my huge laptop with two 7200RPM HDDs. Seriously.

Now, there are two things that mean you “really need to” hit the disc: reading data that isn’t already cached (duh), and the fsync() and fdatasync() calls. The latter are requests by an application to ensure that all of the data written to far has hit the disc, and they cause the disk to spin up in laptop mode.

Unfortunately, Firefox has a habit of randomly issuing fdatasync() calls. It does this as part of the SQLite backend for its various databases (especially places.sqlite), in order to avoid data corruption. Now, data corruption isn’t terribly likely on a laptop with a battery (which is essentially a built-in UPS), so this is a terrible annoyance with little benefit anyway. There has been talk about this problem, but apparently it’s still around (and the toolkit.storage.synchronous about:config property didn’t work for me). Most of the reports appear to claim that this happens while browsing, but I’ve seen it happen periodically even when Firefox is left idle. Maybe it’s caused by some extension or AJAX webapp? Who knows.

Read the rest of this entry »

Last post was more along the lines of an announcement, so here’s a more concrete guide. There have been new releases of most parts of the software stack in the past few days, so now is the time to grab them if you’re interested. Libgpod is the exception, since it’s still being worked on to get proper support for the iPhone OS 3.x database. That said, if you’re interested in being an early adopter of iPhone sync support and helping us test it, here’s how.
Read the rest of this entry »

Those who watch my git repos may have noticed that I’ve been working on this for a while now. iPhones and iPod Touches have never been properly supported under Linux (especially non-jailbroken devices) because they are just so different from all the previous iPod models. There was a lot of new code to write and Apple hasn’t exactly made it easy either:

• The iPhone uses a custom USB communications protocol, connection-oriented, which is totally different from standard mass storage devices
• It provides multiple services over this protocol, and many have to be interacted with to complete sync
• iPhone OS 2.x brought us a new hash (designed to lock users into iTunes) that so far had not been reverse engineered
• iPhone OS 3.x brought us a new SQLite-based database format which, although a lot more Linux-friendly than the old proprietary format, does require a bunch of new code (and the old format still needs to be supported for compatibility).

Well, I’m happy to say that all of this is coming to an end and that Linux will finally get quite complete iPhone/iPod Touch syncing support soon, thanks to the work of many dedicated people. Read the rest of this entry »

It seems the ongoing trend for laptops is to integrate and hide as much as possible from the user. We’re all used to minimalistic crappy BIOS setups with two or three configuration options. However, things go way too far when OEMs remove options related to features that the hardware is capable of but which are disabled by default. This happens with Intel VT on many laptops – even if the CPU supports it, you may not be able to find the BIOS setup option to turn it on.

I certainly wanted to use a feature that I paid for, so I started investigating the BIOS and here’s what I found out.

Update: There’s a 1.21 BIOS floating around that seems to have VT enabled natively. See below.
Read the rest of this entry »

With the new OS version, Apple totally changed up the database format. Now it’s based on a whole bunch of SQLite files and there are also a few files in a format similar to the old proprietary one. There are more than likely still hashes in the critical files, and there’s also a suspicious pair of files that appear to be entirely encrypted. The SQLite format is open and certainly better than the old one, but someone still needs to interface a media player to it.

The upshot of this is that a whole new support library will need to be written or large changes in libgpod need to happen to support the new SQLite format. The DBVersion hack also isn’t going to work – either someone needs to reverse engineer the complete hashing algorithm (and maybe that encrypted file stuff), or the MusicLibrary binary on the phone needs to be patched. So, if you’re currently syncing music with free software, you’ll want to hold off on upgrading to 3.0.

Patching the check out of MusicLibrary looks trivial enough, so although it’s not as easy as the DBVersion hack, it isn’t a real showstopper. The hash algorithm looks the same as the old one, or at least quite similar (and just as badly obfuscated). Those encrypted files do scare me a bit though.