Could MacGyver bring down a surveillance drone hunting him using only a speaker? Although seemingly impossible, the ever-resourceful MacGyver could not only take over a drone, but also eavesdrop on your conversations and track your movements – just by cleverly using a speaker. The common vulnerability that MacGyver could exploit turns out to be a small component doing precisely what it was intended to do: measuring orientation and acceleration. Both drones and phones contain gyroscopes and accelerometers, common examples of micro-electro-mechanical systems (or MEMS) that work to keep the drone stable in flight and to automatically adjust your phone’s screen based on how it is held. So what does a speaker have to do with any of this?

It turns out that MEMS devices resonate at a specific acoustic frequency, usually above 20kHz, which is inaudible to humans. By pointing a speaker at a drone and playing the resonance frequency of the MEMS chip in the drone, MacGyver tricks the drone into thinking it is no longer stable by manipulating the output of its gyroscope. The same trick can be used to turn the gyroscope in your phone into a microphone (extracting any speech below the Nyquist sampling frequency of 100Hz), or track the stores you visit and the shows you watch by playing ultrasonic acoustic pulses that are measurable by your phone’s gyroscope. Sound like science fiction? Advertisers like SilverPush, Shopkick, and Lisnr are already doing it.

It’s clearly difficult to anticipate how products might be exploited. Despite our best efforts to secure our products, vulnerabilities may exist and may not be encountered until the product is already in the field. To combat these vulnerabilities, ADI’s Product Security Incident Response Team (PSIRT) has launched a new vulnerability handling process based on industry standards (FIRST, ISO 30111, and ISO/IEC 29147). The PSIRT team will strive to use the new handling process to analyze reported and discovered vulnerabilities to provide timely information, analysis, and guidance on appropriate mitigations when necessary. We are very excited to begin executing this process by working with internal and external finders (individuals who encounter and report a vulnerability) and stakeholders to improve the security of ADI’s products. 

We wanted to create an efficient, repeatable method for handling a variety of hardware and software-based vulnerabilities. Through this process, we aim to handle vulnerability reports related to our software, hardware, cloud, product documentation, and products available through and ADI distributors. The primary steps to the reporting process are:

  1. Identification
  2. Verification
  3. Resolution development
  4. Disclosure
  5. Post-resolution improvements.

Identification. The identification stage begins with a report from an internal or external finder. Finders wishing to report a vulnerability can do so here. Finders can expect a response to their report within three business days unless otherwise stated on the site. We ask for quite a bit of information surrounding the vulnerability, but the information we ask for will help us more easily replicate the vulnerability in the next step of the process.

Verification. Once a finder reports a vulnerability, our PSIRT team will work with the finder and internal stakeholders and engineers to attempt to replicate the vulnerability and understand its impact on the reported product or other products at ADI. We ask that all parties use discretion through this process. When discussing the vulnerability, please consider using secure communication (our PGP key can be found here). Additionally, please keep the vulnerability between yourself and ADI until we are able to work together to mitigate and disclose the vulnerability. In exchange, we will be as responsive and transparent as possible.

Resolution Development & Disclosure. After the vulnerability is verified and the impact of the vulnerability is quantified, PSIRT will work with internal stakeholders to explore the root cause of the issue. The goal of spending time identifying the root cause is to seek an appropriately scoped resolution. Patching a bug may solve our problems now, but if the real problem is somewhere else in the product development lifecycle, we want to address the core issue as well, when possible.

Once the root cause of the vulnerability is found, the product engineering team will work on identifying an appropriate solution. If the vulnerability is actively exploited in the field, a temporary containment measure may be released. In this case, we will work with the internal stakeholders and the finder to coordinate an appropriate disclosure. If no temporary remediation is required, we will focus on identifying a long-term mitigation. Should a mitigation be required, PSIRT will follow ADI’s standard Product Change Notification process when applicable. PSIRT will work with both internal stakeholders and the finder to ensure the disclosure and mitigation are both suitable.

Lessons Learned. Following disclosure, PSIRT will work with internal stakeholders to try and improve our processes. How did we do as a team? How was our communication? Response time? Could this vulnerability have been avoided with some changes to our development life cycles? These are all questions which will feed into our processes and help us continue to improve ADI’s product security.

PSIRT at ADI is dedicated to collaborating with the security community at large to mitigate any vulnerabilities identified in ADI’s products. If you think you have found a vulnerability, please visit for details on our Vulnerability Disclosure Policy, previous advisories, and information on how to contact us.