В тихом омуте… или интересный режим работы смартфона OnePlus 6T

Несколько лет назад один из членов нашей команды заказал себе 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). Наиболее интересным в нем оказался фрагмент, содержащий командную строку запуска ядра:

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:

    ...     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=%s\n", 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). И все это – на заблокированном загрузчике без каких-либо следов вмешательства после восстановления оригинального значения параметров.

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).
Если у вас есть схожий опыт или интересные мысли по теме, делитесь ими в комментариях!