Несколько лет назад один из членов нашей команды заказал себе OnePlus 6T прямо из Китая. Телефон пришел в оригинальной упаковке и типовой комплектации: с зарядным устройством, кабелем и чехлом. Смартфон без проблем проработал год, ничем, на первый взгляд, не отличаясь от тех, что продаются в России.
Но однажды приложения начали предупреждать о наличии root-доступа, а некоторые, особенно банковские, вообще перестали запускаться. При этом прошивка никаким образом не модифицировалась, а обновления устанавливались исключительно из официальных источников, относящихся к ОС. Такое странное поведение смартфона побудило нас провести исследование, результаты которого описаны в этой статье.
0. Поиск причины
Какое-то время нам не удавалось понять, в чем причина такого поведения приложений. Устройство проходило проверку Play Integrity Strong, а также подтверждалась подлинность цепочки загрузки при проверке аттестации приложением Key Attestation.
Через некоторое время стало ясно, что причиной такого поведения стали установленные параметры ro.debuggable=1 и ro.adb.secure=0. Разобраться в этом оказалось довольно просто: после множества тщетных попыток понять, в чем проблема, мы попытались выполнить команду adb root. В результате adb shell запустился с правами root без каких-либо ошибок:
Демон adbd осуществляет проверку параметра ro.debuggable при сбросе привилегий с root до shell (без него невозможно подключиться клиентом, сохранив права root), а параметр ro.adb.secure влияет на необходимость аутентификации при подключении adb-клиента.
OnePlus6T:/ # getprop|grep ro.debug
[ro.debuggable]: [1]
OnePlus6T:/ # getprop|grep ro.adb
[ro.adb.secure]: [0]Встал вопрос: как такое возможно?
Наличие параметра androidboot.verifiedbootstate=green в командной строке ядра свидетельствует о заблокированном с ключами производителя загрузчике, что в свою очередь исключает компрометацию посредством повторной блокировки устройства. Это подтверждается тем, что устройство успешно проходило проверку play integrity. В случае разблокировки параметр verifiedbootstate изменяется на orange (или yellow после повторной блокировки), и при включении устройства отображается соответствующее окно .
При перезапуске устройства в режиме recovery, оно также предоставляло рутовый шел через adb – это и начинало наводить на определенные мысли.
1. Как прошивка с включенной возможностью отладки попала в release-сборку?
Для анализа ситуации с использованием root-доступа был получен лог загрузки устройства (/proc/bootloader_log). Наиболее интересным в нем оказался фрагмент, содержащий командную строку запуска ядра:
OemCmdLine
OemInfo.OemCmdLine len 805
Cmdline: androidboot.hardware=qcom androidboot.console=ttyMSM0 video=vfb:640x400,bpp=32,memsize=3072000 msm_rtb.filter=0x237 ehci-hcd.park=3 lpm_levels.sleep_
Cmdline: disabled=1 service_locator.enable=1 swiotlb=2048 androidboot.configfs=true loop.max_part=7 androidboot.usbcontroller=a600000.dwc3 rootwait ro init=/i
Cmdline: nit buildvariant=user androidboot.verifiedbootstate=green androidboot.keymaster=1 dm="1 vroot none ro 1,0 5764704 verity 1 PARTUUID=58c917ed-d09f-07d
Cmdline: 1-c7af-88f6e15beec8 PARTUUID=58c917ed-d09f-07d1-c7af-88f6e15beec8 4096 4096 720588 720588 sha1 97af17c8d79629d048c11ad4058f343124279389 61efba56aa1fa
Cmdline: 6397190a518f0aa794bbd02a7f604536e1a402ccb5f173614b7 10 restart_on_corruption ignore_zero_blocks use_fec_from_device PARTUUID=58c917ed-d09f-07d1-c7af-
Cmdline: 88f6e15beec8 fec_roots 2 fec_blocks 726263 fec_start 726263" root=/dev/dm-0 androidboot.vbmeta.device=PARTUUID=c3e4fce8-096e-a707-d9d8-74da4faf0882 a
Cmdline: ndroidboot.vbmeta.device=PARTUUID=c3e4fce8-096e-a707-d9d8-74da4faf0882 androidboot.vbmeta.avb_version=1.0 androidboot.vbmeta.device_state=locked andr
Cmdline: oidboot.vbmeta.hash_alg=sha256 androidboot.vbmeta.size=7616 androidboot.vbmeta.digest=5ae631ed1c9936e5ea64c854419ef7d150b317798975bc7d94fe444267daeac
Cmdline: 2 androidboot.vbmeta.invalidate_on_error=yes androidboot.veritymode=enforcing androidboot.bootdevice=1d84000.ufshc androidboot.fstab_suffix=default a
Cmdline: ndroidboot.serialno=221e6695 androidboot.baseband=msm msm_drm.dsi_display0=dsi_samsung_s6e3fc2x01_cmd_display: androidboot.slot_suffix=_b skip_initra
Cmdline: mfs rootwait ro init=/init androidboot.dtbo_idx=21 androidboot.dtb_idx=1 panel_type=black androidboot.mode=normal androidboot.recoveryreason=000 andr
Cmdline: oidboot.project_name=18811 androidboot.project_codename=fajitat ddr_manufacture_info=Samsung ddr_row0_info=16 androidboot.hw_version=41 androidboot.r
Cmdline: f_version=11 androidboot.prj_version=0 androidboot.platform_id=321 androidboot.platform_name=SDM845 androidboot.startupmode=hard_reset androidboot.en
Cmdline: able_dm_verity=1 androidboot.at_location=factory androidboot.power_cut_test=0 androidboot.secboot=enabled androidboot.battery.absent=false androidboo
Cmdline: t.rpmb_enable=true androidboot.type=sdebug androidboot.product.hardware.sku=3 androidboot.logcat_log_level=49 androidboot.init_log_level=49 androidbo
Cmdline: ot.selinux_log_level=842348088 androidboot.cust=0 androidboot.prmec=true androidboot.opcarrier=none androidboot.bootcount=1919247457В глаза бросился нестандартный параметр androidboot.type=sdebug. Хотя сам по себе флаг androidboot.type не является чем-то уникальным, упоминаний его выставления в sdebug оказалось немного. В ходе поиска удалось найти скрипт init.oem.rc, включающий adb (в том числе в режиме зарядки) в случае, если устройство запущено в режиме sdebug:
on property:sys.boot_completed=1 && persist.vendor.usb.config=none && property:ro.boot.type=sdebug
setprop persist.sys.usb.config adb
...
on charger && property:ro.boot.type=sdebug
setprop sys.usb.config adbОднако на исследуемом устройстве этот файл найти не удалось (позднее выяснилось, что он был встроен в бинарный файл init). Тогда было принято решение изучить все элементы цепочки загрузки устройства в надежде найти место включения режима отладки. К этому моменту стало очевидно, что данный функционал устройства каким-то образом связан с оставленным производителем бэкдором.
В 2017 году в устройствах OnePlus уже находили бэкдор. Однако с того момента прошло уже 4 года (на устройстве стоит прошивка 2021 года).
Анализ процесса загрузки показал, что в бинарном файле init присутствует логика обработки данного параметра.
В функции android::init::PropertyLoadBootDefaults происходит обработка параметра ro.boot.type. В случае, если он имеет значение sdebug, выставляются параметры ro.debuggable=1 и ro.adb.secure=0, что и можно наблюдать на устройстве. Кроме того, в приведенном ниже фрагменте кода видно, что параметр ro.boot.verifiedbootstate при этом выставляется в orange:
Фрагмент кода init загрузчика
...
std::string value = android::base::GetProperty("ro.boot.type", empty_str);
if(std::string::compare(value, 5, "debug")){
android::base::SetProperty("ro.secure", "0");
android::base::SetProperty("ro.adb.secure", "0");
android::base::SetProperty("ro.boot.verifiedbootstate", "orange");
android::base::SetProperty("ro.debuggable", "1");
android::base::SetProperty("ro.force.debuggable", "1");
}
if(std::string::compare(value, 6, "sdebug")){
android::base::SetProperty("ro.adb.secure", "0");
android::base::SetProperty("ro.boot.verifiedbootstate", "orange");
android::base::SetProperty("ro.debuggable", "1");
android::base::SetProperty("ro.force.debuggable", "1");
}
...Но если проверить свойство ro.boot.verifiedbootstate, его значение будет green. Неужели этот код не выполняется, и выставление параметров осуществляется в каком-то другом месте?
OnePlus6T:/ # getprop ro.boot.verifiedbootstate
greenКак оказалось, все намного проще: свойства типа ro в init процессе с использованием функции android::base::SetProperty можно выставить только один раз. Первоначально init реализует обработку командной строки ядра в функции ProcessKernelCmdline, где и выставляет передаваемые с префиксом androidboot. аргументы ядра в качестве параметров с префиксом ro.boot.. В том числе выставляется параметр ro.boot.verifiedbootstate=green, поскольку в командной строке было передано значение androidboot.verifiedbootstate. И только после этого вызывается функция android::init::PropertyLoadBootDefaults.
Не углубляясь в исходный код
init, достаточно заметить, что в функцииandroid::init::PropertyLoadBootDefaultsуже используется параметрro.boot.type. Следовательно он должен быть выставлен ранее.
Погрузимся глубже.
2. Как в командную строку ядра Android попала строка androidboot.type=sdebug?
Если вы не знакомы с тем, как устроен процесс загрузки современного Android-устройства, рекомендуем познакомиться с этой статьей.
Опустим детали и сразу перейдем к фрагменту реализации загрузчика LinuxLoader, запускаемого на финальном шаге.
Данный загрузчик имеет GUID
F536D559-459F-48FA-8BBC-43B554ECAE8Dи, судя по всему, основан на предоставляемом qualcomm edk2 приложении.
При поиске по строкам значения sdebug можно достаточно быстро обнаружить следующий участок кода:
boot_tag = get_boot_tag();
switch (boot_tag){
case 0xB8:
boot_type = "nonrelease";
break;
case 0xA9E:
boot_type = "sdebug";
break;
case 0xA0:
boot_type = "auto";
break;
case 0xB7:
boot_type = "debug";
break;
default:
boot_type = "normal";
break;
}
AsciiVSPrint(&buf, 64, " androidboot.type=%a", &boot_type);
set_sdebug_boot_type(&buf);В зависимости от возвращаемого функцией get_boot_tag значения выставляется аргумент androidboot.type, который затем помещается в передаваемую ядру командную строку (детали этого процесса опустим).
Функция get_boot_tag в свою очередь реализует получение параметра из хранилища param (размещается в одноименном разделе прошивки). Для изменения этого значения в коде загрузчика реализована функция set_boot_tag:
int get_boot_tag(){
int tmp;
get_param_by_index_and_offset(0x12Cu, 0x84u, &tmp, 4u);
return tmp;
}
void set_boot_tag(int* tag){
set_param_by_index_and_offset(0x12Cu, 0x84u, tag, 4u);
}Парсер
paramсекции устройств OnePlus реализован тут, более подробно с форматом можно ознакомиться там же.
Таким образом, приходим к выводу, что появление параметра androidboot.type=sdebug в командной строке ядра напрямую связано с неким параметром, хранимым в секции param устройства. Попробуем продолжить цепочку и разобраться, как же он туда попал.
Если взглянуть на вызовы функции set_boot_tag, можно наткнуться на единственную ссылку из обработчика "секретной" команды ops boottype :
int ops_boottype_handler(wchar_t *arg){
int tmp
get_param_intranet(&tmp);
if ( (get_boot_tag() != 0xA9E || !tmp)
&& !enable_advanced_ops )
{
fastboot_fail("unknown command");
return;
}
DebugPrint(0x80000000, "fastboot cmdlist: cmdname=%sn", arg);
tmp = strcmp(arg, L" normal");
if ( tmp )
{
if ( !strcmp(arg, L" auto") )
{
tmp = 0xA0;
}
else if ( !strcmp(arg, L" debug") )
{
tmp = 0xB7;
}
else if ( !strcmp(arg, L" sdebug") )
{
tmp = 0xA9E;
}
else if ( !strcmp(arg, L" nonrelease") )
{
tmp = 0xB8;
}
else{
fastboot_fail((__int64)"unknown command");
return;
}
}
set_boot_tag(tmp);
fastboot_okay("");
return;
}Команда "секретная", поскольку ее обработчик объявлен в общей таблице со всеми командами типа ops, наименование которых хранится в закодированном виде. Полный список команд приведен под спойлером. Помимо безобидных команд также поддерживается изменение режима работы selinux (ops selinux), отключение и включение dm verity (ops disable_dm_verity и ops enable_dm_verity). И все это – на заблокированном загрузчике без каких-либо следов вмешательства после восстановления оригинального значения параметров.
Таблица поддерживаемых команд ops
encoded_cmds_60720[] = {
"jqtxsth%xut", ops_console,
"jqtxsthsz%xut", ops_unconsole,
"yhjyji%pfjqrjrp%xut", ops_kmemleak_detect,
"yhjyjisz%pfjqrjrp%xut", ops_kmemleak_undetect,
"s|tiyzmx2yttgjw%xut", ops_reboot_shutdown,
"wjiftqyttg2yttgjw%xut", ops_reboot_bootloader,
"lsnsnfwydjhwtk%xut", ops_force_training,
"lsnsnfwydjhwtksz%xut", ops_unforce_training,
"xkfyfi%xut", ops_datafs,
"uqjm%xut", ops_help,
"urzi%xut", ops_dump,
"}zsnqjx%xut", ops_selinux,
"jitrdyttg%xut", ops_boot_mode,
"65K:IYXK<WYK=6WY5955:K9%xut", ops_4F50040TR18FTR7FSTD5F01,
"75K:IYXK<WYK=6WY5955:K9%xut", ops_4F50040TR18FTR7FSTD5F02,
"~ynwj{dridjqgfxni%xut", ops_disable_dm_verity,
"~ynwj{dridjqgfsj%xut", ops_enable_dm_verity,
"xkurjy%ysztr%xut", ops_mount_tempfs,
"xkurjy%ysztrsz%xut", ops_unmount_tempfs,
"lrndfyfidlsnlfjv%xut", ops_qeaging_data_img,
"gifdjhwtk%xut", ops_force_adb,
"yxzhdyjx%xut", ops_set_cust,
"ju~yyttg%xut", ops_boottype,
"lxrp{ji%xut", ops_devkmsg,
"qj{jqdltqdqjswjp%xut", ops_kernel_log_level,
"qj{jqdltqdyfhltq%xut", ops_logcat_log_level,
"qj{jqdltqdynsn%xut", ops_init_log_level,
"qj{jqdltqd}zsnqjx%xut", ops_selinux_log_level,
"kwd|mdowu%xut", ops_prj_hw_rf,
"tksn2jhn{ji%xut",ops_device_info,
"stnyfhtqdyf%xut",ops_at_location,
"yxjydyzhdwj|tu%xut",ops_power_cut_test,
"yjxjwdrwf|dhnru%xut",ops_pmic_warm_reset,
"owudxzqut%xut",ops_oplus_prj,
"nxyidxzqut%xut",ops_oplus_dtsi,
"lfqkiftqidwj{thjw%xut",ops_recover_dloadflag,
}Все эти функции добавляются в связный список обработчиков команд `fastboot` в декодированном виде функцией `fastboot_add_encoded_cmd` (наименование автора). Декодирование наименований команд производится при помощи простого алгоритма:
def decode(cmd):
res = ""
for i in cmd[::-1]:
res += chr(ord(i)-5)
return resВ основном цикле обработки fastboot-команд можно видеть некоторые условия их выполнения. Для большей загадочности в функции `is_ops_commands` проверяемая команда предварительно кодируется и в таком виде сравнивается со значением `xut`:
if ( !is_ops_commands(cmd->prefix) || get_ops_allowed() || get_param_intranet_status())
{
cmd->handle(&input_cmd[cmd->prefix_len], download_base, download_size);
}
else
{
fastboot_fail("unknown command");
}Остается разобраться с функцией get_ops_allowed. Она возвращает некоторое значение op_token_count, которое обнуляется в нескольких случаях: загадочной командой oem unoproot, по истечении 10 загрузок устройства (не во всех случаях) или выполнения команды ops 4F50040TR18FTR7FSTD5F02. Ненулевым значением данная переменная инициализируется только в случае выполнения команды flash:oproot с некоторым подписанным на ключе платформы токеном. Куда интереснее непонятный параметр intranet, выставление которого в значение 3 также приводит к разблокировке описанных выше команд.
3. Как выключить этот режим?
Целью было выключение неведомого режима, а поскольку стандартная реализация fastboot не позволяет отправлять команды типа ops для взаимодействия с устройством, был использован пакет adb для python:
from adb import fastboot
fastboot_dev = fastboot.FastbootCommands()
fastboot_dev.ConnectDevice()
fastboot_dev._SimpleCommand(b"ops 4F50040TR18FTR7FSTD5F01")
fastboot_dev._SimpleCommand(b"ops boottype normal")
fastboot_dev._SimpleCommand(b"ops 4F50040TR18FTR7FSTD5F02")В результате выполнения скрипта root-доступ на устройстве исчез, а выполнение команд ops стало невозможным.
4. А как вернуть это режим?
После выполнения пункта 3 возник вопрос: а возможно ли вернуть этот режим?
Уже после блокировки данного режима выяснилось, что для его разблокировки необходимо иметь специальный подписанный на ключе производителя токен. Получить помещаемые в токен данные можно командой oem oproot, а разблокируется данный режим путем прошивки специального файла oproot (flash:oproot).
Дабы продолжить эксперименты с рутованным девайсом, было принято решение воспользоваться инструментом edl для прошивки на устройство модифицированного раздела param. Путем выполнения нехитрых команд root-доступ был успешно восстановлен:
edl printgpt
edl r param param.bin
py op8t_param.py read -f param.bin
py op8t_param.py write -f param.bin -o param_patched.bin 16 2718
edl w param param_patched.binТакже удивило и то, что в репозитории edl нашелся скрипт oneplus_param.py, судя по всему основанный на результатах исследований APK-файла из выявленного в 2017 году бэкдора.
В скрипте подробно описаны варианты значений различных флагов этого раздела и перечислены команды ops. Также в нем представлен код для генерации QR для разблокировки с использованием инженерного приложения. На прошивке 2021 года данная процедура не актуальна.
Послесловие
Точно выяснить историю включения этого режима на устройстве, увы, уже не представляется возможным. Предположительно его появление связано с перепрошивкой на глобальную версию с помощью MSM Download Tool, проведенной перед продажей устройства. Впоследствии смартфон получал обновления, но активированный режим продолжал функционировать и был замечен благодаря усилению antiroot-механизмов в банковских приложениях.
Надеемся, что данная статья позволила вам глубже погрузиться в особенности работы смартфонов OnePlus и осознать, что даже самые современные устройства могут таить в себе неожиданные сюрпризы. Дальнейшие исследования этого функционала вряд ли имеют смысл, так как сейчас он представляет больше исторический интерес и отсутствует на новых моделях (по крайней мере, проверялся OnePlus 12).
Если у вас есть схожий опыт или интересные мысли по теме, делитесь ими в комментариях!
Автор: RaccoonSecurity
