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.
(more…)

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.