Как сделать дамп андроида
Как снять дамп разделов system, kernel, data, zImage на Андроид
Необходимо для снятия образа
1. Скачайте и установите на ПК фирменную программу сайта ADB RUN (если в курсе, что такое adb или установлено Android SDK, то устанавливать не нужно)
2. Android смартфон или планшет должен быть c Root правами
Подробно о Root Android:
4. Установить драйвера если вдруг не установлены
Инструкция как снять образ с Андроид
1. Подключите устройство Android к ПК
2. Запустите программу ADB RUN и перейдите в меню (7) Manual Command > (1) Adb
Узнаем /dev/block разделов
Что такое /dev/block/? /dev/block/ — это «диски» на которых находятся разделы system, data, cache
Вариант 1
Данный способ самый простой, но к сожалению узнать где находиться ядро не возможно.
Для того чтобы узнать /dev/block/ вводим команду
Получаем список где видим список с нашими разделами и к каким /dev/block/ они примонтированы
Вариант 2
Данный способ более сложный, но за то вы точно будете знать абсолютно все ваши разделы!
Вначале лучше воспользоваться файловым менеджером Android с Root доступом например как:
После того как установили перейдите по пути
Далее вам нужно найти папку by-name, она находиться в одной из под папок в platform
Например для некоторых устройств Samsung это выглядит так:
Для устройств на Tegra 3:
Для устройств на Omap:
Для некоторых Mediatek:
Для некоторых устройств Sony:
После того как выяснили где находиться папка by-name в программу ADB RUN набираем команду
[Обновление]
В новых версиях программы ADB RUN (с версии 3.4x.xx) узнать все разделы стало гораздо проще! Все что вам необходимо это:
Снятие образа Android с выбранного раздела
И так когда мы уже знаем где находятся какие разделы, можно приступать к снятию образа Android (дампа) с выбранного раздела. Перед тем как начать убедитесь что у вас достаточно много свободной памяти на карте памяти!
1. Для того чтобы снять образ необходимо в ADB RUN зайти в меню (7) Manual Command > (1) Adb
3. Набрать команду для снятия дампа
где NAME_razdel.img — имя которое вы присвоите при снятие образа с выборного раздела (давать имена лучше также как они указаны, если data то data)
Процедура снятия может занять определенное время, от 1 минуты до 15, в это время лучше не дергать ваш Android!
[Обновление]
В новых версиях ADB RUN появилась возможность быстро снять образ каждый раз не набирая столь длинные команды. Все что вам нужно это знать имя блока.
Когда вы уже знаете необходимый блок перейдите в ADB RUN:
Восстановление раздела из созданного образа Android (дампа раздела)
Когда вам будет необходимо выполнить восстановление из ранее созданного образа, нужно сделать вот, что:
Убедитесь что образ все еще находиться в разделе /sdcard — так как бекап создавался именно в этот раздел, либо переместите его обратно.
Прописать следующую команду:
где NAME_razdel.img — имя образа выборного раздела (давать имена лучше также как они указаны, если data то data)
Процедура восстановления может занять определенное время, от 1 минуты до 15, в это время лучше не дергать ваш Android!
[Обновление]
Для устройств Sony, HTC, Xiaomi и других устройств на которых есть режим Fastboot
могут выполнить восстановление следующим образом после ранее обязательного снятия boot.img (zImage) и system.img (factoryfs.img) обязательно скопируйте данные файлы на ПК:
1. Переведите Android в режим fastboot (bootloader) и подключить к ПК
2. Файлы boot.img и system.img переместить в папку C:/adb/progbin
4. Набрать следующие команды (подробно о Fastboot)
Система будет восстановлена в исходное состояние! Можете продолжать эксперименты!
Снятие дампа памяти из мобильных устройств на Android
В статье рассмастриваются методы сбора данных о работе мобильного устройства на операционной системе Android, которые позволят оперативно получить криминалистически значимую информацию для расследования инцидента в области информационной безопасности.
Введение
Количество преступлений в сфере информационной безопасности и информационных технологий в отношении и с использованием средств мобильной связи неуклонно растет. В этой связи стоить заметить, что большая часть современных мобильных устройств работает под управлением операционной системы Android. Для выяснения причин и последствий инцидентов возникает необходимость изучения хранящейся на них информации. Но при исследовании устройств на Android специалисты сталкиваются со следующими трудностями:
Разбор инцидентов преступлений в сфере информационной безопасности на первоначальном этапе
Раскрывать преступления в сфере инфокоммуникационных технологий сложно, так как нередко преступники прибегают к различным уловкам, маскируя свои преступные деяния. Отображение в памяти мобильных устройств связи (сотовых телефонов, смартфонов, планшетных компьютеров, портативных устройств GPS и пр.) криминалистически важной доказательственной и ориентирующей информации требует от специалиста целенаправленного поиска и изъятия указанных предметов, извлечения из них имеющей значение для уголовного дела информации, ее фиксации и анализа. Многое здесь зависит от возможностей криминалистической техники, позволяющей в короткие сроки получить важную (включая удаленную) информацию из памяти мобильных устройств связи, карт памяти, SIM-карт участников инцидента. Для выявления инцидентов, произошедших с использованием средств мобильной связи, есть криминалистические методы, применяемые при производстве судебных компьютерных экспертиз. Сотрудники Института повышения квалификации Следственного комитета России исследовали программно-аппаратный комплекс для извлечения судебной информации, и выяснилось, что в 87% исследуемых мобильных аппаратов имеется информация, способствующая раскрытию преступлений. Хочется верить, что вскоре применение программно-аппаратных комплексов для установления объективной истины по уголовным делам станет повсеместным.
Следует учитывать, что речь идет о двух самостоятельных действиях: изъятие самого мобильного устройства связи; извлечение информации из памяти мобильного устройства или SIM-карт, карт памяти.
Получить мобильное устройство связи можно при:
Кроме того, выемку мобильного устройства могут осуществить сотрудники органа дознания по письменному поручению следователя, в производстве которого находится уголовное дело, но обязательно с участием специалиста.
Проводя указанные выше следственные действия (в зависимости от характера и способа совершенного преступления, складывающейся следственной ситуации), следует обращать внимание вот на что:
Во-первых, на место нахождения и возможного сокрытия мобильных устройств связи и, в особенности, извлекаемых из них накопителей (например, SIM-карт). При осмотре места инцидента необходимо изымать все мобильные устройства и SIM-карты, находящиеся при потерпевшем для установления, в частности, последних контактов лица. Кроме того, мобильные устройства связи возможно обнаружить в ходе осмотра местности и жилища. Следует иметь в виду, что данные лица могут принять меры к сокрытию или уничтожению мобильных устройств, либо электронных накопителей (например, SIM-карт).
Известны случаи, когда извлеченная информация из памяти мобильного устройства способствовала раскрытию уголовных преступлений.
Так в деле о совершении действий сексуального характера с ребенком в ходе проводимого расследования было установлено, что преступник снимал на свой мобильный телефон видео о том, как он совершал эти самые сексуальные действия. На момент, когда мобильное устройство попало к специалисту, видео было уже удалено преступником. Восстановить видео из памяти устройства не представилось возможным. Однако с помощью извлечения данных удалось восстановить графическую миниатюру файла, ранее присутствовавшего на исследуемом устройстве. Несмотря на то, что восстановленный графический файл был небольших размеров, это изображение помогло привлечь преступника к уголовной ответственности. Рассмотрим другой пример: необходимо было восстановить сообщения, которыми обменивался преступник со своими подельниками с использованием мобильного приложения WhatsApp. При извлечении данных с мобильного устройства были получены сообщения WhatsApp. В том числе была восстановлена переписка между преступниками.
Так как же специалисту получить данные с мобильного устройства? Надежное извлечение данных из мобильных телефонов требует специальных знаний. Оно выполняется иначе, чем извлечение информации из компьютеров. Не во всех мобильных устройствах используются одинаковые операционные системы или компоненты.
Большинство из них представляют собой устройства оригинальной разработки с уникальной конфигурацией, что сильно осложняет извлечение. Данные в изъятом телефоне могут помочь в быстром раскрытии преступления по горячим следам, опытный специалист за считанные минуты может получить данные, необходимые для подтверждения или опровержения предварительных подозрений.
Но главное — это не сами данные, а их содержание. Будь то простой телефонный звонок или более сложное восстановление координат GPS, скрытых в метаданных изображений, — они помогают проследить соединения между устройствами с целью лучшего понимания взаимосвязей между их обладателями.
На данный момент самым сложным является именно извлечение данных из мобильного телефона, нежели работа с ними. Так как специалистов интересуют в том числе и удаленные данные, находящиеся в памяти мобильных устройств, необходимо сделать физическое извлечение данных из памяти мобильного устройства. Т. е. получить полную копию памяти исследуемого им устройства. Сделать физический дамп памяти мобильного устройства возможно следующими методами.
Метод снятия дампа памяти с помощью программного обеспечения Android Debug Bridge
Android Debug Bridge (ADB) — это программный продукт для отладки, выявление ошибок в приложениях, разблокировки устройств на операционной системе Android.
Примечание: Android-смартфон или планшет должен быть с Root-правами (или, как его еще называют, суперпользователь). Это необходимо, чтобы расширить функциональность операционной системы Android.
Рисунок 1. Список разделов system, data, cache
Примечание: Когда мы уже знаем, где находятся разделы, можно приступить к снятию образа Android (дампа) с выбранного раздела.
Рисунок 2. Меню в ADB RUN
dd if=/dev/block/XXXXXXXXX of=/sdcard/NAME_razdel.img где XXXXXXXXX — раздел, с которого снимается образ, а NAME_razdel.img — имя, которое присваиваем при снятии образа с выбранного раздела, имена лучше оставлять такими же, как они указаны, не переименовывая их.
Примечание: Процедура снятия образа может занять время от 30 минут и более, в это время запрещается пользоваться устройством!
В новых версиях программы ADB RUN имеется возможность быстро снять образ, не набирая каждый раз столь длинные команды. Для этого необходимо знать имя блока.
Программный комплекс «Мобильный Криминалист»
«Мобильный Криминалист» — это программа для судебно-технической экспертизы сотовых телефонов, смартфонов, планшетов и других мобильных устройств. Применение низкоуровневых протоколов доступа к данным позволяет «Мобильному Криминалисту» извлекать намного больше информации, чем другим программам аналогичного назначения, особенно это касается данных, хранящихся в смартфонах. Получение прав суперпользователя (root-права) к устройствам под управлением ОС Android позволяет специалистам полностью извлечь все данные пользователя. Обычно подобная процедура требует определенных знаний и навыков, о которых мы уже говорили, однако программа «Мобильный Криминалист» делает эту операцию автоматически. Получение прав суперпользователя — одна из основных функций Мастера извлечения данных. Важное преимущество этого метода заключается в том, что root-права являются временными и после перезагрузки мобильного устройства отменяются. Поэтому методика полностью соответствует принципам криминалистического исследования.
При подключении телефона в Мастере настройки соединения автоматически запускается Мастер извлечения данных. Это позволяет считать данные с исследуемого мобильного телефона. Устройство может быть подключено как в автоматическом, так и в ручном режиме.
Рисунок 3. Обнаружение устройства
При выборе автоматического режима будет подключено первое обнаруженное программой мобильное устройство. Необходимо учитывать это, если к компьютеру одновременно подключено несколько мобильных устройств. Если же специалист выбирает устройство вручную, необходимо указать производителя и модель.
Рисунок 4. Режим подключения устройств
Если происходит получение данных на ОС Android, специалисту будет предложено выбрать, каким образом извлечь данные из мобильного устройства.
Рисунок 5. Способы извлечения данных
Специалист также может отметить категории данных, которые должны быть извлечены. Чем меньше категорий извлекаемых данных, тем быстрее они будут извлечены.
Рисунок 6. Список разделов для извлечения из устройства
После того как данные будут считаны, специалист может экспортировать их во внешние форматы файлов или открыть исследуемое устройство в программе и проанализировать данные. После того как Мастер извлечения данных закончит свою работу, специалист может посмотреть данные в разделах программы. Список разделов, поддерживающихся в программе «Мобильный Криминалист»:
Аналитические задачи, важные улики, веб-соединение и местоположение, граф связей, журнал, задачи, заметки, календарь, лента событий, лог-файлы аппарата, местонахождение события, объединенные контакты, отчеты, пароли, поиск, приложения, статистика и связи, телефонная книга, файловый браузер. Следует обратить внимание, что количество извлеченных данных и секций зависит от модели телефона. Отчеты, создаваемые программным комплексом «Мобильный Криминалист», могут использоваться в качестве доказательства в суде. Отчет об устройстве содержит основную информацию о телефоне, включая информацию об устройстве, о деле и непосредственно об отчете.
В новой версии программы эксперты-криминалисты имеют возможность извлекать файлы, синхронизированные через сервис OneNote, а также всю информацию из Google Фото (фотографии, географические координаты и временные отметки). Новая версия Мастера извлечения данных из облачных сервисов дает возможность загружать ключ-файл для расшифровки баз сообщений приложения WhatsApp, извлекаемых из облака Google Диск.
Выводы
Специальная экспертиза мобильных устройств — развивающаяся предметная область при расследовании инцидентов в сфере информационной безопасности. Следовательно, инструментальные средства для работы с мобильными телефонами являются относительно новыми разработками и находятся на ранней стадии развития в области информационной безопасности. Умение правильно снять данные с мобильного устройства требует от специалиста глубоких знаний и компетентности, а также основательной подготовки, осторожности и большого количества исследований и тестирований перед экспертизой мобильного устройства. Следовательно, для экспертизы подобных устройств следует выделять значительное количество времени. Сочетание традиционных программно-аппаратных комплексов и методов для анализа мобильных устройств, используемых при производстве компьютерно-технических экспертиз, дает наилучшие результаты при анализе дампов мобильных устройств. При этом специалисты могут получить больше данных, в том числе удаленных, и, соответственно, имеют больше шансов изобличить преступников в совершенных ими злодеяниях.
Ломаем Android. Как глубока кроличья нора?
Мой первый Android телефон Galaxy Note N7000 был приобретен сразу после анонса в октябре 2011 года. Благодаря одному немецкому умельцу под ником bauner, у меня была возможность использовать последнюю версию CyanogenMod (ныне LineageOS). До тех пор, пока полтора года назад телефон не умер от китайской автомобильной зарядки.
Замену искал долго и остановился на Kyocera (да, они и телефоны выпускают) KC-S701. Он отличается брутальным внешним видом и отсутствием сенсорных кнопок. О root доступе к телефону я тогда даже и не задумывался, полагая, что нынче каждый телефон тем или иным способом имеет возможность получения root. И найдется умелец, который сможет под него портировать CyanogenMod. Я ошибался.
За полтора года было выпущено всего одно обновление — фикс падения ядра от специально сформированного ping пакета. А Android KitKat уже год назад был не первой свежести. Root доступ на этот телефон так никто и не получил, и никакой информации о нем не было. Отмечу, что тоже самое железо используется в американской версии телефона Kyocera Brigadier E6782, в котором по-умолчанию активизирован режим fastboot и нет ограничения на запуск неподписанных ядер (именно запуск, а не прошивку, и только при использовании непропатченного bootloader’а, CVE-2014-4325) и присутствует возможность загружаться в эти режимы путём зажатия кнопок телефона. Стараниями Verizon (а может Kyocera?) версия Android на Brigadier была обновлена до Lollipop.
Итак, я решил разобраться с процессом получения root на Android самостоятельно.
Два месяца назад я ничего не знал об устройстве Android (а сейчас я еще больше не знаю). Большую часть знаний пришлось добывать изучением исходных кодов и экспериментами, т.к. информации о взломе Android в интернете очень мало. Последующее описание справедливо для Android 4.4 KitKat, но не исключено, что оно заработает и на более новых версиях.
Хочу обратить ваше внимание на то, что в данном обзоре описан исключительно мой конкретный опыт взлома Android на конкретной модели телефона, поэтому будьте предельно осторожны с его применением в своей практике, если не хотите внезапно получить мертвый телефон. Перед началом исследований я рекомендую забыть о том, что вы пользуетесь взламываемым телефоном в повседневной жизни и сделать backup с последующим hard reset. Это обезопасит ваши данные при совершении ошибки.
В статье описаны не только действия, которые привели к успеху, но и ошибки. Надеюсь, что мои попытки докопаться до истины и многочисленные грабли будут вам интересны.
Все исследования проводились в Linux окружении.
Dirtycow (CVE-2016-5195)
Простыми словами dirtycow (рабочий эксплойт под Android) позволяет заменить память любого процесса (полезно, если хорошо знаешь ASM) или любой доступный для чтения файл, даже если он находится на readonly файловой системе. Желательно, чтобы подменяемый файл был меньше либо равен по размеру заменяемому. Основная атака в dirtycow для Android — подмена /system/bin/run-as — подобие sudo для отладки приложений. Начиная с API android-19 (таблица соответствия версий API и Android) /system/bin/run-as имеет CAP_SETUID и CAP_SETGID capabilities флаги (в старых версиях используется обычный suid bit — 6755).
Если файловая система будет примонтирована в режиме read-write, то всё, что dirtycow подменяет, окажется на файловой системе. Потому необходимо сделать backup оригинального файла и восстановить его после получения доступа, либо не перемонтировать файловую систему в режиме read-write. Как правило раздел /system в Android по умолчанию примонтирован в режиме read-only.
Не зря dirtycow считается одной из серьезнейших уязвимостей, обнаруженных в Linux. И при наличии знаний с помощью dirtycow можно обойти все уровни защиты ядра, в том числе и SELinux.
SELinux
adbd и консоль
Получаем root доступ
root, да не тот
Первым делом я сделал дамп всей прошивки, boot и recovery:
Перезагружаюсь в обычный режим, запускаю эксплойт, проверяю hash recovery раздела — hash соответствует оригинальному. Пробую записать данные опять — hash поменялся! Вспоминаю про page cache, чищу ( echo 3 > /proc/sys/vm/drop_caches ) — hash старый. Т.е. всё, что я пишу в блочное устройство улетает без ошибок в /dev/null и иногда оседает в Linux cache. Но обновление прошивки ведь как-то происходит? И пользовательские данные как-то записываются во внутреннюю память. Надо копать дальше.
Пробуем отключить SELinux
На тот момент я думал, что все ошибки об отсутствии привилегий вызваны SELinux (я полностью забыл о том, что могут быть урезаны capabilities). Логов dmesg я не видел, logcat ничего релевантного не показывал. И я начал думать как отключить SELinux.
Первая зацепка, которую я смог найти:
Т.е. я при помощи dirtycow могу перезаписать /sepolicy и командой setprop selinux.reload_policy 1 загрузить обновленную политику.
В моём случае /sepolicy содержал только allow, что значит — при enforcing режиме SELinux в Android разрешено делать только то, что объявлено в политике. А процессу init разрешалось только загружать политику, но не отключать:
Моей задачей было — разрешить init контексту задать selinux->enforce в permissive (setenforce 0).
Первая же мысль: стоковая политика не подходит этому телефону и он при отсутствии прав начинает тупить.
Я собрал новую политику, в которой просто описал все существующие SELinux context и объявил их permissive. Тоже не помогло.
Потом я решил пересобрать политику и по возможности добавить привилегии для shell контекста.
Чуть позже я нашел утилиту sepolicy-inject, которая добавляет привилегии в уже скомпилированный sepolicy файл. Если правило уже существует, то добавление максимальных привилегий не увеличивает конечный размер политики. К сожалению запуск утилиты добавляет всего одно правило за раз. Написал скрипт, который добавляет максимальные привилегии для каждого правила. Результатом был файл с политикой, в которой каждое правило содержало максимальные привилегии. Размер файла совпадал с оригинальным. И это опять не помогло.
Можно было добавить любой permissive домен, загрузить новую политику и работать в контексте этого домена (кстати, supersu от chainfire для новых версий Android так и работает). Но даже это не дало возможности отключить SELinux. Я решил копать в другом направлении.
Копаем recovery
Выясняю, что initramfs содержит публичный ключ res/keys в формате minicrypt, которым проверяется цифровая подпись ZIP файла. Оказалось это стандартный тестовый ключ Android, и что я могу подписать этим ключём любой архив. Проверить это можно следующим образом:
Моя 64Gb флэшка была отформатирована в exfat. Нашел старую sdcard на 2Gb, отформатировал её как vfat, записал ZIP, вставил её в телефон. Recovery в этот раз смог примонтировать карточку и я мог просматривать её содержимое на телефоне. Однако при установке ZIP опять возникла ошибка: E:failed to set up expected mounts for install; aborting.
Т.е. перед тем как применить ZIP, recovery отмонтирует все разделы, но в моём случае что-то идёт не так.
Копаем исходники ядра
Лицензия GPL обязывает производителей смартфонов выкладывать исходники ядра. Спасибо Линусу и Столлману за это. Иногда производители выкладывают что-то левое, иногда правильные исходники, но без defconfig файла, иногда правильные и очень редко с инструкцией как их собирать (например LG).
В моём случае были исходники с правильным defconfig но без инструкции. Немного попотев я смог собрать ядро и убедился, что это не полная липа.
Через продолжительное время я остановился на двух файлах:
hooks
restart
Тоже интересный для изучения файл. В нем описываются возможные варианты загрузки телефона:
Немного о том, как происходит загрузка на телефонах с процессором Qualcomm:
Встроенный ROM загрузчик Qualcomm (pbl — primary bootloader) загружает раздел sbl1 (secondary bootloader). sbl1 загружает tz (trust zone), затем aboot (android boot, little kernel, lk). Aboot в свою очередь загружает boot, recovery или fota.
Описание разделов, участвующих при загрузке:
Все эти разделы подписаны цепочкой сертификатов.
В некоторых случаях полезно игнорировать обновления прошивки.
На мой телефон имелось обновление. Отважиться на него я мог потому, что я уже имел возможность писать в /cache и прервать обновление в любой момент.
Изучив исходники отвечающего за обновление Java приложения, мне стало ясно как оно происходит:
Перезагрузка происходит не моментально, значит у меня есть возможность удалить файл перед перезагрузкой и посмотреть что происходит с разделом fotamng.
Начинаю изучать данные, которые сдампил. В разделе /cache бонусом получаю логи fota, в которых даже есть логи dmseg! Сама перезагрузка в fota инициализируется байтами «1» в разделе fotamng:
После перезагрузки они обнуляются. В dmesg я обратил внимание на наличие параметра ядра kcdroidboot.mode=f-ksg. Вот оно! Т.е. загрузчик снимает защиту для fota. И чисто теоретически, если я запишу раздел boot в fota и перезагружу телефон в этот режим, то я получу ядро с отключенной защитой Kyocera. Но писать в системные разделы я всё еще не могу.
Изучение исходников little kernel (lk)
То, что находится в разделе aboot — загрузчик Android, ванильные исходники которого находятся по адресу: https://source.codeaurora.org/quic/la/kernel/lk/
Там можно найти и информацию как происходит загрузка в некоторые из режимов. Например я нашел информацию о том, что если в раздел misc записать «boot-recovery», то перезагрузиться в recovery можно без adb reboot recovery. При загрузке в recovery эта метка обнуляется. И если recovery загрузиться не может, то телефон попадёт в boot loop и вы его потеряете. Так что будьте осторожны, а лучше избегайте этого варианта перезагрузки.
Первые успехи
dmesg
uevent_helper
Патченный adbd
WiFi в моем телефоне работает через модуль ядра. WiFi включен — модуль загружен. WiFi выключен — модуль выгружен. Если подменить модуль на свой, то при включении WiFi должен загрузиться подставной модуль. На моё счастье цифровая подпись модулей не проверялась. Первое, что я попробовал, это собрать и загрузить модуль, который отключает SELinux путем замены памяти ядра на Amazon Fire Phone: https://github.com/chaosmaster/ford_selinux_permissive
Если при загрузке модуля ядро будет ругаться (disagrees about version of symbol module_layout), то потребуется извлечь Module.symvers из boot раздела. Это можно сделать, используя скрипт https://github.com/glandium/extract-symvers:
Нельзя просто так взять и собрать свой модуль для телефона Kyocera.
Помните список доступных для загрузки модулей? Модуль должен называться wlan и никак иначе. Решается это просто:
Модуль на удивление загрузился (память, которую занимает модуль wlan сократилась, проверяется командой lsmod), но SELinux не отключился.
Единственное, что я не уяснил, как программно вызвать отключение и включение WiFi. Мне приходится выключать/включать WiFi вручную через интерфейс Android.
Пишем свой модуль
Снимаем защиту
SELinux отключить не удалось, но по аналогии с модулем https://github.com/chaosmaster/ford_selinux_permissive можно попробовать сделать тоже самое, но с Kyocera hooks. Мне нужно лишь задать переменную kc_bootmode или kc_kbfm в единицу.
Получив адрес нужной функции, я мог передать в неё параметр и функция задаст переменную в 1. Опытным путем выяснил, что не все ядра отображают kallsyms для переменных (тип d или D, регистр говорит глобальная переменная или нет), поэтому в примерах я использую указатели на функции. Возможно это определяется опцией CONFIG_KALLSYMS_ALL при компиляции ядра.
Описываю функцию в модуле:
Можно адреса найти динамически:
Загрузка подставного модуля отключила встроенную защиту! Теперь я могу монтировать /system и загружать любой модуль ядра независимо от его имени.
Системная область emmc всё еще доступна только для чтения и не позволяет редактировать /system раздел на постоянной основе. Файлы редактируются, но при очистке cache все возвращается в исходное состояние.
Всё-таки отключаем SELinux
Это делается вызовом функции reset_security_ops :
После этого защита SELinux работать не будет, но система всё еще будет думать, что она включена. Потому возможны некоторые ошибки в работе системы.
Перезагружаемся в download mode
Пришлось ограничить скорость записи, иначе телефон отваливается и запись прекращается. Возможно это результат переполнения кэша mass storage загрузчика. Пришлось написать хак:
При помощи этого же способа я примонтировал /system раздел к компьютеру и вручную записал на него supersu. Первоначальная задача выполнена: перманентный root доступ получен. Осталось автоматизировать загрузку подставного WiFi модуля, который отключает hooks. И хорошо бы, чтобы WiFi после этого оставался работоспособным. А еще лучше разблокировать загрузчик, чтобы загружать своё ядро.
Для начала можно изучить какие средства применялись для разблокировки других телефонов. При беглом поиске я обнаружил лишь следующие два, к тому же устаревшие:
Цифровая подпись aboot и boot разделов
В качестве эксперимента я попробовал записать boot раздел в раздел fota, зная, что при загрузке fota снимаются все ограничения. Здесь я сильно рисковал, т.к. мог получить bootloop, похожий на bootloop recovery. Метка загрузки в fota записывается в раздел fotamng и если раздел не загрузится, то я получу бесконечную перезагрузку.
К сожалению, boot раздел, записанный в fota не загрузился, а bootloop я, к счастью, не получил. Не понятно почему тогда boot раздел, записанный в recovery успешно загрузился. Толку от этого конечно нет, для recovery используется та же защита, что и для boot. Не знаю чем вызвано подобное поведение. Возможно различными смещениями ramdisk и tags:
В Secure boot whitepaper от Qualcomm говорится о том, что подписывается sha256 hash от sha256 hash’ей нескольких сегментов ELF загрузчика. Количество сегментов определено в Subject’е сертификата. Например OU=05 00002000 SW_SIZE говорит о том, что в подписи содержится sha256 hash от первых 256 hash’ей областей по 32 байта (0x2000/32=256). Сам по себе aboot не содержит ELF заголовка и описание больше подходит к sbl1 (secondary boot loader).
Есть описание работы little kernel от Qualcomm, но и там нет ничего про алгоритм создания подписи aboot. Задача определить алгоритм все еще актуальна.
Эксперименты с загрузчиками
Для проведения экспериментов я заказал из штатов за символическую сумму Kyocera Brigadier с разбитым экраном.
Я проверил цифровые подписи aboot загрузчиков. Subject’ы сертификатов оказались идентичными, следовательно они могут быть взаимозаменяемыми. Решился на эксперимент: прошить aboot от KC-S701 в Brigadier. Загрузчик заработал. На удивление, защита emmc от записи с этим загрузчиком не включилась и я смог спокойно восстановить загрузчик от Brigadier. Понимая все риски, я решил прошить загрузчик от Brigadier на KC-S701. Я бы получил возможность загружать любое неподписанное ядро и использовать fastboot. В этот раз телефон не загрузился.
То, что еще требует работы или выяснить не удалось
Загрузка Fota
Почему boot раздел не грузится из раздела fota? Ведь они подписаны одним ключём. Если бы загрузка произошла, то я бы получил разлоченный телефон, в котором не пришлось бы подменять модули.
Расшифровка Kyocera properties
Kyocera наряду с android system properties использует свой внутренний механизм properties, который мне тоже не удалось выяснить. Наверняка там хранятся интересные опции, которые могут влиять в том числе и на снятие защиты bootloader’а. В телефоне есть библиотека libkcjprop_jni.so и демон kcjprop_daemon. Библиотеку можно подключить и использовать её функции, но у меня пока не нашлось времени этого сделать.
Опции пишутся на файловую систему, внутри бинарные данные:
Kexec
Kexec позволяет из ядра Linux загрузить другое ядро. По умолчанию в production релизах ядер отключают поддержку Kexec, но его можно включить через модуль ядра. Затем из user-end можно загрузить любое ядро, которое заменит текущее. Это выглядит как хак, но если хочется загружать своё ядро — этот вариант имеет своё место под солнцем.
Уязвимость в QSEE
QSEE — защита в процессорах Qualcomm, в которой недавно уже достаточно давно обнаружили уязвимость. Суть уязвимости — полный доступ к выполнению команд на уровне Trust Zone. Вплоть до загрузки любого ядра.
Пока еще разбираюсь в этом вопросе. Насколько я понял мне необходимо получить доступ к области emmc, называющейся RPMB. Этого можно добиться отправкой специально сформированной SCM командой. В области RPMB (Replay Protected Memory Block) содержатся биты, которые отвечают за lock/unlock статус.
Заключение
Код модулей, aboot загрузчики и библиотека для работы с Kyocera Propertiies находятся в моём репозитории на github: https://github.com/kayrus/break_free.
С каждым решением очередной проблемы, процесс всё больше напоминает апорию об Ахиллесе и черепахе. Не знаю на сколько еще хватит моего энтузиазма. Возможно здесь есть знающие люди, которые помогут достичь дна кроличьей норы.
Пользуясь случаем, выражаю благодарность разработчикам из компании Kyocera за прекрасные устройства и их защиту. В противном случае этой статьи бы не было. С другой стороны отсутствие регулярных обновлений сильно огорчает. Если у вас появится модель телефона с возможностью разблокировки загрузчика, я непременно его приобрету.