Zoom detecta uso do microfone por outros apps sem permissão

Como o Zoom detecta reuniões em outros aplicativos

O recurso My Notes do Zoom pode capturar anotações durante reuniões hospedadas em aplicativos como Google Meet, Microsoft Teams e Slack. Antes de o usuário iniciar o recurso, o Zoom exibe um convite "Take Note" quando considera que uma reunião de terceiros está em andamento - o que levanta a questão de como o aplicativo reconhece o outro programa sem ter begun a tomar notas.

Uma análise estática de Xusheng Li, publicada em seu blog, mostra que o mecanismo varia por plataforma. No macOS, o Zoom monitora os registros de telemetria do sistema; no Windows, ele consulta registros de privacidade de microfone armazenados no registro do sistema operacional.

O detector no macOS

O autor analisou estaticamente a versão arm64 do Zoom Workplace 7.1.5 (84650). A implementação está na classe PrivacyEventMonitor, dentro do viper.framework, com métodos como startMonitoring, handleLogOutput: e parseSystemLogLine:.

O método startMonitoring executa /usr/bin/log stream com um predicate que filtra o subsistema com.apple.controlcenter, categoria sensor-indicators. O Control Center do macOS é responsável pelos indicadores de privacidade laranja e verde de microfone e câmera, e o mesmo subsistema grava no Unified Logging quais aplicativos estão usando esses sensores. Um registro típico tem o formato "[mic] Google Chrome (com.google.Chrome)", já contendo nome de exibição e bundle ID.

O Zoom mantém as entradas marcadas com [mic], extrai os dois campos e compara cada nova lista de atribuições com a anterior. A aparição ou desaparição de um aplicativo vira um evento de início ou parada de uso do microfone - sem qualquer análise de áudio. Na camada de interface, o Zoom mapeia o Chrome para o produto "Google Meet", aplica configurações de notificação e listas de exclusão por aplicativo e, então, pode exibir o convite "Take Note".

O autor ressalva que isso é mais precisamente detecção de uso de microfone do que detecção de reunião: o Chrome pode acessar o microfone por motivos não relacionados ao Google Meet, e são as camadas superiores do Zoom que decidem se o sinal deve gerar um aviso.

O detector no Windows

Na versão Windows x64 7.1.8.46825, o detector está em viper_async_device.dll e lê a chave de registro por usuário HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\microphone. O Zoom abre a chave com KEY_READ, enumera entradas de aplicativos empacotados e a subárvore NonPackaged, usada por aplicativos de desktop clássicos, e consulta o valor de 64 bits LastUsedTimeStop de cada entrada.

Um valor zero indica um intervalo de acesso ainda não encerrado, ou seja, o aplicativo está usando o microfone no momento. O fluxo usa APIs comuns de registro: o autor não encontrou consumidor de ETW, observador de sessão de áudio nem processamento PCM na rotina de atribuição. A análise estática não determina o intervalo de varredura, os sinalizadores de funcionalidade que controlam o recurso nem se os metadados de detecção são incluídos em telemetria.

Permissões e fragilidade

Nenhum dos dois mecanismos exige privilégios elevados ou acesso ao microfone. O autor testou o predicate exato do /usr/bin/log stream como usuário comum, sem sudo, e o macOS aceitou; a leitura não exigiu permissões de Microfone, Gravação de Tela, Gravação de Áudio do Sistema ou Acessibilidade. No Windows, a chave está em HKEY_CURRENT_USER e o Zoom pede apenas KEY_READ, sem elevação nem acesso de microfone.

O autor alerta que nenhum dos mecanismos deve ser tratado como API estável de aplicativos: o Zoom depende de formato de log do macOS não documentado e de detalhes de implementação do registro do Windows que qualquer um dos fabricantes pode alterar. A conclusão é que se trata de um uso engenhoso do controle de privacidade que os dois sistemas já expõem - e um lembrete de que os próprios indicadores de privacidade podem se tornar fonte de informação sobre atividade entre aplicativos.