Как взломать андроид в машине
Ломаем софт для Android. Делаем платное приложение бесплатным
Содержание статьи
- Снаряжаемся
- Вскрываем подопытного
- Изучаем код
- Вносим правки
- Выводы
Ни один разговор о взломе и модификации приложений не обходится без упоминания дизассемблера, дебаггера, формата исполняемых файлов и вездесущей IDA Pro. Однако в случае с Android все намного проще, и здесь для вскрытия и даже внедрения кода в приложение совсем не обязательно использовать все эти инструменты. Код можно легко декомпилировать обратно в Java и модифицировать, используя пару простых инструментов и текстовый редактор.
Этой статьей мы начинаем цикл, посвященный вскрытию и модификации приложений для Android. Первая часть — вводная, поэтому никакого хардкора: мы разберемся в устройстве пакетов APK, научимся разбирать APK на части, декомпилировать его код, вносить правки и собирать обратно, и в качестве примера взломаем одно популярное приложение из маркета. Вторая статья будет целиком посвящена внедрению бэкдора/вируса в чужое приложение. Это уже не просто правка нескольких строк, а глубокая модификация. Третья статья — методы обфускации и их обхода. Все больше разработчиков используют нетривиальную обфускацию, чтобы осложнить жизнь реверсерам. Мы распутаем их код и опять же внесем правки в приложение.
WARNING
Снаряжаемся
Для выполнения описанных в статье действий понадобится ряд инструментов, и главный инструмент — это Linux. Да, многие из названных далее программ могут работать и в Windows, но в любых операциях, связанных с Android и его приложениями, лучше не полагаться на детище Билли. В Linux практически все сделать проще, командная строка здесь в разы удобнее (она нам ох как понадобится), а некоторые инструменты просто недоступны для других ОС.
После установки Linux в виртуалку или второй системой сразу устанавливаем средства разработки на Java и виртуальную машину. В Ubuntu это можно сделать с помощью одной команды:
Также нам нужны четыре инструмента для распаковки и декомпиляции приложений:
- Apktool — швейцарский армейский нож для распаковки и запаковки приложений;
- Jadx — декомпилятор байт-кода Dalvik в код на Java;
- Backsmali — дизассемблер кода Dalvik (не пугайся, с настоящим ассемблером он имеет мало общего);
- Sign — утилита для подписи пакетов.
Для удобства создадим в домашнем каталоге подкаталог Android и скачаем эти инструменты в него:
Добавим в конец файла
/.bashrc следующие строки:
Они нужны для того, чтобы вместо длинных и неудобных команд вроде java -jar
/Android/sign.jar можно было набрать просто sign.
Вскрываем подопытного
Теперь нам нужно найти приложение, которое, во-первых, нетрудно расковырять, а во-вторых, которое несет какую-то пользу и достаточно известно. То есть брать простейшую софтину только для того, чтобы было не очень сложно разобраться в ее коде, мы не будем, а вместо этого устремим свой взор на топ Play Store. Практически идеальный кандидат на эту роль — выпущенный два месяца назад ASAP Launcher, удобнейший домашний экран с массой полезных и неординарных функций.
Для начала пройдемся по APK без использования специальных инструментов. Для этого скачаем пакет при помощи сервиса APKPure: открываем страницу приложения в Play Store, копируем URL из адресной строки и вставляем в строку поиска на APKPure. Далее нажимаем кнопку Download APK и ждем окончания загрузки.
Страница ASAP Launcher на APKPure.com
Xakep #212. Секреты даркнета
- Содержание выпуска
- Подписка на «Хакер»
Для удобства переименуем пакет в asap.apk:
Разархивируем с помощью unzip:
Да, APK — это обычный архив ZIP, но тем не менее он имеет четкую структуру:
- META-INF — каталог, содержащий файлы MANIFEST.MF, CERT.MF и CERT.RSA. Первые два — список всех файлов пакета и их контрольных сумм, последний содержит открытый ключ разработчика и созданную с помощью закрытого ключа цифровую подпись файла CERT.MF. Эти данные нужны, чтобы при установке пакета система смогла выяснить, что пакет не был модифицирован и действительно создан его автором. Это важно, так как, поскольку нет возможности подделать цифровую подпись пакета (для этого нужен закрытый ключ), модифицированный пакет придется подписывать другим ключом;
- res — ресурсы приложения. Здесь находятся иконка (mipmap), переводы строк (values), изображения (drawable), а также описания интерфейса приложения (layout). Все их можно модифицировать, чтобы изменить внешний вид приложения. Правда, файлы XML придется сначала «разжать» — для улучшения производительности они хранятся в бинарном формате;
- classes.dex — код приложения в форме байт-кода виртуальной машины Dalvik. Обычно приложения содержат только один такой файл, но, используя директиву multiDex, разработчик может заставить среду разработки разбить его на множество более мелких для улучшения производительности или преодоления ограничения на 65 536 методов в одном dex-файле;
- AndroidManifest.xml — манифест приложения, описывающий его структуру, включая активности, сервисы, обработчики интентов и так далее. Опять же в формате бинарного XML.
Также пакет может содержать другие каталоги, например assets (любые файлы, включенные разработчиком, в данном случае — шрифты и база данных) и lib (нативные библиотеки, созданные с использованием Android NDK).
Изучаем код
Само собой разумеется, просто разархивировать пакет недостаточно. Чтобы разобраться в работе приложения, необходимо декомпилировать файл classes.dex.
Для этого мы воспользуемся jadx-gui. Запускаем, выбираем asap.apk и видим слева список пакетов Java, включенных в APK. В данном случае это пакеты android.support — официальная библиотека Google, реализующая поддержку функций новых версий Android в старых (например, чтобы получить Material Design в Android 4.1), com.google.android.gms — Google Mobile Services, com.nispok.snakbar — реализация GUI-элемента snakbar, а также несколько других.
Пакеты Java
Основной код приложения содержится в пакете com.citc.asap, именно такое имя носит и само приложение в Google Store и на устройстве. Открываем его и видим больше десятка каталогов и множество исходников Java. Наша задача — сделать приложение «оплаченным», не платя за него. Но как найти нужный файл, реализующий проверку на оплату? Скорее всего, он будет содержать в имени слово billing. Пробегаемся по исходникам в поисках нужного нам файла и натыкаемся на исходник BaseBillingFragment в подкаталоге (пакете) fragments:
Это очень простой класс Java, в котором есть интересный метод:
Все, что он делает, — просто возвращает значение поля mHasPrime, однако интересен он не этим, а своим именем. Дело в том, что платная (точнее, оплаченная) версия ASAP называется Prime, и очевидно, что метод hasPrime как раз и нужен для проверки оплаты приложения. Чтобы подтвердить свою догадку, сохраним декомпилированные исходники (File -> Save all) в каталог и попробуем найти в них вызовы hasPrime():
Совпадений немного, основной «пользователь» hasPrime() — это SettingsFragment, то есть исходник, отвечающий за формирование окна настроек. Учитывая, что Prime-версия отличается от бесплатной именно тем, что в ней разблокированы дополнительные поля настроек, уже сейчас мы можем быть на 90% уверены, что hasPrime() — нужный нам метод. Скорее всего, именно с его помощью приложение выясняет, куплена ли Prime-версия. Осталось только убедиться в этом окончательно, подменив код метода на свой.
Вносим правки
Метод hasPrime() очень прост: он возвращает значение поля mHasPrime, которое имеет тип boolean. Нетрудно предположить, что в случае, если приложение оплачено, hasPrime() вернет true, иначе вернет false. Наша задача — сделать так, чтобы метод всегда возвращал true и остальная часть приложения думала, что приложение оплачено, и разблокировала дополнительные опции в окне настроек.
К сожалению, сделать это с помощью прямой правки исходного кода не получится: приложение нельзя скомпилировать обратно. Однако никто не запрещает дизассемблировать код, внести правки и собрать его вновь. И как раз здесь нам понадобится apktool. Дизассемблируем APK:
В текущем каталоге появится подкаталог asap. Открываем файл asap/smali/com/citc/asap/fragments/BaseBillingFragment.smali и находим hasPrime() . Декларация метода будет выглядеть так:
Это и есть дизассемблированный листинг, и, как ты видишь, он на порядок проще, чем дизассемблированный код нативных приложений. В целом здесь все тривиально:
- .method protected hasPrime()Z — объявляет protected-метод, который возвращает значение типа boolean (Z);
- .locals 1 — говорит виртуальной машине, что метод использует в своей работе один регистр (в данном случае он будет содержать возвращаемое значение);
- .prologue и .line 167 — директивы, необходимые для отладки, на ход исполнения не влияют;
- iget-boolean v0, p0 . — получает значение поля типа boolean и записывает в регистр v0, регистр p0 — это нулевой параметр, он всегда равен имени класса (this);
- return v0 — возвращает значение регистра v0;
- .end method — закрывает тело метода.
Теперь мы должны изменить данный метод так, чтобы он возвращал true независимо от значения поля mHasPrime . Мы могли бы сделать это вручную, но проще написать новый метод на Java:
И пропустить его через компилятор и дизассемблер:
На выходе получаем следующий ассемблерный код:
Ты уже должен сам догадаться, что он объявляет константу v0 со значением 1 и возвращает ее (в Dalvik тип boolean — это int, который может иметь значение 1 — true или 0 — false). Осталось только вставить этот код вместо оригинального и собрать пакет обратно:
Пакет появится в каталоге asap/dist . Переименуем его, чтобы не запутаться:
И подпишем с помощью тестового ключа:
В результате в текущем каталоге появится файл asap-fake-hasPrime.s.apk. Остается только закинуть его на карту памяти и установить, удалив перед этим оригинальное приложение.
Выводы
Взломать приложение для Android очень и очень просто. Да, я не спорю, нам попался удобный и простой пример для модификации, но опять же повторюсь — это весьма популярное приложение, о котором рассказывали на большинстве сайтов, посвященных Android.
Большинство других приложений вскрыть так же просто, однако есть достаточное количество экземпляров, пропущенных через обфускаторы и различные системы защиты. С ними все несколько сложнее, и таким приложениям будет посвящена третья статья цикла. Во второй статье мы рассмотрим, как тот же самый метод модификации использовать для внедрения собственного кода.
Евгений Зобнин
Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.
5 способов взломать Андроид без получения root доступа.
Как не печально об этом говорить но мобильные и не только, устройства на базе системы Андроид более уязвимы по сравнению со своими яблочными конкурентами. Это происходит благодаря открытому исходному коду платформы и изобилию настроек, которые доступны для пользователей системы. О некоторых таких уязвимостях мы и поговорим сегодня, а именно — как получить контроль над системой андроид с помощью разрешений приложений.
API которые применяются для взлома андроид.
- Администрирование устройства — API, предназначенный для корпоративных приложений. Позволяет сбрасывать и устанавливать пароль экрана блокировки, сбрасывать смартфон до заводских настроек и устанавливать правила минимальной сложности пароля. Одна из особенностей API — запрещено удалять приложения, получившие права администратора, чем с радостью пользуются авторы зловредных приложений.
- Accessibility — API для реализации приложений, ориентированных на людей с ограниченными возможностями. Фактически API позволяет создавать альтернативные способы управления устройством и поэтому открывает поистине огромный простор для злоупотребления. С его помощью можно получить доступ к содержимому экрана практически любого приложения, нажимать кнопки интерфейса и программно нажимать клавиши самого смартфона. Но есть и способ защиты: разработчик приложения может прямо указать, что определенные элементы интерфейса приложения будут недоступны для сервисов Accessibility.
- Уведомления — API, позволяющий получить доступ ко всем уведомлениям, которые отображаются в панели уведомлений. С помощью этого API приложение может прочитать всю информацию об уведомлении, включая заголовок, текст и содержимое кнопок управления, нажать на эти кнопки и даже смахнуть уведомление. API пользуется особой популярностью среди разработчиков всевозможных банковских троянов, с помощью которого они могут читать коды подтверждения и смахивать предупреждающие сообщения от банков.
Получив доступ ко всем этим API, зловредное приложение сможет сделать со смартфоном практически все что угодно. Именно поэтому для их защиты используются не традиционные запросы полномочий, на которые пользователь может машинально ответить «Да», а скрытый глубоко в настройках интерфейс, который при активации покажет угрожающее сообщение. Все, что может сделать приложение, чтобы получить нужное полномочие, — это перебросить пользователя в окно настроек, после чего тот должен будет найти нужное приложение, включить напротив него переключатель и согласиться с предупреждающим сообщением.
Заставить пользователя дать разрешение на использование этих API можно обманом. Зачастую зловреды прикидываются легитимными приложениями, которым разрешение нужно для работы ключевой функциональности. К примеру, это может быть приложение для ведения журнала уведомлений или приложение для альтернативной жестовой навигации (такому приложению нужен сервис Accessibility для нажатия кнопок навигации). Также можно использовать атаку Cloak & Dagger, чтобы перекрыть окно настроек другим безобидным окном.
1. Нажатие кнопок смартфона
Простейший сервис Accessibility может выглядеть так (код на Kotlin):
Как взламывают подключенные автомобили и что с этим делать
Подключённые к интернету автомобили с автопилотами, по сути, полуавтономные гаджеты на колёсах, сегодня учатся взаимодействовать со своими механическими собратьями, облачными сервисами и дорожной инфраструктурой, чтобы сделать движение безопаснее, помочь водителю принять правильное решение, а в критической ситуации отреагировать быстрее человека. Вместе с тем, электронная начинка и софт современных автомобилей имеют столько уязвимостей, что их взлом напоминает скорее движение по хайвею, чем бег с препятствиями. В этом посте мы поделимся результатами изучения безопасности современных автомобилей, собранными в исследовании компании Trend Micro, получившем название «Driving Security Into Connected Cars: Threat Model and Recommendations».
Прежде чем перейти к описанию конкретных кейсов, сделаем небольшое введение в проблему. Типичный легковой автомобиль последнего поколения содержит под капотом не только двигатель, но и более 100 млн строк кода. Даже относительно простые модели имеют около 30 электронных блоков управления (ЭБУ), оснащённых собственными процессорами и прошивкой. В люксовых авто таких блоков может быть больше ста. Чтобы взаимодействовать между собой, эти ЭБУ подключаются через лабиринт цифровых шин. Здесь и CAN (Control Area Network), и Ethernet, и FlexRay, LIN и MOST. Все они работают с разной скоростью, передают различные типы данных и обеспечивают соединение между разными частями автомобиля.
Именно ЭБУ управляют критически важными функциями автомобиля: двигателем, коммуникациями, подачей топлива, тормозной системой и безопасностью. Частично управление этими компонентами доступно через головное устройство.
Современные авто оборудованы модулями геопозиционирования, умеют подключаться к мобильному интернету и даже использовать публичные сети Wi-Fi. Такой «смартфон на колёсах», как и его более компактный карманный аналог, имеет беспроводные интерфейсы и может раздавать интернет своим пассажирам.
Мы изучили устройство автомобильных сетей разных производителей и выяснили, что, хотя каждый вендор реализует их по-разному, все архитектуры имеют общие компоненты: шлюзы, ЭБУ, шины CAN, USB- и беспроводные интерфейсы. При всех отличиях они выполняют сходные функции и взаимодействуют между собой одним образом. На основании этих данных мы создали обобщённую архитектуру автомобильной сети.
Структурная схема типовой сети подключённого автомобиля. Источник: Trend Micro
Из схемы видно, что подключённый автомобиль обладает сетевыми интерфейсами, которые позволяют атаковать его удалённо. Результатом таких атак может стать компрометация одного или нескольких ЭБУ и полный перехват управления автомобилем. Рассмотрим несколько случаев таких атак и уязвимости, которыми воспользовались хакеры.
Случай 1: Удалённый взлом Jeep Cherokee в 2015 году
В 2015 году Чарли Миллер и Крис Валасек совместно с корреспондентом журнала Wired продемонстрировали дистанционный взлом подключённой модели автомобиля Jeep Cherokee.
Корреспондент выехал на хайвей, после чего исследователи перехватили управление системами его автомобиля — они включили на полную мощность музыку и кондиционер, заставили работать щётки стеклоочистителя, а затем снизили скорость авто до 10 миль в час, так что другие водители сигналили участнику эксперимента, обгоняя его. Самым ужасным было то, что он полностью лишился контроля: управление мультимедийной системой, кондиционером и даже педалью газа взяли на себя хакеры.
Исследователям удалось обнаружить IP-сеть класса А, которую производитель, компания Chrysler, использовала для своих подключённых автомобилей. Сканируя открытые порты, они выяснили, что в каждом автомобиле был открыт порт 6667, на котором демон сообщений D-Bus принимал команды через протокол Telnet без аутентификации. Отправляя команды демону D-Bus, Миллер и Валасек полностью перехватили управление автомобилем.
Цепочка атаки на Jeep Cherokee. Источник: Trend Micro
Вообще, в процессе изучения внутреннего устройства Jeep Cherokee хакеры нашли много любопытного, например:
- головное устройство может работать с устройствами, подключёнными не только к шине CAN-IHS (CAN Interior High Speed), но и к шине CAN-C (CAN Critical), то есть критические с точки зрения безопасности системы в сетевой архитектуре Jeep не отделены от обычных систем;
- подключиться к Jeep лучше всего через его мобильный сетевой интерфейс, при этом злоумышленник может находиться хоть в другой стране и всё равно сможет управлять транспортным средством;
- диапазон IP-адресов автомобилей Jeep находится в полностью открытом интернет-пространстве, поэтому получить доступ к любому автомобилю может любой пользователь интернета — теоретически можно создать сетевого червя, который просканирует сеть и заразить все подключённые к сети Chrysler автомобили через демон D-Bus, работающий на открытом порте 6667;
- прошивка для микропроцессора Renesas V850 и процессора OMAP (Open Multimedia Applications Platform) доступна для загрузки с сайта Chrysler — это делает возможным реинжиниринг и модификацию (в частности, Миллер и Валасек заставили прошивку интерпретировать SPI сообщения как сообщения CAN и транслировать их на все подключённые к шине CAN ЭБУ);
- алгоритм вычисления контрольной суммы CAN-сообщений, чтобы они выглядели легитимными для ЭБУ автомобиля.
- алгоритм разблокировки ЭБУ для перепрограммирования — оказалось, что ЭБУ ассистента парковки, который считывает CAN-сообщения для манипулирования функцией рулевого управления, также является чипом V850, что позволяет с лёгкостью провести реверс-инжиниринг алгоритма его работы;
- сообщения CAN, которые отключают двигатель и тормоза и поворачивают руль;
- способ подменить CAN-сообщения от настоящих ЭБУ или деактивировать эти ЭБУ, чтобы вместо их команд выполнялись вредоносные CAN-сообщения.
Заметим, что хотя речь тут идёт об автомобилях одного производителя и определённого поколения, эта ситуация совсем не редка в отрасли — это не проблема Chrysler, а системная проблема.
Случай 2: взлом Tesla в 2016 году
В 2016 году специалисты лаборатории безопасности Tencent Keen взломали Tesla Model S. Для атаки они проэксплуатировали сложную цепочку уязвимостей для компрометации компонентов сети автомобиля и внедрения вредоносных CAN-сообщений.
Цепочка атаки на Tesla Model S в 2016 году. Источник: Trend Micro
- Исследователи установили фальшивую точку доступа Tesla Guest, к которой автоматически подключаются все «Теслы» в соответствии со стандартом производителя.
- Используя уязвимости браузера Tesla, выполнили шелл-код, который повысил привилегии через уязвимость ядра Linux CVS-2013-6282. Это позволили отключить модуль безопасности ядра AppArmor.
- Используя повышенные привилегии, получили root-доступ к центральному инфодисплею «Теслы», а с него — к приборной панели, модулю Parrot, управляющему Bluetooth и Wi-Fi, а также к шлюзу шины CAN.
- Далее они модифицировали прошивку шлюза и заставили его отправлять вредоносные CAN-сообщения.
- Tesla Model S игнорирует некоторые сообщения CAN-шины, когда скорость выше установленного предела. Исследователи заблокировали трансляцию сообщений о скорости, подменив идентификатор соответствующего ЭБУ.
- Далее они внедрили собственную прошивку в один из ЭБУ, чтобы получить возможность выполнять операции прямого чтения/записи памяти.
- Используя эту возможность, они смогли перевести ЭБУ в специальный диагностический режим, который блокирует возможность приёма и ответа на CAN-сообщения.
- Таким образом им удалось отключить системы ESP, ABS, управление педалью акселератора и тормозной системой.
Случай 3: взлом Tesla в 2017 году
Через год после наглядной демонстрации уязвимостей в Tesla специалисты Tencent Keen проверили, насколько качественно компания Илона Маска провела работу над ошибками. Результатом стала очередная компрометация электромобиля.
Цепочка атаки на Tesla Model S в 2017 году. Источник: Trend Micro
Атака началась всё с той же фальшивой точки доступа Tesla Guest, к которой автомобиль доверчиво подключился. Далее исследователи снова воспользовались уязвимостью браузера на базе движка Webkit. И хотя уязвимость была другая, результат оказался тот же. Не помогло даже обновление ядра Linux, выполненное вендором: хакеры снова отключили AppArmor и получили root-доступ к CID.
После этого исследователи модифицировали прошивку, чтобы она игнорировала проверку ЭЦП Tesla, а затем взломали несколько «пасхалок», встроенных в оригинальную прошивку автомобиля. Несмотря на развлекательный характер «пасхалок» они имели доступ к различным ЭБУ, чем и воспользовались исследователи.
Случай 4: взлом BMW в 2018 году
Чтобы продемонстрировать, что проблемы с безопасностью существуют не только у Tesla, специалисты Tencent Keen провели разработали три варианта атак на автомобили BMW: локальную атаку через USB/OBD-II и две удалённые атаки.
Схема атаки на BMW в 2018 году. Источник: Trend Micro
Первая атака использовала удалённое выполнение кода в BMW ConnectedDrive (набор электронных опций автомобиля, представленный ещё в 2008 году), через перехват HTTP-трафика:
- поскольку сервис BMW ConnectedDrive в службе HU-Intel периодически опрашивает внутренние серверы BMW через 2G или 3G соединение телематического коммуникационного блока (TCB) по протоколу HTTP, исследователи установили фальшивую базовую станцию GSM и перехватили весь GPRS-трафик транспортного средства;
- исследуя перехваченный трафик, они нашли файл инициализации, загружаемый автомобилем, и выяснили его URL; поскольку автомобиль был подключён через подконтрольную хакерам базовую станцию GSM, они смогли подменить содержимое в файле инициализации и проэксплуатировать уязвимость в автомобильном браузере также на базе WebKit;
- в результате они получили веб-шелл, с помощью которого повысили привилегии и получили root-доступ к прошивке через чип HU-Jacinto, который обрабатывает все коммуникации шины CAN;
- итогом стала возможность использования функции CanTransmit_15E2F0 для отправки произвольных CAN-сообщений.
Второй вариант удалённой атаки более сложен и эксплуатирует уязвимости TCB через незащищённые SMS.
Выводы и рекомендации
Подключенные автомобили — лишь один из компонентов умной транспортной сети, которая представляет собой сложнейшую экосистему, содержащую миллионы взаимосвязей, конечных точек и пользователей. Эта экосистема состоит из четырёх основных компонентов:
- собственно подключенного автомобиля;
- сети передачи данных, которая обеспечивает взаимодействие подключенного автомобиля с бэкэндом;
- бэкэнда — серверов, баз данных и приложений, обеспечивающих взаимодействие всей умной транспортной инфраструктуры;
- центра управления безопасностью автомобилей (vehicle security center, VSOC), который собирает и анализирует уведомления, поступающие от остальных компонентов умной транспортной сети.
Сложность умной транспортной системы достигла такого уровня, что крайне сложно прогнозировать, в какую часть периметра будет направлена очередная атака. В связи с этим защита подключённых автомобилей не ограничивается софтом и электроникой транспортного средства. Необходимо также обеспечить безопасность бэкэнда и сети передачи данных.
Комбинированная архитектура подключённых автомобилей. Источник: Trend Micro
Для защиты автомобилей:
- использовать в сети автомобиля сетевую сегментацию, отделив критические узлы от «развлекательно-пользовательские». Это снижает риск бокового перемещения и повышает общую безопасность.
- воспользоваться рекомендациями отраслевой группы ISO и SAE. Разработанный участниками группы свод руководящих принципов обеспечения безопасности подключённых автомобилей — ISO/SAE 21434 содержит ряд предложений, внедрение которых позволит существенно изменить сложившуюся ситуацию.
- внедрить безопасность в качестве обязательной части всех процессов от создания концепции и разработки до производства, эксплуатации, технического обслуживания и вывода из эксплуатации. Для управления рисками следует использовать ISO 31000.
- в обязательном порядке проводить мониторинг рисков в соответствии со стандартом управления информационной безопасностью ISO/IEC 27001.
- внедрить управление исправлениями и обновлениями в соответствии с новым стандартом ISO/AWI 24089 «Транспортные средства — Инжиниринг обновления программного обеспечения»
Для защиты сети передачи данных:
- шифрование потока данных;
- обязательная аутентификация;
- ограничение доступа из публичного интернета к интеллектуальной транспортной сети.
Для защиты бэкенд-инфраструктуры:
- использовать брандмауэры для отслеживания вредоносного трафика и идентификации приложений или устройств, которые генерируют или запрашивают этот трафик;
- воспользоваться брандмауэрами следующего поколения (NGFWs)/ унифицированными шлюзами управления угрозами (UTM), которые могут включать в себя классические брандмауэры, системы предотвращения вторжений (IPS), системы обнаружения вторжений (IDS), антивирусное программное обеспечение, веб-фильтрацию, управление приложениями и другие решения, объединённые в одном устройстве;
- антивирусное программное обеспечение;
- антифишинговое ПО для фильтрации электронной почты сотрудников вендоров, обслуживающих бэкэнд-инфраструктуру, поскольку фишинг — один из основных векторов заражения;
- системы обнаружения взлома (BDS);
- IPS и IDS — системы сетевой безопасности, которые исследуют трафик для обнаружения и предотвращения сетевых атак.
Взлом Android пошагово: разблокируем загрузчик
Bootloader, Recovery, Root и ROM… Если вы не знаете, что скрывается за этими терминами Android, вам необходимо прочитать эту статью. В ней рассказывается обо всех инструментах взлома и хаках, применимых к системе Android.
Прежде чем начать взлом Android, надо понять, как он в целом работает, и лишь затем можно приступать к разблокировке загрузчика системы. Итак, попробуем разобраться.
Что происходит при включении и запуске Android?
Перед нами выключенный смартфон под управлением Android. Давайте разберемся, что произойдет, если его включить.
Сначала произойдет запуск BIOS мобильного телефона. ВIOS (Basic Input/Output System ) в переводе с английского означает «Базовая система ввода / вывода». Она постоянно автосохраняется и обеспечивает работу входов и выходов. В частности, эта система также запускает загрузчик (Bootloader).
Как явствует из названия, загрузчик загружает другие части операционной системы, например, ядро. Ядро операционной системы — это основная ее часть. По сути, это нижний уровень системы Android, который отвечает за ход основных процессов и организацию данных.
Затем запускается основная операционная система под названием «ПЗУ/ ROM». ROM означает «Read Only Memory», или «Постоянное запоминающее устройство», используемое для запоминания всего массива неизменяемых данных. Будучи обычным пользователем, вы ничего не можете в ней поменять.
Параллельно загрузчик запускает не только ядро, но и Recovery, или систему восстановления.
Если система Android вдруг оказывается повреждена, можно загрузить Recovery и из нее восстановить OS с нуля или с момента сохранения. Также в системе Recovery можно (и нужно) создавать резервные копии.
В свою очередь, загрузчик может находиться в трех разных состояниях: «Заблокировано», «Открыто» или «Зашифровано». Если загрузчик открыт, в систему могут быть внесены глубокие изменения, например, можно установить собственную операционную систему, также называемую «кастомной ПЗУ», вместо стандартной, то есть, «стоковой ПЗУ». Но и другие моменты, такие как изменение Recovery или получение root-прав на смартфон, можно проводить только с помощью открытого загрузчика.
Если загрузчик зашифрован, могут быть установлены лишь самые срочные обновления системы от изготовителя. То же самое относится и к заблокированному загрузчику, но, в отличие от зашифрованного, его можно разблокировать.
Как разблокировать загрузчик
Большинство смартфонов Android имеют так называемый режим fastboot. Это своего рода «расширенный загрузчик». С помощью этого режима обычный загрузчик можно разблокировать. Базовым инструментом для этого является «Android Debug Bridge», или ADB. Он ориентирован, в первую очередь, для разработчиков приложений под Android, но и обычным пользователям дает много возможностей.
Для начала вам нужны драйвера для смартфона. Их можно легко установить автоматически из Windows 7, просто подключив смартфон к ПК.
Также нужны драйвера ADB и Fastboot. Для этого загрузите из интернета установщик и запустите скачанный файл в режиме администратора. Обязательно установите драйвера для всей системы. Установщик спросит вас, действительно ли вы хотите это сделать.
После того, как вы совершили эти шаги, необходимо подключить устройство к ПК в режиме fastboot. У многих смартфонов есть для этого специальная комбинация клавиш. В качестве альтернативы, однако, вы также можете подключить включенный смартфон к ПК и ввести команду «adb reboot bootloader» в командной строке. Однако сначала вы должны включить «Отладку по USB» в настройках смартфона. Если необходимо, вы также должны включить функцию «Разрешить OEM-разблокировку».
Теперь вы можете легко разблокировать загрузчик командой «fastboot flashing unlock». Затем снова загрузитесь в режим fastboot и введите «fastboot flashing unlock_critical», чтобы окончательно разблокировать загрузчик. Таким образом вы можете свести к минимуму риск того, что ваш смартфон превратится в «кирпич» при установке новой прошивки.
В качестве альтернативы на некоторых смартфонах разблокировка может быть выполнена с помощью команды «fastboot oem unlock».
Однако бывают исключения. Например, смартфоны Samsung не имеют реального режима fastboot. Вместо этого есть режим загрузки. Чтобы разблокировать загрузчик, необходимо использовать программу Odin, которая может устанавливать файлы, умеющие это делать. Для получения root-прав или установки кастомного ROM или Recovery на устройства Samsung это не обязательно.
Еще одно исключение составляют смартфоны от Sony. Перед тем, как взломать смартфон, вам сначала сначала придется зарегистрировать устройство на странице разработчика, введя IMEI и свой e-mail, чтобы получить специальный код разблокировки.
О том, как инсталлировать кастомную систему восстановления данных, читайте в следующем материале.