Google Play Integrity API научили проверять источник Android-приложений

Google Play Integrity API научили проверять источник Android-приложений

Google Play Integrity API научили проверять источник Android-приложений

В Play Integrity API добавлена возможность верификации установки Android-софта из магазина Google. Вердикт «UNLICENSED» разработчик теперь может использовать для блокировки доступа либо через подсказку настоять на скачивании версии с Google Play.

Подобные проверки позволяют повысить безопасность приложений и предотвратить злоупотребления. При использовании неофициальных источников (sideloading) юзер рискует получить неполноценную, мошенническую или откровенно вредоносную версию приложения; разработчику оригинала в таких случаях грозит потеря доброго имени.

Предотвратить sideloading помогает Play Integrity API — средство предоставления разработчикам информации о надёжности запущенных приложений. Проверки проводятся по различным параметрам, в том числе определяются целостность бинарника, обратившегося к серверу, и наличие на устройстве поддержки Google Play (а теперь и наличие соответствующего аккаунта у текущего пользователя).

Вызов Play Integrity API может происходить на любом этапе выполнения программы. Разработчик также волен выбрать реакцию приложения на результаты проверок.

 

Новую опцию (проверку «подлинности» пользователя) уже освоили некоторые создатели игр для Android. На GitHub опубликован код, демонстрирующий данную функциональность.

Когда Play Integrity API возвращает вердикт «UNLICENSED», пользователю выводится диалоговое окно с предложением установить софт через Google Play. Если последовать этой подсказке, приложение добавится в библиотеку Play Store (нелегитимная версия удаляется вместе со связанными данными) и с этого момента будет получать апдейты из официального источника.

В Сеть выложили восстановленный исходный код легендарного Stuxnet

Неизвестный исследователь опубликовал на GitHub реконструированный исходный код Stuxnet — одного из самых известных и опасных компьютерных червей в истории. В репозитории представлены результаты обратной разработки вредоноса и инструкции по его сборке. В общем, цифровой экспонат из музея кибероружия теперь можно разобрать буквально по винтикам.

Stuxnet обнаружили в 2010 году, однако создавался он, предположительно, в рамках американо-израильской операции Olympic Games.

Целью атаки называли иранский завод по обогащению урана в Натанзе, где использовались промышленные контроллеры Siemens.

Добравшись до нужного оборудования, червь менял режим работы преобразователей частоты и выводил из строя роторы центрифуг. При этом операторам показывались нормальные показатели — промышленное оборудование ломалось, а на экранах царили тишина и порядок. По некоторым оценкам, атака повредила около 10% центрифуг предприятия.

Для распространения Stuxnet использовал USB-накопители, сетевые ресурсы и уязвимость Windows Print Spooler. Достаточно было открыть содержимое заражённой флешки, чтобы неизвестная на тот момент брешь запустила вредонос. Для обхода проверки драйверов применялись сертификаты, похищенные у Realtek и JMicron.

Червь также внедрялся в ПО Siemens WinCC и проекты Step 7, а затем перехватывал взаимодействие с программируемыми логическими контроллерами. Такой набор возможностей сделал Stuxnet первым широко известным вредоносом, который не просто портил файлы, а наносил физический ущерб промышленному объекту.

Идеальной операция всё же не была. Из-за ошибки в проверке окружения червь выбрался за пределы целевой сети и разлетелся по интернету, где его и заметили специалисты. В коде, к счастью, была предусмотрена дата самоуничтожения — 24 июня 2012 года.

Авторы публикации советуют изучать реконструкцию только в полностью изолированной виртуальной машине без сетевого доступа. Всё-таки это не ретроигра для Windows XP, а разобранная граната цифровой эпохи.

RSS: Новости на портале Anti-Malware.ru