This blog post details the process of emulating an iPhone 11 running iOS 14.4.2 using QEMU, specifically highlighting the complexities involved. The author explains the necessity of using a pre-built kernel and device tree, obtained through a jailbreak, and emphasizes that building these components from source is not currently feasible. The post walks through setting up the necessary files, including the kernel, device tree, ramdisk, and a signed IPSW, and configuring QEMU for ARM virtualization. While the emulation achieves a basic boot, the author acknowledges significant limitations, such as lack of GPU acceleration, networking, and a functional touchscreen, ultimately rendering the emulated environment impractical for general use but potentially useful for low-level debugging or research.
Google's Project Zero discovered a zero-click iMessage exploit, dubbed BLASTPASS, used by NSO Group to deliver Pegasus spyware to iPhones. This sophisticated exploit chained two vulnerabilities within the ImageIO framework's processing of maliciously crafted WebP images. The first vulnerability allowed bypassing a memory limit imposed on WebP decoding, enabling a large, controlled allocation. The second vulnerability, a type confusion bug, leveraged this allocation to achieve arbitrary code execution within the privileged Springboard process. Critically, BLASTPASS required no interaction from the victim and left virtually no trace, making detection extremely difficult. Apple patched these vulnerabilities in iOS 16.6.1, acknowledging their exploitation in the wild, and has implemented further mitigations in subsequent updates to prevent similar attacks.
Hacker News commenters discuss the sophistication and impact of the BLASTPASS exploit. Several express concern over Apple's security, particularly their seemingly delayed response and the lack of transparency surrounding the vulnerability. Some debate the ethics of NSO Group and the use of such exploits, questioning the justification for their existence. Others delve into the technical details, praising the Project Zero analysis and discussing the exploit's clever circumvention of Apple's defenses. The complexity of the exploit and its potential for misuse are recurring themes. A few commenters note the irony of Google, a competitor, uncovering and disclosing the Apple vulnerability. There's also speculation about the potential legal and political ramifications of this discovery.
"Notes" is an iOS app designed to help musicians improve their sight-reading skills. Available on the App Store for 10 years, the app presents users with randomly generated musical notation, covering a range of clefs, key signatures, and rhythms. Users can customize the difficulty level, focusing on specific areas for improvement. The app provides instant feedback on accuracy and tracks progress over time, helping musicians develop their ability to quickly and accurately interpret and play music.
HN users discussed the app's longevity and the developer's persistence, praising the 10-year milestone. Some shared their personal sight-reading practice methods, including using apps like Functional Ear Trainer and various websites. A few users suggested potential improvements for the app, such as adding support for other instruments beyond piano and offering more customization options like adjustable clefs. Others questioned the efficacy of pure note-reading practice without rhythmic context. The overall sentiment was positive, acknowledging the app's niche and the developer's commitment.
Apple's imposed limitations hinder the Pebble smartwatch's functionality on iPhones. Features like interactive notifications, sending canned replies, and using the microphone for dictation or voice notes are blocked by Apple's restrictive APIs. While Pebble can display notifications, users can't interact with them directly from the watch, forcing them to pull out their iPhones. This limited integration significantly diminishes the Pebble's usability and convenience for iPhone users, compared to the Apple Watch which enjoys full access to iOS features. The author argues that these restrictions are intentionally imposed by Apple to stifle competition and promote their own smartwatch.
HN commenters largely agree with the author's premise that Apple intentionally crippled Pebble's functionality on iOS. Several users share anecdotes of frustrating limitations, like the inability to reply to messages or use location services effectively. Some point out that Apple's MFi program, while ostensibly about quality control, serves as a gatekeeping mechanism to stifle competition. Others discuss the inherent tension between a closed ecosystem like Apple's and open platforms, noting that Apple prioritizes its own products and services, even if it means a degraded experience for users of third-party devices. A few commenters suggest the limitations are technically unavoidable, but this view is largely dismissed by others who cite examples of better integration on Android. There's also cynicism about Apple's purported security and privacy concerns, with some suggesting these are merely pretexts for anti-competitive behavior.
This webpage does not exist. I cannot provide a summary of a webpage that is not accessible to me. Please provide a valid URL or the text of the article itself.
HN commenters are generally skeptical of the iPhone 16e's value proposition. Several express disappointment that it uses the older A16 Bionic chip rather than the A17, questioning the "powerful" claim in the press release. Some see it as a cynical move by Apple to segment the market and push users towards the more expensive standard iPhone 16. The price point is also a source of contention, with many feeling it's overpriced for the offered specifications, especially compared to competing Android devices. A few commenters, however, appreciate Apple offering a smaller, more affordable option, acknowledging that not everyone needs the latest processor. The lack of a USB-C port is also criticized.
iOS 18 introduces a new feature that automatically reboots devices after a prolonged period of inactivity. Reverse engineering revealed this is managed by the SpringBoard process, which monitors user interaction and triggers a reboot after approximately 72 hours of inactivity. The reboot is signaled by setting a specific flag in a system property and is considered a "soft" reboot, likely to maintain device state where possible. This feature seems primarily targeted at corporate devices enrolled in Mobile Device Management (MDM) systems, as a way to clear temporary states and potentially address performance issues resulting from prolonged uptime without requiring manual intervention. The exact conditions for triggering the reboot, beyond inactivity time, are still being investigated.
Hacker News users discussed the potential reasons behind iOS 18's automatic reboot after extended inactivity, with some speculating it's related to memory management, specifically clearing caches or resetting background processes. Others suggested it could be a security measure to mitigate potential exploits or simply a bug. A few commenters expressed concern about the reboot happening without warning, potentially interrupting ongoing tasks or data syncing. Some highlighted the lack of official documentation on this behavior and the author's reverse engineering efforts to uncover the cause. The discussion also touched on similar behavior observed in other operating systems and the overall complexity of modern OS architectures.
Summary of Comments ( 0 )
https://news.ycombinator.com/item?id=43592409
HN commenters generally praised the technical achievement of emulating iOS 14 on QEMU, calling it "impressive" and "quite a feat." Some discussed the potential for security research and malware analysis, while others speculated about the possibility of running iOS apps on other platforms, though acknowledging Apple's legal stance against this. Several commenters questioned the practicality and performance of the emulation, pointing out the slow speed and limited hardware support. One highlighted the difficulty of getting the GPU to work properly, emphasizing the complexity of fully emulating a modern mobile operating system. The legality of distributing iOS firmware was also a point of discussion.
The Hacker News post titled "Emulating an iPhone in QEMU" (https://news.ycombinator.com/item?id=43592409) has generated a moderate number of comments, discussing various aspects of iOS emulation and the linked blog post.
Several commenters express excitement and interest in the advancements of iOS emulation, noting its potential for security research, app development and testing, and general experimentation. One commenter highlights the potential for analyzing malware in a controlled environment without risking a physical device. Another anticipates the ability to run older iOS versions on newer hardware as a compelling use case. The challenge of accurately emulating specific hardware features, like the GPU, is also acknowledged.
A few commenters discuss the legal implications of such emulation, particularly concerning copyright and digital rights management (DRM). The point is raised that while emulation itself may be legal, distributing copyrighted iOS firmware is not. The difference between emulating the hardware and obtaining the software is emphasized. The potential for this technology to enable piracy is also touched upon, though countered by the argument that existing jailbreaking methods already offer similar capabilities.
Technical details of the emulation process are discussed in some comments. One comment dives into the complexities of emulating the Apple A12 system-on-a-chip (SoC) and the effort required to accurately reproduce its functionality. The role of Just-In-Time (JIT) compilation in achieving reasonable performance is also mentioned. One commenter asks clarifying questions about performance benchmarks and the blog author replies with additional context about the challenges of performance analysis in emulation.
Some comments offer alternative solutions or related projects. One commenter suggests exploring Corellium, a commercial iOS virtualization platform. Another mentions the UTM project as a potential alternative for iOS virtualization on macOS. A few commenters mention the limitations of the current state of iOS emulation, particularly regarding its performance and compatibility.
Finally, a few comments engage directly with the author of the blog post, asking clarifying questions about specific technical aspects of the emulation process or offering suggestions for future development. The author engages actively, providing further insights into the project.