Piezo-Acoustic iPod Hack 397
jugander writes "nilss over at the iPodLinux Project (previously on /.) has performed one of the coolest and most bizzare hacks I've seen in a while. He was able to extract the bootloader from the 4G iPod by sounding out ticks with the iPod's squeaky piezo. With some tweaking and a makeshift recording studio, he was able to dump the 64 kb file at 5 bytes/sec. And yes, this means that 4G iPods can now boot linux!"
Google Cache (Score:5, Informative)
The Sound of iPod
I got an iPod for christmas. The ipodlinux project was one of the main reasons for my choice and so I started exploring the iPod as far as I was able to. I patched the bootloader and got some basic code to run but there was no way to access any hardware other than the two CPUs yet. To get the LCD, Clickwheel and the harddisk working we needed to reverse engineer the bootloader in the flashrom. But to do that we first had to find a way to get that code. Seems quite impossible without any knowlegde about the IO-Hardware but I found a solution...
The whole idea started last week when leachbj gave me a piece of code that caused the piezo in the iPod to make some *squeek*-sound. I played around with that code, changed some values and somehow was able to produce different sounds. Just for fun I came up with the idea of using this different sounds for transferring data. Some minutes later I dropped the idea because I thought that just won't work and I won't be able to write a decoder for that. Two days later I woke up and somehow just tried encoding a 32bit value into different beeps. It worked so made a loop around it to dump about 4kb of memory.
The problem with that idea was that I could only transfer 8bit/s. Anyway, I tried writing a decoder and it seemed to work. Well, it didn't really work but it decoded about the first 256 bits correctly. The decoder was some Perlscript that loaded the whole audio into RAM and used about 1GB RAM for a 20MB audio file. It worked ok with some tweaking but still the RAM usage was way to high because if I wanted to dump the whole 64kb I would have an 1200MB audio file or something.
Some ideas came to my mind after thinking about the problems I had. The first one was to use compression so the transfer won't take too long. It would have taken about 45hours with the code we had. With compression maybe only 22h. To solve the memory problem I decided to rewrite the decoder in C that only reads about 96bytes chunks of audio data and then decodes that. Davidc_ helped me with that.
This was the first time I thought I this could really work. Again I played with the piezo code and figured out, how the piezo really works. I was able to produce some more unique beeps. Later I made the beep for 0 (the last bleep you can see in the picture) much shorter so it sounded more like a click. I even managed to make the first bleep shorter so I got about 5byte/s.
When we thought we got the encoder in the iPod with zlib and the decoder working, I decided to try recording the whole dump at night. So I put the iPod in the "iPod Recording Studio" and went to sleep. The iPod is just a cardboard box in which Samsung send me my laptop back. It has foam in it so I thought it would be ideal for recording the bleeping of the iPod. (Move your mouse over the picture.)
The next day I woke up quite early. The first thing I did was looking at the recording. I heard the iPod stopped bleeping so I thought everything went fine. In fact nothing worked at all. I recorded 8 hours full of zeros. Furthermore, the iPod's battery became empty though it was plugged into the USB port of my laptop the firmware wasn't loaded so it didn't request power over USB. So what you can see in the picture is the harddrive spinning down, then the iPod goes off for some minutes and then reboots. The harddriver was spinning during the whole recording session because there was no way to turn it off.
After this I was really disappointed and I dropped the project for the rest of the day but in the evening I tried again with a better decoder. It worked quite well but we weren't able to decompress the file. I concluded that was caused by the malloc() hack and zlib would allocate the same memory twice or something like that. Anyway, I haven't had much sleep that weekend so I was tired and just went to bed and thought about dropping the whole
Re:piezo? (Score:4, Informative)
Coral Cache link to article (Score:3, Informative)
Re:piezo? (Score:5, Informative)
His goal: extract the data from the ROM.
His problem: he didn't know very much about the hardware. Sending the data through the FireWire port was not an option, since he had no idea how to access that port.
His opportunity: someone showed him how to make the piezo make sounds.
So, he picked one sound to represent a 1 bit, and picked a different sound (more of a click) to represent a 0 bit. Then he wrote code to read data from the ROM, and bit by bit, look at each bit and play the appropriate sound. He recorded the sound. It took hours to dump the whole ROM this way.
Then it was a matter of sampling the recording with a desktop computer, and writing code to detect the two different sounds, turn them into data bits, and save the data bits on disk.
steveha
Re:looking forward to an iPod emulator (Score:3, Informative)
Unlike a GBA emulator, for example, there's no content for an iPod emulator to play that you can't already just play in your native desktop OS.
Re:Does this mean? (Score:3, Informative)
Vorbis gives you better quality for the same number of bits, or a smaller file for similar quality. Partly this is because it's just newer technology and does some stuff better, but it's also because it's a little more complicated. While MP3 uses standard reference tables for encoding and decoding, a Vorbis encoder computes an ideal reference table for the particular song being encoded and then saves that reference table as part of the Ogg file. This means that a Vorbis decoder needs to read the reference file and save it in RAM.
Also, MP3 has been around a while, and lots of people have worked to write code that is small and fast for low-CPU-power devices. Vorbis is much newer. The original, "reference" decoder makes use of floating-point maths, which is fine for a desktop workstation but not so good for a low-CPU-power device. The Vorbis guys did write an integer-math-only decoder, Tremor, which presumably is what devices like the iRiver iHP-40 use. But the Tremor decoder could probably use a few man-years of optimisation work to speed it up, make it smaller, etc.
The iPod Linux guys do have Vorbis decoding working on a Linux iPod; the problem is that it's not full-speed yet. It should be possible to optimise Tremor and get it working on iPod but I don't know when it will happen.
http://www.xiph.org/ogg/vorbis/ [xiph.org]
Re:blindPod? (Score:3, Informative)
Now that he has dumped the firmware, he knows where most of the other hardware is mapped.
Re:Yeah it's pointless.. (Score:2, Informative)
Linux on iPod Sourceforge Project (Score:2, Informative)
i agree! (Score:3, Informative)
don't pick on someone that has a hobby that exercises their mind. go after all the people wasting their brains.... or the ones that take financial aid to go to college just to drink and fuck off for 4 years and end up doing some worthless job shuffling papers.
Re:Does this mean? (Score:3, Informative)
I looked up the spec sheets to double-check my info (and realized I was wrong.) Here they are in case anyone else wants to check them out:
PP5002 for 1-3 Gen iPods:
PP5002 [portalplayer.com]
PP5020 for 4+ Gen iPods:
PP5020 [portalplayer.com]
Re:iPod's crappy software (Score:2, Informative)
Maybe you should spend your next hour on the train to read the manual ?
Re:why do you people only care about linux (Score:2, Informative)
The iPod can't run BSD, Darwin or any other system like that because it does not have a hardware memory management unit. iPod linux is based on the uClinux [uclinux.org] distribution, which is, "a port of Linux to systems without a Memory Management Unit (MMU)".
This hack was for transmission, not for reading (Score:2, Informative)
This was not a hack for reading data from the ROM. Apparently, he already had the code for that, so this was not a problem.
What he was missing was a way of transmitting the data to another device. The piezo hack solved this problem.
This hack will consequently only be useful for other devices if you:
- have already found a way of reading the data from the ROM.
- have not found an easier way of transmitting these data to another device.
- have an option of creating a sound output from the device through software.
I don't know how frequently this scenario will occur. My guess is "very rarely".