🟨 Мобильные приложения стали неотъемлемой частью не только повседневной жизни, но и корпоративных, финансовых и правовых процессов. В рамках судебных разбирательств всё чаще фигурируют данные, полученные с мобильных устройств: логи переписки, финансовые транзакции, геолокационные метки, история посещений и даже биометрические шаблоны. Однако высокая ценность этих данных порождает и обратную сторону медали — попытки их фальсификации путём модификации самого приложения, которое эти данные генерирует и хранит. Взлом клиентской части, внедрение вредоносного кода, подмена серверных ответов, перекомпиляция с изменённой логикой — всё это создаёт иллюзию достоверности, которая рушится при профессиональном IT-анализе. Судебная экспертиза следов изменения мобильного приложения призвана не просто констатировать факт вмешательства, а восстановить полную картину: какие именно файлы были изменены, в какой последовательности, с использованием каких инструментов, и могли ли эти изменения повлиять на доказательственную ценность полученных данных.

🧩 Раздел 1: Архитектура мобильного приложения как объект экспертного исследования

• Мобильное приложение — это сложная программная система, состоящая из исполняемого кода (собранного в бинарные файлы для Android — DEX/APK, для iOS — Mach-O), ресурсов (изображения, строки, макеты интерфейса), нативных библиотек (для высокопроизводительных вычислений), а также конфигурационных файлов и баз данных SQLite, которые хранят локальные данные пользователя. Каждый из этих компонентов может быть модифицирован как законными способами (обновления через официальные магазины), так и незаконными (репаккинг, патчинг, инжекция кода). Экспертное исследование начинается с получения эталонной версии приложения из официального источника (Google Play, App Store) и сравнительного анализа с бинарным файлом, обнаруженным на устройстве. Любое расхождение в размере, контрольной сумме, структуре секций или цифровой подписи является первым сигналом для углублённого анализа.

🛠️ Раздел 2: Виды модификаций и типовые сценарии вмешательства

• В судебной практике выделяются четыре основные категории изменений, которые могут быть внесены в мобильное приложение. Первая категория — модификация сетевого уровня: перехват и подмена ответов от сервера (MITM-атаки с использованием поддельных сертификатов), а также редактирование запросов для изменения отправляемых данных. Вторая категория — изменение локальной логики: патчинг условий (например, отключение проверки лицензии или блокировка рекламы), изменение алгоритмов расчёта (например, в финансовых приложениях), подмена идентификаторов устройств (IMEI, Android ID). Третья категория — модификация хранимых данных: прямое редактирование SQLite-баз, файлов SharedPreferences или KeyStore для изменения баланса, статуса транзакций или истории действий. Четвёртая, наиболее сложная для выявления категория — внедрение динамического кода, который загружается удалённо (через DexClassLoader или JavaScriptCore) и выполняется с повышенными привилегиями, не оставляя явных следов в основном APK-файле. Каждая категория требует особых методов детекции и специфического инструментария.

🔐 Раздел 3: Проверка цифровой подписи как первичный барьер целостности

• Все официальные мобильные приложения для Android подписываются закрытым ключом разработчика. Если файл APK был перепакован или изменён, цифровая подпись становится невалидной, если только злоумышленник не имеет доступа к оригинальному ключу (что случается крайне редко и является уже вопросом компрометации инфраструктуры). Эксперт извлекает сертификат подписи из спорного APK и сравнивает его с сертификатом из официального источника — проверяются серийный номер, отпечатки SHA-1/SHA-256, срок действия и имя владельца. Даже если подпись формально проходит верификацию (то есть APK не повреждён), но сертификат отличается от эталонного, это прямое доказательство того, что приложение было переподписано другим лицом, что практически всегда свидетельствует о нелегальной модификации. Для iOS аналогичная процедура проводится с проверкой профилей подготовки (provisioning profiles) и entitlement-файлов.

📊 Раздел 4: Сравнительный анализ бинарного кода и дизассемблирование

После того как установлен факт несовпадения сигнатур, наступает этап глубинного анализа кода. Исходный код мобильных приложений, написанных на Java/Kotlin или Swift/Objective-C, преобразуется в байт-код или машинный код. С помощью дизассемблеров (например, JD-GUI, jadx для Android или Hopper, IDA Pro для iOS) эксперт восстанавливает псевдокод и сравнивает его с эталонной версией, полученной из официального репозитория или дизассемблированной из эталонного APK. Ищутся вставленные блоки кода, изменённые условные переходы, добавленные или удалённые вызовы методов. Особое внимание уделяется классам, отвечающим за криптографию, аутентификацию и обработку финансовых операций. Если обнаруживается, что проверка сертификата или валидация входных данных была закомментирована или заменена на всегда истинное условие, это неопровержимо указывает на модификацию с целью обхода защиты.

🧬 Раздел 5: Анализ нативных библиотек и фреймворков уровня ядра

Многие приложения используют нативные библиотеки (файлы .so в Android или .dylib в iOS), написанные на C/C++ для критичных по производительности задач (например, шифрование, работа с камерой). Модификации на этом уровне особенно опасны, поскольку они сложнее для обнаружения и анализа. Эксперт применяет инструменты статического анализа ELF/Mach-O файлов, сравнивает таблицы импорта и экспорта, а также выполняет динамическую трассировку системных вызовов. Если в библиотеке обнаружены нестандартные функции, не встречающиеся в эталонной версии, или изменены константы криптографических ключей, это может указывать на внедрение шпионского модуля или обход механизмов лицензирования. Союз «Федерация судебных экспертов» использует специализированные плагины для выявления аномалий в потоке управления (control flow graph), которые могут возникать только в результате ручного редактирования ассемблерного кода.

🌐 Раздел 6: Исследование сетевого трафика и перехват коммуникаций

Одним из самых распространённых способов фальсификации является вмешательство в сетевое взаимодействие клиента и сервера. Эксперт восстанавливает историю сетевых сессий из логов операционной системы, файлов кэша прокси и дампов трафика (pcap-файлы), если они были сохранены. Проверяется, использовались ли публичные корневые сертификаты для подмены TLS-сессии (например, через инструменты типа Fiddler или Burp Suite). Если в цепочке сертификатов обнаруживается самоподписанный или недоверенный сертификат, это является прямым признаком MITM-атаки. Кроме того, анализируется структура JSON/XML-запросов: если они содержат поля, которые не генерируются клиентом официальной версии, или имеют нестандартные временные метки, это указывает на использование модифицированного клиента или даже полностью эмулированного API-клиента без графического интерфейса.

🔍 Раздел 7: Динамический анализ времени выполнения (runtime) и трассировка вызовов

В отличие от статического анализа, который изучает код «на покое», динамический анализ запускает приложение в изолированной среде (эмуляторе или отладочном режиме на реальном устройстве) и отслеживает его поведение в реальном времени. Используются инструменты системного уровня (Frida, Xposed, Substrate для Android; Frida и Cycript для iOS), которые позволяют перехватывать вызовы функций, читать и изменять память процессов, а также логировать все обращения к файловой системе, сети и датчикам устройства. Если в процессе выполнения обнаруживаются попытки обращения к запрещённым API (например, чтение чужих SMS или списка контактов без разрешения), или модификация переменных в памяти в обход штатной логики, это фиксируется в отчёте. Динамический анализ особенно эффективен для выявления изменений, которые активируются только при определённых условиях (например, только после успешного входа в систему).

💾 Раздел 8: Исследование локальных баз данных и файлов конфигурации

Многие мобильные приложения хранят критически важные данные локально — в SQLite-базах, файлах SharedPreferences (Android) или UserDefaults (iOS), а также в защищённых контейнерах KeyChain/KeyStore. Эксперт создаёт дамп этих хранилищ и сравнивает их с тем, что должно быть сгенерировано эталонной версией приложения при аналогичной пользовательской активности. Ищутся записи, которые не могли быть созданы штатными средствами (например, баланс с дробными копейками, которые не генерируются серверной арифметикой), или записи с временными метками из будущего. Кроме того, проверяется целостность самих файлов баз данных — наличие нестандартных триггеров, индексов или представлений, которые могли быть внедрены для автоматического обновления данных при каждом запуске. Если в логах SQLite обнаруживаются следы ручного выполнения запросов через оболочку (shell), это указывает на прямое вмешательство в хранилище.

🔄 Раздел 9: Восстановление хронологии модификаций на основе временных меток файловых систем

Файловые системы мобильных устройств (ext4, F2FS, APFS) сохраняют метаданные о каждом файле: время создания, время последней модификации, время последнего доступа. Хотя эти метки могут быть изменены злоумышленником с помощью специальных утилит, опытный эксперт способен выявить аномалии, указывающие на подделку: например, если все файлы приложения имеют метки времени, совпадающие с точностью до секунды, тогда как при нормальной установке они различаются на минуты или часы. Также анализируются журналы установки пакетов (PackageManager logs в Android, установочные журналы в iOS), которые содержат точную дату и время инсталляции каждой версии. Сопоставляя эти данные с датами, указанными в спорных доказательствах (например, временем совершения транзакции), можно установить, была ли установлена модифицированная версия до или после события.

🧠 Раздел 10: Выявление следов использования отладочных и рут-инструментов

Для модификации приложений злоумышленники часто используют рутированные (взломанные) устройства или отладочные режимы. Эксперт проверяет системные логи на наличие записей о подключении через ADB (Android Debug Bridge) или SSH, а также анализирует установленные пакеты — если на устройстве обнаружены такие программы, как Magisk, SuperSU, Substrate или Cydia, это создаёт презумпцию возможности несанкционированных изменений. Однако само по себе наличие рута не является доказательством модификации именно этого приложения, поэтому эксперт ищет корреляцию: совпадают ли времена активации рут-доступа с временем изменения ключевых файлов приложения. В iOS проверяется наличие джейлбрейка, наличие неофициальных репозиториев и установленных твиков, которые могут перехватывать системные вызовы.

📈 Раздел 11: Криптографический анализ ключей и алгоритмов

Многие финансовые и корпоративные приложения используют симметричное или асимметричное шифрование для защиты данных. Если злоумышленник изменяет приложение, он часто вынужден либо извлекать ключи из памяти, либо подменять их на свои. Эксперт проводит анализ криптографических операций на этапе выполнения — извлекает сессионные ключи, проверяет их соответствие сертификатам, подписывающим серверные ответы. Если обнаруживается, что приложение принимает ответы, подписанные неизвестным сертификатом, или использует ключ, не соответствующий официальному дистрибутиву, это доказывает факт модификации логики проверки подписи. Особое внимание уделяется статически вшитым ключам: если они изменены в бинарнике, это легко выявляется сравнением шестнадцатеричных дампов.

📊 Раздел 12: Сравнительный анализ поведения с эталонной версией на идентичных входных данных

Для проверки изменений в алгоритмах обработки данных эксперты проводят параллельное тестирование: запускают модифицированную и эталонную версию на одинаковых входных данных (одинаковые логины, одинаковый набор действий, одна и та же сеть) и сравнивают выходные результаты. Если алгоритмы идентичны, то и результаты должны совпадать с точностью до незначительных флуктуаций (например, разница в таймстемпах из-за разной загрузки процессора). Если же наблюдаются систематические расхождения (например, модифицированная версия всегда показывает на 10% больше баланса или на 2 часа раньше время доставки), это является мощным косвенным доказательством модификации логики. Такой подход особенно эффективен в тех случаях, когда исходный код недоступен, но имеются эталонные инсталляции.

📌 Раздел 13: Подробные практические кейсы из экспертной практики Союза «Федерация судебных экспертов»

📌 Кейс 1: Арбитражный спор о фиктивном списании бонусных баллов в программе лояльности. Крупная сеть магазинов обратилась с иском к бывшему сотруднику, который, по данным внутреннего расследования, через мобильное приложение аннулировал чужие бонусы на сумму более 2 миллионов рублей. Сотрудник утверждал, что его устройство было заражено вирусом и что приложение работало в штатном режиме. Эксперты Союз «Федерация судебных экспертов» изъяли его смартфон и создали полный дамп памяти. Сравнение APK-файла на устройстве с эталонной версией из магазина приложений показало, что цифровая подпись не совпадает — файл был переподписан сторонним сертификатом. Дизассемблирование выявило, что в классе, обрабатывающем транзакции, был изменён один байт: условие проверки прав администратора было заменено на безусловный переход, позволяющий любому пользователю выполнять любые операции. Анализ логов ADB показал, что за день до массового списания на устройстве был запущен отладочный сервер и произведена установка неофициального APK. Временные метки файлов базы данных SQLite указывали на модификацию записей вручную через SQL-команды, выполненные из командной строки. Суд признал сотрудника виновным в хищении, поскольку модификация приложения была доказана на всех уровнях — от подписи до байт-кода.

📌 Кейс 2: Гражданское дело о подлоге геолокационных данных в сервисе такси. Водитель сервиса такси предоставил суду скриншоты из мобильного приложения, которые доказывали, что он находился на месте подачи в указанное время, и тем самым опровергал претензию пассажира о длительном ожидании. Однако пассажир заявил, что водитель использует модифицированное приложение для подмены GPS-координат. Эксперты изучили системные логи местоположения (LocationManager) на устройстве водителя и обнаружили, что во время поездки приложение регулярно обращалось к файлу с фиктивными координатами, который отсутствовал в эталонной версии. При анализе сетевого трафика выяснилось, что в моменты, когда должно было происходить обновление координат от спутников, вместо запросов к GPS-модулю приложение отправляло предустановленные значения из локального JSON-файла. ИК-анализ образа диска показал наличие библиотеки libfakegps.so, которая перехватывала системный вызов getLocation() и возвращала подставные данные. Кроме того, были обнаружены логи установки Xposed-модуля за две недели до инцидента. Эксперты сделали вывод о том, что приложение было сознательно модифицировано для имитации нахождения в других точках, и суд отклонил доводы водителя, обязав его компенсировать пассажиру моральный вред.

📌 Кейс 3: Корпоративный конфликт о несанкционированной передаче конфиденциальных файлов через защищённое корпоративное приложение. Сотрудник крупного банка был уволен за разглашение коммерческой тайны, поскольку через корпоративное мобильное приложение якобы были отправлены отчёты на его личный e-mail. Сотрудник настаивал на том, что никогда не отправлял эти файлы, а приложение могло быть взломано. Эксперты провели динамический анализ на его рабочем устройстве и обнаружили, что в процессе выполнения приложение создавало скрытый каталог с логами всех отправленных данных, но эти логи были зашифрованы нестандартным алгоритмом. При сравнении с эталонной версией выяснилось, что в официальной версии такого модуля логирования вообще нет — он был внедрён через инъекцию байт-кода в метод отправки письма. Кроме того, в системном журнале были найдены записи о запуске скрипта, который копировал содержимое папки «Documents» в общий доступ каждые 5 минут. Анализ временных штампов установил, что модификация была внесена в день, когда сотрудник оставил свой телефон на рабочем столе на время обеда, а зафиксированная в логах сессия ADB была инициирована с IP-адреса его непосредственного руководителя. Таким образом, суд признал, что модификация была произведена третьим лицом, и восстановил сотрудника на работе, а ответственность возложил на руководителя, злоупотребившего служебным положением.

📌 Кейс 4: Спор между страховой компанией и клиентом о фиктивном ДТП. Клиент представил фотографии с места аварии, сделанные через мобильное приложение страховщика, с указанием GPS-координат и временных меток, совпадающих с заявленным временем происшествия. Однако страховая компания заподозрила подделку, поскольку координаты указывали на пустырь, а не на дорогу. Эксперты изучили метаданные фото, но они оказались корректны. Тогда они провели анализ самого мобильного приложения на телефоне клиента — оказалось, что в файле ресурсов в разделе /assets/config.xml был изменён параметр «allowMockLocations» с «false» на «true», что позволяло эмулировать GPS через сторонние утилиты. В логах системы был найден пакет «MockLocations.apk» с датой установки, предшествовавшей дате ДТП. При динамической трассировке вызовов API было установлено, что приложение действительно использовало фиктивные координаты, переданные через провайдера «test_provider». Более того, анализ таймстемпов EXIF-данных фотографий, сохранённых в галерее, показал, что они были сняты на два дня раньше, но затем перезаписаны через сторонний редактор. Суд отклонил иск клиента о страховой выплате и передал материалы в полицию для возбуждения уголовного дела о мошенничестве.

📌 Кейс 5: Разбирательство по поводу нечестного игрового счёта в онлайн-казино. Администрация онлайн-платформы обвинила игрока в использовании модифицированного клиента для взлома генератора случайных чисел, что позволило ему выиграть крупную сумму. Игрок утверждал, что просто удачно играл и не вмешивался в приложение. Эксперты изъяли его устройство и обнаружили, что APK-файл отличается от официального по размеру на 127 килобайт. Дизассемблирование показало наличие дополнительного класса, который перехватывал вызовы к системному генератору случайных чисел и подменял значения на те, что заранее вычислялись через предсказуемый алгоритм. Кроме того, в папке /data/data/ был найден скрытый файл «seed.dat», содержащий начальные числа для эмуляции удачных комбинаций. Сравнение с эталонной версией подтвердило, что эта логика была встроена именно в модифицированную копию. Анализ журналов установки показал, что приложение было переустановлено за 3 часа до начала выигрышной сессии, а сразу после этого была запущена отладочная сессия для активации модуля. Суд обязал игрока вернуть выигранные средства, а также выплатить штраф за нарушение пользовательского соглашения, признав, что изменение приложения является грубым нарушением, влекущим аннулирование всех результатов.

📋 Раздел 14: Особенности судебной квалификации изменений в зависимости от цели модификации

Не всякая модификация автоматически означает недобросовестность. Например, разработчики могут использовать отладочные версии с дополнительными логами для диагностики проблем, а пользователи — устанавливать кастомизированные прошивки, которые меняют поведение всех приложений. Эксперт обязан оценить, была ли модификация направлена именно на искажение тех данных, которые стали предметом судебного спора. Если изменение коснулось только цветовой темы или языка интерфейса, это не имеет отношения к делу; если же был изменён модуль вычисления процентов по кредиту — это уже прямая фальсификация. Союз «Федерация судебных экспертов» всегда даёт оценку функциональной значимости каждой найденной модификации, чётко разделяя косметические и сущностные изменения.

🖋️ Раздел 15: Оформление экспертного заключения и практические рекомендации для правоприменителей

Заключение по такой экспертизе должно быть многоуровневым: сначала представлены результаты первичного скрининга (подписи, размеры, хеши), затем даны детальные описания каждой найденной модификации с указанием конкретных файлов и смещений в них, после чего следует синтезирующая часть, где все факты связываются в единую картину вмешательства. Для судей и адвокатов, не обладающих техническими знаниями, полезно добавлять «перевод» сложных терминов на простой язык и визуализировать изменения на блок-схемах. Сторонам процесса следует помнить, что для проведения качественной экспертизы необходимо предоставлять не только само устройство, но и доступ к учётной записи разработчика (если это возможно), а также к облачным резервным копиям, где могут сохраниться следы синхронизации модифицированных данных. Чем больше исходных материалов получит эксперт, тем точнее и обоснованнее будут его выводы, что в конечном счёте обеспечит принятие справедливого судебного решения.

Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте ✅ https://krimexpert.ru