It has to. The only way that it wouldn’t trip the indicator is if it was built into the operating system itself or somehow had an exploit to get around OS security protections.
The information is fascinating but by and large should no longer be applicable because the OS has been designed to prevent using the microphone without the users knowledge. An app doesn’t have access to the microphone hardware without going through the OS first. Google could modify the OS to do such a thing, but of course, they have to hide this in the proprietary parts of Android, and the generally open nature of the platform give security researchers quite good access to observe such activity. I’d be surprised such activity would go unnoticed. It seems unlikely.
I think this type of approach might have worked on older OS versions but I don’t see how it could work today in general.
Starting with version 12, the Android operating system introduced a limit of 200Hz to help mitigate such attacks, but as you indicate research shows that some reconstruction may be possible in some scenarios. This is an ongoing area and future mitigations continue to be considered.
From Kaspersky:
In 92% of cases, the accelerometer data made it possible to distinguish one voice from another. In 99% of cases, it was possible to correctly determine gender. Actual speech was recognized with an accuracy of 56% — half of the words could not be reconstructed.
The monitoring application would also need to run in the foreground to access the data on a continuous basis.
Overall it does look like an interesting theoretical concern.
What about Google Play Services? A pre-installed Swiss army knife of a system app with proprietary code and apps relying on it as a dependency seems to check the box.
That might be possible. I’m not an expert in the wide ranging permissions that preinstalled system apps can access. It would require Google complicity. We haven’t seen this behavior in various sandbox versions of Google play running on custom ROMs, nor hasn’t been seen in any teardowns, but it cannot be completely ruled out.
I feel like there are better places to hide such malicious code. For example, down in the hardware abstraction layer, or another proprietary demons that aren’t part of AOSP. At the end of the day, you need to have some trust in the company that develops your OS.
Would this trigger the ‘mic in use’ indicator on Android and iPhone platforms?
It has to. The only way that it wouldn’t trip the indicator is if it was built into the operating system itself or somehow had an exploit to get around OS security protections.
The information is fascinating but by and large should no longer be applicable because the OS has been designed to prevent using the microphone without the users knowledge. An app doesn’t have access to the microphone hardware without going through the OS first. Google could modify the OS to do such a thing, but of course, they have to hide this in the proprietary parts of Android, and the generally open nature of the platform give security researchers quite good access to observe such activity. I’d be surprised such activity would go unnoticed. It seems unlikely.
I think this type of approach might have worked on older OS versions but I don’t see how it could work today in general.
Unless…
https://crypto.stanford.edu/gyrophone/
Starting with version 12, the Android operating system introduced a limit of 200Hz to help mitigate such attacks, but as you indicate research shows that some reconstruction may be possible in some scenarios. This is an ongoing area and future mitigations continue to be considered.
From Kaspersky:
The monitoring application would also need to run in the foreground to access the data on a continuous basis.
Overall it does look like an interesting theoretical concern.
Background app can request “disable battery optimization” aka continuous operation. Users will just click okay
What about Google Play Services? A pre-installed Swiss army knife of a system app with proprietary code and apps relying on it as a dependency seems to check the box.
That might be possible. I’m not an expert in the wide ranging permissions that preinstalled system apps can access. It would require Google complicity. We haven’t seen this behavior in various sandbox versions of Google play running on custom ROMs, nor hasn’t been seen in any teardowns, but it cannot be completely ruled out.
I feel like there are better places to hide such malicious code. For example, down in the hardware abstraction layer, or another proprietary demons that aren’t part of AOSP. At the end of the day, you need to have some trust in the company that develops your OS.
If it existed, yes. They probably didn’t realize before making this failed “pitch”, which is why they never developed this.
Don’t think so. Wait until you find out what your smart TV is doing.
Nah it got banned from the network when it started inserting ads into my YouTube feed that I already pay for.
Heh. My TV has never been online, not even once. I’d rather suffer the occasional firmware bug than have it act as a sensor.