Изображение : этник , CC BY-NC-ND 2.0
Использование смартфонов в повседневной жизни не ограничивается голосовыми звонками и SMS. Возможность скачивать и запускать программы, а также мобильный доступ в Интернет привели к появлению огромного количества мобильных приложений.
Функционал современного смартфона состоит из браузеров, клиентских программ социальных сетей, офисных приложений и всевозможных сервисов, работающих в сети Интернет. Устройства Android заняли большую часть рынка смартфонов благодаря открытой архитектуре платформы Android и удобному API для разработчиков.
В настоящее время Android является самой популярной мобильной ОС с долей рынка более 75%.
Количество приложений, скачанных из магазина Google Play в 2016 году, составило 65 миллиардов.
[1] .
При этом наблюдается стремительный рост количества вредоносных приложений: в 2015 году их было обнаружено 2,3 млн.
[3] .
Кроме того, около 60% Android-устройств работают под управлением версий ОС с известными уязвимостями и потенциально могут быть атакованы злоумышленниками.
[6] .
Эти угрозы, в свою очередь, привели к развитию оборонительных сил.
В официальном магазине Google Play появилась фильтрация приложений с помощью песочницы Google Bouncer. Антивирусные компании начали выпускать свои продукты для Android (хотя, как показано на [8] , многие из них сами содержат опасные уязвимости).
Увеличилось и количество научных публикаций на эту тему: одна из обзорных статей 2015 года по решениям безопасности для Android [2] содержит более 40 проектов и не упоминает все известные на данный момент исследования.
В связи с тем, что мобильные устройства являются источником и хранилищем большого количества конфиденциальных данных, проблема безопасности ОС Android и ее приложений стоит особенно остро.
Платформа Android является свободным программным обеспечением, а ее исходный код полностью открыт. Производители устройств самостоятельно разрабатывают кодовую базу, создавая специализированные прошивки с целью достижения большей функциональности и лучшей производительности.
Побочным продуктом этой деятельности являются уязвимости и недостатки в реализации алгоритмов, которых нет в основной кодовой базе, но существуют на многих реальных устройствах.
Вредоносное ПО использует эти уязвимости для повышения привилегий и обхода механизмов защиты.
Выявить уязвимости в прошивках при отсутствии исходных кодов крайне сложно.
Основной проблемой является отсутствие контролируемой среды выполнения, необходимой для проведения динамического анализа.
Таким образом, полноценный анализ безопасности устройства требует совместного изучения свойств системного и прикладного программного обеспечения.
В данной статье представлена собственная классификация проблем безопасности Android, а также список требований к системе для полносистемного анализа платформы Android.
1. Устройство с ОС Android
ОС Android основана на ядре Linux с некоторыми архитектурными изменениями, внесенными инженерами Google. Приложения для операционной системы Android разрабатываются на языке Java. Начиная с Android 1.5 был представлен Android NDK, который позволяет разрабатывать модули приложений на C и C++ и компилировать их в машинный код. [4] .Приложения поставляются в виде файлов специального формата APK, который представляет собой ZIP-архив с определенной директорией и структурой файлов.
APK-файл приложения содержит:
- манифест;
- модули, скомпилированные в машинный код (общие библиотеки .
so);
- различные ресурсы приложения;
- DEX-файл;
- другие необходимые файлы.
Также при разработке Dalvik были учтены ограничения памяти в мобильных устройствах.
Начиная с Android 2.2, среда выполнения Dalvik включает JIT-компилятор, который компилирует «горячие» фрагменты Java-программ в машинный код. [5] .
Стандартные библиотеки Java были либо заменены модифицированными библиотеками из пакета Apache Harmony, либо написаны заново.
При компиляции программы Java создается файл DEX (исполняемый файл Dalvik), содержащий байт-код для виртуальной машины Dalvik. Формат файла был разработан для уменьшения объема памяти и существенно отличается от стандартного формата JAR. Для вызова модулей, реализованных в собственном коде, из Java-программ используется интерфейс JNI. Стоит отметить, что возможна динамическая загрузка модулей машины по сети с помощью компонента DexClassLoader.
2. Проблемы безопасности
Родительским процессом всех приложений Android является процесс Zygote. Этот процесс представляет собой скелет Android-приложения, в котором уже загружены все необходимые библиотеки среды Android, но отсутствует код самого приложения.Запуск Android-приложения с точки зрения операционной системы происходит следующим образом:
- Сначала выполняется системный вызов fork для создания дочернего процесса Zygote (см.
рисунок 1).
- В этом новом процессе открывается запускаемый файл приложения (системный вызов open).
- Информация о файлах классов (classes.dex) и ресурсах считывается из файла приложения.
Сокеты открыты для IPC.
- Системный вызов mmap предназначен для отображения файлов приложения в памяти.
- Среда выполнения настраивает необходимую среду и выполняет приложение (интерпретирует байт-код Dalvik или передает управление функциям в исполняемом коде в случае ART).
[7] ).
Таким образом, каждая программа работает в своей песочнице.
Начиная с версии 4.3, помимо этой политики безопасности, было добавлено использование компонента обязательного контроля доступа SELinux. [10] .
Рис.
1. Запуск нового приложения в ОС Android По умолчанию приложение ограничено в своих возможностях и не может сделать ничего, что могло бы негативно повлиять на другое приложение или пользователя: ни читать пользовательские данные, ни изменять системные приложения; нет доступа к сети.
Для получения доступа к различным ресурсам приложение обращается к сервисам ОС Android. Разрешения на доступ устанавливаются статически в файле манифеста приложения и предоставляются приложению во время выполнения по мере необходимости.
Система запрашивает у пользователя согласие на предоставление этих разрешений во время установки или при обновлении приложения.
Ответственность за предоставление доступа к приложению лежит на пользователе; он самостоятельно решает, какому приложению давать разрешения на те или иные действия, а какому не давать - во время его установки.
Использование такого подхода, при котором все разрешения выдаются сразу при установке приложения, привело к тому, что пользователи стали назначать разрешения приложениям, не задумываясь о последствиях.
В свою очередь, приложения стали запрашивать все больше разрешений по мере расширения их функционала.
В Android 6 Marshmallow эта система заменена другой: приложение во время работы запрашивает у пользователя доступ к ресурсам, и пользователь может либо разрешить доступ, либо запретить его.
[11] .
Приложение Android состоит из четырех типов компонентов и не содержит функции main() или какой-либо другой единой точки входа.
Компоненты приложения взаимодействуют друг с другом с помощью специальных сообщений, называемых намерениями.
Компоненты, называемые Activity, определяют пользовательский интерфейс.
Обычно один компонент Activity используется для описания одного экрана приложения.
Действие может запустить другое действие, передав параметры с помощью механизма Intent. Во время работы может работать и обрабатывать ввод пользователя только один Activity; остальные в это время остаются замороженными или уничтожены, в зависимости от выбранного режима работы приложения.
Компоненты, называемые Сервисом [9] выполнить фоновую обработку.
Когда Activity необходимо выполнить какую-то операцию, например, скачать файл или воспроизвести музыку, и продолжить работу, когда пользователь перешел в другое приложение или свернул текущее, приложение запускает службу, целью которой является выполнение этой операции.
Разработчики могут использовать Сервис как приложение-демон, которое запускается во время загрузки системы.
Компонент Служба обычно поддерживает RPC (удаленный вызов процедур), поэтому другие компоненты системы могут получить к нему доступ.
Компонент «Поставщик контента» хранит данные и обменивается ими, используя интерфейс реляционной базы данных.
Каждый Контент-провайдер содержит уникальный URI для данных и обрабатывает запросы к ним в виде SQL-очередей (Выбрать, Вставить, Удалить).
Компоненты приемника широковещательной рассылки действуют как почтовые ящики для сообщений из других приложений.
Проблемы безопасности, возникающие в ОС Android, обсуждались в [ 2 , 12 , 13 ], но классификация проблем по категориям приведена только в статье [2] .
Эта классификация достаточно подробная и охватывает многие вопросы безопасности, однако имеет ряд существенных недостатков: некоторые категории охватывают широкую область уязвимостей, тогда как другие достаточно специализированы; вышеперечисленные категории уязвимостей никак не коррелируют с программными уровнями архитектуры ОС Android; не охвачены уязвимости из Интернет-источников, а также слабо охвачены уязвимости в протоколах и аппаратном обеспечении (п.
2.7 и 2.8 нашей классификации).
Предложенная ниже классификация уязвимостей устраняет эти недостатки.
2.1. Уязвимости ядра Linux и его модулей
К этой категории проблем относятся уязвимости, присущие всем операционным системам, основанным на той же версии ядра Linux, что и ОС Android. «Эксплойты, использующие уязвимости ядра, могут получить данные пользователя или права системного администратора.Повышая привилегии процесса до прав системного администратора, вредоносное ПО может отключать безопасность Android, вставлять вредоносный код в существующие программы и устанавливать руткит. Кроме того, производители различных устройств добавляют в ядро для своих устройств модули; Эти модули также могут иметь уязвимости.
Примеры уязвимостей повышения привилегий описаны в [ 14 , 15 , 16 , 64 ].
Также стоит отметить, что недавно была обнаружена уязвимость в компоненте ashmem для межпроцессного взаимодействия в Android. [62] .
2.2. Уязвимости модификаций и компонентов производителей устройств
В последнее время производители различных мобильных устройств начали выпускать свои модифицированные прошивки Android. Эти прошивки могут содержать различные приложения и сервисы, разработанные производителем устройства, которые чаще всего невозможно удалить.Например, в октябре 2016 года в прошивке Foxconn был обнаружен скрытый бэкдор.
[63] .
Анализ этих сервисов приведен в статьях.
[17] , показывает, что они содержат от 65 до 85% уязвимостей, обнаруженных во всей системе.
Кроме того, стоит отметить, что уязвимости, которые были обнаружены и исправлены в основной ветке Android, могут долгое время оставаться в ветках производителей устройств[ 18 , 19 ].
2.3. Уязвимости модулей в машинных кодах
Приложения Android поддерживают запуск собственного кода через интерфейс JNI. Это порождает еще одну категорию уязвимостей, связанных с известными уязвимостями утечки памяти в языках низкого уровня (например, C и C++).[20] .
Поскольку на уровне процессов ОС Android нет никаких ограничений, кроме тех, которые налагаются ядром Linux, сторонние библиотеки в нативном коде могут использовать разрешения, предоставленные всему приложению, для выполнения вредоносной активности (см.
также следующую категорию уязвимостей, раздел 2.4).
Кроме того, модули приложений в нативном коде используются авторами вредоносных приложений для обхода инструментов анализа и мониторинга на уровне Android. Эти модули также могут использовать методы антианализа, используемые в обычных программах.
2.4. Уязвимости механизмов межкомпонентного взаимодействия
В эту категорию входят уязвимости, связанные с взаимодействием различных компонентов приложения.Поскольку приложение изолировано на уровне операционной системы, ему необходим механизм доступа к компонентам ОС Android для взаимодействия с ними.
Это происходит через устройство /dev/Binder и различные другие службы ОС Android. Как упоминалось выше, параметры этого доступа задаются в файле манифеста в виде XML-файла с разрешениями.
Анализ, приведенный в статьях [ 12 , 21 , 22 , 23 , 24 , 25 ], указывает на недостатки данной системы ограничений и показывает пути их обхода.
Например, приложение может воспользоваться правами доступа другого приложения и использовать его для получения данных через ICC. Также могут быть уязвимости, связанные со сторонними библиотеками.
На сторонние библиотеки, используемые в приложении, распространяется тот же набор ограничений, что и на само приложение.
Таким образом, сторонние библиотеки могут использовать разрешения, предоставленные всему приложению, для выполнения вредоносной деятельности.
Приложения также могут перехватывать системные события, отправленные посредством широковещательного запроса, и хранить информацию о входящих звонках и SMS.
2.5. Уязвимости в самих приложениях
Каждое приложение хранит некоторые данные о пользователе.Эти данные должны быть должным образом защищены, чтобы другие приложения не могли получить к ним доступ – но такая защита не всегда обеспечивается.
Например, Skype в одной из версий приложения сохранил базу контактов в открытом виде на диске.
Таким образом, контакты могут быть прочитаны любым другим приложением, имеющим доступ к диску.
[26] .
Приложения также могут использовать криптографические библиотеки с ошибками.
[27] или некоторые собственные реализации.
Кроме того, не все приложения обеспечивают хорошую аутентификацию и авторизацию пользователей.
Кроме того, приложения могут допускать SQL-инъекцию и подвержены XSS-атакам.
Также стоит отметить, что большинство разрабатываемых приложений пишутся на Java без какой-либо защиты двоичного кода, а байт-код Java, как известно, легко дизассемблируется и анализируется.
Стоит отметить, что известный список Mobile OWASP-10 также относится к этой категории уязвимостей.
Многие подобные уязвимости описаны в [ 28 , 29 ].
2.6. Уязвимости во встроенных сервисах и библиотеках
Стандартный набор библиотек и сервисов, работающих на Android, также содержит уязвимости.Например, недавно в библиотеке отображения видео в MMS-сообщениях была обнаружена уязвимость Stagefright, которая затронула все версии Android, начиная с 2.2. [30] .
Позже была обнаружена уязвимость в компоненте MediaServer, которая затрагивает все версии Android от 2.3 до 5.1. [31] .
В статье [13] Показаны рантайм-уязвимости Dalvik: запустив большое количество процессов в системе, можно гарантировать, что последующий процесс запустится с правами администратора.
2.7. Интернет-источники
Приложения для Android распространяются через множество источников, помимо официального магазина приложений.Поскольку приложения Android написаны в основном на Java, их можно легко реконструировать и переупаковать с использованием вредоносного кода.
Более того, как было показано в статье [34] , песочницу анализа приложений Bouncer, используемую в официальном каталоге, легко обойти.
Поэтому сам официальный магазин содержит большое количество вредоносных программ.
Кроме того, Android поддерживает удаленную установку приложений через Google Play на устройствах, привязанных к учетной записи Google. Таким образом, если вы взломаете аккаунт Google на устройстве, вы сможете установить вредоносное приложение из Google Play, которое ранее скачал туда злоумышленник.
Однако подтверждения этих действий на экране мобильного телефона не требуется, так как они запрашиваются в окне браузера и приложение устанавливается на телефон в фоновом режиме при выходе в Интернет. Также в эту категорию уязвимостей входит использование социальной инженерии, когда для продолжения работы предлагают установить приложение из неавторизованного источника.
[35] .
2.8. Уязвимости аппаратного обеспечения и связанных с ним модулей и протоколов
Мобильные устройства под управлением ОС Android имеют широкий спектр оборудования для взаимодействия с внешним миром.Соответствующие уязвимости могут быть использованы в непосредственной близости от устройства или при наличии физического доступа к устройству.
Примеры таких атак включают атаку типа «отказ в обслуживании» на технологию Wi-Fi Direct. [36] , кража данных кредитной карты с использованием NFC [37] , удаленное выполнение кода через Bluetooth [38] , установка вредоносного приложения без ведома пользователя через adb с использованием механизма резервного копирования [39] .
В ходе выполнения [13] показаны уязвимости, которые можно использовать для повышения привилегий приложения с помощью ошибок в реализации протокола adb.
3. Инструменты для анализа Android-приложений
С момента выпуска первых телефонов Android было написано большое количество инструментов для анализа приложений Android. Наиболее полный обзор этих инструментов содержится в статьях [ 40 , 41 , 42 , 2 ].В первых трёх источниках инструменты классифицируются по видам анализа: статические, динамические и их комбинированные (смешанные).
В статье [2] используется классификация инструментов по этапам развертывания приложения на Android-устройстве.
В нашей работе мы используем классификацию по видам анализа.
Статический анализ
Инструменты статического анализа можно разделить на следующие категории:- Инструменты, которые извлекают метаинформацию из манифеста приложения и предоставляют информацию о запрошенных разрешениях, компонентах действий, службах и зарегистрированных получателях широковещательных рассылок.
Метаинформация часто используется позже в динамическом анализе для управления функциональностью приложения.
- Инструменты для изменения существующего байт-кода приложения с использованием методов инструментирования.
Это позволяет, например, добавить функциональность трассировки в существующие приложения.
- Инструменты, реализующие декомпилятор или дизассемблер байт-кода Dalvik.
Он имеет возможности декодирования ресурсов приложения примерно до исходного вида, переупаковки приложений обратно в файлы APK/JAR, отладки байт-кода smali. Для декомпиляции и компиляции байт-кода Dalvik в apktool используется другой известный проект smali/backsmali. [44] .
Инструмент Dedexer также часто используется для дизассемблирования байт-кода Dalvik. [45] .
Радаре2 [46] — это инструмент с открытым исходным кодом для дизассемблирования, анализа, отладки и изменения двоичных файлов приложений Android. Одним из наиболее универсальных инструментов статического анализа является Androguard. [47] .
Он может дизассемблировать и декомпилировать приложение обратно в исходный код Java. Учитывая два APK-файла, он может рассчитать их коэффициент сходства для обнаружения переупакованных приложений или известных вредоносных приложений.
Благодаря своей гибкости он используется в нескольких инструментах смешанного анализа.
Более полный список инструментов статического анализа можно найти в статьях, ссылки на которые приведены выше.
Следует отметить, что статический анализ имеет ряд существенных ограничений из-за того, что существует лишь абстрактное представление о программе.
Например, статический анализ становится намного сложнее, если к программе применяются запутывающие преобразования.
В зависимости от сложности обфускации некоторые (или, возможно, все) статические подходы могут стать совершенно бесполезными.
Если каждый метод вызывается только косвенно, построить граф вызовов программы вряд ли получится.
В Android это преобразование можно выполнить с помощью Java Reflection API для вызова методов и создания объектов вместо использования обычных вызовов и операторов создания новых объектов.
Рынок решений для защиты исходного кода уже предлагает несколько продуктов для обфускации файлов приложений Android, которые могут свести на нет все преимущества статического анализа.
Подробнее о методах противодействия статическому анализу можно прочитать в 50 .
Инструменты динамического и смешанного анализа
Инструменты динамического анализа отслеживают поведение неизвестного приложения во время его запуска в контролируемой песочнице, чтобы получить поведенческую трассировку.
Для этого песочница на разных уровнях архитектуры оснащается участками кода, которые следят за поведением приложения и ОС Android. 
Рис.
2. Уровни архитектуры песочницы Android Архитектура песочницы Android состоит из эмулятора Android (чаще всего QEMU), в котором работает ОС Android. Инструментирование выполняется либо на уровне эмулятора, либо на уровне ОС Android, либо на том и другом.
Уровень ОС Android также разделен на четыре подслоя:
- Приложения,
- среда разработки приложений,
- рабочая среда приложения и библиотеки,
- ядро и его модули.
- Отслеживание помеченных данных.
Такие инструменты используются для отслеживания потенциальных утечек конфиденциальной информации.
- Мониторинг системных вызовов.
Инструменты могут записывать системные вызовы с использованием инструментов виртуальной машины, strace или модуля ядра.
Это позволяет отслеживать машинный код.
- Методы (функции) трассировки.
Эти инструменты могут отслеживать вызовы методов Java приложения на виртуальной машине Dalvik, вызовы собственных функций через JNI, системные вызовы и прерывания.
4. Идеальная система полного системного анализа для платформы Android.
Статьи [ 40 , 41 , 42 , 2 ] имеют более 40 различных инструментов как для анализа Android-приложений, так и для анализа ОС Android в целом.Как отмечается в статьях [ 34 , 60 , 61 ], существующие средства динамического анализа имеют ряд серьезных недостатков.
Эти недостатки присущи и стандартному инструменту анализа приложений в магазине Google Play — Google Bouncer, в результате чего вредоносные приложения могут распространяться по официальному магазину, не будучи обнаруженными.
Сравнение возможностей подходов и систем в рассмотренных публикациях позволяет сформулировать требования к идеальной системе анализа платформы Android, способной анализировать приложения и все уровни системного ПО в совокупности.
Система заимствует некоторые эффективные приемы из рассмотренных работ, объединяя их для преодоления недостатков существующих решений.
Архитектура системы представлена на рис.
3. Основным компонентом является полносистемный эмулятор, способный загружать как прошивки ОС Android с реальных устройств, так и официальный образ Android для эмулятора.
Симулятор поддерживает пересылку датчиков с реального устройства, а также выполнение отдельных участков кода на реальных устройствах.
Внутри эмулятора имеются модули, обеспечивающие:
- поддержка смешанного исполнения,
- отслеживание приложений,
- анализ размеченных данных,
- анализ межкомпонентного взаимодействия,
- объединение машинного и Java-кода приложения,
- взаимодействие с реальным оборудованием.
1. Поддержка загрузки прошивок от различных производителей устройств.
Существенным недостатком всех существующих инструментов анализа ОС Android и ее приложений является невозможность запуска прошивок от производителей устройств в доступных эмуляторах.
Как было показано в пункте 2.2, модифицированные прошивки от производителей устройств содержат от 65 до 85% уязвимостей, обнаруженных во всей системе.
На данный момент нет инструментов анализа, позволяющих запускать прошивки от производителей.
Все существующие решения работают на специальной сборке Android для виртуальной платформы GoldFish.
2. Возможность выполнения отдельных фрагментов машинного кода на реальном устройстве.
По информации из статей [ 34 , 61 ], существуют способы обнаружения работы внутри эмулятора.
Как правило, детектируется выполнение в эмуляторе QEMU в режиме бинарной трансляции, поскольку на этом основано большинство песочниц.
Методы основаны на различном поведении определенных участков машинного кода в эмуляторе и на реальном устройстве.
Поскольку изменить механизм двоичной трансляции сложно, выполнение отдельных фрагментов машинного кода на реальном устройстве будет хорошим подходом для противодействия этим методам обнаружения эмулятора.
3. Пересылка данных с датчиков реального устройства в эмулятор.
Как описано в статьях [ 34 , 61 ], существуют способы определения эмулятора на основе данных, полученных от датчиков оборудования, таких как акселерометр, гироскоп, GPS, датчик освещенности, гравитации.
Выходные значения этих датчиков основаны на информации, полученной из окружающей среды, и, следовательно, их реалистичная имитация является сложной задачей.
Наличие такого рода датчиков является основным отличием смартфонов от настольных компьютеров.
Увеличение количества датчиков на смартфонах открывает новые возможности для идентификации мобильных устройств.
4. Совместный анализ на уровне Java-кода и машинного кода.
Проблема для многих систем анализа приложений Android заключается в том, что приложения содержат как модули байт-кода Dalvik, так и модули собственного кода.
Из существующих решений поддержка анализа всех модулей реализована только в DroidScope. [57] и КопперДроид [ 58 , 59 ].
Идеальная система анализа должна иметь возможность отслеживать данные и управлять потоками на уровне пользовательского и системного кода.
Для пользовательского кода, когда это возможно, вам следует повысить уровень представления до кода Java, который является языком разработки высокого уровня.
Также необходимо обеспечить «склеивание» потоков данных и управления при переходе от машинного кода к Java и наоборот.
5. Поддержка анализа межкомпонентного взаимодействия.
В статье о CopperDroid [58] показана реализация для поддержки анализа межкомпонентных связей как внутри приложения Android, так и между различными приложениями.
Это делается путем перехвата данных, проходящих через основной компонент Binder, поскольку весь обмен данными проходит через него.
Подход, реализованный в CopperDroid, позволяет избежать модификации исходного кода Android, что дает возможность портировать его на новые версии ОС Android и новую среду запуска ART-приложений с минимальными изменениями.
6. Защита от статических эвристик обнаружения
Как показано в статьях [ [57] , 61 ], большинство «песочниц» анализа можно обнаружить, просто проверив IMEI, IMSI или номер сборки прошивки устройства.Эмулятор также можно обнаружить, проверив таблицу маршрутизации на наличие стандартных значений.
Из существующих решений защита от обнаружения с помощью статической эвристики реализована только в проекте ApkAnalyzer. [65] .
7. Минимальные изменения в прошивке Android
Также стоит отметить, что многие решения динамического анализа основаны на инструментировании кода различных компонентов ОС Android, в частности виртуальной машины Dalvik. Это усложняет их дальнейшую поддержку, а также миграцию в новую среду запуска приложений ART. Многие песочницы ограничиваются только анализом кода компонентов Java, в то время как все больше и больше приложений используют собственные компоненты.
8. Поддерживает полносистемный анализ помеченных данных с отслеживанием потока управления.
Стоит отметить, что многие инструменты динамического анализа используют анализ помеченных данных с помощью инструмента TaintDroid. [56] .
В статье [60] показаны успешные способы обхода анализа этого инструмента.
Причиной успеха этих атак являются следующие факты: 1) TaintDroid отслеживает только потоки данных и не отслеживает потоки управления, 2) TaintDroid отслеживает потоки данных только на уровне виртуальной машины Dalvik и проходящие через интерфейс JNI. Возможные пути устранения этих недостатков описаны в [60] и дать направление для дальнейших исследований.
9. Поддержка символьного исполнения и частичного исполнения с конкретными значениями с использованием данных, полученных в результате статического анализа кода (конколическое исполнение – смешанное исполнение).
В статье [51] Описана среда анализа, реализующая данный подход. Эта среда сочетает в себе методы статического анализа графа потока управления.
Теги: #Android #мобильные приложения #информационная безопасность #уязвимости #информационная безопасность #разработка Android
-
Phdays Vii: Хроники Противостояния
19 Oct, 24 -
Первая В Мире Видеоигра
19 Oct, 24
