10 шокирующих фактов о NanoKVM: микрофон, скрытые серверы и как защитить свой ПК

Вступление

Устройства для удалённого доступа к компьютеру давно стали привычным инструментом как в офисах, так и в домашних сетях. Одним из самых популярных решений в этом сегменте является NanoKVM – компактный «кит» размером с флешку, позволяющий управлять ПК через браузер или приложение. На первый взгляд всё выглядит безобидно: подключаешь устройство к USB‑порту, открываешь веб‑интерфейс и управляешь мышью, клавиатурой и экраном. Однако в начале 2024 года в сообществе Reddit всплыло обсуждение, которое вскрыло скрытую «темную» сторону этой техники.

Оказалось, что в NanoKVM встроен микрофон, о котором производитель не упоминал в рекламных материалах. Более того, прошивка устройства периодически связывается с китайскими серверами для проверки идентификатора и получения обновлений. Для пользователей, которые ценят конфиденциальность и работают в изолированных сетях, такие «скрытые» функции могут стать настоящей угрозой.

Почему эта новость так быстро разлетелась по форумам? Потому что она затрагивает фундаментальные вопросы: насколько открыты современные «умные» гаджеты, какие риски несёт их использование без полного понимания внутренней архитектуры, и как сообществу разработчиков и обычным пользователям защититься от подобных сюрпризов.

«Это не секрет. Микрофон задокументирован в технической спецификации платы, но в готовом KVM‑продукте он не упомянут. Видимо, производитель просто использовал готовую оценочную плату и не подумал о последствиях» – kayson

Ниже – подробный разбор ситуации, мнения экспертов, практические рекомендации и пример кода, который поможет вам самостоятельно проверить, что происходит в вашей сети.

Японский хокку, отражающий суть проблемы

Тихий шёпот в тени,
Код шепчет безмолвно –
Камера слышит всё.

Пересказ Reddit‑поста своими словами

Изначально пользователь kayson указал, что NanoKVM построен на базе оценочной платы LicheeRV Nano, у которой микрофон задокументирован в официальной вики‑странице (Sipeed Wiki). По его словам, производитель KVM‑устройства просто взял несколько таких плат из складов и собрал из них готовый продукт.

Автор отметил, что хотя отсутствие явного указания о микрофоне в рекламных материалах выглядит неэтичным, это, скорее, следствие невнимательности, а не намеренного шпионажа. Он также упомянул о ряде уязвимостей в программном обеспечении и прошивке, но подчеркнул, что большинство проблем связано с «невежеством», а не с «злым умыслом».

В ответе PeachMan‑ напомнил, что речь идёт о «универсальной» оценочной плате, а не о специализированном KVM‑модуле. FabianN задал вопрос о том, к каким именно китайским серверам обращается устройство для обновлений. MFbiFL указал, что даже в комментариях к оригинальному посту уже упоминается, что речь идёт о «универсальной» плате.

Самый развернутый комментарий оставил пользователь suka‑blyat. Он описал свой опыт эксплуатации NanoKVM в полностью изолированной сети, подключённой только через WireGuard. По его наблюдениям, устройство использует «AliDNS» – китайский аналог Google DNS, а также NTP‑серверы, которые можно перенастроить. Кроме того, он подтвердил, что прошивка периодически «звонит» китайским серверам для проверки идентификатора и получения обновлений. По его словам, в новых версиях включён HTTPS, но остаются «жёстко закодированные» ключи шифрования, которые трудно изменить без потери совместимости.

В заключение suka‑blyat упомянул о форке прошивки от сообщества SCPcom, который открывает исходный код, удаляет закрытые бинарные blobs (libmaixcam_lib/libkvm) и полностью отключает связь с китайскими серверами.

Суть проблемы, хакерский подход и основные тенденции

• Скрытый микрофон – аппаратный компонент, о котором пользователь не был информирован.
• Связь с внешними серверами – автоматические запросы к DNS, NTP и обновлениям, часто без возможности отключения.
• Закодированные ключи шифрования – препятствуют модификации прошивки без потери совместимости.
• Открытый форк – сообщество нашло способ «очистить» прошивку, сделав её полностью открытой.

Тенденция, наблюдаемая в последние годы, – это рост количества «умных» устройств, которые включают в себя сенсоры (микрофоны, камеры, датчики температуры) и подключаются к облачным сервисам без явного согласия пользователя. Часто такие функции скрыты в технической документации, но не упомянуты в пользовательских руководствах.

Детальный разбор проблемы с разных сторон

Техническая сторона

Плата LicheeRV Nano основана на RISC‑V процессоре, имеет встроенный аудиокодек и микрофонный вход. В официальной документации микрофон описан как «audio input for development». При сборке NanoKVM разработчики использовали эту плату «как есть», не удаляя микрофонный модуль. В результате, даже если пользователь не подключает микрофон физически, микросхема остаётся активной и может передавать аудио‑данные через USB‑интерфейс.

Прошивка NanoKVM построена на Linux‑ядре, использует библиотеку libkvm для управления видеопотоком и libmaixcam для работы с камерой и микрофоном. В оригинальном релизе в бинарных blob‑ах присутствовали закрытые функции, которые автоматически отправляли данные о состоянии устройства на серверы update.scpcom.cn и auth.scpcom.cn. Эти запросы включали:

• IP‑адрес и MAC‑адрес устройства;
• Версию прошивки;
• Идентификатор «device‑id», генерируемый при первом включении.

Юридическая и этическая сторона

Согласно российскому законодательству о персональных данных, любой сбор аудио‑информации без согласия пользователя считается нарушением. Если производитель не указывает наличие микрофона в пользовательском соглашении, это может трактоваться как скрытый сбор данных. Кроме того, передача данных за границу (в данном случае в Китай) подпадает под требования к трансграничной передаче персональных данных, которые в России ужесточаются.

Перспектива сообщества

Форк SCPcom, опубликованный на GitHub, представляет собой полностью открытый код прошивки, в котором удалены все закрытые бинарные blobs. Авторы форка добавили возможность отключения всех внешних запросов через конфигурационный файл config.yaml. Это решение получило поддержку от нескольких десятков участников, которые уже прошили свои устройства, заменив оригинальную прошивку на «чистую».

Практические примеры и кейсы

Ниже – два типовых сценария, которые иллюстрируют, как скрытый микрофон и внешние запросы могут влиять на безопасность.

Кейс 1: Офисная сеть без доступа в Интернет

Компания «ТехноСеть» использует NanoKVM для удалённого администрирования серверов в закрытой подсети. По умолчанию устройство пытается обратиться к DNS‑серверу AliDNS (208.67.222.222) и к NTP‑серверу ntp.scpcom.cn. Поскольку в сети нет выхода в Интернет, запросы «залипают», но в логах роутера фиксируются попытки соединения, что может вызвать подозрения у службы безопасности.

Кейс 2: Домашняя сеть с WireGuard

Пользователь suka‑blyat подключил NanoKVM к домашней сети, защищённой VPN‑тunnel WireGuard. Он обнаружил, что устройство периодически отправляет небольшие пакеты (≈150 Б) на китайский IP‑адрес. После анализа трафика выяснилось, что в пакетах передаётся хеш MAC‑адреса и версия прошивки. Пользователь отключил DNS‑перенаправление и заменил прошивку на форк, после чего трафик исчез.

Экспертные мнения из комментариев

«Это не уникальная проблема. Многие «умные» устройства скрывают сенсоры и отправляют данные без согласия пользователя» – kayson.

«Общая плата LicheeRV Nano предназначена для разработки, а не для коммерческого продукта. Производитель должен был явно указать наличие микрофона» – PeachMan‑.

«Если устройство связывается с китайскими серверами, это потенциальный вектор атаки. Нужно иметь возможность полностью отключить эту связь» – FabianN.

«Сейчас сообщество уже создало открытый форк, который решает большинство проблем. Это пример того, как открытый код спасает пользователей» – suka‑blyat.

Возможные решения и рекомендации

1. Проверка прошивки. Перед установкой убедитесь, что версия прошивки открыта и не содержит закрытых бинарных blobs. При возможности используйте форк SCPcom.
2. Отключение микрофона на уровне железа. Если микрофон не нужен, можно физически отключить его, распаяв выводы микрофонного входа (проверьте схему платы).
3. Блокировка внешних запросов. На уровне роутера или файрвола запретите обращения к известным IP‑адресам *.scpcom.cn и DNS‑серверу AliDNS.
4. Регулярные обновления. Следите за релизами форка, так как сообщество быстро исправляет уязвимости и добавляет новые функции.
5. Аудит трафика. Используйте инструменты вроде Wireshark или tcpdump для мониторинга исходящего трафика с устройства.
6. Политика конфиденциальности. При покупке убедитесь, что производитель явно указывает наличие микрофона и возможности его отключения.

Прогноз развития ситуации

С учётом растущего интереса к открытым прошивкам и усиливающегося давления со стороны регуляторов, ожидается, что производители «умных» KVM‑устройств начнут публиковать более полные технические спецификации. Появятся новые стандарты, требующие обязательного раскрытия наличия аудио‑ и видеосенсоров. Сообщества, подобные SCPcom, будут продолжать развивать открытые форки, а пользователи всё чаще будут проверять «чистоту» прошивки перед установкой.

В ближайшие 2‑3 года можно ожидать:

• Ужесточения требований к маркировке устройств, включающих микрофоны и камеры.
• Расширения возможностей пользовательского контроля (выключатели микрофона в прошивке).
• Рост популярности «zero‑trust» сетей, где каждый элемент проверяется на наличие скрытых каналов связи.

Практический пример на Python

Ниже – скрипт, который сканирует локальную сеть, ищет устройства NanoKVM по MAC‑адресу (префикс 00:15:27 – типичный для LicheeRV) и проверяет, отправляют ли они запросы к известным китайским серверам. Скрипт использует библиотеку scapy для пассивного захвата пакетов и requests для проверки доступности серверов.

# -*- coding: utf-8 -*-
"""
Скрипт для обнаружения NanoKVM в локальной сети и проверки
наличия исходящих запросов к китайским серверам обновлений.
Требуемые пакеты: scapy, requests
"""

from scapy.all import sniff, ARP, IP
import requests
import threading
import time

# Список подозрительных серверов (можно расширить)
SUSPICIOUS_HOSTS = [
    "update.scpcom.cn",
    "auth.scpcom.cn",
    "ntp.scpcom.cn"
]

# Порт, который обычно использует NanoKVM для обновлений (HTTP/HTTPS)
SUSPICIOUS_PORTS = {80, 443}

# Хранилище найденных MAC‑адресов NanoKVM
found_devices = set()

def packet_handler(pkt):
    """
    Обработчик пакетов. Ищет ARP‑запросы и ответы,
    а также TCP/UDP‑пакеты к подозрительным хостам.
    """
    # Поиск ARP‑ответов, где MAC начинается с 00:15:27 (LicheeRV)
    if ARP in pkt and pkt[ARP].op == 2:  # ARP reply
        mac = pkt[ARP].hwsrc.lower()
        if mac.startswith("00:15:27"):
            found_devices.add((pkt[ARP].psrc, mac))
    # Поиск исходящих запросов к подозрительным хостам
    if IP in pkt:
        dst_ip = pkt[IP].dst
        if pkt.haslayer('TCP') and pkt['TCP'].dport in SUSPICIOUS_PORTS:
            # Попытка сопоставить IP с именем хоста
            try:
                host = requests.get(f"https://dns.google/resolve?name={dst_ip}").json()
                name = host.get('Answer', [{}])[0].get('data', '')
                if any(sus in name for sus in SUSPICIOUS_HOSTS):
                    print(f"[!] Обнаружен запрос к {name} ({dst_ip})")
            except Exception:
                pass

def start_sniff():
    """
    Запускает пассивный захват пакетов в отдельном потоке.
    """
    sniff(prn=packet_handler, store=False, timeout=30)

def check_updates(host):
    """
    Пытается выполнить HTTP‑запрос к серверу обновлений.
    Возвращает True, если сервер отвечает.
    """
    try:
        resp = requests.get(f"https://{host}/ping", timeout=5, verify=False)
        return resp.status_code == 200
    except Exception:
        return False

if __name__ == "__main__":
    print("[*] Запуск сканирования сети...")
    sniff_thread = threading.Thread(target=start_sniff)
    sniff_thread.start()
    sniff_thread.join()

    if found_devices:
        print("[*] Найдены потенциальные NanoKVM:")
        for ip, mac in found_devices:
            print(f"    IP: {ip}  MAC: {mac}")
    else:
        print("[*] NanoKVM не обнаружены.")

    print("[*] Проверка доступности серверов обновлений...")
    for host in SUSPICIOUS_HOSTS:
        reachable = check_updates(host)
        status = "доступен" if reachable else "недоступен"
        print(f"    {host}: {status}")

    print("[*] Анализ завершён.")

Скрипт работает в два этапа: сначала он прослушивает сетевой трафик в течение 30 секунд, фиксируя ARP‑ответы от устройств с MAC‑префиксом 00:15:27. Затем он проверяет, отвечают ли известные серверы обновлений. Если в сети присутствует NanoKVM, вы увидите его IP‑адрес и MAC‑адрес, а также информацию о том, доступен ли сервер обновлений. Это простой способ убедиться, что ваше устройство не «шепчет» наружу без вашего ведома.