Source-linked AI summary
Your Voice Assistant is Mine: How to Abuse Speakers to Steal Information and Control Your Phone
Wenrui Diao, Xiangyu Liu, Zhe Zhou, Kehuan Zhang
TL;DR
Prior Android sensor attacks generally accessed sensitive input components directly and required corresponding permissions. This paper introduces GVS-Attack, which uses a zero-permission app, the speaker, Android Intents, and Google Voice Search to execute commands; it reports permission bypasses including sensitive-data access and secure-lock dialing, with feasibility demonstrated by a prototype.
Problem
Previous Android sensor attacks mainly accessed cameras, microphones, or GPS directly and therefore required sensor permissions, leaving permission-free output components insufficiently examined as attack surfaces.
Method
GVS-Attack uses VoicEmployer to invoke Google Voice Search through Android Intent and play prepared voice commands through the speaker for recognition and execution.
Results
The attack can forge SMS and email, access privacy information, transmit sensitive data, and remotely control the device without permissions; a Google Search vulnerability also enables arbitrary-number dialing under secure lock.
Takeaways & Limitations
The findings identify the speaker and built-in voice assistants as attack surfaces and show that zero permission does not necessarily mean safety on affected Android devices.
Takeaways & Limitations
Soundless operation is constrained because Android microphone recording is synchronized, preventing VoicEmployer from accessing the microphone concurrently with Google Voice Search at least at the stated SDK API level.
Abstract
from arXiv · showhide
Previous research about sensor based attacks on Android platform focused mainly on accessing or controlling over sensitive device components, such as camera, microphone and GPS. These approaches get data from sensors directly and need corresponding sensor invoking permissions. This paper presents a novel approach (GVS-Attack) to launch permission bypassing attacks from a zero permission Android application (VoicEmployer) through the speaker. The idea of GVS-Attack utilizes an Android system built-in voice assistant module -- Google Voice Search. Through Android Intent mechanism, VoicEmployer triggers Google Voice Search to the foreground, and then plays prepared audio files (like "call number 1234 5678") in the background. Google Voice Search can recognize this voice command and execute corresponding operations. With ingenious designs, our GVS-Attack can forge SMS/Email, access privacy information, transmit sensitive data and achieve remote control without any permission. Also we found a vulnerability of status checking in Google Search app, which can be utilized by GVS-Attack to dial arbitrary numbers even when the phone is securely locked with password. A prototype of VoicEmployer has been implemented to demonstrate the feasibility of GVS-Attack in real world. In theory, nearly all Android devices equipped with Google Services Framework can be affected by GVS-Attack. This study may inspire application developers and researchers rethink that zero permission doesn't mean safety and the speaker can be treated as a new attack surface.
1. INTRODUCTION
The paper asks whether a zero-permission Android app using only permission-free output components can still achieve malicious goals. It presents GVS-Attack, which uses the speaker and Google Voice Search to bypass sensitive permissions and perform actions including dialing, data access, and remote transmission.
- Previous sensor attacks primarily accessed sensitive input components directly, requiring permissions such as CAMERA, RECORD_AUDIO, or ACCESS_FINE_LOCATION.
- A zero-permission VoicEmployer can make phone calls, forge SMS and email, steal personal schedules, obtain location, and transmit data remotely.
- GVS-Attack instead treats the speaker as an attack surface and routes prepared voice commands through Google Voice Search.VoicEmployer invokes Google Voice Search with Android Intent and plays audio containing commands such as “call number 1234 5678”.
- A Google Search status-checking vulnerability lets GVS-Attack dial arbitrary numbers even when the phone is securely locked with a password.
- The authors implemented a VoicEmployer prototype and tested attack-assisting schemes to demonstrate feasibility in real-world conditions.The schemes included context-aware information analysis and sound-volume setting.
2. GOOGLE VOICE SEARCH ON ANDROID
Google Voice Search is a built-in Google Search component that accepts voice commands through Android Intents and selects operating modes based on phone status. A status-checking vulnerability allows third-party apps to trigger voice dialing while the device is securely locked, enabling the attack under stated device and victim assumptions.
- Google Services Framework is pre-installed on nearly all Android brands and includes Google Search, which provides the Google Voice Search component used by the attack.
- Android Intent mechanism lets VoicEmployer invoke Google Voice Search as a normal operation handled by a built-in app module.
- Google Voice Search starts Velvet when the phone is unlocked, Voice Dialer when it is insecurely locked, and normally gives an unlock warning when it is securely locked.
- Google Search fails to strictly verify Bluetooth-headset connectivity, allowing an ACTION_VOICE_COMMAND Intent to trigger Voice Dialer even under secure lock.
- The attack assumes Google Services Framework and an installed VoicEmployer; secure locking still permits Basic Attack dialing, while broader attacks require the victim not to use secure screen locking.
3. ATTACKS
GVS-Attack uses a zero-permission app’s speaker output to drive Google Voice Search, creating attacks that bypass sensitive permissions. Its designs support malicious dialing, data leakage, remote transmission, and voice-based phone control.
- Attack Mechanism: VoicEmployer triggers Google Voice Search and plays prerecorded voice commands through a background audio service.The commands are recognized as if spoken to the assistant and can invoke corresponding operations.
- Attack Mechanism: The attack creates an uncontrolled inter-application channel in which speaker output becomes Google Voice Search’s microphone input.Android cannot distinguish whether voice commands originate from the user or an internal application.
- Basic Attack: Basic Attack dials arbitrary malicious numbers, including when the phone is securely locked, by exploiting Google Search’s voice-dialing behavior.A prerecorded “call” command followed by “OK” can complete the call and potentially incur premium-rate charges.
- Extended Attack: Extended attacks use Google Voice Search to forge Emails and SMS messages and leak calendar schedules, IP addresses, and district-level location.Some commands execute actions directly, while query commands return sensitive information through voice feedback.
- Permission Bypassing: The attack bypasses Android permission checks because the operating system observes only Intent invocation and audio playback, not the malicious operations executed by Google Voice Search.Commands requiring touch interaction are excluded from the listed bypasses.
- Remote Voice Control Attack: GVS-Attack can transmit data through a call channel and let a remote attacker interact with the victim’s phone using spoken commands.The attacker can issue queries and commands remotely, including location-related questions and self-note creation.
4. IMPLEMENTATION AND ANALYSIS
VoicEmployer implements GVS-Attack through coordinated modules that invoke Google Voice Search, analyze context, and calibrate speaker output. Experiments demonstrate successful attacks across tested devices, nearly 100% command success in quiet conditions, antivirus evasion, environment detection, and low-volume transmission.
- Implementation: VoicEmployer uses five modules to schedule attacks, collect context, invoke Google Voice Search, and play prepared voice commands.The implementation includes MainActivity, AlarmReceivor, EnvironmentService, WakedActivity, and VoiceCommandService.
- Implementation: The alarm mechanism triggers attack modules without maintaining constant background services.This workflow is illustrated for Remote Voice Control Attack.
- Attack Experiments: Android 4.1-or-later phones from three tested models successfully launched GVS-Attack.On the Samsung Galaxy S3, Samsung’s S Voice handled the command because it had higher Intent priority, but the attack process remained similar.
- Attack Experiments: Command Success Rate was nearly 100% in quiet tests because commands were simple and synthesized with Google TTS.CSR was used instead of WER because execution outcomes were the relevant measure.
- Attack Experiments: None of five tested antivirus applications detected the VoicEmployer prototype or its attack behavior.The result covered both threat scans and real-time monitoring modules.
- Context-aware Analysis: Context-aware analysis combines light, motion, screen, time, CPU, and RAM signals to identify suitable attack conditions.Tests across three scenes found significant differences for the target scene, supporting practical environment detection.
- Context-aware Analysis: The target scene was a screen-off phone on a horizontal table with the room lamp off, contrasted with active-use and pocket scenarios.The Meizu MX2 experiments used three typical scenes and measured results over 30 seconds.
- Sound Experiments: The MASV procedure increases speaker volume from the minimum until Google Speech-to-Text recognizes a prepared test message.This successive-approximation method adapts to different speaker hardware and locations.
5. DEFENSE
The paper proposes several defenses, including stricter locked-device checks, runtime speaker monitoring, Intent permissions, and speaker recognition. These measures involve practical trade-offs and are described as possible but imperfect schemes.
- Device and Voice Authentication: When securely locked, Google Search should permit voice dialing only with a connected Bluetooth headset; otherwise it should require device unlocking.The authors identify fixing the status-checking vulnerability as the first defense priority.
- Scope Boundary: Noise-induced awakening depends on sleep stages, age, gender, smoking, and individual sensitivity, limiting simple interpretation of sound-level results.These factors are outside the paper’s scope.
- Runtime Monitoring: Runtime speaker checks could stop Google Voice Search when another application accesses the speaker, but may suppress legitimate notification sounds.The paper gives instant-messaging notifications as an example of the user-experience cost.
- Intent Permissions: Custom permissions for invoking built-in apps or services could require user authorization before installation, but may create permission-abuse problems.The defense shifts the trust boundary to installation-time permission decisions.
- Device and Voice Authentication: Speaker recognition could authenticate the command source before Google Voice Search accepts subsequent commands.The paper notes Touchless Control as an existing Motorola implementation of this approach.
6. DISCUSSION
The discussion examines practical constraints and scope boundaries of GVS-Attack, including soundless operation, noisy environments, network protections, and affected devices.
- Soundless Attack: Soundless GVS-Attack is impractical on standard Android because microphone access is synchronized and apps cannot directly install or modify audio drivers.A customized Android version with modified audio drivers is presented as one feasible solution.
- Soundless Attack: High-frequency sound does not provide a soundless channel because Google Voice Search filters out frequencies outside the reasonable human speech range.
- TLS protection and an unclear voice-data compression algorithm make connection hijacking and data-packet tampering difficult.
- Quiet Vs Noisy: Background noise reduces speech-recognition accuracy, although attacks can use low volume in quiet environments or louder commands masked by noise.Context-aware analysis in noisy settings may require the RECORD_AUDIO permission.
- Attack Scope: Most Android devices running Android 4.1 or later may be affected because Google Services Framework is pre-installed on nearly all brands.The discussion also identifies similar risks in other voice assistants and leaves iOS and Windows Phone testing for future research.
7. RELATED WORK
Related work covers sensor side channels, inter-application communication, and Android application analysis, while GVS-Attack exploits a physical sound channel that bypasses these established checks.
- Sensor based Attacks: Prior sensor attacks used microphones, cameras, accelerometers, and other sensors to extract private information, infer input, or fingerprint devices.Examples include recovering credit-card and PIN information, inferring touchscreen input, and identifying devices through audio analysis.
- Inter-Application Communication: Intent-based attacks can leak information, transfer permissions, or trigger actions when malicious apps send Intents to exported components.
- Application Analysis: Android application-analysis research includes static permission analysis, behavioral footprinting, dynamic taint tracking, and emulation-based malware analysis.
- GVS-Attack evades these methods because VoicEmployer neither directly accesses sensitive data nor executes sensitive operations, instead transmitting commands through sound.The paper describes the physical communication channel and sound-based call channel as breaking previous checking and protection mechanisms.
8. CONCLUSION
The paper presents a permission-bypassing attack using Google Voice Search and the speaker, demonstrates its feasibility, and argues that zero permission does not ensure safety.
- GVS-Attack uses Google Voice Search and the speaker to let a zero-permission app pursue targets ranging from privacy theft to remote voice control.
- A Google Search vulnerability can let the attack dial arbitrary malicious numbers even when the phone is securely locked.
- Experiments with a prototype demonstrate the feasibility of the attack schemes in real-world conditions.
- The study identifies the speaker as a new attack surface and challenges the assumption that zero permission means safety.
A. PERMISSIONS STATISTICS
This section begins listing the system-defined permissions declared or possessed by the Google Search app under Android API Level 19.
- Under Android API Level 19, Google Search app version 3.4.16.1149292.arm declares or possesses system-defined permissions.
- ACCESS_COARSE_LOCATION is listed among the Google Search app’s system-defined permissions.
11. INTERNET
The section lists Android permissions associated with external storage, browser history, boot completion, and external-storage writing.
- READ_EXTERNAL_STORAGE is listed as permission 17.
- READ_HISTORY_BOOKMARKS is listed as permission 18.
- RECEIVE_BOOT_COMPLETED is listed as permission 22.
- WRITE_EXTERNAL_STORAGE is listed as permission 33.