Emulating an iPod Contact 2G utilizing QEMU

2023-12-25 17:13:43

In a previous blog post, I described how I managed to get an iPod Contact 1G up and working utilizing the QEMU emulator. Whereas I’m very joyful that the emulator runs easily total, its performance is restricted to some inventory apps, not all of that are totally purposeful. Furthermore, I acquired just a few questions on whether or not it could be attainable to run third-party apps. Sadly, the iPod Contact 1G (and iPhoneOS 1.0) don’t include the App Retailer or an SDK; thus, the quantity of third-party apps that may run on this explicit machine and OS is restricted.

Subsequently, I made a decision to shift focus to emulating an iPod Contact 2G, arguably probably the most standard and iconic iPod Contact gadgets. This machine was additionally my first Apple product, and it motivated me to pursue iOS growth. I focused iOS 2.1.1, the bottom model of iOS that this machine can run. This time, I began by emulating the bootrom and dealing in the direction of userland emulation and executing SpringBoard, hoping to re-use many of the emulated {hardware} gadgets from the iPod Contact 1G. On this weblog put up, I’ll describe some challenges I encountered, architectural variations between the iPod Contact 2G and the iPod Contact 1G, and my additional plans for emulation. All supply code and directions on the way to run the emulator will be discovered in this GitHub repository.

For reverse engineering and understanding the parts, I gratefully used this device tree dump, which has been tremendously useful.

iPod Contact 2G Schematic

For reference, I created the schematic beneath to indicate a few of the {hardware} parts this machine makes use of and grouped associated components. Nevertheless, this schematic nonetheless must be accomplished since there are some parts I nonetheless want to begin taking a look at, corresponding to parts associated to video encoding/decoding. Nevertheless, I’ve some QEMU logic for all parts on this diagram, and I consider it highlights how difficult these sorts of embedded gadgets are from an architectural perspective.

The First Steps with SecureROM and LLB

I began by emulating the 240.4 SecureROM bootrom, which I downloaded from here. Much like the iPod Contact 1G, the iPod Contact 2G makes use of the ARMv6 instruction set, so thankfully, I didn’t should make important modifications to the emulated CPU in QEMU. The bootrom places the machine in DFU mode when a specific button mixture is pressed or hundreds the low-level bootloader (LLB) saved on the NOR reminiscence. Right here, issues began to be completely different from the iPod Contact 1G.

The primary distinction is that the iPod Contact 2G has NOR reminiscence accessed by way of the SPI controller. Compared, the iPod Contact 1G used CFI flash, the performance of which was already offered by QEMU. Subsequently, I needed to reverse engineer the communication protocol with the NOR, which was comparatively straightforward as this protocol is reasonably simple. Its implementation will be discovered here.

The second, more difficult distinction is that the iPod Contact 2G makes use of the safer IMG3 file format (as an alternative of IMG2) to retailer binaries on the NOR/NAND. Fortunately, IMG3 has been well-documented, nevertheless it entails fairly a little bit of cryptographic operations, together with RSA signatures and hashes to ensure authenticity and integrity. Since I intention to get an emulator as near the {hardware} as attainable, I wished to keep away from patching the binaries to show off signature verification. Subsequently, I needed to get the PKE engine up and working, which is chargeable for modulo arithmetic when verifying RSA signatures. I computed the ensuing numbers utilizing OpenSSL’s BIGNUM functionality. Regardless that my implementation is a bit hacky, it appears to move the signature verification of all IMG3 photos which might be loaded.

Some IMG3 photos additionally depend on the UID key, a key distinctive to every Apple machine and fused into the applying processor throughout manufacturing. Since I don’t have entry to this key, I generated one myself and used that one when storing IMG3 files on the NOR/NAND. I then outline the identical key within the AES engine.

I re-used many iPod Contact 1G emulator {hardware} parts, together with the timers, clocks, and vector interrupt controllers. It was simple to get previous LLB as its fundamental duty was initializing {hardware} parts and loading iBoot, the principle bootloader.

iBoot and the NAND

For a number of months, I’ve been caught in numerous features of iBoot. The primary problem got here from the LCD, which makes use of a special underlying communication protocol (MIPI-DSIM) than the iPod Contact 1G. The second problem, which was rather more troublesome, was to get the NAND working the place iBoot hundreds the kernel picture from. The NAND within the iPod Contact 2G has two fundamental variations from the iPod Contact 1G. First, the NAND driver makes use of a special communication protocol, known as FMSS within the kernel. Second, there have been some important variations within the VFL/FTL specs, so I needed to spend fairly a while understanding the mapping operate that interprets a logical block quantity to a bodily one.

Within the iPod Contact 1G and iPhoneOS 1.0, I might simply move boot args to the kernel. Nevertheless, Apple has turned off this performance in manufacturing mode for the iPod Contact 2G. Subsequently, I needed to manually write this string to the suitable location in kernel reminiscence. There are most likely higher options than this, however some boot flags had been essential to set to get debug output printed to the terminal.

const char *boot_args = "kextlog=0xfff debug=0x8 cpus=1 rd=disk0s1 serial=1 pmu-debug=0x1 io=0xffff8fff debug-usb=0xffffffff";
cpu_physical_memory_write(0x0ff2a584, boot_args, strlen(boot_args));

I additionally spent fairly some effort getting previous the kernel picture’s signature verification. For some cause, my decryption algorithm doesn’t appropriately decrypt the ultimate block when the size of the info shouldn’t be a a number of of the important thing measurement, inflicting the CRC computation to fail. I’m nonetheless not sure what I’m doing improper right here, however to work round this, I patched the anticipated CRC code with the code I get throughout decryption. This workaround appropriately validates the kernel picture however ought to nonetheless be revised.

Booting the Kernel and SpringBoard

The kernel boots many of the {hardware} parts outlined within the machine tree. I didn’t have too many difficulties getting previous the initialization of the remaining {hardware} parts. IOKit, Apple’s framework for implementing drivers, may be very well-structured, and its debug output makes it straightforward to establish when and the place a driver will get caught.

When the kernel has booted, it launches launchd, which executes completely different system daemons, together with SpringBoard. The configuration of most of those daemons is positioned in /System/Library/LaunchDaemons. The iPod Contact 2G has many alternative daemons, together with ones associated to media, DNS, FairPlay, and iTunes. To simplify issues, I solely enabled the required daemons to get SpringBoard operational and disabled all others in the interim.

I used to be very joyful that the multitouch driver labored out of the field since I spent fairly a while getting it purposeful for the iPod Contact 1G. With that, I now have a fundamental iPod Contact 2G emulator!

Working in the direction of WiFi

After SpringBoard grew to become operational, I wished to know the way troublesome it could be to get the WiFi controller purposeful. The iPod Contact 2G makes use of a Broadcom BCM4325, and one can talk with that machine by way of the SDIO controller. This driver is included within the kernel as a kernel module. I seen that the kernel wouldn’t routinely load the BCM4325 kernel module, and up to now, I’m nonetheless attempting to determine the place and the way precisely this module is loaded. To work round this challenge, I patched the kernel and added some directions to load this kernel module manually. Once more, it’s not splendid, however no less than these drivers are loaded now.

The SDIO normal is well-documented, and it took little time to get that half up and working. The BCM4325 {hardware} is extra difficult, and the iOS kernel uploads a Linux kernel picture to the machine as a part of the boot process. The {hardware} additionally has many registers, and their content material is unclear. Nevertheless, with some hacking, I might get previous the initialization process, as seen within the screenshot beneath. The initialization process typically hangs, most likely due to race situations or different timing points. Nevertheless, full WiFi emulation is way from purposeful as fundamental primitives corresponding to SSID scanning or connecting to a community are nonetheless not applied.

Subsequent Steps

I loved engaged on this subsequent step in emulating legacy Apple gadgets and enhancing my understanding of the {hardware} parts within the iPod Contact 2G. I consider the iPod Contact 2G is extra secure and simpler to work with than the iPod Contact 1G and has fairly some potential since it may natively run third-party purposes. Under, I checklist some follow-up steps that might enhance the usability of the emulator.

Working bash would make debugging processes, executing purposes, and amassing statistics from the machine a lot simpler. I’ve but to look into this.
I’d additionally prefer to make putting in third-party apps on the emulator a lot simpler, which now requires a full rebuild of the NAND reminiscence.
Some compilation points should be resolved for the emulator to run on different platforms, together with Home windows and Linux.
NAND persistence nonetheless must be fastened, e.g., writes to the NAND will not be saved throughout periods.

I’m additionally joyful to announce that I’ll give a discuss this challenge at FOSDEM’24 in Brussels, additionally see here. Hope to see you there!

As all the time, please let me know what you suppose by opening a difficulty on the GitHub repository, or by leaving a remark beneath.

Source Link