Приховати кореневий доступ у Magisk стане набагато складніше завдяки нещодавній зміні в SafetyNet, яка передбачає атестацію апаратного забезпечення.
Ще в березні кілька користувачів встановили Magisk помітили що їхні пристрої не пройшли атестацію SafetyNet. Ця новина стурбувала спільноту на XDA, оскільки це означає, що багато важливих банківських/фінансових програм і популярних ігор, таких як Pokémon Go і Fate/Grand Order, відмовлялися запускатися на пристроях із root-доступом. Деякий час здавалося, що посилені обмеження в SafetyNet було скасовано, щоб лише за останні кілька тижнів знову запровадити для кількох користувачів. Однак на початку травня Google тихо підтвердив, що тестує апаратну атестацію Відповіді SafetyNet, через що Magisk не зміг приховати статус розблокування завантажувача в березень. Якщо ця зміна буде широко розгорнута, це означатиме, що користувачам доведеться вибирати між доступом до root/спеціальних ПЗУ/ядер тощо. або улюблені банківські програми та ігри. Одна з найбільших привабливостей Android для досвідчених користувачів незабаром може зникнути.
Щоб підсумувати цю серію подій, ми повинні спочатку поговорити про саму SafetyNet. SafetyNet – це набір API у сервісах Google Play. API атестації SafetyNet є одним із таких API, і його можуть викликати програми сторонніх розробників, щоб перевірити, чи програмне середовище пристрою будь-яким чином підроблено. API перевіряє різні речі, як-от ознаки двійкових файлів суперкористувача, стан розблокування завантажувача тощо. Коли ви рутуєте пристрій за допомогою Magisk, він «[створює] ізольоване «безпечне середовище» для процесу виявлення [SafetyNet] і проходить через API Google для створення законний Результат SafetyNet, який не відображає реальний стан пристрою», – старший визнаний розробник XDA topjohnwu. Це дозволяє користувачеві рутувати свій телефон, гарантуючи, що API завжди повертає «false» для будь-яких перевірок розблокування завантажувача. Цей метод обходу виявлення розблокування завантажувача SafetyNet працював у Magisk протягом останніх кількох років, але це лише тому, що Google відклав перевірку цілісності завантажувального образу за допомогою апаратного забезпечення атестація. У березні здавалося, що Google нарешті почав використовувати атестацію апаратного забезпечення в SafetyNet для перевірки завантажувальний образ, але ми так і не отримали офіційної заяви від Google, яка б підтверджувала зміни, і лише кілька користувачів отримали постраждали. Як помітив XDA Senior Member Дисплакс5 травня 2020 року Google підтвердив, що відповіді SafetyNet Attestation API від деяких пристроїв тепер включають апаратні перевірки.
У групі Google для «Клієнтів API SafetyNet» Google детально описав нову функцію для API атестації: evaluationType. Відповідь веб-підпису JSON (JWS) від деяких пристроїв матиме поле під назвою «evaluationType», яке «надасть розробникам розуміння у типи сигналів/вимірювань, які сприяли кожній окремій відповіді API атестації SafetyNet." Один із підтримуваних маркерів у цьому полі є «HARDWARE_BACKED», що вказує на те, що API «[використовував] доступні апаратні функції безпеки віддаленого пристрою (наприклад, апаратна підтримка ключа атестації), щоб вплинути на [його] оцінку". Google каже, що "наразі вони оцінюють і коригують критерії відповідності для пристроїв, де ми будемо покладатися на апаратне забезпечення функції безпеки." Це означає, що на деяких пристроях сервіси Google Play тепер використовують апаратну атестацію, щоб виявити, що програмне забезпечення пристрою не було підроблено. Google офіційно не задокументував цю зміну, окрім оголошення в групі Google, тому деякі розробники, які використовують SafetyNet, можуть не знають про цю зміну (і тому ще не перевіряють наявність поля «HARDWARE_BACKED» у відповідях JWS). Однак для тих програм, які перевіряють це поле, тепер немає способу приховати від них доступ root, якщо ваш пристрій є частиною тесту, який Google біг.
За словами topjohnwu, апаратна атестація означає, що сервіси Google Play тепер «[надсилають] немодифікований сертифікат сховища ключів на сервери SafetyNet, [перевіряють] його законність і [перевіряє] дані розширення сертифіката, щоб дізнатися, чи [на вашому пристрої] увімкнено перевірене завантаження (статус завантажувача).» Оскільки закриті ключі, з яких отримано сертифікати сховища ключів підтримуються ізольованим захищеним середовищем телефону, їх отримання призведе до порушення безпеки довіреного середовища виконання телефону (TEE) або спеціального апаратного захисту модуль (HSM). Якби хтось якимось чином міг отримати витік приватного ключа, то ключі будуть швидко анульовані як тільки Google дізнався. Google пропонує винагороду в сотні тисяч доларів за будь-які критичні вразливості безпеки, що впливають на TEE у телефонах Pixel, що лише свідчить про те, що це неймовірно малоймовірно, щоб це був потенційний спосіб обійти виявлення розблокування завантажувача все одно.
Ще один можливий спосіб, за допомогою якого Magisk може продовжувати підробляти стан розблокування завантажувача, — змінити клієнтський код SafetyNet, щоб завжди використовувати оцінку BASIC. як примітки topjohnwu, однак для цього знадобиться впровадити спеціальний код у Google Play Services через фреймворк підключення, такий як Xposed Framework. Це не тільки важко зробити, оскільки сервіси Google Play дуже заплутані, але й неможливо приховати, оскільки «деякий аналіз пам’яті виявить маніпуляції з кодом дуже Крім того, це також працюватиме, лише якщо сервери Google продовжуватимуть приймати оцінки BASIC і якщо оцінки HARDWARE_BACKED не застосовуватимуться на пристроях, які підтримують їх. (За словами topjohnwu, відповіді SafetyNet «[походять] із серверів Google і підписуються закритим ключем Google», тому фактичні відповіді неможливо підробити.)
Починаючи з Android 7 Nougat, Google вимагає, щоб усі пристрої мали ізольоване безпечне середовище, це означає, що ця зміна в тому, як SafetyNet перевіряє розблокування завантажувача, вплине на більшість пристроїв, які не працюють там. Оскільки старі пристрої без ізольованого захищеного середовища, очевидно, не можуть виконувати апаратну атестацію, Magisk усе одно зможе приховати кореневий доступ на цих пристроях. Але якщо ця зміна пошириться широко, усім іншим доведеться зробити важкий вибір між кореневим доступом і банківськими програмами.
На жаль, напевно існує багато програм, які використовують перевірки SafetyNet, коли їм це насправді не потрібно. Одним із прикладів, наведених topjohnwu, є офіційний додаток McDonald's, який, здається, відмовляється запускатися на пристрої з розблокованим завантажувачем. У Twitter topjohnwu називає програми, які надмірно використовують API, створюючими вороже середовище для досвідчених користувачів. Визнаний розробник XDA Quinny899 приєднується до анекдоту про те, як його команда розглядала використання SafetyNet для перевірки стану безпеки пристрою. Зрештою вони вирішили не робити цього, оскільки програма його команди шифрує всі конфіденційні дані, з якими працює. SafetyNet, стверджує він, не слід використовувати замість належної безпеки та практики обробки даних, особливо з огляду на можливість експлойтів суперкористувача.
Щоб дізнатися більше про те, як нова зміна SafetyNet впливає на Magisk, перегляньте сайт topjohnwu чудовий FAQ у Twitter. Якщо ви просто хочете перевірити, чи ваш пристрій є частиною нового тесту Google SafetyNet, ви можете підписатися цей посібник від XDA Senior Member Displax або завантажте останню версію Magisk Manager.
Цю статтю було оновлено о 10:46 за стандартним стандартним часом 30 червня 2020 року, щоб виправити те, що Google виплачує винагороду лише за вразливості TEE, виявлені в телефонах Pixel. Крім того, було додано деталі щодо останнього випуску Magisk Manager, у якому тепер відображається поле evaluationType у вбудованому засобі перевірки SafetyNet.