The iPod 4G was very similar to its predecessors. The software was stored on the internal drive, kind of like the MBR of a PC. In addition, the iPod had a mode where it would act as a regular USB storage device (or firewire). That firmware was stored in a flash. Even with a blank drive the USB storage mode was always accessible. This made this whole hack somewhat safe.
With custom code put at the correct offset with some magic numbers in the right places the iPod would start executing code from the first sectors of its drive. This was just a dd if=mycode.bin of=/dev/sdb, so no exploit or anything special was needed. A few people on the #ipodlinux channel helped me with C and creating position-independent binaries without any external libraries. I had some experience writing a toy OS in assembler on x86 which came in handy.
The piezo was controlled by writing to some memory addresses. Someone else already figured that out. I toyed around with various values until I had two distinct noises, one for 0 and the other for 1. Then I write code for loop over a memory region one bit at a time while the piezo played either of those noises. I had audacity (an audio recorder) open on my computer and just started recording using a cheap dynamic microphone. The decoding software was embarrassingly stupid but I had no clue about signal analysis in 2005. It would have been possible to use a modulation method to speed up the process quite a lot. I opted for a compression algorithm instead.
I think I tried different memory regions until I found one that started with data that looked like ARM opcodes. When I found that region the final dump took a few hours over night.
After sending the extracted binary over to the other devs we had a kernel running not much later.
This project taught me a lot: ARM assembler, C, SDL (for visualization), sox (audio processing tools) and patching/porting the linux kernel for new hardware. It also got me job offers from a few big companies but I did not take any of them as I had different plans already. I kept on hacking and contributing to various open-source projects over the years, spent way too much time on hyper-optimizing crypto mining algorithms, and eventually got back to hacking more meaningful code again. Basically, my career after this hack has been almost exclusively open-source projects.
Till today, I use the "unhackable" iPod Nano 7g. I collected a ton of information what would be needed to hack it, but unfortunately, I did not have the time.
In case you are interested in getting functional / non-functional devices to experiment, reach out on https://pilabor.com (I'm from Germany).
My plan was to desolder the 16GB flash chip (it's LGA60) and try to reprogram it with a device like this:
Old iPhones (I think the 5s has the same LGA60 Nand) can be reprogrammed with a JC Pro 1000S Programmer, but they don't have a setting for iPods AFAIK. So maybe with a lot of effort it would be possible to use it to reprogram a Nand Chip having an Apple Serial No.
lemonjesus (https://github.com/lemonjesus/iPodBluetooth) created a bootloader Hack for the iPod Nano 3g enabling him to use a bluetooth device. He also made a youtube video about it.
But I never got into it too far. I just found out that milling out the backplate of an iPod Nano 7g can fit an iPod Mini 600mah battery and make it "replaceable" without opening the device again - so as long as the Nand does not die, I'll keep using my iPods :-)
The next device I'm planning to buy is the HiBy M300. It's way bigger but runs Android 13 and is a real DAP.
> Till today, I use the "unhackable" iPod Nano 7g.
CUB3D recently got code execution on n6g/n7g via a freetype 1day (comex's star vuln/exploit, after using another bug which allowed disabling resource partition checks).
This is great news, thank you for pointing this out. I'll transfer that knowledge to the rockbox community, if they don't know. Maybe someone is willing / has time to do the work.
How did you support yourself financially with a career of mostly open source? Fascinating story. Very good anecdote of just doing it and learning. Thanks!
I remember installing iPod Linux on my first gen iPod nano. One of my biggest regrets is trading it in for a brand new iPod nano when they had the battery replacement program. The memories were worth much more than a free iPod.
I remember playing Doom on Linux on my 3rd gen iPod...
It got rather warm, and just seemed crazy silly at the time. For context, smart phones weren't quite a thing yet and capacitative touch screens were an emerging technology.
I still have a iPod. I replaced the battery and the hard drive for a SD card and its still a great way to listen to music over a nice pair of headphones. I plan to make a few more so I have enough for the rest of my life.
Phone + Bluetooth is more convenient but something about the experience of the iPod, perhaps the lack of distraction makes it more visceral.
Modern digital audio players (DAPs) exist. Basically an iPod with an upgraded DAC and amp, and optionally WiFi and Bluetooth for direct streaming from Tidal or local media server or from your phone. I also use mine as a Bluetooth receiver for my TV audio when watching late at night.
Nice acoustic hack. It's also amazing what you can do with a simple
FM/AM radio to perform short range tempest sniffs. No doubt some
amazingly clever tricks can be done with SDR. If it runs code, it
leaks EMR.
Another incredible category of attack is power analysis / power starvation attacks.
IIRC, a research group succeeded to extract the private key by power starving a server and analysis its power draw at the same time. OpenSSL had to implement some randomization to thwart it.
If you look at modern crypto libs you’ll see most operations require an rng function. This isn’t because random data is added to the operation, it is to make sure the operations on the data are obscured during lengthy operations that can be replayed for differential power analysis. Like ECDH secret mixing will add random numbers to the points and the normalize them out after the point multiply. It’s pretty damn clever.
I think step 1 of getting something like secret keys out of Xbox or
whatever would be learning to 3D print micrometer scale antenna arrays
and use those fancy broadband SDR chips someone was talking about the
other day with some image source and phased array tricks used in radar
to precisely sniff out whats going on and where.
Indeed, constant execution time, block padding, resource use
obfuscation... it all helps, but in the end different bit patterns
moving around produce different EM waves and advanced DSP methods can
remove noise and find those patterns.
What do they say? Possession is nine tenths of the law.
If I have it in one hand and some time on the other, eventually I'll
find out how it works. A security posture based on any other
assumption is naive. Which is why appliance computing and DRM using
"trusted consumer modules" is a fools errand.
Is it really? The Xbox One has been around for years and yet online cheating is non-existent. The only way that's possible is if no one has extracted the enclave private keys to sign modified data. And game hackers are notorious for going the extra mile (development Xboxes have been physically stolen from Microsoft headquarters in Redmond) so it must be very difficult.
The keys are in the Xbox, where else would they be? Each console has a unique endorsement key burned in at silicon level.
This is also how undefeatable hardware bans can be issued, blocklisting the key.
DRM works in practice. Most users end up not side-loading things on their phones or playing homebrew on their consoles, even though it's theoretically possible.
Because piracy is not a problem of price, but problem of convenience.
If I can buy an album DRM-Free for a good price, I'd buy it. Same for books, games, or anything digital.
If I can make personal copies by stripping the DRM without quality reduction, that works too.
People producing these things pour blood sweat and tears into these things, and they have bills to pay. They deserve to get compensated for what they do.
I started with music, let me end with one example. An amateur symphony orchestra needs to give 14 full weekends for a 2 hour concert. That thing is hard.
It is very much a problem of convenience. I paid for the Sims 4. It required me to use the EA launcher, which wasn't only slow, it was buggy and crashed constantly. So I pirated the game and played that way instead, despite having access to a legal copy. No launchers, no account sign in, no ads. Plenty of other people happily cut out the middle man and go straight to piracy.
Am I understanding right that he essentially printed part of memory to the piezoelectric circuit in binary? How did he get his code to run to do so, or was there some other technique in play? Really interesting stuff.
I did this. You could just dd a binary to the iPods drive (with some magic numbers) and the iPod would execute it on boot. Someone figured this out for older iPods already. The USB storage mode was still available so this was quite safe.
It sounds like he already had linux running on the device, it just couldn't control/access everything, which was the ultimate goal of this project. So once you have linux running, even without being able to control everything, you have code execution. It seems like there'd be other ways to get the bootloader out, but I'm not familiar with the project, presumably he did the easiest thing he could do - or most interesting.
I think he must already have code execution, and just used this technique to dump bits of RAM.
Perhaps it it was a shellcode exploit, he maybe only had a few hundred bytes of his own code to play with, and maybe no knowledge of memory addresses needed to access 'easier' peripherals like serial UART's.
This is a total guess, but it reads to me like he physically rewired the internals of the device to connect the clicker to the CPU bus, so he could hear instructions as they were processed. Wish there were more details, though, really interesting attack!
Yeah, I don't pick up calls unless they're from someone in my contacts. Too much spam, scam, and scum.
Also: push-to-Siri is maybe the least convenient, but also least annoying and most consistent trigger. Apple Watch comes with "raise-to-Siri" on by default; picture chatting with someone while chilling on the couch, moving your wrist the wrong way, and Siri randomly interjecting based on something you said, taken completely out-of-context. I tend to disable features like these as soon as they come out.
> Apple Watch comes with "raise-to-Siri" on by default; picture chatting with someone while chilling on the couch, moving your wrist the wrong way, and Siri randomly interjecting based on something you said, taken completely out-of-context.
This is exactly what I’m curious about with these calls, especially after reading the article and the curious transcription of the voicemail — might they be intended to trigger the watch or iPad or another iPhone or something when played aloud? Probably not but I’m curious.
Sure skipped over a lot of details. Like how did they reprogram the iPod code to play the boot rom as Audio? Why not just desolder the flash chip and read it out with a programmer?
EDIT: I missed the fact that there was already a "Linux on iPod" distro to build upon.
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...
Not an expert, but my read of the article was that he had code execution already, but needed to dump the bootloader so he could gain access to peripherals. You could no doubt pull the chip and read it out with a programmer: this has been done for many other devices, i have no trouble believing you could do the same with an iPod. The method he developed is noninvasive, though, simply requiring a soundproof box and some analysis software. Thats what makes it cool, to me.
> Bernard Leach, a UK software engineer who helped set up the so-called iPod Linux project, had already worked out how to control the piezoelectric component within the iPod that produces the click.
Was this a hardware mod? Is there information online about this process?
The iPod 4G was very similar to its predecessors. The software was stored on the internal drive, kind of like the MBR of a PC. In addition, the iPod had a mode where it would act as a regular USB storage device (or firewire). That firmware was stored in a flash. Even with a blank drive the USB storage mode was always accessible. This made this whole hack somewhat safe.
With custom code put at the correct offset with some magic numbers in the right places the iPod would start executing code from the first sectors of its drive. This was just a dd if=mycode.bin of=/dev/sdb, so no exploit or anything special was needed. A few people on the #ipodlinux channel helped me with C and creating position-independent binaries without any external libraries. I had some experience writing a toy OS in assembler on x86 which came in handy.
The piezo was controlled by writing to some memory addresses. Someone else already figured that out. I toyed around with various values until I had two distinct noises, one for 0 and the other for 1. Then I write code for loop over a memory region one bit at a time while the piezo played either of those noises. I had audacity (an audio recorder) open on my computer and just started recording using a cheap dynamic microphone. The decoding software was embarrassingly stupid but I had no clue about signal analysis in 2005. It would have been possible to use a modulation method to speed up the process quite a lot. I opted for a compression algorithm instead.
I think I tried different memory regions until I found one that started with data that looked like ARM opcodes. When I found that region the final dump took a few hours over night.
After sending the extracted binary over to the other devs we had a kernel running not much later.
This project taught me a lot: ARM assembler, C, SDL (for visualization), sox (audio processing tools) and patching/porting the linux kernel for new hardware. It also got me job offers from a few big companies but I did not take any of them as I had different plans already. I kept on hacking and contributing to various open-source projects over the years, spent way too much time on hyper-optimizing crypto mining algorithms, and eventually got back to hacking more meaningful code again. Basically, my career after this hack has been almost exclusively open-source projects.