Augusto Bortoluzzi

Covering your device's camera with tape blocks the lens, but it does nothing to the sensor right beside it. In January 2024, MIT CSAIL researchers published a paper in Science Advances showing how the ambient light sensor on a tablet can be repurposed into a coarse imaging system. On Android, ambient light sensors require zero runtime permissions. Any app can read the raw lux values in the background, with no permission prompt and no green camera dot on your screen. The sensor is just a single photodiode designed to auto-dim the screen. It has no lens, no shutter, and no pixel array. It only outputs a single brightness number over the internal bus. The researchers turned that single number into an imaging tool using dual photography, treating the display screen as an active array of light sources and the photodiode as a single-pixel detector. As the screen displays changing light patterns, that light reflects off your hand hovering above the glass back into the sensor. An algorithm called Plug-and-Play Quantized Compressed Sensing combines an L_p-norm dequantizer with a deep denoiser to solve the inverse problem. By matching the known display output against the tiny fluctuations in reflected light, it reconstructs an image of the hand from the perspective of the display. The research was demonstrated on an unmodified 17.3-inch Samsung Galaxy View2 tablet, recovering 32 by 32 pixel images of hand positions, pointing, pinching, and scrolling. The physical constraints are severe. The attack needs objects in contact with or centimeters from a large display, and small smartphone screens do not provide enough surface area. Reconstructing a single frame with subsampled patterns took 3.3 minutes, while natural video took tens of minutes. The experiment demonstrates that zero-permission passive sensors leak spatial interaction data when paired with an active screen. Operating systems could neutralize this by placing the sensor behind a runtime permission prompt, capping its sampling rate to 1 Hz, and quantizing lux readings into coarse steps. Until mobile platforms restrict the bus, physical tape on the lens leaves the adjacent light diode completely accessible.

When you shut down a modern iPhone, the Power Management Unit (PMU) cuts voltage to the main A-series processor, the OLED display, and the camera array. It leaves a separate Low Power Mode (LPM) rail live on the motherboard. Sitting on that energized rail are three wireless chips: the Bluetooth controller, the NXP NFC controller, and the Apple U1 Ultra-Wideband chip. Apple built this hardware partition to run "Findable After Power Off," Express Transit passes, and Digital Car Keys when your battery dies. Even with iOS completely unloaded from RAM, those three chips stay powered for up to 24 hours on a manual shutdown (and up to 5 hours on automatic battery reserve). Right before iOS powers down, it pre-computes 96 rolling NIST P-224 public keys (one for every 15-minute window over the next 24 hours) and sends them to the Bluetooth chip using Host Controller Interface (HCI) commands. The final HCI command severs communication with the main processor and starts a standalone thread inside the Bluetooth silicon. While the main SoC sits unpowered, the Bluetooth chip wakes up every 2 seconds to broadcast the current P-224 public key over Bluetooth Low Energy. Any passing iPhone or MacBook that hears that broadcast encrypts its own GPS coordinates with your broadcasted public key and relays the packet to Apple servers. In 2022, researchers at the SEEMOO lab at TU Darmstadt audited this low-power hardware chain ("Evil Never Sleeps") and found a major gap between the three wireless chips. While the NFC chip runs encrypted and signed firmware and the U1 Ultra-Wideband chip checks cryptographic signatures at boot, the Broadcom Bluetooth chip has neither encryption nor signature verification on its firmware updates. Broadcom bakes its base Bluetooth firmware into read-only Mask ROM at the factory. To fix bugs and load the standalone Find My feature, iOS writes raw binary patches directly into the chip internal SRAM using a mechanism called PatchRAM (Write_RAM HCI commands). The hardware never checks a cryptographic signature on those RAM patches. If an attacker already has kernel-level code execution on iOS (through spyware or a local jailbreak exploit), they can overwrite the Bluetooth chip PatchRAM in SRAM before the user powers the phone down. When the user drags the power-off slider, iOS halts and wipes main system RAM. Because the PMU keeps the LPM power rail alive, the modified Bluetooth firmware stays in SRAM and keeps executing on reserve battery power. Worse, the TU Darmstadt team showed from iPhone board schematics that the Bluetooth and U1 chips are wired directly to the Secure Element inside the NFC controller via dedicated hardware buses (SE_I2C and R1_WAKE/SYNC) so car keys and transit cards work while the phone is off. Compromised Bluetooth firmware running in LPM can broadcast custom tracking beacons, listen for over-the-air wake commands, or talk directly to the Secure Element over SE_I2C while the main operating system is dead. Apple lets you tap "Temporarily Turn Off Finding" on the shutdown screen and enter your passcode to disable LPM for that power cycle. That toggle works if your phone is clean, because a clean iOS kernel tells the PMU to cut the LPM rail. If your phone is already compromised by kernel spyware, the malware controls the shutdown sequence. It can turn off the screen, play the shutdown animation, ignore your toggle, and tell the PMU to keep the patched Bluetooth chip powered in the background. Once kernel malware can hide inside unverified radio SRAM, a software power-off slider means nothing. Until the battery is physically disconnected from the board or the phone goes inside an RF-shielded Faraday bag, the Bluetooth silicon can stay on the air.