Adbd cannot run as root in production builds android studio

Всего лишь меняем модель эмулятора Android устройства

Пролог

Казалось бы, на первый взгляд весьма простая задача. Некоторые читатели могли еще в те бородатые времена лазить по всяким 4пда, рутить свой сенсорный самсунг, менять содержимое файла build.prop и показывать наивным ламерам свой iPhone 15+ Max Pro. Однако, как оказалось, и как оно часто бывает, не все так просто и здесь есть свои подводные камни. Статья призвана помочь простым работягам избежать все кочки да ямы на пути к своей цели!

Дисклеймер

Сразу предупрежу, что люблю писать подобные статьи довольно подробно, не ради объема и многобукав, а ради максимального погружения в проблему и способ ее решения. Обратите внимание, что я работаю на macOS, поэтому все команды в терминале будут ориентированы под данную ОС. Также, следует отметить, что проворачиваю все это для API 30, то есть для самого последнего на момент написания статьи. Как говорят интернеты, сложности по этой теме начались с API 29.

Зачем это нужно?

Предполагаю, что у вас, дорогой читатель, есть на это своя веская причина, иначе не стали бы вы этим заниматься. Наиболее вероятно, что у вас, как и у меня есть программная проверка на модель устройства с которого запущено приложение, примерно как здесь. К слову, таким образом можно будет проверять результат наших трудов. Второй же, и более простой способ проверки модели эмулятора будет через настройки девайса в разделе сведений об устройстве:

Ради контекста вкратце расскажу зачем это понадобилось мне. Я получил .apk с багом где-то внутри приложения. Однако пройти дальше первого экрана в этом приложении я не смог. Дело в том, что при запуске, с сервера приходит список разрешенных для запуска устройств и ни мой народный Ксяоми, ни мой эмулятор в этот список не входит. Вот и додумался поменять имя модели устройства на одно из разрешенных. Рутить свой личный телефон не хотелось, поэтому решил шаманить с эмулятором.

Экран не пустивший меня дальше

Достаем build.prop

Как уже говорилось в начале статьи, за имя производителя и модель устройства отвечает системный файл build.prop, который находится в корне устройства в папке system/. Однако при попытке просмотреть его, не говоря уже о редактировании, мы получим отказ в доступе:

Для решения этой проблемы необходимо в терминале обратиться к adb и запросить root права следующей командой: adb root . И вот и первый подводный камень, а именно вывод следующего сообщения: adbd cannot run as root in production builds . Это из-за того что при создании эмулятора мы выбрали вариант с установленными Google сервисами:

Простое решение — создать эмулятор без установленных Google сервисов, после чего повторить команду adb root . После чего в консоли должно появиться сообщение: restarting adbd as root что говорит об успешном проведении операции. Естественно если с самого начала у вас был эмулятор без Google сервисов, то скорее всего с adb root и выше описанной проблемой вы не столкнулись.

Отлично, теперь мы видим содержимое файла build.prop:

Редактируем build.prop

Сохраним файл build.prop в любое удобное место для дальнейшего редактирования выделенной красным области на скриншоте выше. Я сохранил прямо на рабочий стол:

Вносим необходимые изменения. Просмотрев логи запросов и ответов предоставленного мне .apk я нашел приходящий с сервера список разрешенных устройств. То есть, для моих целей нужно поменять два значения на PIXEL 3A XL (как вы поняли, здесь вы можете указывать необходимую именно вам модель):

Сохраняем изменения и заливаем файл обратно на эмулятор. Делается это при помощи команды adb push (кстати, скачать файл с эмулятора можно при помощи adb pull если у вас вдруг аллергия на GUI).

Вводим команду в терминал: adb push build.prop system/

И получаем ошибку:

adb: error: failed to copy ‘build.prop’ to ‘system/build.prop’: remote couldn’t create file: Read-only file system

Вот здесь и начинается самое интересное! По умолчанию эмулятор запускается в режиме чтения системных файлов, без возможности делать записи. Следовательно, что либо поменять без прав на запись у нас не выйдет. Для этого нам необходимо запустить эмулятор в ручном режиме с доступом на запись системных файлов.

Запускаем эмулятор с доступом на перезапись системных файлов

Для этого нужно выполнить следующую команду в терминале (чтобы скорее всего получить еще одну ошибку):

emulator -avd Pixel3XLAPI30 -writable-system -no-snapshot -nocache

итак здесь Pixel3XLAPI30 — это название нашего эмулятора который мы будем запускать в режиме записи, получить это имя можно выполнив команду emulator -list-avds

-writable-system — собственно тот самый флаг и виновник торжества.

-no-snapshot -nocache — просто советую ввести чтобы избавиться от любого возможного мусора, который может помешать нашему плану-капкану.

После у нас либо запустится эмулятор (несколько секунд запускается, так что если тупит то так и должно быть) либо получаем ошибку следующего типа:

PANIC: Missing emulator engine program for ‘x86’ CPU.

Что бы и нам решить с этим нужно в файле .bash-profile (или если у вас zsh то в файле .zshenv) находящийся в корне вашего профиля macOS, добавить дополнительные пути. Вот как это выглядит у меня:

есть такая переменная ANDROIDHOME и с ее участием редактируем переменную PATH:

Чтобы изменения вступили в силу перезапускаем терминал (или вводим source

/.bash_profile ) (или source

/.zshenv ). Результат можно проверить выполнив команду echo $PATH и убедиться что в переменной PATH появился добавленный нами путь.

Пробуем запустить эмулятор еще раз.

emulator -avd Pixel3XLAPI30 -writable-system -no-snapshot -nocache

Теперь он должен был успешно запустится.

Активируем доступ на перезапись системных файлов

Из описания флага -writable-system:

-writable-system make system & vendor image writable after ‘adb remount’

делаем вывод что теперь нам нужно выполнить adb remount . Для этого открываем новое окно терминала и выполняем сначала команду adb root , что бы adb remount сработало.

После adb remount , будет сообщение что эмулятор нужно перезапустить. Сделать это можно командой adb reboot. Но и здесь не все так просто. Очередной подводный камень об который мы разбили еще один ноготь на пальцах ног. Если сделать adb reboot то все просто напросто зависает НАВСЕГДА. Настолько навсегда, что придется удалять эмулятор и создавать его заново. Интернет и с этим столкнулся и даже баг создали на гуглов. И благо нашлось решение. Чтобы эмулятор не зависал нужно добавить пару команд до adb remount .

Итак по порядку:

Делаем adb root

Теперь делаем adb shell avbctl disable-verification

Если вы вдруг остались в shell то введите exit

Перезагружаем эмулятор adb reboot и ждем

Снова делаем adb root

И вот теперь можно делать adb remount

Ура! Теперь мы можем записывать файлы в системную папку нашего эмулятора. Можем пушнуть наш отредактированный build.prop файл: adb push build.prop system/ . Сделаем adb reboot и убеждаемся что ничего не поменялось… Имя модели не изменилось.

Редактируем правильный build.prop

Вернемся к началу и заметим, что значения ro.product.product.name и ro.product.product.model не соответствует тому, что отображается в настройках устройства. Изучив структуру системных папок я заметил, что существует несколько файлов build.prop, которые располагаются в папках: system, system_ext, vendor и product. Эмпирическим методом я скачивал, редактировал и пушил обратно каждый из этих файлов. В конце концов ключевым оказался файл в папке product. Отредактировав его я наконец-то смог изменить название модели эмулятора устройства!

Подводим итоги

Наконец-то я смогу запустить приложение и воспроизвести баг. Подумал я…

Теперь я уперся в то, что запускаю приложение якобы с рутованого девайса (ну да есть такой грешок). И дело даже не в команде adb root , ведь команда adb unroot не помогла. Что ж, опускать руки уже поздно, придется что-то придумать.

О том, как я обходил проверку на рутованность устройства я расскажу в следующей своей статье. Немного реверс инжиниринга и даже такая популярная библиотека как RootBeer не проблема.

Данной статьей я стремился собрать как можно больше проблем по этому вопросу и изложить все в форме step-by-step. Спасибо за ваше внимание и очень надеюсь, что статья оказалась полезной!

Источник

adb shell su работает, но adb root — нет

Я рутировал свой разблокированный Galaxy S3 (SGH-T999)

Теперь я пытаюсь запустить adb root из командной строки Windows , но получаю сообщение adbd cannot run as root in production builds об ошибке. Итак, первое, что я проверил, было действительно ли мой телефон рутирован?

Итак, я попробовал следующее:

Открыть командную строку

Однако когда я это делаю adb root , я получаю adbd cannot run as root in production builds ошибку. Так что, подумал я, мне, возможно, придется сделать еще кое-что помимо того, что я сделал выше. Я попробовал все решения в следующих вопросах SO:

У меня ничего из вышеперечисленного не сработало. Все, что они делают, это дают ROOT доступ ВНУТРИ ОБОЛОЧКИ. Я хочу adb root работать так, чтобы я мог выполнять различные команды adb БЕЗ входа в оболочку.

По конструкции adb root команда работает в разработке строит только (то есть eng и userdebug которых есть ro.debuggable=1 по умолчанию). Итак, чтобы включить adb root команду на вашем устройстве с рут- правами, просто добавьте ro.debuggable=1 строку в один из следующих файлов:

Если хотите adb shell запустить как root по умолчанию — то ro.secure=0 тоже добавляйте .

В качестве альтернативы вы можете использовать модифицированный adbd двоичный файл (который не проверяет ro.debuggable )

В некоторых удобных для разработчиков ПЗУ вы можете просто включить рут-доступ в « Настройки»> «Разработчик»> «Корневой доступ» . После этого adb root становится доступным. К сожалению, это не работает для большинства стандартных прошивок на рынке.

Я столкнулся с этой проблемой при попытке получить root-доступ к эмулятору, я обнаружил, что это потому, что я запускал эмулятор Nexus 5x, на котором был Google Play. Создал другой эмулятор, у которого не было Google Play, и он adb root будет рутировать устройство за вас. Надеюсь, это кому-то поможет.

Я использую для входа в режим su в оболочке abd

У меня рутированный Samsung Galaxy Trend Plus (GT-S7580).

Запуск ‘adb root’ дает мне ту же ошибку ‘adbd не может работать как root в производственных сборках’.

Для устройств, у которых есть параметры разработчика -> Root-доступ, выберите «ADB only», чтобы предоставить устройству root-доступ по adb (как предлагает NgaNguyenDuy ).

Затем попробуйте выполнить команду в соответствии с решением в разделе Запуск сценария от имени пользователя root через ADB . В моем случае я просто хотел запустить команду netcfg rndis0 dhcp, и сделал это следующим образом:

Пожалуйста, проверьте, не допускаете ли вы ошибок при использовании этого способа.

Если он по-прежнему не работает, проверьте, правильно ли вы рутировали устройство. Если по-прежнему не повезло, попробуйте установить пользовательское ПЗУ, такое как Cyanogen Mod, чтобы «adb root» работал.

Вам необходимо заменить двоичный файл adbd в папке boot.img / sbin / на тот, который поддерживает su. Вам также придется внести некоторые правки в default.prop.

Samsung, похоже, делает это сложнее, чем другие производители. У меня есть несколько двоичных файлов adbd, которые вы можете попробовать, но для этого потребуются знания о декомпиляции и повторной компиляции boot.img с новым двоичным кодом. Кроме того, если у вас заблокирован загрузчик . этого не произойдет.

Также у Chainfire есть приложение, которое будет предоставлять root-права adbd в игровом магазине: https://play.google.com/store/apps/details?id=eu.chainfire.adbd&hl=en

Наконец, если вы пытаетесь написать сценарий Windows с разрешениями SU, вы можете сделать это, используя следующий стиль команд . Однако вам, по крайней мере, потребуется предоставить (по телефону) разрешения SU при первом запуске .. .

adb shell «su -c ls» /data/test.file»

Это всего лишь несколько примеров. Если вы конкретно укажете, чего вы пытаетесь достичь, я могу дать более конкретный совет.

Источник

Про production build и root. Часть 1.

Про production build и root. Часть 1.

В сети легко найти как получить рут доступ для почти любого устройства на Android. Программы для этого и методики отличаются, но вариант всегда есть. Большинство, получив рут, даже не задумываются о том, как он был получен. Я не смогу рассказать про все способы и как они работают. Но я смогу рассказать про одну интересную вещь, которая связана с получение root доступа.

Я предполагаю, что читатели хотя бы поверхностно знаю об утилите для Android — ADB. Если кто-то еще не слышал, можете легко поиском найти что это такое. Это утилита для отладки устройств. С её помощью можно получить доступ к командной строке (shell) устройства на Android, передавать и принимать файлы и делать много интересных вещей. В большинстве скриптов для получения рута или всяких модов для вашего устройства так или иначе используется ADB.

У ADB есть команда root. Она должна перевести режим работы в root доступ. Казалось бы так можно элементарно получить рут на любом устройстве. Но работает она не всегда. Часто, даже на устройстве с уже полученными root правами при попытке выполнить «adb root» можно получить следующую ошибку:

adb cannot run as root in production builds

Что значит, что ADB не будет запускаться из-под root’а в продакшен (финальном) билде (речь о прошивке). Если у вас есть рут, вы можете и без этого зайти в шелл (adb shell), и уже там получить root права, набрав su. При этом adb root упорно не будет работать, сетуя на продакшен билд.

Сделано это конечно же специально, чтобы не дать получить root на реальных устройствах для конечных пользователей. С другой стороны некоторые прошивки без проблем дают выполнить эту команду или даже скажут, что ADB уже работает от root’а, если в них это разрешено.

Раз работает по разному в разных прошивках, догадливый читатель поймет, что это может регулироваться какой-то настройкой. И если эту настройку сменить, то можно будет получить root просто через adb root. Конечно же так и есть. Но конечно же эта настройка храниться в «недрах» прошивки и просто так её поменять не дадут. Во всяком случае в современных прошивках без наличия root прав заранее точно не получится «на лету».

Настройки эти являются обычными свойствами (prop), навроде тех, что хранятся в build.prop. Называются ro.debuggable и ro.secure. Только хранятся они в /default.prop. Т.е. в отличии от build.prop, которых хранится в /system, эти хранятся прямо в корне. Проблема в том, что даже если при наличии root прав отредактировать этот файл, то изменения не вступят в силу, а после перезагрузки содержимое файла вернется назад.

Дело в том, что default.prop, как и вся корневая файловая система в Android не является обычной. Это специально подготовленный образ ramdisk. Т.е. он загружается из прошивки в память (ОЗУ) и все изменения происходят только в памяти. Следовательно после перезагрузки все изменения теряются. Для их редактирования нужно снять образ раздела BOOT, распаковать его, достать оттуда образ ramdisk’а (initramfs) и отредактировать в нём default.prop. Далее проделать всё в обратном порядке. Но как записать данные назад, если нет доступа? Хорошо, если root у нас уже есть и мы просто хотим напрямую разрешить adb root по каким-то причинам. А если root еще нет? Получается проблема — чтобы получить root, нужно иметь root.

Чтобы статья не получилась слишком длинная, я разбил её на две части. Продолжение о том, как можно обойти это дело вы сможете прочитать в следующей части.

Источник