Published on 2025-08-12 08:42 by Kevin Coyle

Update on Sileninja Progress

When I last wrote about Sileninja I was mostly just interested in the concept of a “mic blocking” or “mic jamming” app. I ended up going on several side quests: here, here, here, and here. [Author’s note: In the preceding sentence, I almost wrote “unfortunately went on several side quests…” but I have amended this. I have decided to lean into the side quest as a way of life].

My initial hypothesis is that I can just turn off or mute the microphone. I’m going to go with this as I figure out if there is a sizable enough market for Sileninja.

However, it also occurs to me to over intellectualize this whole thing and spend hours on Arxiv figuring out what the latest and greatest SOTA is.

Here’s some initial findings.

The NYT wrote an article way back in 2018 about home assistants and people’s weariness with always on devices (source) as did Wired (source).

Broadly, it seems like there are two approaches to how to disrupt:

1. Mask the signal of audio. This is basically like shouting down someone when they are trying to give a talk. The shouter is disruptive of the listeners (audience) by shouting over the source (speaker/talker).
2. Occupy the mic. This would involve muting or otherwise shutting down the actual microphone. This is the approach I’m most interested in, as I think it both a.) runs in the background, as a silent process (pun intended) and b.) I’m like 92% certain that apps can’t “see” what other apps are doing, so mobile app A - Sileninja - running this technique wouldn’t be detectable by mobile app B - sneaky snooper app. I’ll discuss these in order, even though I’m taking approach #2. This will allow me to get some research on #1 out there.

Many of the articles have some sort of jamming technique with an external device. This probably makes sense for at least two reasons:

1. Consumers probably assume that the tool that is causing their upset is not the tool that would fix it. That would be like saying that the way to get over how gross kale tastes is to eat more kale.
2. Limitations of what a mobile phone can produce.

A Portable and Stealthy Inaudible Voice Attack Based on Acoustic Metamaterials leverages acoustic “metamaterials” (a portable device) to achieve this jamming.

There was an attempt to make a phyical product that follows this from the University of Chicago. It feels like kind of out of the spirit of what I’m trying to accomplish here - one of the main goals is to keep this as low barrier to entry to users.

Additionally, these wearables are largely hindered by directionality. If blind spots exists, the device’s effectiveness is severely hampered.

The other version of this is an “ultrasonic firewall” from this paper: SoniControl - A Mobile Ultrasonic Firewall. The authors point out that

near-ultrasonic signals exchange information across the auditory channel through the loudspeakers and microphones of mobile devices… This technology, also called data over audio enables effective near field communication capabilities but also opens up a number of security and privacy concerns.

This team’s blog was a treasure trove of info. I somewhat get the sense though that this technology is meant to block NFC types of transmissions, rather than my use case, which is to block incoming signal from apps.

So that brings me to the approach I’ll be taking, which is to try to occupy the mic.

AuDroid: Preventing Attacks on Audio Channels’s authors (Petracca et al.) introduced AuDroid, an Android modification that extends the SELinux security monitor to explicitly track audio channel usage. AuDroid can enforce context-dependent policies on when and how apps use the microphone or speaker. For instance, it can prevent a lower-privilege app from accessing the mic if it could create a covert channel with another process. In their evaluation, AuDroid was able to stop several audio-based attacks (like apps trying to misuse the mic or speaker in tandem) while still permitting normal app functionality. To me, I read this like: this paper shows that it’s possible to impose stricter controls on mic usage without unduly breaking app features.

Another whole thread of thought also figured out that apps can circumvent the single occupancy policy via side channels. Since only one app can use the real microphone, attackers have turned to other sensors that are not so strictly regulated. A landmark example is the Gyrophone attack (Stanford, 2014), which showed that a smartphone’s gyroscope (which requires no permission) can pick up vibrations from sound and thus serve as a crude microphone source.

I’m going to work on coding out the mic occupancy and side channel prevention styles!

Written by Kevin Coyle