Театр безопасности Klipsch: как мы вскрыли подпись прошивки Flexus 2026

Через несколько месяцев после того, как я выпустил open-source интеграцию Klipsch Flexus для Home Assistant, OTA-обновление саундбара её убило. Чтение работало, любая запись возвращала 401 Forbidden. Дальше — многонедельное расследование: Flutter-бинарник, декомпилированный собранным из исходников тулчейном, WireGuard man-in-the-middle, офлайн-перебор, упёршийся в глухую стену, и охота за устройством с Frida по пяти телефонам — чтобы восстановить точную подпись запроса, которую теперь требует прошивка Klipsch 2026. Это полный разбор: что сломалось, в какие стены я упирался, как подпись в итоге пала — и почему «безопасность», которую добавил Klipsch, оказалась театром на устройстве, которое и так раздаёт свои секреты бесплатно. Всё исследование, код и полевые заметки открыты на GitHub.

Место преступления: что реально изменила прошивка 2026

Заявка была в одну строку: «они поменяли обмен». На входе — два захвата PCAPdroid и живое устройство на столе; расследование велось как датированная хроника. Я начал с read-only прощупывания. Первое, что я подтвердил, — самое важное: модель данных не изменилась вообще. В захватах почти всё переехало на TLS:443; в открытом виде на :80 остался только long-poll событий — GET /api/event/pollQueue?queueId={UUID}&timeout=5 — и эти открытые event-кадры прямо показывали, какие настройки меняются (dialogMode, nightMode, audioDecoder, player:volume). Те же пути, те же формы значений, что и раньше. GET /api/getData отдавал 200 и на обычном HTTP:80, и на новом TLS:443. С чтением устройства ничего не сломалось. С записью — другая история:

• Неподписанный POST /api/setData на любую защищённую настройку → 401 Forbidden.
• Старый fallback интеграции GET /api/setData?... → 405 "Strict HTTP required!" — легаси-форма записи запрещена напрочь.
• Эндпоинты событий (/api/event/create, /api/event/subscribe) ушли за TLS и отдают 501 "Not implemented!" на :80; неизвестный pollQueue-id даёт 400, зарегистрированный — 200.
• settings:/webserver/authMode теперь читается как setData; 401 анонсирует WWW-Authenticate: HMAC_SHA256, HMAC_SHA256_AES256 — две схемы по имени, но без соли и без nonce для ответной подписи.
• :443 теперь прикрыт самоподписанным сертификатом — Subject O=Klipsch Group Inc, CN=Klipsch-device, Issuer CN=Klipsch-CA, выдан 2026-05-28, TLS 1.3.

То есть запись делится на три уровня. Громкость и mute по-прежнему пишутся без подписи (теперь только POST). Режим, диалог, ночной, EQ, Dirac, тон, вход, декодер и любой уровень канала требуют подписи. А GET-форма записи просто исчезла. Диагноз: прошивка прикрутила слой аутентификации записи к в остальном неизменному API — данные те же, новый только замок на двери. Полная таблица проб — в PROTOCOL_2026_CHANGES.md.

Крепость с распахнутыми дверями

Ещё до всего этого я провёл полный аудит сетевой безопасности саундбара. Скан nmap -sV -p- — 5189 секунд — нашёл 11 открытых TCP-портов (80, 2019, 5002, 5003, 7000, 8008, 8009, 8443, 10001, 16500, 37205). Главный — 8008: неаутентифицированный Google Cast API. Любой запрос из локалки, без всяких креденшелов. GET /setup/eureka_info → 200 и полная идентичность устройства. get_app_device_id → 200 с X.509-сертификатом устройства и подписанным attestation-блобом. Сертификат выдан O=Klipsch Group Inc, OU=Cast, CN=Flexus Core 300, ключ RSA-2048, действителен около двенадцати лет (до 2036). Тот же ответ eureka_info отдаёт и публичный RSA-ключ устройства в Base64. И ни пароля — нигде, ни для чего.

Дальше — лучше. Cast-прошивка под капотом устарела на два года — сборка от января 2024 — и несёт пять незакрытых CVE: одна Moderate в загрузчике AMLogic U-Boot (CVE-2024-47036) и четыре High в ARM (CVE-2024-6790, CVE-2025-0050, CVE-2025-0427, CVE-2025-0819). SoC — AMLogic с публично задокументированной цепочкой эксплойтов загрузчика: впрыск ошибки в eMMC (CVE-2023-48424) → баг AVB в U-Boot (CVE-2023-48425) → обход whitelist boot-команд (CVE-2023-6181), на выходе — кастомная неподписанная прошивка. Аудит закрылся четырнадцатью находками: три High, пять Medium, три Low и три позитивных.

И вот это устройство в 2026 году решило, что срочно нужно залочить именно запись настройки саундбара. Оно отдаст незнакомцу в вашем Wi-Fi свою идентичность, сертификат и публичный ключ без единого 401 — но чтобы включить ночной режим, теперь нужны AES-256 и HMAC. Запомните это.

Вскрываем приложение: blutter и Dart-снапшот

Раз устройство теперь подписывает запись, логика подписи лежит в официальном приложении — Klipsch Connect Plus (com.klipsch.connectxp v2.3.7, build 2026051321). И это первая стена: оно на Flutter. Логика управления не в Java/DEX-слое, куда дотягивается jadx, а скомпилирована в lib/arm64-v8a/libapp.so как Dart AOT-снапшот — машинный код без таблицы символов. (Соседние libdc.so/libduff.so — это SDK Dirac Live, ложный след, который пришлось исключить, прежде чем я убедился, что они не касаются канала /api/*.) Обычные нативные декомпиляторы тут бесполезны: r2 pdc и r2ghidra не резолвят строковый пул Dart, вывод нечитаем. Dart AOT требует blutter, которому, в свою очередь, нужен Dart SDK, собранный из исходников ровно той версии, с которой вышло приложение: я собрал Dart 3.10.0-232 из исходников, чтобы его запустить. Когда он отработал, восстановленные имена функций выдали всю схему: generateUsernameFromMac, generatePasswordFromMac и класс HmacAuthHelper с generateAuthHeader и setCredentials. Крипто-примитивы под ними — библиотека PointyCastle.

Пароль никогда не был секретом

Деривация имени пользователя, восстановленная из generateUsernameFromMac, — антиклимакс: она безусловно возвращает строку "user", дефолтный аккаунт веб-сервера StreamUnlimited. Деривация пароля пала почти так же быстро, прочитанная дословно из generatePasswordFromMac:

cleaned  = MAC.replaceAll(RegExp("[^A-F0-9]"), "")   // только UPPER hex → 12 символов
password = base64( cleaned + "KlipschSupport!!88" )

// worked example, MAC AA:BB:CC:DD:EE:FF:
//   base64("AABBCCDDEEFFKlipschSupport!!88")
//   = QUFCQkNDRERFRUZGS2xpcHNjaFN1cHBvcnQhITg4

Весь «секрет» — одна захардкоженная 18-символьная строка KlipschSupport!!88, приклеенная к MAC-адресу устройства и закодированная в Base64. Base64 — это кодирование, не шифрование: прогоните через base64 -d, и пароль разворачивается в открытый текст. Ни соли, ни KDF, ни секрета на установку; константа байт в байт одинакова во всех Flexus на свете, меняется только MAC. Приложение провижинит ровно этот пароль на саундбар при онбординге — его собственные логи: «Pushing webserver password to device, username: user» — поэтому устройство и отбивает неподписанную запись сразу после настройки. (Тонкая ловушка: тот UPPER-only regex молча выбрасывает строчные hex, так что MAC, прочитанный как aa:bb:..., даст неверный пароль, если предварительно не привести к верхнему регистру. Моя имплементация приводит.) И MAC тоже не секрет — он вещается в ARP, в mDNS, в BLE-рекламе устройства, и его же отдаёт тот самый неаутентифицированный Cast API на 8008. Это была лёгкая половина. Подпись так тихо не далась.

Подпись, которая не давалась

Декомпиляторы не резолвят строковые пулы Dart AOT, поэтому generateAuthHeader я трассировал вручную по аннотированному ассемблеру blutter, прослеживая каждый стек-слот: [fp-0x168] держит nonce, [fp-0x170] — метку времени в миллисекундах, [fp-0x180].field_f — AES-шифротекст, а [fp-0x150] загружается в x2 прямо перед конструктором Hmac — то, что я сперва принял за ключ, но что оказалось именем пользователя. Я мог проследить вызов SHA-256 по 0x6d8240, интерполяцию канонической строки по 0x6d8be4 и интерполяцию заголовка по 0x6d8cd4 — и по ним закрепить раскладку заголовка. А вот последние байты, решающие всё, — нет: точный порядок канонической строки, чем ключуется HMAC, режим AES — call-site (stream_unlimited_api_service.dart) оставлял правдоподобными и AESMode.sic (CTR), и AESMode.cbc. Имея только бинарный оракул (устройство отвечает 200 или безподсказочным 401) и зашифрованное тело, перебирать эти перестановки статикой было непропорционально дорого. Пора было перестать читать код и начать смотреть, как он исполняется.

17 подписей — и глухая стена

Поймать живую подпись было отдельной борьбой. Обычный HTTP-прокси не видел ничего — Flutter шлёт прямо на IP устройства мимо системного прокси — а PCAPdroid с пользовательским CA не расшифровывал трафик :443. Сработал mitmproxy в режиме WireGuard, с AllowedIPs только на саундбар (чтобы mDNS-discovery остался на реальном Wi-Fi) и --ssl-insecure, чтобы принять сертификат Klipsch-CA. Приложение не пиннит сертификат, поэтому расшифровалось чисто: 17 живых подписанных вызовов setData, снятых полностью. Реальный выглядит так:

Authorization: HMAC_SHA256_AES256 dXNlcg==.UpnlFt5z.1781204748147.gncG+ZgSG5WsjzMtVoWOsRpZNw3c4VAo5AS2NLwXtyQ=
                                  └ b64("user") └ nonce └ ts(мс)  └ HMAC-SHA256 (32 байта, base64)

body: { "path": "settings:/cinema/dialogMode", "role": "value", "value": "" }

И тут стена, которой я не ждал. Имея реальную подпись как точный оракул, я перебрал деривацию офлайн. Для HMAC: около десяти кандидатов ключа против всех порядков полей method, path, role, ts, user, nonce, cipher, как строк и как сырых байт, для обоих MAC устройства. Ноль совпадений. Для AES-тела: семь кандидатов ключа × шесть форм MAC × четыре режима (CBC, CTR, CFB, OFB) × пять позиций IV × три варианта обрезки паддинга, против известного plaintext (postProcessorMode="music"). Ноль читаемых plaintext. Ключ на запрос просто не был наивной функцией от восстановленного пароля — моя лучшая догадка sha256(password) оказалась неверной, и ничего рядом тоже не сработало. Обходного пути не осталось. Нужно было снять ground-truth изнутри работающего приложения через Frida — и тут расследование превратилось в сафари по телефонам.

Сафари по телефонам: матрица тупиков

Frida ground-truth требует устройства, способного одновременно на две вещи: видеть саундбар в локалке и давать инструментировать приложение. Каждое устройство умело одно, но не другое. Лучший способ потерять неделю — выяснять это по одному телефону за раз:

• iPhone — дал чистый WireGuard-MITM-захват, но без джейлбрейка нет Frida.
• Android-эмулятор (Pixel 8, API 35, arm64) — Frida работает безупречно, но его блокируют три вещи разом: нет Bluetooth (приложение читает MAC и находит бар по BLE), multicast mDNS не проходит через NAT эмулятора, а Dart-HTTP едет на собственном BoringSSL внутри libflutter.so с SSL_write/SSL_read, обрезанными до нуля экспортов — так что даже перехват TLS требует byte-pattern-хука. Frida есть, бара нет.
• Samsung Galaxy Z Fold6 — видел бар, но Knox/RKP молча побеждает Frida Interceptor. Через objection я слил split-APK, внедрил gadget и переподписал; gadget грузится, чтение памяти проходит, attach без ошибок — но трамплины никогда не пишутся, поэтому даже хуки на memcpy и clock_gettime (тысячи вызовов в секунду) срабатывают ноль раз. Идеально тихий тупик на залоченном флагмане.
• Redmi 5 Plus (рут) — готов помочь, но застрял на Android 7.1.2 / SDK 25, ниже minSdk 28 приложения; даже после даунгрейда через apktool оказался слишком старым.

Асимметрия сводила с ума: Samsung видел бар, но не Frida (Knox); эмулятор имел Frida, но не бар (NAT); iPhone имел MITM, но не Frida (нет джейлбрейка). Требование выкристаллизовалось как любой не-Samsung физический Android. Стенд, который наконец его сломал, — рутованный OnePlus Nord CE (Android 13 / SDK 33, Magisk): Interceptor там работал, подтверждено self-тестовым хуком на malloc, который реально сработал, и проверкой байтов трамплина, которые реально изменились. Оставалось заставить хуки поймать нужную функцию в нужный момент.

Два озарения, которые всё решили

Сначала хуки молчали, по двум причинам, которые стоит запомнить. Первая: при attach Frida пишет трамплин в память, но CPU продолжает исполнять старые байты горячей Dart-функции прямо из кэша инструкций — патч не вступает в силу. Лекарство — spawn, а не attach: запустить приложение под Frida, чтобы функция была пропатчена до первого исполнения. (Даже вызов хитрый — sleep 600 | frida -D <serial> -f <pkg> -l hook.js, держим stdin живым, чтобы обойти spawn-timeout.) Вторая: вариант APK. Вариант APK, который видел blutter, был с extractNativeLibs=false, так что libapp.so мапился из самого пакета и оффсеты плыли; переустановка сборки с extractNativeLibs=true кладёт библиотеку на диск, и оффсеты совпадают 1:1. (Соблазнительная теория «16-КБ выравнивания страниц» для этого сдвига оказалась полным ложным следом — оба устройства на 4-КБ страницах; реальные причины — неправильный вариант APK плюс attach к простаивающему приложению, которое почти не исполняет Dart.)

Был ещё один подвох: Dart-AOT-функции используют собственную регистровую конвенцию Dart (регистр потока и пула, не C-ABI), поэтому вызвать их напрямую из Frida нельзя — нужно триггерить их естественно. Так что, сидя рядом с баром, я гонял приложение руками: онбординг — чтобы сработала generatePasswordFromMac, переключение режима — чтобы сработала generateAuthHeader. Хуки на generateAuthHeader, Hmac.convert и Encrypter.encrypt наконец напечатали точные ключ, каноническую строку и параметры AES. Выпали два факта, до которых не дотянулась никакая статика: ключ на запрос — это SHA256(base64decode(nonce) + password) — nonce не просто передаётся, он подмешивается в ключ — а шифруемое значение — это base64(iv + AES-256-CBC(...)), с IV, добавленным в начало шифротекста, а не отдельным полем. Воспроизведённая на Python офлайн-сборка совпала с приложением байт в байт, и саундбар ответил HTTP 200 — состояние реально сменилось. Полный рапорт по дням — в полевом отчёте (есть и английская версия).

Алгоритм — и почему это чистый театр

Вот восстановленная схема целиком:

username = "user"                                  # generateUsernameFromMac (константа)
password = base64(MAC_UPPER_HEX + "KlipschSupport!!88")  # generatePasswordFromMac
nonce    = base64(6 случайных байт)                # клиентский, на каждый запрос
ts       = str(int(time.time() * 1000))            # клиентский, мс
key      = sha256(base64decode(nonce) + password)  # ОДИН 32-байтный ключ для AES *и* HMAC
value    = base64(iv + AES_256_CBC(key, iv, PKCS7(compact_json(value))))   # iv в начале
body     = json(indent=4){"path", "role": "value", "value"}   # «красивый» JSON, 4 пробела
canonical= "user" + "." + nonce + "." + ts + "." + url + "." + body   # username здесь сырой…
sig      = base64(HMAC_SHA256(key, canonical))
Authorization: HMAC_SHA256_AES256 base64("user").nonce.ts.sig         # …base64 только в заголовке

Все мелочи, стоившие дней, тут: один 32-байтный ключ делает и шифрование тела AES, и HMAC; подписываемое body печатается «красиво» (отступ 4 пробела, порядок ключей path, role, value), а шифруемое value внутри него — компактный JSON (separators=(",",":")); IV кладётся в начало шифротекста, а не отдельным полем; role — это "value" для настроек и "activate" для действий вроде питания (неверная role даёт характерный HTTP 500 — подпись валидна, глагол не тот). И деталь, стоившая целой неверной гипотезы: nonce, IV и метка времени — все клиентские. Серверного challenge нет — заголовок 401 лишь анонсирует имя схемы. Весь запрос воспроизводим офлайн.

Именно это и делает её театром. Пароль — это base64(публичный MAC + захардкоженная константа); MAC открыт в эфире и, по аудиту выше, отдаётся собственным неаутентифицированным Cast API устройства вместе с сертификатом и RSA-ключом. Константа одинакова во всех установках. Так что любое устройство в сети считает тот же кред одной строкой, и — поскольку серверного nonce нет — подписывает совершенно валидный запрос полностью офлайн. Церемония AES-и-HMAC не добавляет никакой стойкости против такого атакующего. Единственный, кого она реально лочит, — легитимный локальный клиент (Home Assistant, эта интеграция), пока он не переимплементирует схему. Она поднимает цену интеропа, а не цену атаки: галочка ради комплаенса, прикрученная к записи настроек саундбара, на устройстве, которое одновременно сливает свою идентичность, сертификат и ключи всей подсети и крутит двухлетнюю прошивку с незакрытыми CVE уровня High. Это та же слепая зона IoT-безопасности — подкреплённая 6 патентами в информационной безопасности — что я закрываю клиентам по консалтингу. Театр безопасности, в точности.

Как выглядела бы настоящая аутентификация записи

Ничего из этого не сложно сделать правильно — вот что цепляет. Схема, которая реально сопротивлялась бы атакующему в локалке, поменяла бы четыре вещи. Серверный challenge: 401 должен нести серверный nonce, который клиент обязан вмешать в подпись, чтобы захваченный запрос нельзя было переиграть и ничего нельзя было посчитать офлайн заранее — ровно то поле, которое этот дизайн опускает. Настоящий секрет на устройство: провижиненный out-of-band и невыводимый из публичного MAC плюс зашитой константы; одна утёкшая константа не должна отпирать всю линейку. Разделение ключей: выводить ключ шифрования и ключ MAC из одного 32-байтного значения через KDF, а не использовать один ключ и для AES, и для HMAC. Транспортная идентичность, которая что-то значит: цепочка сертификатов, которую клиент может реально пиннить, а не самоподписанный Klipsch-CA, который каждому клиенту велят игнорировать через --ssl-insecure. Ирония в том, что устройство уже несёт RSA-ключи и сертификат — материал для настоящей взаимной аутентификации был на борту всё это время; он просто стережёт не ту дверь.

Инженерия под капотом

Восстановление подписи — лишь половина работы; интеграция ещё обязана быть бережной к хрупкому устройству. Flexus держит однопоточный HTTP-сервер — пошлите два запроса разом, и один зависнет — поэтому каждый вызов сериализуется через asyncio.Lock, с таймаутами под реальное поведение железа: 8 с на чтение, 10 с на запись, 15 с на питание (устройству реально нужно столько, чтобы проснуться). Сбои получают два ретрая с backoff 0.5 с, а частичный опрос деградирует мягко — упавшее чтение настройки откатывается на кэш, а не помечает устройство офлайн.

Тоньше — standby-aware опрос. Наивная интеграция, опрашивающая 20+ параметров каждый цикл, заставляет спящий саундбар выстреливать 40-секундными задержками и моргать сущностями в «недоступно». Вместо этого координатор сначала прощупывает питание; если бар отвечает networkStandby, он возвращает один запрос кэшированного состояния и растягивает интервал с 15 с до 60 с. Оптимистичные UI-обновления (TTL 5 секунд, покрывающий время «оседания» устройства) делают дашборд мгновенным, а отложенный повторный опрос подтверждает реальное значение. Но за самый чистый фикс отвечает чтение: с v2.5.9 интеграция получает signing MAC детерминированно из settings:/system/primaryMacAddress — auth-free чтение, на которое устройство само отвечает — вместо старого танца с перебором соседей MAC по последнему байту (проводной …:3D против беспроводного …:3E), пока один не аутентифицируется. Замок, добавленный прошивкой, побеждается полем, которое прошивка же охотно выдаёт.

Результат: 41 сущность, управление в standby

Когда запись стала подписываться, я расширил интеграцию (теперь v2.5.15) далеко за исходные 20 сущностей — до 41: один медиаплеер, 5 селектов, 14 чисел, 10 переключателей и 11 сенсоров. Конкретно: медиаплеер (громкость и mute остаются без подписи); селекты для ночного режима, диалога, EQ-пресета, фильтра Dirac и режима LED; 14 чисел — 11 уровней каналов по ±6 дБ плюс задержка lip-sync (0–300 мс), баланс (−10…10) и таймаут простоя (0–3600 с); 10 переключателей, включая loudness, «не беспокоить», авто-standby, OTA-обновления и BLE-сопряжение; и 11 сенсоров, среди них два, делающих саму подпись наблюдаемой — сенсор Signing MAC с выведенным кредом и защищёнными путями, и сенсор Network Link.

Путь сюда — отдельный changelog: v2.4.1 починил 405, переведя запись на POST; v2.4.2 добавил command-health пробу; v2.5.0 принёс HMAC-подпись; v2.5.7–2.5.9 добавили доп-настройки, переключатели и детерминированный MAC; поздние сборки починили откат настроек в standby. Из этого последнего фикса и выпадает главная фича: все 41 сущность остаются управляемыми, пока бар спит — он применяет и сохраняет записи в standby, а интеграция кэширует заданное значение, так что следующий standby-опрос его не сбрасывает. Та же однопоточная инженерная автоматизация с retry-with-backoff, что и в первой сборке, теперь с подписью на каждой записи.

Вердикт

Ирония пишет себя сама: запереть API за константой и публичным MAC ничего не защитило — это лишь превратило рабочую интеграцию в многонедельный реверс-проект, и результат стал лучше. Локальный контроль полностью восстановлен и расширен, саундбару не нужно звонить домой, а каждый шаг — схема подписи, полевой рапорт, оценка безопасности, код — открыт с CI, HACS-валидацией и CodeQL-сканированием. Если будущая прошивка сменит константу, tools/extract_secret.py заново выведет её прямо из следующего APK: скачает пакет ~144 МБ, распакует вложенный split до libapp.so и найдёт секрет самостоятельно. Практический вывод для всех остальных — неэффектный: именно поэтому IoT-устройствам место в изолированном VLAN — не потому что подпись ночного режима опасна, а потому что устройство, её стерегущее, всё остальное раздаёт бесплатно. Замок поменялся; отмычка уже написана.

Нужна помощь с реверсом упрямого устройства, харденингом IoT или умным домом, которым вы реально управляете? Запишитесь на бесплатную консультацию →

Часто задаваемые вопросы

Прошивка Klipsch 2026 сломала интеграцию для Home Assistant?

Только запись. Чтение (getData) работает и по HTTP:80, и по новому TLS:443, но большинству записей setData теперь нужна HMAC-подпись, без неё — 401, а старая GET-форма записи даёт 405. Громкость и mute пишутся без подписи. Интеграция v2.5.0+ подписывает остальное автоматически — просто обновите.

Как была отреверсирована подпись записи Klipsch?

Dart-AOT-снапшот Flutter-приложения декомпилирован через blutter (на собранном из исходников Dart 3.10.0 SDK), что выдало деривацию пароля. Реальная подпись снята через WireGuard-mitmproxy, но её офлайн-перебор провалился полностью. Точные ключ и каноническая строка в итоге закреплены Frida-хуком на рутованном OnePlus — через spawn, а не attach, после того как Knox у Samsung, NAT у эмулятора и старый Redmi по очереди закрыли путь.

Аутентификация записи Klipsch действительно безопасна?

Нет. Пароль — это base64(MAC + "KlipschSupport!!88"): захардкоженная константа, общая для всех устройств, плюс публичный MAC (вещается в ARP, mDNS, BLE и через неаутентифицированный Cast API устройства), без серверного challenge — так что любое устройство в сети его воспроизводит и подписывает офлайн. Слой AES/HMAC поднимает цену интеропа, а не атаки — театр безопасности. Держите IoT-устройства в изолированном VLAN.

Почему открытый Cast API саундбара — проблема большая, чем подпись записи?

Потому что он вообще не требует креденшелов. Порт 8008 отвечает на неаутентифицированные запросы любого хоста в локалке идентичностью устройства, X.509-сертификатом, публичным RSA-ключом и подписанным attestation-блобом — на прошивке двухлетней давности с пятью незакрытыми CVE. Залочить запись саундбара, оставив это нараспашку, — и есть главная ирония обновления 2026.

Можно ли управлять саундбаром в режиме ожидания?

Да. Все 41 сущность доступны в standby; устройство применяет и сохраняет настройки во сне, а интеграция кэширует заданное значение, так что standby-опрос (один запрос раз в 60 с) его не сбрасывает.

Нужна консультация?

Если вам нужна профессиональная экспертиза — запишитесь на бесплатную 15-минутную консультацию.