IISEEYOU: DISABLING THE MACBOOK WEBCAM INDICATOR LED
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
iıSeeYou: Disabling the MacBook
Webcam Indicator LED
Matthew Brocker Stephen Checkoway
Johns Hopkins University Johns Hopkins University
Abstract—The ubiquitous webcam indicator LED is an im-
portant privacy feature which provides a visual cue that the
camera is turned on. We describe how to disable the LED on
a class of Apple internal iSight webcams used in some versions (a) Image sensor (front)
of MacBook laptops and iMac desktops. This enables video to
be captured without any visual indication to the user and can
be accomplished entirely in user space by an unprivileged (non-
root) application.
The same technique that allows us to disable the LED, namely (b) Image sensor (back)
reprogramming the firmware that runs on the iSight, enables
a virtual machine escape whereby malware running inside a
virtual machine reprograms the camera to act as a USB Human
Interface Device (HID) keyboard which executes code in the host
operating system. (c) Main board (front)
We build two proofs-of-concept: (1) an OS X application,
iSeeYou, which demonstrates capturing video with the LED
disabled; and (2) a virtual machine escape that launches
Terminal.app and runs shell commands. To defend against
these and related threats, we build an OS X kernel extension,
(d) Main board (back)
iSightDefender, which prohibits the modification of the iSight’s
firmware from user space. Fig. 1: The iSight from a 2008 MacBook we studied.
I. I NTRODUCTION
At the beginning of the 2008 school year, the Lower Merion the technology to indicate that the sensor is currently in use.
School District provided a MacBook laptop to each enrolled Such mechanisms include camera-use indicator LEDs, shutter
student. These laptops came pre-loaded with the LANrev sounds on cell phone cameras, and GPS-use indicator icons
remote administration tool (RAT) which allowed school district on mobile devices and laptops.
officials to, among other things, capture images from the In the past few years, the ever-expanding set of sensors
MacBooks’ built-in iSight webcam. During the following 18 present in commodity laptops and smart phones has prompted
months, officials captured more than 30 thousand images from the security and privacy community to begin researching ways
these webcams [5, 6]. The first indication that images were to detect and limit the undesired use of sensors [20, 22, 24, 25,
being captured was every time the software took a picture, the 29]. At the same time, researchers have demonstrated attacks
green indicator LED would briefly illuminate [5, 6, 40]. Some exploiting the presence of sensors such as a clickjacking
teachers were so concerned by this they they covered the lens attacks against Adobe Flash to gain access to the camera and
of the webcams on their own laptops [6]. Here, the indicator microphone [23] from a malicious web page and exfiltrating
LED worked exactly as it was supposed to and alerted the audio from microphones in modern automobiles [11]. (See
users that they were being photographed. Section II for more examples.)
The possibility that a webcam could be capturing pictures Our results in this paper demonstrate that, at least in some
without the LED illuminating has led to suggestions that cases, people have been correct to worry about malware
owners should tape over the webcam [41] as well as products covertly capturing images and video. We show a vulnerability
designed to cover the camera such as stickers [10] and the in the iSight webcam that affects a particular range of Apple
amusingly named iPatch [53]. computers — including the MacBooks given to the students
This incident illustrates the dangers of passive sensors like in the Lower Merion School District — that can be exploited
cameras and microphones. Unlike active input devices like to turn on the camera and capture images and video without
keyboards and mice that require user actions to provide input, the indicator illuminating.
a passive sensor requires no action on the part of the user to At a high level, our investigation of the iSight revealed
capture input. Indeed, a user is typically unaware that input is that it is designed around a microprocessor and a separate
being captured at all unless specific mechanisms are built into image sensor with an indicator LED sitting between them such
that whenever the image sensor is transmitting images to the Section VI likely holds for other USB devices that use the
microcontroller, a hardware interlock illuminates the LED. We Cypress EZ-USB chip used in the iSight, but we have not yet
show how to reprogram the microcontroller with arbitrary, new tested other devices.
firmware. This in turn enables us to reconfigure the image
sensor, allowing us to bypass the hardware interlock and II. R ELATED WORK
disable the LED. We also show a new method of performing General purpose computers contain a variety of processors
a virtual machine escape based on our ability to reprogram designed for performing specialized tasks other than general-
the microcontroller. purpose computation. Examples include graphics processing
Specifically, our technical contributions in this paper are units (GPUs) which produce video output; processors in
five-fold: network interface controllers (NICs) which perform network
1) We describe the architecture of the Apple internal iSight packet processing; microcontrollers in perhipherals such as
webcam found in previous generation Apple products keyboards, mice, and webcams; microcontrollers in laptop
including the iMac G5 and early Intel-based iMacs, batteries; and, in some systems, baseboard management
MacBooks, and MacBook Pros until roughly 2008 controllers (BMCs) which enables out-of-band system man-
(Section III). agement independent of the host computer’s CPU.
2) We demonstrate how to bypass the hardware interlock that Security researchers have only recently begun examining
the iSight uses to turn on the indicator LED whenever these additional processors and the firmware that runs on them.
the camera is capturing images or video (Section IV) In many cases, the designers of these systems appear not to
and provide a proof-of-concept user space application, have appreciated the security implications of their interfaces
iSeeYou, to do so (Section V). and implementations.
3) We demonstrate how to use the capability developed Perhaps the most well-studied processor apart from the
to bypass the hardware interlock to achieve a virtual CPU is the GPU. Vasiliadis et al. [54] demonstrate using
machine escape (Section VI). the GPU to harden malware against detection by using the
4) We develop an OS X kernel extension, iSightDefender, GPU to implement unpacking and runtime polymorphism.
to defend against these attacks (Section VII). Ladakis et al. [31] use the GPU’s direct memory access (DMA)
5) We sketch the design space for building a secure camera capability to monitor the system’s keyboard buffer to build a
module (Section VIII). keylogger. Beyond GPU malware itself, researchers have used
The ability to bypass the interlock raises serious privacy the GPU to accelerate malware detection [30] and intrusion
concerns and the technical means by which we accomplish detection systems [46].
it raises additional security concerns which we discuss in Duflot and Perez [17] demonstrate exploiting a NIC to
Section IX. achieve arbitrary code execution. In follow up work, Duflot
et al. [18] build a NIC malware detection framework.
Miller [36] demonstrates how to communicate with Apple
Threat model. To mount our main attack where we capture laptop batteries using the System Management Bus, authenti-
video without any external indication to the victim, we assume cate to the battery to “unseal” it, and change both configuration
that an attacker is able to run native code on the victim’s values and firmware. This enables overcharging the battery
computer as an unprivileged user. Further, we assume the code resulting in overheating and, potentially, leading to a fire.
is unencumbered by defenses such as Apple’s App Sandbox [2] Tereshkin and Wojtczuk [52] introduce the concept of a
which is used for applications downloaded from the Mac App “Ring −3” rootkit which runs on Intel’s Active Management
Store but by little else. This assumption is quite mild and Technology (AMT) hardware which has a processor indepen-
would typically be satisfied by malware such as RATs. dent of the host CPU with a separate interface to the NIC and
For the virtual machine escape, we assume the attacker has DMA access to main memory.
code running locally in the virtual machine and with whatever In a very similar vein, Farmer [21] discusses weaknesses
privileges the guest OS requires to communicate with USB and vulnerabilities in the Intelligent Platform Management
devices. We also assume that the virtual machine monitor Interface (IPMI) — the standard interface to the baseboard
has exposed the iSight device to the virtual machine. This management controller (BMC). Like AMT, a BMC has direct
second assumption is quite strong as virtual machine monitors access to the host system but its operation is completely
typically do not expose USB devices to the guest OS unless independent making exploits both extremely powerful and
the user specifically configures it to do so, for example to use difficult to detect. Moore [39] builds on this work to produce
video conferencing software. a penetration tester’s guide for examining IPMI and BMCs.
A webcam is just a particular type of sensor attached
Generality of results. We stress that our main result — to a computing device. Others include microphones, ac-
disabling the iSight LED — only applies to the first generation celerometers, and GPS sensors. Our work joins an emerging
internal iSight webcams and we make no claims of security or line or research on the security and privacy implications of
insecurity of later models, including the most recent (renamed) such sensors. For example, Schlegel et al. [50] show how
FaceTime cameras. The virtual machine escape described in to use a mobile phone’s microphone to extract credit card
numbers and PINs from spoken and tone-based interfaces.
Marquardt et al. [34], Miluzzo et al. [38], Owusu et al. [43] MT9V112
use smartphone accelerometers to extract information about CMOS Digital Image
key presses. Checkoway et al. [11] extract audio and GPS Sensor
coordinates from automobiles. Templeman et al. [51] use
smartphone cameras to covertly take pictures which are then
DOUT[7:0]
STANDBY
#RESET
used to create 3D models of physical spaces. EEPROM
Our virtual machine escape (Section VI) is not the first
SDA
SDA
SCL
SCL
to emulate a USB Human Interface Device (HID) such as
a mouse or keyboard. Wang and Stavrou [56] among other Vcc
things, use a compromised smart phone to act as a USB HID
keyboard and send key presses to the host system. Kennedy
and Kelley [28] use a small microcontroller to interact with
8
the Windows Powershell. Pisani et al. [45] similarly describe
having USB devices pose as HID keyboards to control the
LED driver
computer. Elkins [19] adds a RF receiver for remote controlling
circuit
SDA
FD[7:0]
a fake HID keyboard.
SCL
PD3
PA0
III. I NTERNAL I S IGHT ARCHITECTURE
USB D+
This section describes the architecture of the internal iSight USB D-
webcam in sufficient detail to understand how the multi-step
attack described in Section IV works. Readers who are already CY7C68013A
familiar with the iSight or the Cypress EZ-USB or who are not EZ-USB FX2LP
interested in the low-level details of the device are encouraged
to skip directly to Section IV and use this section and Figure 2,
in particular, as a reference as needed.
The internal iSight consists of a Cypress CY7C68013A Fig. 2: Internal iSight architecture block diagram consisting of
EZ-USB FX2LP, a Micron MT9V112 CMOS digital image a Cypress EZ-USB, a Micron digital image sensor, a 16 byte
sensor, a 16 byte configuration EEPROM, and an indicator configuration EEPROM, and an indicator LED.
LED (see Figure 1). A block diagram is given in Figure 2.
A. Cypress EZ-USB registers [35]. In addition to the I2 C interface, several hardware
The host computer interacts with the iSight entirely through signals influence the operation of sensor.
a USB connection to the Cypress EZ-USB. The EZ-USB is The most important signals from our perspective are the
responsible for handling all USB requests and sending replies active-low #RESET and active-high STANDBY signals. The
including video data. corresponding hardware pins are connected directly to the EZ-
The EZ-USB has an internal Intel 8051-compatible mi- USB’s general purpose I/O (GPIO) pins. As shown in Figure 2,
crocontroller core and 16 kB of on-chip RAM accessible as #RESET is connected to pin 0 of GPIO port A and STANDBY
both code and data “main” memory1 but lacks persistent is connected to pin 3 of GPIO port D. The other connection
storage [13]. In general, the firmware for the 8051 core can between the image sensor and the EZ-USB shown in Figure 2
be located in one of three locations: (1) external memory such DOUT[7:0]→FD[7:0] is an 8 bit unidirectional bus which
as flash or EPROM attached to the EZ-USB address/data bus; transfers pixel data to the EZ-USB’s FIFO interface. Other,
(2) an I2 C EEPROM; or (3) loaded from USB. The iSight less important, control signals are omitted from the diagram.
loads its firmware at boot from the host computer over USB The #RESET signal performs a hardware reset, resetting all
(see Section IV-B). configuration registers to their default value. The STANDBY
signal controls controls output enable and power down
B. Micron digital image sensor functions. That is, when STANDBY is asserted, the image
sensor stops producing data on DOUT[7:0] which enters the
The Micron digital image sensor is a low-power system- high impedance state as well as allowing the image sensor to
on-a-chip (SOC) capable of producing an image in several transition to a low power state.
formats. The image sensor is configured by the I2 C interface
which can read from and write to several hundred configuration C. Configuration EEPROM
The first byte of the 16 byte EEPROM controls whether the
1 The standard 8051 is a Harvard architecture which has separate code and EZ-USB loads its firmware from USB or from the EEPROM
data memory differentiated by hardware signals. In the configuration used by
the iSight, the signals are combined effectively giving a single main memory itself. When set to load firmware from USB, as the iSight does,
address space. the EEPROM contains the USB vendor ID (VID), product
TABLE I: Relation between the PD3 GPIO, the STANDBY Bit 4. Disable pixel data output if set.
signal, and the LED. Bit 3. Chip enable. Normal operation if set, no sensor
readout otherwise.
PD3 STANDBY LED
Bit 2. Software standby if set, otherwise normal operation.
High Asserted Off Bit 1. Restart reading an image frame.
Low Deasserted On Bit 0. Reset the sensor to its default state if set, normal
operation otherwise.
Bits 0, 1, and 5 are of no interest and can be set to 0
ID (PID), device release number, and a configuration byte but the remaining 5 bits enable us to bypass the STANDBY
for the initial device enumeration. Once the EZ-USB has signal while still maintaining normal operation. This includes
enumerated using the VID, PID, and release values, software entering a (software) standby state and disabling output when
on the host computer can load the firmware. The iSight initially appropriate.
enumerates with vendor ID 0x05ac (Apple, Inc.) and product When the iSight is first powered up (or, more precisely,
ID 0x8300 (Built-in iSight (no firmware loaded)). when #RESET becomes deasserted), the RESET register has
D. Indicator LED value 0x0008; that is, normal operation and STANDBY affects
the low-power state and output enable. If RESET is set to
Since the purpose of the indicator LED is to illuminate 0x00c8, then the camera has normal operation but STANDBY
whenever the camera is capturing video, a LED driver circuit is is effectively bypassed. When it becomes desirable for the
connected directly to the STANDBY input of the image sensor camera to enter the standby state, RESET can be set to
(see Figure 2). In this way, whenever PD3 is high — that is, 0x00d4 which disables output and enters the software standby
STANDBY is asserted — the LED is off and whenever PD3 state.
is low — so STANDBY is deasserted and the image sensor is With RESET set to either 0x00c8 or 0x00d4, the
producing output — the LED is on. Since the LED is controlled hardware STANDBY signal is ignored. This enables the use
by the same output that controls STANDBY, there is no danger of the EZ-USB PD3 output to control the LED independent
that firmware on the EZ-USB could deassert STANDBY and of the standby state of the image sensor.
turn the LED off (see Table I). However, as we demonstrate
in Section IV, we can bypass the STANDBY signal such that
B. Programming the EZ-USB
changing PD3 allows us to control the LED without affecting
the operation of the image sensor. When the iSight is first powered, it checks the config-
uration EEPROM and then waits for programming over
IV. D ISABLING THE INDICATOR LED USB (see Section III-C). The AppleUSBVideoSupport I/O Kit
Disabling the indicator LED on the iSight entails two driver matches the vendor ID (VID) and product ID (PID).
requirements. First, as described in Section III, the indicator The driver loads and the AppleUSBCamera::start()
LED is directly connected to the STANDBY pin on the image function downloads the camera’s firmware (stored in the
sensor. In order to disable the LED, we need to keep STANDBY gTheFirmware array) to the EZ-USB using a series of
asserted. Since asserting STANDBY will disable the image vendor-specific USB “Firmware Load” device requests [13,
sensor output, we need to configure the image sensor to ignore Section 3.8]. The camera will then reenumerate and function
STANDBY before we assert this signal. Second, we need a as a webcam.
way to modify the firmware on the EZ-USB to in order to One approach to change the firmware on the camera is to
configure the image sensor appropriately as well as keep modify the AppleUSBVideoSupport driver to contain different
STANDBY asserted whenever we want the LED to stay off. firmware. A second approach would be to provide a new
driver that matches the VID/PID and provides a higher probe
A. Bypassing the STANDBY signal
score [3]. The new driver would run at system start up instead
The Micron image sensor has a 16 bit configuration register, of Apple’s driver and download the new firmware to the
RESET (which is distinct from the #RESET power on reset camera. These approaches have two major drawbacks. The
signal). RESET is addressable from the I2 C interface at address first drawback is that they rely on programming the iSight
0x0D in register page 0 [35]. The most significant 8 bits when it is in its unprogrammed state which only happens
control hardware clocks and how bad frames should be handled when the camera is first powered by the USB bus. The second
which are of no interest to us and can be left as 0. The least drawback is that root access is required in order to modify
significant 8 bits have the following functionality as described the existing driver or load a new driver.
in the image sensor data sheet [35, Table 13]: A third approach overcomes both drawbacks by letting the
Bit 7. Prevent STANDBY from affecting entry to or exit iSight be programmed with the legitimate firmware when it
from the low-power state if set. is first powered. Once the firmware has been loaded onto the
Bit 6. Prevent STANDBY from contributing to output enable camera, it can be reprogrammed at any time using “Firmware
control if set. Load” vendor-specific USB device requests. Furthermore, it
Bit 5. Reset the SOC (but not the sensor) if set. can be reprogrammed from any user space process.
V. P ROOF OF CONCEPT state, the STANDBY signal is asserted to turn off the LED
The discussion in Section IV shows that, in principle, it is which will have momentarily illuminated during the reset
possible to modify the legitimate firmware to disable the LED. sequence. Otherwise, the sensor is left running and the LED
In this section, we describe the proof-of-concept application, is enabled so STANDBY remains deasserted and the LED
iSeeYou we created which reprograms the iSight to add the stays on. Finally, the reset_sensor function jumps into
capability to enable or disable the LED using a new vendor- the middle of the configuration function, just past the #RESET
specific USB device request. and STANDBY manipulating code, in order to perform the rest
of the configuration.
A. Modifying the firmware The enter_standby and exit_standby functions
Although one could reimplement the camera functionality, update the bit of state which records if the image sensor
we opted to create new firmware by appending new binary is running or in standby. Then, based on whether the LED is
code to the legitimate firmware and patching it to call our enabled or not, they deassert (resp. assert) STANDBY as needed
new code. The first step is to extract the legitimate firmware to turn the LED on (resp. off). Finally, these functions use
from the AppleUSBVideoSupport driver.2 I2 C to program the RESET register to enter or exit software
The firmware consists of an 8 byte header followed by a standby. Each location in the legitimate firmware which sets
sequence of triples: a 2 byte size, a 2 byte address, and size- the state of the STANDBY signal is patched to call its new,
bytes of data. This format corresponds exactly to the “C2 corresponding standby function instead.
Load” format of the EEPROM for loading firmware directly The final function, handle_led_control is responsible
from the EEPROM [13, Table 3-6]. Each triple specifies the for handling a new vendor-specific USB device request. The
data that should be written to the EZ-USB’s main memory at a main loop in the legitimate firmware which handles USB
given address. By stripping off the header and the final triple,3 device request “setup” packets is patched to instead call
we can construct the “raw” firmware image. The raw firmware handle_led_control. If the bRequest field of the
can then be analyzed, for example, by using IDA Pro. request does not match the new vendor-specific value, then
The raw firmware is structured similarly to sample code it jumps to the legitimate handler. Otherwise, based on the
provided in the Cypress EZ-USB FX2LP Development Kit [14] wValue field of the request, the LED is enabled or disabled.
including a hardware initialization function and USB events As with the other functions, the LED is then turned on if it
that are serviced by a main loop based on state bits set by has been enabled and the image sensor is running. Otherwise,
interrupt handlers. it is turned off.
To the legitimate firmware, we add two bits of state,
B. Demonstration application: iSeeYou
“is the sensor in software standby or running” and “is
the LED enabled or disabled,” as well as four new iSeeYou is a simple, native OS X application; see Figure 3.
functions, reset_sensor, enter_standby, exit_ When iSeeYou starts, it checks for the presence of a built-in
standby, and handle_led_control. iSight using the appropriate vendor and product IDs. If the
When the LED is enabled, the behavior of the camera is iSight is found, iSeeYou initiates the reprogramming process
indistinguishable from the normal behavior. That is, when the using the modified firmware described above. Once the camera
camera is in its standby state the LED is off and when the has been reprogrammed and has reenumerated, the start/stop
camera is in its running state, the LED is on. button begins/ends capturing and displaying video. The LED
The legitimate firmware contains a function to reset and Enable/LED Disable control sends USB device requests
configure the image sensor. This is called both from the with the new vendor-specific value to enable/disable the
hardware initialization function and the handler for the USB indicator LED while video is being captured. Finally, when
set interface request. It begins by deasserting the STANDBY the user quits iSeeYou, the camera is reprogrammed with the
signal and asserting the #RESET. After a short spin loop, it legitimate firmware.
deasserts #RESET and, depending on the function argument,
VI. V IRTUAL MACHINE ESCAPE
deasserts STANDBY. It then proceeds to configure the image
sensor. We patch the firmware to call reset_sensor instead The reprogramability of the iSight firmware can be exploited
of this configuration function in both locations. The reset_ to effect a virtual machine escape whereby malware running
sensor function reimplements the reset functionality but in a guest operating system is able to escape the confines of
adds a call to the function which writes to the I2 C bus to the virtual machine and influence the host operating system.
program the RESET register to bypass the STANDBY signal One method is to reprogram the iSight from inside the
(see Section IV-A). At this point, if the LED has been disabled virtual machine to act as a USB Human Interface Device (HID)
or the argument indicates that it should enter the standby such as a mouse or keyboard. Once the iSight reenumerates, it
would send mouse movements and clicks or key presses which
2 There are several open source tools to perform this task, e.g., iSight
the host operating system would then interpret as actions from
Firmware Tools [7], several of which include binary patching to fix bugs in the user.
the USB interface descriptors.
3 The final triple stores a single 0x00 byte to address 0xE600 which takes To demonstrate the feasibility of a virtual machine escape
the Intel 8051 core out of reset so that it can begin executing instructions. from a VirtualBox virtual machine, we implemented a USB
Fig. 3: iSeeYou running on a white MacBook “Core 2 Duo” capturing video from the internal iSight with the LED (the black
dot to the right of the square camera at the top, center of the display bezel) unilluminated.
HID keyboard which, once loaded, performs the following Apple USB keyboard, the assistant does not appear and there
actions in order: is no visual indication that the operating system believes a
1) send a “host key” press; new keyboard has connected.
2) send command-space to open Spotlight; The shell command entered into the Terminal is uncon-
3) send the key presses for “Terminal.app” one at a time; strained and could, for example, use curl to download arbitrary,
4) wait a few seconds, send a return key press, and wait a new code and run it.
few more seconds for the Terminal to open; After the iSight has finished typing commands, it reenumer-
5) send the key presses for a shell command followed by a ates as an unprogrammed iSight which causes the AppleUSB-
return key press; VideoSupport driver to reprogram it with the legitimate iSight
6) disconnect from the USB bus and modify its USB device firmware, removing evidence that the iSight was the infection
descriptor to use the product ID 0x8300 — the PID for vector.
the iSight in its unprogrammed state; and Although we use the iSight to escape from the virtual
7) reenumerate. machine, in theory, any EZ-USB device which is accessible
The VirtualBox host key, which defaults to the left command from inside the virtual machine can be reprogrammed to
key on a Mac host, releases keyboard ownership, causing the behave as a HID keyboard.
rest of the key presses to go to the host operating system The one major limitation is that the USB device must be
rather than to the guest operating system [42, Chapter 1]. connected to virtual machine before the attack is possible.
Figure 4 shows an iSight that has been reprogrammed from By default, virtual machine monitors do not provide this
inside a VirtualBox virtual machine sending key presses to connection for most devices and thus malware would need to
Spotlight, instructing it to open Terminal.app. coerce the user into establishing the connection.
When a new keyboard is first plugged into the computer, Even with the device connected to the virtual machine, there
the Keyboard Setup Assistant asks the user to press several is no feedback to the firmware that the attack is proceeding
keys in order to determine the keyboard layout. This behavior as planned. All it can do is send key presses in response the
appears to be controlled by the vendor ID, product ID, and USB polling. If the user is sitting in front of the computer,
device release number. By using the appropriate values for an the key presses sent by the iSight may be apparent and theFig. 4: Virtual machine escape. The iSight has been reprogrammed to act as a USB keyboard from inside a VirtualBox virtual
machine and it is sending key presses to the host operating system. It is in the middle of entering “Terminal.app” into Spotlight.
user can interfere by performing an action such as typing TABLE II: Overview of possible defenses.
or clicking the mouse. One way to partially compensate is
Defense Deployable User Root
to decrease the USB polling interval by changing the USB
endpoint descriptors in the firmware allowing the iSight to Change hardware No Yes Yes
send key presses more quickly. Change firmware Yes No No
Each operating system has its own policy which governs a App Sandbox Yes Some No
process’s ability to send USB device requests. On Linux, this iSightDefender Yes Yes No
is controlled by udev. In Figure 4, we used sudo to bypass
the access controls. Alternatively, the appropriate permissions A “Yes” in the Deployable column indicates that the
could be granted to the user. One of these steps is required defense could be deployed to existing computers. A “Yes”
even though the host operating system, OS X, imposes no in the User (resp. Root) column indicates that the defense
would prevent an unprivileged (resp. root) process from
restrictions on the use of USB device requests. Since each reprogramming the iSight. A “Some” indicates that some
guest operating system controls access to the USB device reprogramming attempts would be prevented but others
once it has been connected to the virtual machine, to perform allowed.
an escape, malware must first acquire sufficient privileges
in the guest operating system to reprogram the camera — a
potentially nontrivial feat. secure hardware designs. Of course, changing the hardware is
not a deployable solution for existing devices.
VII. D EFENSES
If the hardware must remain the same, then if the firmware
There are several approaches one can envision to defend the on the camera could be changed to disallow future reprogram-
iSight against the attacks described in the previous sections. ming, then the camera would be secure against our attacks.
One can change (1) the hardware, (2) the firmware on the EZ- Unfortunately, the “Firmware Load” USB device request used
USB (unfortunately this is not effective, see below), or (3) the to reprogram the 8051 core is handled entirely by the EZ-USB
software on the host system. See Table II for an overview of device itself and cannot be blocked or handled by the 8051
possible defenses and their efficacy. itself [13, Section 3.8]. Thus no matter how one programs
The most comprehensive defense would be to change the the device’s firmware, it can be reprogrammed by an attacker
hardware used in the iSight. See Section VIII for several who can send basic USB messages to the camera.Apple deploys sandboxing technology called the App machine. The latter requires some care as the normal drivers
Sandbox4 [2] which can prevent applications inside the that match against the IOUSBDevice are unloaded and the
sandbox from accessing the iSight. Specifically, the com. virtual machine monitor’s own driver is loaded in their place.
apple.security.device.camera entitlement enables Using iSightDefender raises the bar for attackers by requir-
an application to capture still images and video from cameras, ing the attacker to have root privileges in order to reprogram
including the internal iSight. The com.apple.security. the iSight. In some sense, this is the strongest possible software-
device.usb entitlement enables applications to access USB based defense. Since malware running as root would have
devices. the ability to replace or modify kernel code, any defense
Any App Sandbox–protected application lacking the usb implemented in the kernel can, theoretically, be bypassed.
entitlement would be prohibited from reprogramming the Despite this limitation, we believe it is a step in the right
iSight and thus prohibited from disabling the indicator LED. direction and encourage its use.
Although an application with the usb entitlement but lacking iSightDefender, and its source code, is freely available.7
the camera entitlement would be prohibited from using the
high-level APIs for accessing the camera, such as the QTKit VIII. S ECURE CAMERA DESIGNS
API [4], it could easily reprogram the camera to not appear When designing a secure camera, there are two main consid-
as a USB video class (UVC) device and instead transfer the erations. First, for sensors such as cameras and microphones,
frames of video using a custom protocol. an indicator that the sensor is recording is essential to prevent
The major drawback to using the App Sandbox to protect surreptitious recording. (Although laptop microphones do not,
the camera is that applications need to opt into the protection, in general, have indicators, it is common for stand alone USB
something malware is unlikely to do. Worse, the App Sandbox microphones; see [27] for an example.) For the highest level of
has, at times, been broken allowing applications to escape assurance that the indicator cannot be bypassed, the indicator
from the restrictions [12, 37]. should be controlled completely by hardware.
Perhaps the best way to defend against reprogramming Second, as with any peripheral connected to the computer,
the iSight without changing the hardware is to modify the a vulnerability in the software running on the peripheral or
operating system to prevent particular USB device requests the ability to reprogram the software enables an attacker to
from being sent to the camera. We have built such a defense leverage all of the capabilities of the peripheral. Section II
structured as an OS X kernel extension called iSightDefender. contains numerous examples of this. The virtual machine
When iSight is powered for the first time, it enumerates escape in Section VI is another example where an attacker
with vendor ID 0x05ac and product ID 0x8300 and is leverages the USB connection and the ability of the EZ-USB
programmed with the legitimate firmware via the AppleUSB- to mimic any USB device to the host computer. Apple’s most
VideoSupport kernel extension as described in Sections III-C recent FaceTime cameras in its 2013 MacBook Air model
and IV-B. When it reenumerates with product ID 0x8501 eschews USB 2.0. Instead, the camera is connected to the host
the kernel matches and loads the normal drivers as well as computer over PCIe [33]. Vulnerabilities in the camera would
iSightDefender. potentially enable an attacker to have DMA access to the host
I/O Kit kernel drivers are written in a subset of C++ system. This is a significantly stronger capability than USB
and each USB device is represented by an object of class access.
IOUSBDevice which is responsible for communicating
with the hardware by sending messages to objects in lower A. Secure indicators
layers of the USB stack. When iSightDefender is started, Laptop cameras are typically constructed by pairing a
it overwrites the C++ virtual method table of its “provider” CMOS image sensor-on-a-chip (e.g., the Micron MT9V112
IOUSBDevice to point to the virtual method table of a found in the iSight or the Toshiba TCM8230MB(A)) with
subclass of IOUSBDevice.5 The subclass overrides the four a separate microcontroller that handles communication with
DeviceRequest member functions. The overridden imple- the host computer (e.g., the EZ-USB FX2LP found in the
mentations check if the device request is for the “Firmware older MacBooks or the Vimicro VC0358 [55] found in more
Load” vendor-specific request and, if so, log the attempt in recent MacBook Pros [26]. There are, of course, many possible
the system log and block the request. combinations of image sensors and microcontrollers one could
iSightDefender is able to block all user space reprogram- use.
ming attempts,6 including those mounted from within a virtual Image sensors-on-a-chip tend to have a number of common
features that can be used to build a secure indicator.
4 Formerly codenamed Seatbelt.
5 There seems to be no supported mechanism for interposing on USB device 1) Separate power connection for CMOS sensor itself. For
requests. The authors appreciate the irony of using virtual table hijacking — example, VAAPIX on the MT9V112 powers its pixel
a common hacker technique — for defending against attack. array and PVDD on the TCM8230MB(A) powers its
6 In fact, iSightDefender worked so well that one author spent more than
an hour attempting to diagnose (nonexistent) problems with iSeeYou before
photo diode. A GPIO pin on the microcontroller can
noticing the tell-tale lines in the system log indicating that iSightDefender be connected to both the LED driver circuit and the
had been loaded by a computer restart and it was blocking reprogramming
requests. 7 https://github.com/stevecheckoway/iSightDefenderCMOS sensor power supply circuit. Whenever images apply more generally to any peripheral or embedded system
are to be captured, the microcontroller sets its GPIO pin connected to a host computer.
appropriately, power is supplied to the sensor and the
LED turns on. 1) Store the firmware in nonvolatile storage on the camera
2) #RESET pins. The LED driver circuit can be connected module. Most commercial off-the-self (COTS) microcon-
to the #RESET pin and a GPIO pin on the microcontroller. trollers contain some amount of nonvolatile storage, such
The microcontroller would hold the image sensor in reset as flash memory, to hold firmware.8 By programming the
whenever it was not capturing images. Compared to the firmware at the factory, one avoids the possibility that
power connection for CMOS sensor, holding the entire the legitimate firmware will be replaced by an attacker
sensor-on-a-chip in reset means that before images could on the host system before being downloaded to the
be captured, the sensor would need to be reconfigured. microcontroller.
Reconfiguring typically means sending a few dozen bytes Depending on the specific requirements of the system,
over an I2 C or SPI bus. This introduces a slight delay. the factory programming could be the complete firmware
3) Output clocks and synchronization signals. Image sensors or a secure loader designed to load cryptographically
typically latch outputs on one edge of an output clock signed firmware from the host (see below).
signal and image consumers are expected to read the 2) Use a microcontroller which can block unwanted
data on the other edge of the clock. In addition, there firmware reprogramming attempts. It is essential that
are signals used to indicate which part of the image the trusted code running on the microcontroller is able to
latched data represents. For example, the MT9V112 has block reprogramming attempts for illegitimate firmware.
FRAME_VALID and LINE_VALID signals indicating 3) Firmware updates, if necessary, should be cryptographi-
when it’s outputting a frame or a line within the frame, cally signed and the signature verified before applying the
respectively, whereas the TCM8230MB(A) has VD and update. This requires both nonvolatile storage for the code
HD for vertical and horizontal synchronization. These to verify the signature and a microcontroller which can
pins can also be used to control the LED by adding some block reprogramming attempts. Since microcontrollers
simple hardware that drives the LED if it has seen one are typically resource constrained devices, choosing an
of these signals change in the past few milliseconds. appropriate signature scheme which can be implemented
Depending on the specifics of the image sensor output within the constraints is important. Scheme selection
signal, a retriggerable, monostable multivibrator can be is outside the scope of this paper but we note that
used to drive the LED as long as its input changes recent microcontrollers have started to contain specialized
sufficiently often. The multivibrator’s output pulse width crypto instructions which can reduce code size and
needs to be set appropriately such that it is triggered increase efficiency. For example, Rohde et al. [49] use
frequently enough to continuously drive the LED while specialized AES instructions in some Atmel ATxmega
images are being recorded. microcontrollers to implement the Merkle signature
Some care must be taken when using these output scheme.
signals. The exact meanings of the signals can frequently 4) Require root/administrator privileges to send reprogram-
be changed by configuring the sensor. This is analogous ming requests. Strictly as a matter of defense in depth,
to the situation with the iSight where we changed the software running on the host system should restrict
meaning of the STANDBY signal. reprogramming attempts. Thus, even if the hardware and
firmware defenses prove inadequate, this added layer of
An all-in-one design where the image sensor is integrated
protection can still defend against some attacks.
with the microcontroller which communicates to the host
Adding this sort of restriction typically involves a
computer is likely to have fewer options for a secure design.
device-specific kernel module (our iSightDefender is
A dedicated output pin which could drive an indicator LED
an example). This may be more difficult for plug and
would suffice. However, hardware designers are typically
play devices expected to conform to standard protocols
loathe to dedicate pins to specific functions, instead a variety
and interact with generic drivers such as USB video
of functions tend to be multiplexed over a single pin.
class (UVC) or USB human interface device (HID) class
It is likely that, even in this case, there would be a separate
devices.
power connection for the CMOS sensor. As with the two-
chip design above, the LED driver circuit and a power supply The inability of the EZ-USB to block reprogramming
circuit could be driven by a GPIO. attempts indicates that this widely-used microcontroller is
B. Secure firmware inappropriate for use in any system where security is a
consideration.
Although using one of the secure indicator designs described
above will ensure the LED will turn on when the camera turns
on, it does nothing to protect against reprogramming attacks.
For this, we make four concrete recommendations which, 8 Microcontrollers without nonvolatile storage can be paired with external
taken together, can secure the firmware on the camera. These nonvolatile storage, such as flash or an EEPROM, to the same effect.IX. D ISCUSSION webcams. For example, BioID is software-as-a-service which
Although some webcams, such as the Logitech QuickCam provides biometric identification to online service providers
Pro 9000, come with an explicit “LED control” that can disable using a webcam [8]. Luxand’s FaceSDK is a cross-platform
the LED [57], such controls are not the norm and, in fact, software development kit that uses the webcam to identify the
are a very bad idea from both a security and a privacy stand user [32].
point. Giving the user the ability to disable a privacy feature In principle, this sort of facial recognition is trivially
is tantamount to giving malware the same capability. defeated by providing the expected picture or video to the
A particularly unsavory element of the hacker culture, software performing the authentication. Malware that can
“ratters,” install malware bundled with remote administration capture video of the victim can replay that video to authenticate
tools (RATs) on victims’ computers. There are several popular to the given service. This is not a new attack. The Android
RATs, including Blackshades and DarkComet, which come Face Unlock system was defeated shortly after being released
with a variety of “features” such as keyloggers, the ability by holding a picture of the face in front of the camera [9].
to install additional malware, and the ability to record video Duc and Minh [16] describes weaknesses of several facial
and sound using the webcam. Rats are often installed with recognition authentication systems in the presence of pictures.
the goal of spying on women. By disabling the indicator LED before capturing video, the
RATs and the ratters who use them have recently come victims have no way of knowing that their accounts may be
under public scrutiny after Miss Teen USA Cassidy Wolf’s compromised.
webcam was used by ratter Jared Abrahams to capture her Although the ability to disable the LED can lead to serious
naked images without her knowledge [15]. Abrahams arrest privacy and security problems, there are at least two legitimate
and guilty plea came on the heels of an ars technica exposé use cases. The first is that some people really do not want the
on ratters [1]. LED on while they are recording. We do not find this to be a
A commonly asked question on forums devoted to ratting, compelling use as the benefit does not seem to outweigh the
such as the Hack Forums “Remote Administrator Tools” potential cost; however, others may value this more than we
forum, is how can one disable the webcam’s LED. In one do.
representative thread, started by forum user “Phisher Cat” [44], The second use case is significantly more compelling: laptop
the poster asks recovery. For example, the OS X version of Adeona software
captures pictures using the laptop’s internal iSight to aid in
So as all of you know, newer laptops have a
recovery of a laptop that has been stolen by taking a picture
light when a laptop webcam turns on, and so this
of the thief [47, 48]. The LANrev software used in the Lower
scares the slave.
Merion School District incident discussed in the introduction
Is it theoretically possible for a RAT to disable
had a similar “Theft Track” feature which is how the school
this light?
officials were able to obtain pictures of students. For this use,
disturbingly referring to his victim as “the slave,” as is common one does not want the thief to know he is being observed.
in this subcommunity. The first response by “Jabaar” notes that
“[p]eople have been trying to figure this out for a very long X. R ESPONSIBLE DISCLOSURE
time. The light won’t be able to be disabled as it is built into The authors followed responsible disclosure practices by
the hardware.” Others agree: “Capital Steez” writes that there disclosing the LED disabling vulnerability to Apple product
is “no way to disable it,”9 and “FBITM ” concurs “there [i]s security team on July 16, 2013 and the virtual machine escape
no way to do” it. Still others suggest using social engineering on August 1, 2013. The disclosures included the source code
in an attempt to convince the victim that the LED is normal, for iSeeYou and the virtual machine escape as well as directions
for example, “Orochimaru” writes, “You can’t physically turn for mounting both attacks. Apple employees followed up
it off but you can use social engineering to fool them. Maybe several times but did not inform us of any possible mitigation
send an error or warning msgbox that says ‘Camera is now plans. The iSightDefender code was also provided to Apple
updating, please do not disturb’ or something.” There are many and is now publicly available.10
such threads on Hack Forums alone, all expressing similar
sentiments: disabling LEDs is a capability the ratters really XI. C ONCLUSIONS AND FUTURE WORK
want to have but do not think is possible.
We have shown that being able to reprogram the iSight
Unfortunately, the implications of surreptitiously capturing
from user space is a powerful capability. Coupled with the
video do not end with privacy violations like school officials
hardware design flaw that allows the indicator LED hardware
and ratters spying on people. As part of the general trend of
interlocks to be bypassed, malware is able to covertly capture
growing frustration with passwords as an authentication mecha-
video, either for spying purposes or as part of a broader
nism, some companies are moving to biometric identification;
scheme to break facial recognition authentication. Although
in particular, using facial recognition on video taken with
the iSightDefender defense described in Section VII raises the
9 With what appears to be a complete lack of empathy for his own hapless barrier for malware, including RATs, to take control of the
victims, “Capital Steez” further comments, “If I was using my laptop at night
and that light randomly turned on I would freak the fuck out” [44]. Indeed. 10 https://github.com/stevecheckoway/iSightDefendercamera without being detected by requiring root privileges, [7] E. Bersac. iSight Firmware Tools. Oct. 2009. Online:
the correct way to prevent disabling the LED is a hardware https://launchpad.net/isight-firmware-tools
solution.
In this paper, we have examined only a single generation [8] BioID, Inc. The easy, secure way to log in and manage
of webcams produced by a single manufacturer. In future online identities and accounts. 2013. Last accessed:
work, we plan to expand the scope of our investigation to 2013-08-06. Online: http://mybioid.com/index.php?id=67
include newer Apple webcams (such as their most recent high-
definition FaceTime cameras) as well as webcams installed in [9] M. Brian, “Android 4.0 Face Unlock feature defeated
other popular laptop brands. using a photo,” The Next Web, Nov. 2011. Online:
The virtual machine escape described in Section VI demon- http://thenextweb.com/google/2011/11/11/android-4-0-
strates the danger that reprogrammable peripheral devices face-unlock-feature-defeated-using-a-photo-video/
such as keyboards and mice pose. We plan to undertake a
much broader examination of these devices in an attempt to [10] camJAMR.com. 2012. Last accessed: 2013-08-07.
understand the security implications of connecting one device Online: http://store.camjamr.com/shop-now/camjamr-
to a computer which can, under attacker control, pretend to be webcam-covers.html
a wide range of devices. One particularly promising direction is
to study how drivers react to malformed or malicious responses [11] S. Checkoway, D. McCoy, D. Anderson, B. Kantor,
from devices. In the worst case, a user space program could H. Shacham, S. Savage, K. Koscher, A. Czeskis,
reprogram a peripheral device which in turn exploits a poorly F. Roesner, and T. Kohno, “Comprehensive experimental
written driver to inject code into the kernel. analyses of automotive attack surfaces,” in Proceedings
of USENIX Security 2011, D. Wagner, Ed. USENIX,
R EFERENCES Aug. 2011. Online: http://www.autosec.org/pubs/cars-
usenixsec2011.pdf
[1] N. Anderson, “Meet the men who spy on women
through their webcams,” ars technica, Mar. 2013. [12] CoreLabs, Core Security Technologies. Apple OS X
Online: http://arstechnica.com/tech-policy/2013/03/rat- Sandbox predefined profiles bypass. Nov. 2011. Online:
breeders-meet-the-men-who-spy-on-women-through- http://www.coresecurity.com/content/apple-osx-
their-webcams/ sandbox-bypass
[2] App Sandbox Design Guide, Apple Inc., Mar. 2013. [13] EZ-USB R Technical Reference Manual, Cypress
Online: http://developer.apple.com/library/ Semiconductor Corporation, 2011. Online:
mac/#documentation/Security/Conceptual/ http://www.cypress.com/?docID=27095&dlm=1
AppSandboxDesignGuide/AboutAppSandbox/
AboutAppSandbox.html [14] Cypress Semiconductor Corporation. CY3684 EZ-USB
FX2LP Development Kit. 2013.
[3] I/O Kit Fundamentals: Driver and Device Matching, Online: http://www.cypress.com/?rID=14321
Apple Inc., May 2007. Online: https://developer.
apple.com/library/mac/#documentation/devicedrivers/ [15] A. Dobuzinskis, “California man agrees to plead guilty
conceptual/IOKitFundamentals/Matching/Matching. to extortion of Miss Teen USA,” Reuters, Oct. 2013.
html Online: http://www.reuters.com/article/2013/10/31/us-
usa-missteen-extortion-idUSBRE99U1G520131031
[4] QTKit Framework Reference, Apple Inc., Feb. 2009.
Online: http://developer.apple.com/library/ [16] N. M. Duc and B. Q. Minh, “Your face is NOT your
mac/#documentation/QuickTime/Reference/ password: Face authentication bypassing Lenovo – Asus
QTCocoaObjCKit/_index.html – Toshiba,” Presented at BlackHat Briefings, Jul. 2009.
Online: https://www.blackhat.com/html/bh-usa-09/bh-us-
[5] Ballard Spahr, “Lower Merion School District forensics 09-main.html
analysis: Initial LANrev system findings,” May 2010,
redacted. Online: http://www.scribd.com/doc/30891576/ [17] L. Duflot and Y.-A. Perez, “Can you still trust your
LMSD-Initial-LANrev-System-findings network card?” Presented at CanSecWest 2010, Mar.
2010. Online: http://www.ssi.gouv.fr/IMG/pdf/csw-
[6] ——, “Report of independent investigation: Regarding trustnetworkcard.pdf
remote monitoring of student laptop computers by the
Lower Merion School District,” May 2010. Online: [18] L. Duflot, Y.-A. Perez, and B. Morin, “What if you
http://www.social-engineer.org/resources/100503_ can’t trust your network card?” in Proceedings of RAID
ballard_spahr_report.pdf 2011, R. Sommer, D. Balzarotti, and G. Maier, Eds.Springer, Sep. 2011, pp. 378–397. Online: [28] D. Kennedy and J. Kelley, “PowerShell omfg. . . .”
http://www.ssi.gouv.fr/IMG/pdf/paper.pdf Presented at DefCon 18, Aug. 2010. Online:
http://www.youtube.com/watch?v=eWoAGxh0a_Q
[19] M. Elkins, “Hacking with hardware: Introducing
the universal RF USB keyboard emulation device: [29] J. Kim, Y. Yoon, K. Yi, and J. Shin, “ScanDal:
URFUKED,” Presented at DefCon 18, Aug. 2010. Stack analyzer for detecting privacy leaks in android
Online: http://www.youtube.com/watch?v=EayD3V77dI4 applications,” in Proceedings of MOST 2013, H. Chen
and L. Koved, Eds. IEEE Computer Society, May
[20] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, 2013. Online: http://www.mostconf.org/2012/papers/26.
P. McDaniel, and A. N. Sheth, “TaintDroid: An pdf
information-flow tracking system for realtime privacy
monitoring on smartphones,” in Proceedings of OSDI [30] N. S. Kovach, “Accelerating malware detection via a
2010, R. Arpaci-Dusseau and B. Chen, Eds. USENIX, graphics processing unit,” Master’s thesis, Air Force
Oct. 2010. Online: http://static.usenix.org/events/osdi10/ Institute of Technology, Sep. 2010.
tech/full_papers/Enck.pdf
[31] E. Ladakis, L. Koromilas, G. Vasiliadis, M. Polychron-
[21] D. Farmer, “IPMI: Freight train to hell,” Jan. 2013. akis, and S. Ioannidis, “You can type, but you can’t
Online: http://fish2.com/ipmi/itrain.pdf hide: A stealthy GPU-based keylogger,” in Proceedings
of EuroSec 2013, T. Holz and S. Ioannidis, Eds. ACM,
[22] C. Gibler, J. Crussell, J. Erickson, and H. Chen, “An- Apr. 2013. Online: http://www.cs.columbia.edu/
droidLeaks: Automatically detecting potential privacy ~mikepo/papers/gpukeylogger.eurosec13.pdf
leaks in Android applications on a large scale,” in
Trust and Trustworthy Computing, ser. Lecture Notes [32] Luxland, Inc. Detect and recognize faces with Luxand
in Computer Science, S. Katzenbeisser, E. Weippl, L. J. FaceSDK. 2013. Last accessed: 2013-08-06. Online:
Camp, M. Volkamer, M. Reiter, and X. Zhang, Eds. http://luxand.com/facesdk/index_c.php
Springer Berlin Heidelberg, 2012, vol. 7344, pp. 291–
307. [33] Mactaris. Webcam Settings 2.0 will support FaceTime
HD camera on MacBook Air 2013. Jul. 2013. Online:
[23] J. Grossman. Clickjacking: Web pages can see and hear http://mactaris.blogspot.com/2013/07/webcam-settings-
you. Oct. 2008. Online: http://jeremiahgrossman. 20-will-support.html
blogspot.com/2008/10/clickjacking-web-pages-can-see-
and-hear.html [34] P. Marquardt, A. Verma, H. Carter, and P. Traynor,
“(sp)iPhone: Decoding vibrations from nearby keyboards
[24] P. Hornyack, S. Han, J. Jung, S. Schechter, and using mobile phone accelerometers,” in Proceedings of
D. Wetherall, “ ‘These aren’t the droids you’re looking CCS 2011, G. Danezis and V. Shmatikov, Eds. ACM
for’: Retrofitting Android to protect data from imperious Press, Oct. 2011. Online: http://www.cc.gatech.edu/
applications,” in Proceedings of CCS 2011, G. Danezis ~traynor/papers/traynor-ccs11.pdf
and V. Shmatikov, Eds. ACM Press, Oct. 2011. Online:
https://research.microsoft.com/pubs/149596/AppFence. [35] 1/6-Inch SOC VGA CMOS Digital Image Sensor:
pdf MT9V11212ASTC, Micron Technology, Inc., 2005.
Online: http://download.micron.com/pdf/datasheets/
[25] J. Howell and S. Schechter, “What you see is what they imaging/MT9V112.pdf
get: Protecting users from unwanted use of microphones,
cameras, and other sensors,” in Proceedings of W2SP [36] C. Miller, “Battery firmware hacking: Inside the innards
2010, C. Jackson, Ed. IEEE Computer Society, May of a smart battery,” Presented at Black Hat Briefings,
2010. Online: https://research.microsoft.com/pubs/ Aug. 2011. Online: http://media.blackhat.com/bh-us-11/
131132/devices-camera-ready.pdf Miller/BH_US_11_Miller_Battery_Firmware_Public_
WP.pdf
[26] iFixit. MacBook Pro Retina Display teardown. 2013.
Online: http://www.ifixit.com/Teardown/MacBook+Pro+ [37] ——, “Owning the fanboys: Hacking Mac OS X,”
Retina+Display+Teardown/9493 Presented at Black Hat Japan Briefings, Oct. 2008.
Online: https://www.blackhat.com/presentations/bh-jp-
[27] S. T. Inc. Meteor Mic - USB Studio Microphone. 2013. 08/bh-jp-08-Miller/BlackHat-Japan-08-Miller-Hacking-
Online: http://www.samsontech.com/samson/products/ OSX.pdf
microphones/usb-microphones/meteormic/
[38] E. Miluzzo, A. Varshavsky, S. Balakrishnan, andYou can also read
