Gmsnet2 jpg что это за файл
Обновлено: 21.11.2024
Аттестация SafetyNet — это Google, сообщающий приложению свое мнение относительно состояния CTS-совместимости устройства. CTS обычно расшифровывается как Compatibility Test Suite, который представляет собой набор тестов, которые устройство должно пройти перед выпуском, чтобы получить разрешение на включение сервисов Google Play. Это означает что-то другое в контексте SafetyNet, например, «устройство в настоящее время находится в неподделанном состоянии».
Состояние подделки имеет несколько определений и может включать в себя «рутирование», «отслеживание» или «заражение вредоносным ПО».
"Совместимость с CTS" не означает отсутствие уязвимостей. Google не проверяет, обновлено ли устройство или уязвимо для общедоступных эксплойтов, в рамках службы SafetyNet. Он проверяет, не было ли оно подделано, по сравнению с ожидаемым нормальным и безопасным состоянием.
Можно возразить, что именно этого хотят разработчики приложений: статус уязвимости устройства будет полезен конечным пользователям, но не разработчикам. Причина в том, что это нереально: если приложение отказывается работать на уязвимых устройствах, очень немногие приложения будут работать даже на самых последних устройствах Android. SafetyNet призвана гарантировать разработчикам приложений, что устройство «безопасно для работы», а не гарантировать, что устройство «безопасно» для конечных пользователей — другая целевая группа, другие цели.
Очевидно, что Google не хотел использовать слишком громоздкие термины, такие как рутирование или обнаружение несанкционированного доступа, поэтому он выбрал нейтральный термин «совместимость с CTS».
Использование аттестации SafetyNet
SafetyNet Attestation — это новая функция, по крайней мере, для сторонних разработчиков приложений. Любой разработчик приложений может использовать его в своем приложении.
Процесс состоит из нескольких шагов:
- Приложение вызывает SafetyNetApi.attest() . Это обеспечивается SDK сервисов Google Play. Запрос использует GoogleApiClient для доступа к серверам Google.
- Запрос должен включать одноразовый номер. Это очень важно для предотвращения повторных атак. Лучше всего, если сервер создаст этот одноразовый номер и отправит его на устройство для использования в запросе.
- Google отвечает результатом аттестации. Это в формате JSON Web Signature (JWS) — тип подписанного объекта JSON. Ответ включает в себя различные подписи и следующее: "ctsProfileMatch": true|false
- Разработчику необходимо вручную проверить поля ответа. Подпись ответа также может быть проверена самим Google с помощью другого вызова API, и это рекомендуется.
- Предполагая, что ответ проверен, если ctsProfileMatch имеет значение true, тогда разработчик может быть уверен, что устройство не было взломано (..совместимо ли CTS).
Интересно, что ответ также можно проверить на сервере разработчика. Приложение может получить ответ аттестации JWS и отправить его на сервер приложений, к которому оно обычно подключается. Затем этот сервер может напрямую попросить Google проверить подпись JWS (или сделать это самостоятельно) и приступить к обработке результатов на стороне сервера, например, запретить доступ API к клиенту.
Это хороший дизайн: решения по безопасности принимаются на сервере, а не на клиенте. Даже если клиентом будут манипулировать, сервер откажет в предоставлении услуг. Насколько я могу судить, в AndroidPay результат аттестации используется в качестве параметра практически в каждом кошельке и платежном API. Однако это не означает, что систему аттестации нельзя обмануть — вредоносная среда может передать сборщикам поддельные данные. Причем это не значит, что результат аттестации всегда свежий.. Но лучше хоть что-то, чем ничего.
Но как все это работает?
Проектирование системы SafetyNet
SafetyNet – это система сбора данных, используемая Google для сбора информации, связанной с безопасностью, с 1 миллиарда устройств Android с поддержкой Play.
Идея заключается в том, что сервисы Google Play, пакет с закрытым исходным кодом, запускают на устройстве постоянно работающую службу с именем snet . Эта служба часто собирает различные фрагменты данных с устройства и отправляет их обратно в Google.
Google использует эту информацию для различных целей, например для анализа экосистемы и профилирования угроз для устройств.
Оказывается, на основе собранной информации Google может определить, подделывается ли устройство множеством способов. Google хранит эту информацию и в любой момент знает, находится ли конкретное устройство в подозрительном состоянии.
Аттестация — это то, как эта информация предоставляется сторонним разработчикам. Когда приложение выполняет запрос на подтверждение, Google отправляет обратно подписанный ответ, который включает его решение о «совместимости с CTS», основанное на анализе информации, ранее собранной с устройства.
Фактический анализ собранных данных выполняется на стороне сервера, что оставляет меньше возможностей для манипулирования; снова хороший дизайн безопасности.
Конечно, понимание того, какие фрагменты данных собираются, может означать, что кто-то может в конечном итоге разработать систему перехвата, которая постоянно загружает snet «невредоносной» информацией.
Однако это не тривиально:
- Механизм, используемый для обновления snet, очень гибкий, как описано ниже.
- Google не раскрывает, как именно он определяет «совместимость с CTS» на основе собранных данных. Для большей части этих данных не очень очевидно, что считается «безопасным», а что нет. Например, если Google соберет список всех путей к файлам в файловой системе, злоумышленнику придется выяснить, что скрывать, методом проб и ошибок. Даже если он сможет сделать обоснованные предположения, он не будет знать, что именно ищет Google.
Внутреннее устройство SafetyNet
Когда стороннее приложение хочет выполнить запрос на подтверждение, оно вызывает com.google.android.gms.safetynet.SafetyNetApi;->attest(mGoogleApiClient, nonce) , метод подтверждения SDK Play Services, включенный в приложение. . Эта библиотека взаимодействует со службой com.google.android.gms.safetynet.internal.ISafetyNetService, запущенной на устройстве через Binder.
SafetyNetService — это одна из служб Google Play. Код обработки службы упакован в пакет Служб Google Play, который поставляется с одобренными Google устройствами Android и обновляется через Play Маркет.
Однако если копнуть глубже, можно обнаружить очень интересный трюк:
Фактическая реализация snet не находится ни в одном APK-файле.
Служба SafetyNet обращается к серверу Google и загружает двоичный пакет с кодом. Он делает все возможное, чтобы проверить целостность пакета, например, используя жестко закодированные сертификаты (закрепление). Этот двоичный пакет по существу является JAR-файлом, который содержит файл class.dex с байт-кодом java. Play Services кэширует его в dalvik-cache ( snet.dex ) и загружает его динамически, используя отражение.
Это очень удобно для Google: актуальную реализацию методов сбора можно очень легко обновить, даже не загружая приложения через Google Play.
Эти файлы никак не обфусцированы (даже с помощью ProGuard), хотя пакеты Google Play обфусцированы. После разговора с членами команды безопасности Android выяснилось, что это сделано специально: им нужна реализация, которую можно легко проверить. Я предполагаю, что они хотят убедиться, что люди знают, что они не собирают конфиденциальную/конфиденциальную информацию. Обфускация может вызвать сомнения.
Как видно из дат выпуска пакетов, части этой системы вовсе не новы: SafetyNet существует как минимум с декабря 2014 года, но в последних версиях она была значительно улучшена.
Этот файл JAR содержит реализацию класса com.google.android.snet.Snet. Самое интересное начинается с метода enterSnet — именно его сервисы Play вызывают посредством отражения.
Google загружает код, связанный с безопасностью, чаще. Например, устройства Android также загружают встроенную общую библиотеку droidguard и запускают ее, но давайте оставим это для другой статьи.
ЭнтерСнет
Система очень модульная: snet может быть запущен Play Services с помощью файла конфигурации, который определяет, какие модули коллекции будут использоваться. Не все из них включены по умолчанию.
Давайте посмотрим, что делает каждый из этих модулей более подробно:
пакеты_по умолчанию
su_files
Сообщает, существуют ли файлы /system/bin/su или /system/xbin/su. Если да, то это явное указание на фальсификацию.
Я надеюсь, что результат аттестации основан не только на этой проверке, хотя есть свидетельства того, что она играет важную роль. На незараженном, только что рутированном устройстве перемещение этих файлов в другое место, по-видимому, приводит к положительному результату аттестации. Тот же результат достигается с помощью таких действий, как «Отключить SuperSU». Возможно, Google проявляет особую осторожность.
настройки
Собирает различные поля, связанные с безопасностью, из android.provider.Settings$Secure или android.provider.Settings$Global в зависимости от версии ОС. Собранные настройки включают значения переменных, таких как adb_enabled, install_non_market_apps, isKeyguardSecure(), getNotificationVisibility(), lock_screen_lock_after_timeout, lockscreen.password_type, lock_pattern_autolock. Очевидно, что все это указывает на то, что устройство может быть «интересным».
локаль
Отображает текущую языковую настройку устройства. Я предполагаю, что это сделано для того, чтобы они могли профилировать пользователей в соответствии с их местоположением и корректировать свои пороговые значения по мере необходимости.
ssl_redirect
Это интересный модуль. Он пытается установить, правильно ли устройство выполняет перенаправления SSL. Он собирает такую информацию, как тип активного подключения, используемые DNS-серверы, доступные подключения.
ssl_рукопожатие
Это еще один очень интересный модуль. Он пытается выяснить, можно ли перехватить обмен данными несколькими способами, например, установив приложение SSL-Kill-Switch.
Для каждого хоста соблюдается следующий алгоритм, и фиксируются все результаты каждого шага вместе с любыми возможными ошибками.
- Модуль пытается подключиться к сокету SSL, используя TrustAllX509TrustManager "принять все".
- Сертификаты одноранговых узлов получены
- Код находит все TrustManager системы
- Каждый найденный TrustManager инициализируется без якорей доверия, и для полученной цепочки сертификатов выполняется метод checkServerTrusted(). Обычно это вызывает исключения, но в большинстве реализаций SSL Kill Switch этого не происходит. Код проверяет, генерируются ли исключения (отличная проверка)
- Параметры DefaultHostnameVerifier используются для проверки имени хоста соединения.
- Затем модуль вручную проверяет цепочку сертификатов, а также проверяет, используют ли какие-либо сертификаты алгоритм MD5withRSA и открытые ключи короче 2048 бит.
- Для каждого полученного сертификата в цепочке модуль проверяет, существует ли эмитент в хранилище ЦС системы ( /system/etc/security/cacerts ) ИЛИ был ли он добавлен пользователем ( /data/misc/ цепочка ключей/cacerts-добавлено )
- Модуль также включает жестко запрограммированный промежуточный сертификат для Google и проверяет, соответствует ли он одному из полученных цепных сертификатов.
- Наконец, идентификаторы объекта расширенного использования ключа конечного сертификата также извлекаются и сравниваются с жестко заданным списком (!)
После всех этих проверок вся информация о том, удалось ли установить соединение, какие были получены сертификаты, прошла ли проверка цепи и проверка доверия, отправляется обратно в Google.
mx_record
sslv3_fallback
прокси
Собирает, настроены ли на устройстве прокси-серверы, каковы их IP-адреса и являются ли эти IP-адреса локальными для устройства. При этом делается попытка установить, есть ли на устройстве вредоносное ПО, отслеживающее трафик (некоторые вредоносные программы и блокировщики рекламы работают с использованием прокси-серверов) или сообщение отправляется во внешние заведомо опасные места. р>
selinux_status
Собирает, доступна ли поддержка SELinux на устройстве (если присутствует /sys/fs/selinux/enforce) и находится ли оно в принудительном режиме (через чтение содержимого этого файла). Если SELinux находится в не- принудительного режима в более новых версиях Android, это явный признак того, что происходит что-то подозрительное.
sd_card_test
Пытается понять, была ли подделана SD-карта. Это создает файл JPEG с именем gmsnet2.jpg на SD-карте и заполняет его некоторым жестко запрограммированным содержимым. Затем ИТ анализирует, соответствует ли длина файла жестко запрограммированному значению, и проверяет, соответствуют ли записанные байты тому, что было отправлено, байт за байтом. Я не уверен, что понимаю, почему существует эта проверка и при каких условиях безопасности она не будет работать.
google_page_info
captive_portal_test
логарифм
Выполняет команду logcat -d и ищет настраиваемый набор «интересных строк». Google мог бы просто загружать все журналы на свои серверы и искать их там, но я предполагаю, что они выбрали этот подход, чтобы избежать случайной утечки личной информации пользователя. Набор «интересных строк» по умолчанию пуст, поэтому я не могу сказать, что они ищут.
журнал_событий
Аналогично проверке logcat, но для событий EventLog. Пропускает события с префиксом do-not-log-tag.
Сначала проверяется, существует ли на устройстве учетная запись Google. Затем, в зависимости от переключателей конфигурации, предоставляемых Google Play, он может собирать и сообщать информацию обо всех несистемных приложениях или обо всех системных приложениях. Этот модуль не включен по умолчанию. Во время тестирования приложения мы помечаем такое поведение как проблему конфиденциальности. Но я предполагаю, что Google уже знает, какие приложения вы установили, поскольку вы, скорее всего, использовали для этого Google Play, поэтому, вероятно, это не большая утечка. Я могу понять, почему Google интересно узнать, какие еще приложения установлены на устройстве.
страница_google
подозрительная_страница_google_page
gmscore
Собирает информацию о приложении com.google.android.gms на устройстве. Это приложение Google Mobile Services, также известное как Play Services. Собранная информация включает полный путь к APK и подписи пакета. Здесь Google пытается определить, не пытались ли что-то (например, вредоносное ПО) статически подделать игровые сервисы.
подтвердить
Отправляет запрос на подтверждение и получает ответ AttestationInfo. Было бы интересно узнать, в какой степени результаты прошлой аттестации учитываются при расчете новых ответов.
device_admin_deactivator
Получает активных администраторов устройства, если таковые имеются.Проверяет их по содержимому файла с именем device_admin_blacklist.txt. Он включен в загруженный файл snet.jar и содержит более 70 записей, таких как следующие:
Это HashMap, где ключи — это имена пакетов, а значения — это префиксы хэша sha256 полного имени пути.
Если обнаруживается, что какое-либо из приложений из черного списка по правильному пути APK является активным администратором устройства, вызывается removeActiveAdmin() для удаления администратора, а пакет останавливается с помощью forceStopPackage() . Собирается информация о приложении для пакетов администратора устройства.
Очевидно, что это выходит за рамки сбора и фактически пытается защитить устройство от опасных приложений, используя метод черного списка.
системные_разделы_файлы
Собирает различную информацию о настраиваемом списке интересующих файлов в /system . Информация включает в себя все разрешения, имена файлов, цели символических ссылок, контекст безопасности selinux, хэши и т. д. В настоящее время список интересующих файлов кажется пустым. Интересно, что фреймворк использует отвлекающий маневр, чтобы сбить злоумышленников с толку: наряду с интересующими файлами таким же образом можно получить доступ к настраиваемому количеству случайных файлов. В продуктах расширенной защиты приложений обычно используются отвлекающие подходы. Однако по умолчанию это не включено.
системное_ca_cert_store
Модуль содержит настраиваемый список хэшей сертификатов sha256. Эта проверка просматривает содержимое /system/etc/security/cacerts или /system/etc/security/cacerts.bks (до ICS), пытаясь найти их, и возвращает их, если они найдены, либо полные сертификаты, либо просто имя субъекта, имя эмитента и информация о подписи, снова настраиваемые. Это попытка понять, перехватывается ли трафик, путем поиска сертификатов, занесенных в черный список. Существует вредоносное ПО, которое сбрасывает вредоносные сертификаты в хранилище сертификатов, позволяя перехватывать SSL-трафик на сетевом уровне.
setuid_files
Эта проверка, как и следовало ожидать, собирает информацию о файлах setuid, присутствующих в файловой системе. Он использует libcore.io.StructStat и libcore.io.OsConstants, libcore.io.OS, libcore.io.Libcore и связанные классы для получения информации. Наличие исполняемых файлов с setuid является очевидным тревожным сигналом в новых версиях Android.
- похоже, система спроектирована таким образом, чтобы сбор был прозрачным: код сбора данных не запутан намеренно, чтобы его можно было просмотреть, как это сделано в этом анализе.
- похоже, что система также спроектирована таким образом, что она не собирает случайно личную информацию. Например, журнал и сборщик событий собирают только определенные события, соответствующие регулярным выражениям, а не все журналы. Конечно, без самих регулярных выражений мы не можем знать, что именно собирается.
- никакие пользовательские идентификаторы, такие как IMEI, IMSI и другие, не собираются.
- некоторые сборщики отключены по умолчанию. Я предполагаю, что Google может включить их только в определенных регионах или после того, как впервые обнаружит признаки несанкционированного доступа, чтобы собрать дополнительную информацию.
- для сбора большей части собранной информации не требуются системные привилегии или множество разрешений. Некоторые из них могут быть собраны обычными приложениями. Я видел рекламные библиотеки, встроенные в сотни приложений, которые собирают гораздо больше личной информации.
При этом я понимаю, что некоторые люди могут считать SafetyNet навязчивой — у каждого человека разные взгляды на то, что составляет личную/конфиденциальную информацию.
Также следует сказать, что системы отказа, похоже, не существует. Это может иметь интересные последствия, когда сторонние приложения начнут использовать сертификацию SafetyNet.
Я знаю, что не сошёл с ума (пока), но у меня есть сильное подозрение, что элементы, перечисленные в моём заголовке выше, как-то связаны с нарушениями безопасности на моём телефоне Android. это сводит меня с ума! Я не слишком разбираюсь в технологиях, но иногда сам обучаю основам. Я мало что знаю, но я знаю, что каждый раз, когда я пытаюсь понять, почему громкость моего динамика такая низкая, или почему приложения, которые я даже не открывал, внезапно появляются, когда я разблокирую свое устройство, или почему мой телефон работает так медленно, или почему мои приложения продолжают давать сбои, или почему все эти серверы и порты, похоже, используют мою сеть для доступа к вещам, к которым им не следует обращаться, или почему я сбрасываю настройки своего телефона для нулевой раз, или. и так далее. Я ловлю себя на том, что смотрю на отчет об отладке, который я не могу прочитать или интерпретировать, или на какой-то файл журнала, в котором есть много данных для меня, которые я не могу понять. Что я заметил, так это то, что мне всегда кажется, что я сталкиваюсь со строкой, связанной с Estrongs.pop, которую я не могу удалить, или с файлом с именем gmsnet2, который просто показывает мне изображение крошечной точки, значение которого я понятия не имею.Я также заметил, что в моем телефоне, похоже, отсутствуют файлы, которые когда-то были там, меня перенаправляют, когда я пытаюсь найти эти отсутствующие файлы с помощью ES File Manager, и я не уверен, что такое emulated/0, но эмулированный, похоже, заимствован все данные моего телефона и отказывается вернуть их мне. Я схожу с ума, ища файлы, которые не имеют отношения к делу, или мой телефон был украден, а мои файлы требуют выкупа? Стоит ли беспокоиться об этом, или com.android.Estrongs.pop был связан со вредоносными тенденциями, о которых я не знаю? Если да, то что мне делать, чтобы это исправить?
BC AdBot (войдите для удаления)
Эстронгс известен шпионажем. Я на самом деле поймал их на том, что они просили скриншоты, когда они у меня были. Был активным пользователем в течение многих лет. И хочешь показаться сумасшедшим? Я тот, кто пытается убедить кого-то помочь мне, потому что меня взломали, это не сумасшедшая часть, сумасшедшая часть - это когда я говорю им, кто. Эээ...
emulated/0 – это внутреннее хранилище устройства.
Estrongs — это название компании, которая предоставляет ES File Explorer. Файлы, содержащие это имя, относятся к файловому проводнику. Чтобы удалить файл, необходимо удалить проводник.
gmsnet2.jpg является частью SafetyNet, функции Android. Это обычный файл.
Почему я вижу так много людей по всему Интернету, которые сомневаются в достоверности этого файла, заявляя, что у них есть сильное подозрение, что он вредоносный, а затем я вижу модераторов, сотрудников Google и других различных организаций, которые могут иметь корыстные заинтересованы в сокрытии определенной информации от общественности, выйдите и ответьте на эту искреннюю озабоченность по поводу безопасности, что этот файл является частью SafetyNet, безусловно, самой распространенной связанной программы, но я видел, как кто-то утверждал, что он был частью какой-то другой программа. Я видел сообщение, в котором говорилось, что файл был создан Google Pay и помещен на вашу SD-карту в целях безопасности. . . на что ОП ответил, что он никогда не пользовался Google Pay, и, кроме того, в его телефоне нет SSD-карты. Разве вредоносный файл не может маскироваться под законный файл? Итак, как почти каждый эксперт форума может предположить, что каждый отдельный экземпляр файла gmsnet2.jpg, о котором люди спрашивают, совершенно безопасен, и не о чем беспокоиться, даже не анализируя сам файл. Пожалуйста, ответьте на один вопрос, который у меня есть, потому что, как и в ОП, у меня тоже есть некоторые знания-самоучки (больше в отношении мира ПК, чем смартфона ... для другой ОС и другой архитектуры для меня в новинку, и обычно бросает меня на несколько циклов.Если мой экземпляр gmsnet2.jpg является совершенно законным и безопасным файлом изображения, и это один из самых популярных форматов файлов изображений, то почему, когда я пытался открыть его с помощью средства просмотра изображений на мой компьютер, это заставило мой компьютер сходить с ума, как будто он выдавал команды. Он открыл примерно 30 экземпляров моего средства просмотра изображений, прежде чем мне удалось его остановить, наряду с несколькими другими вещами, которые он, казалось, инициализировал. вызвать такое ненормальное поведение на моем ПК из-за простой попытки открыть его с помощью соответствующего программного обеспечения, чтобы просто просмотреть его.
Он создан не Google Pay, а службой Google Mobile Services, которая является частью операционной системы Android. Даже если у вас не установлена внешняя SD-карта, она все равно будет присутствовать в вашей системе. Каким средством просмотра изображений вы пытаетесь его открыть? Файлы JPG никогда не должны вызывать такие проблемы. Размер файла превышает 159 байт?
Читайте также: