Телевизор 

Dmesg linux что делает. Анализ логов с помощью dmesg. А что же HAL

Иногда во время работы какой-либо системы, будь то домашний персональный компьютер или мощный сервер, обслуживающий множество подключений, полезно иметь под рукой инструмент, способный отобразить данные о сетевой активности. Для чего это может понадобиться? Для вычисления приложений, нелегально выходящих в Сеть интернет, или же пользователей. Именно этим и занимается рассматриваемая нами утилита.

Что такое Netstat?

Это такое приложение, с помощью которого можно узнать, что происходит в данный момент в Сети. Для запуска используется командная строка. В ней же при запуске Netstat используются дополнительные ключи и параметры.

Стоит отметить, что название утилиты образовано из двух составляющих - network statistics, то есть сетевая статистика, что, в принципе, логично. Среди информации, которую показывает программа, можно выделить статистику подключений маршрутизации.

Команды и ключи

Синтаксис ключей и параметров команды довольно обширен. Это позволяет получить сетевую статистику на самых разных уровнях. Далее пойдет описание команды Netstat, ее параметры и ключи:

  • -a - запуск с данным параметром выведет на экран все активные подключения TCP, а также порты TCP и UDP, прослушиваемые системой;
  • -e - отображение расширенной статистики Ethernet, например, о перемещении байтов и пакетов;
  • -n - параметр позволяет показать активные подключения TCP с адресами и номерами портов;
  • -o - так же, как и предыдущий ключ, выводит активные TCP подключения, но в статистику добавлены коды процессов, по ним уже можно точно определить, какое именно приложение использует подключение;
  • -p - отображение информации по определенному протоколу, указанному в параметре. Среди значений может быть tcp, udp, tcpv6 и udpv6;

  • -s - вывод на экран статистики по протоколу, по умолчанию отобразятся все известные типы;
  • -r - данный ключ выведет содержимое IP, параметр равносилен использованию команды route;
  • интервал - в общей строке команды можно использовать значение интервала, через который будет происходить отображение выбранной статистики; если он опущен, то информация отобразится всего один раз;
  • /? - выведет справочную информацию по команде Netstat.

Использование Netstat в Windows

Для того чтобы вывести на экран командной строки все соединения, при этом разместив их на нескольких страницах, нужно использовать такой синтаксис: «-a | more». Если нужно сохранить всю статистику в определенный файл, нужно использовать « -a > C:\имя файла». Таким образом, в файл, указанный по данному пути, будет записана вся собранная информация.

Результатом работы может выступать небольшая таблица, которая содержит следующие типы данных:

  • Имя. Здесь указывается название найденного активного протокола.
  • Локальный адрес. IP-адрес и порт, использующиеся локальным сервисом для создания соединения. Среди значений может встречаться 0.0.0.0, что означает любой доступный адрес или 127.0.0.1. Это говорит о локальной петле.
  • Внешний адрес. IP и порт внешней службы в сети, с которой установлено соединение.

  • Состояние. Показывает текущий статус соединения. Может принимать разные значения. Например, Listening говорит о том, что служба «слушает» и ждет входящего подключения. Established означает активное соединение.

Netstat, запущенная с ключами -a и -b, покажет все сетевые подключения, а также связанные с ними программы. Это очень удобно, если нужно вычислить, какая программа активно использует трафик и куда отсылает данные.

Дополнительные состояния соединений

Помимо указанных выше состояний соединений, имеются и дополнительные:

  • closed - как следует из названия, соединение находится в закрытом виде;
  • syn_sent - происходит активная попытка установить подключение;
  • syn_received - показывает начальный этап синхронизации;
  • close_wait - отключен, и происходит завершение соединения.

Использование Netstat в Linux

Применение утилиты в среде Linux, по сути, мало чем отличается от Windows. Есть всего лишь небольшие отличия в параметрах команды. Описание команды Netstat и ее параметров с примерами:

  • Чтобы отобразить все порты, нужно использовать команду - «netstat -a».
  • Все то же самое, но только типа TCP - «-at».
  • UDP порты - «-au».
  • Отобразить в Netstat открытые порты - «-l». Их состояние будет отражено как Listening.
  • Отобразить в Netstat открытые порты TCP - «netstat -lt.
  • Вывод идентификатора процесса и его имени - «netstat -p».
  • Показать статистику для отдельного - «netstat -s».

Иногда, чтобы получить более полную информацию о каком-либо сетевом соединении, нужно совместить Netstat с некоторыи командами и утилитами Linux. Например, так:

netstat -ap | grep ssh

Данная строка выведет на экран список портов, которые в данный момент используется утилитой SSH. Если, наоборот, нужно узнать, какой процесс занимает определенный порт, можно использовать следующий синтаксис:

netstat -an | grep `:80`

Также для Netstat в Linux имеется универсальный набор ключей, способный отобразить все необходимое сразу. Выглядит он так: netstat -lnptux. В наборе данных будут отражены все протоколы TCP, UDP, UNIX Socket, названия процессов и их идентификаторов.

Несколько примеров для определения атаки типа DoS или DDoS

Следующая команда позволит узнать, сколько подключений активно на каждом IP-адресе:

netstat -naltp | grep ESTABLISHED | awk "{print $5}" | awk -F: "{print $1}" | sort -n | uniq -c

Определяем большое количество запросов с одного IP-адреса:

netstat -na | grep:80 | sort

Определяем точное количество запросов, полученных на одно соединение:

netstat -np | grep SYN_RECV | wc -l

При проведении DoS-атаки число, полученное в результате работы данной команды, должно быть довольно большим. В любом случае оно может зависеть от конкретной системы. То есть на одном сервере оно может быть одним, на другом - иным.

Заключение

В какой операционной системы бы не использовалась команда, она является незаменимым инструментом для сканирования, анализа и отладки сети. Ее активно используют системные администраторы всего мира.

Netstat можно использовать при заражении системы каким-либо вирусным программным обеспечением. Она способна показать все приложения с большой активностью подозрительного сетевого трафика. Это поможет на ранних этапах выявить вредное ПО и нейтрализовать его или же защитить сервер от нежелательного вторжения злоумышленников.

Выводы

В статье было дано подробное описание команды Netstat и её параметров и ключей. Полноценное использование программы возможно после нескольких этапов практики на реальном устройстве. Совмещение с другими командами придаст ей еще больше эффективности. Полный набор описания команд Netstat можно найти в руководстве на официальном сайте утилиты. Также стоит отметить, что при использовании в среде Linux команда Netstat устарела и вместо нее настоятельно рекомендуют использовать SS.

Системные администраторы, да и обычные пользователи Linux, часто должны смотреть лог файлы для устранения неполадок. На самом деле, это первое, что должен сделать любой сисадмин при возникновении любой ошибки в системе.

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

В этой статье мы рассмотрим основные части системы логирования в Linux, файлы логов, а также утилиты, с помощью которых можно посмотреть логи Linux.

Большинство файлов логов Linux находятся в папке /var/log/ Вы можете список файлов логов для вашей системы с помощью команды ls:

Rw-r--r-- 1 root root 52198 май 10 11:03 alternatives.log
drwxr-x--- 2 root root 4096 ноя 14 15:07 apache2
drwxr-xr-x 2 root root 4096 апр 25 12:31 apparmor
drwx------ 2 root root 4096 май 5 10:15 audit
-rw-r--r-- 1 root root 33100 май 10 10:33 boot.log

Ниже мы рассмотрим 20 различных файлов логов Linux, размещенных в каталоге /var/log/. Некоторых из этих логов встречаются только в определенных дистрибутивах, например, dpkg.log встречается только в системах, основанных на Debian.

/var/log/messages - содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы. В этот лог записываются несколько типов сообщений: это почта, cron, различные сервисы, ядро, аутентификация и другие.

/var/log/dmesg - содержит сообщения, полученные от ядра. Регистрирует много сообщений еще на этапе загрузки, в них отображается информация об аппаратных устройствах, которые инициализируются в процессе загрузки. Можно сказать это еще один лог системы Linux. Количество сообщений в логе ограничено, и когда файл будет переполнен, с каждым новым сообщением старые будут перезаписаны. Вы также можете посмотреть сообщения из этого лога с помощью команды dmseg.

/var/log/auth.log - содержит информацию об авторизации пользователей в системе, включая пользовательские логины и механизмы аутентификации, которые были использованы.

/var/log/boot.log - Содержит информацию, которая регистрируется при загрузке системы.

/var/log/daemon.log - Включает сообщения от различных фоновых демонов

/var/log/kern.log - Тоже содержит сообщения от ядра, полезны при устранении ошибок пользовательских модулей, встроенных в ядро.

/var/log/lastlog - Отображает информацию о последней сессии всех пользователей. Это нетекстовый файл, для его просмотра необходимо использовать команду lastlog.

/var/log/maillog /var/log/mail.log - журналы сервера электронной почты, запущенного в системе.

/var/log/user.log - Информация из всех журналов на уровне пользователей.

/var/log/Xorg.x.log - Лог сообщений Х сервера.

/var/log/alternatives.log - Информация о работе программы update-alternatives. Это символические ссылки на команды или библиотеки по умолчанию.

/var/log/btmp - лог файл Linux содержит информацию о неудачных попытках входа. Для просмотра файла удобно использовать команду last -f /var/log/btmp

/var/log/cups - Все сообщения, связанные с печатью и принтерами.

/var/log/anaconda.log - все сообщения, зарегистрированные при установке сохраняются в этом файле

/var/log/yum.log - регистрирует всю информацию об установке пакетов с помощью Yum.

/var/log/cron - Всякий раз когда демон Cron запускает выполнения программы, он записывает отчет и сообщения самой программы в этом файле.

/var/log/secure - содержит информацию, относящуюся к аутентификации и авторизации. Например, SSHd регистрирует здесь все, в том числе неудачные попытки входа в систему.

/var/log/wtmp или /var/log/utmp - системные логи Linux, содержат журнал входов пользователей в систему. С помощью команды wtmp вы можете узнать кто и когда вошел в систему.

/var/log/faillog - лог системы linux, содержит неудачные попытки входа в систему. Используйте команду faillog, чтобы отобразить содержимое этого файла.

/var/log/mysqld.log - файлы логов Linux от сервера баз данных MySQL.

/var/log/httpd/ или /var/log/apache2 - лог файлы linux11 веб-сервера Apache. Логи доступа находятся в файле access_log, а ошибок в error_log

/var/log/lighttpd/ - логи linux веб-сервера lighttpd

/var/log/conman/ - файлы логов клиента ConMan,

/var/log/mail/ - в этом каталоге содержатся дополнительные логи почтового сервера

/var/log/prelink/ - Программа Prelink связывает библиотеки и исполняемые файлы, чтобы ускорить процесс их загрузки. /var/log/prelink/prelink.log содержит информацию о.so файлах, которые были изменены программой.

/var/log/audit/ - Содержит информацию, созданную демоном аудита auditd.

/var/log/setroubleshoot/ - SE Linux использует демон setroubleshootd (SE Trouble Shoot Daemon) для уведомления о проблемах с безопасностью. В этом журнале находятся сообщения этой программы.

/var/log/samba/ - содержит информацию и журналы файлового сервера Samba, который используется для подключения к общим папкам Windows.

/var/log/sa/ - Содержит.cap файлы, собранные пакетом Sysstat.

/var/log/sssd/ - Используется системным демоном безопасности, который управляет удаленным доступом к каталогам и механизмами аутентификации.

Просмотр логов в Linux

Чтобы посмотреть логи на Linux удобно использовать несколько утилит командной строки Linux. Это может быть любой текстовый редактор, или специальная утилита. Скорее всего, вам понадобятся права суперпользователя для того чтобы посмотреть логи в Linux. Вот команды, которые чаще всего используются для этих целей:

  • zgrep
  • zmore

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

Смотрим лог /var/log/messages, с возможностью прокрутки:

less /var/log/messages

Просмотр логов Linux, в реальном времени:

tail -f /var/log/messages

Открываем лог файл dmesg:

cat /var/log/dmesg

Первые строки dmesg:

head /var/log/dmesg

Выводим только ошибки из /var/log/messages:

grep -i error /var/log/messages

Кроме того, посмотреть логи на linux можно и с помощью графических утилит. Программа System Log Viewer может быть использована для удобного просмотра и отслеживания системных журналов на ноутбуке или персональном компьютере с Linux.

Вы можете установить программу в любой системе с установленным X сервером. Также для просмотра логов может использоваться любой графический тестовый редактор.

Выводы

В каталоге /var/log вы можете найти всю необходимую информацию о работе Linux. Из сегодняшней статьи вы достаточно узнали, чтобы знать где искать, и что искать. Теперь просмотр логов в Linux не вызовет у вас проблем. Если остались вопросы, задавайте в комментариях!


Если коротко, то:

  • контекст процесса SELinux менять можно, если подобная операция описана в правилах sepolicy. В версии Android 4.4 (KitKat) есть возможность повысить привилегии, изменяя контекст. Но начиная с 5.x это уже сделать нельзя.
  • существуют контексты файлов.
  • Кроме контекста файлов и процессов в Android реализованы контексты для параметров property_contexts .

adbd и консоль

Единственный доступный способ получения относительно привилегированного shell в production устройствах Android - developer mode. Developer mode запускает демон adbd, который может выступать в том числе и как аналог ssh/telnet. В Android KitKat он находится в initramfs по пути /sbin/adbd и не доступен для чтения для не-root пользователей. Изначально adbd запускается под пользователем root и работает в SELinux контексте/домене init (используется процессом init и как правило имеет больше привилегий, чем другие домены). Если в /init.rc явно указан контекст процесса, например seclabel u:r:adbd:s0 , то процесс запускается сразу в указанном контексте. При инициализации adbd в зависимости от параметров компиляции ( и параметров Android (properties) понижает привилегии, а именно меняет текущего пользователя с root на shell, устанавливает SELinux context в shell и урезает все системные capabilities кроме CAP_SETUID и CAP_SETGID (что требуется для отладки приложений через run-as). Так называемый Capability Bounding Set не позволяет дочерним приложениям повышать capabilities, только понижать. Эти привилегии позволяют делать на телефоне чуть больше, чем ничего. Просмотреть capabilities текущего процесса можно командой cat /proc/self/status | grep CapBnd . А расшифровать их можно с помощью команды capsh (не доступна на Android), например:


$ capsh --decode=0000001fffffffff

Текущий SELinux context можно просмотреть командой id или cat /proc/self/attr/current . Предыдущий контекст процесса можно просмотреть командой cat /proc/self/attr/prev .


Просмотр context"а файлов: ls -Z
Просмотр context"а запущенных процессов: ps -Z

Получаем root доступ

root, да не тот

Первое, что я сделал это использовал dirtycow по прямому назначению - подменил /system/bin/run-as , который задал UID/GID в 0 (тоже самое делает su). Однако монтировать файловую систему я не мог, даже tmpfs. Загружать модули ядра я тоже не мог. Просматривать dmesg - нет. Я даже не мог просматривать директории, которые имели права 700 и принадлежали другим системным пользователям. Я мог лишь читать и писать в блочные устройства, а просмотр файлов или директорий был возможен благодаря заданию UID/GID определенного пользователя (написал свой велосипед - аналог su, который мог задавать selinux context и пользователя/группу).


Первым делом я сделал дамп всей прошивки, boot и recovery:


$ dd if=/dev/block/mmcblk0 of=/storage/sdcard1/mmcblk0.img $ dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/storage/sdcard1/boot.img $ dd if=/dev/block/platform/msm_sdcc.1/by-name/recovery of=/storage/sdcard1/recovery.img

Изучить дамп можно утилитами kpartx и unpackbootimg . Команда kpartx -a mmbblk0.img создает виртуальное блочное устройство, доступное по пути /dev/mapper/loop0 . С ним можно работать как с любым другим блочным устройством. Дампы разделов boot и recovery распаковал утилитой unpackbootimg .


Потом попробовал записать в recovery /dev/zero , проверить и сразу восстановить из дампа.


Раз я мог писать в блочные устройства, значит я мог записать custom recovery. Нашел TWRP от Brigadier, прошил в recovery и перезагрузился в него adb reboot recovery . TWRP я не увидел, а лишь иконку Android"а с восклицательным знаком. Так выглядит стандартный recovery, а значит TWRP не прошился.


Перезагружаюсь в обычный режим, запускаю эксплойт, проверяю hash recovery раздела - hash соответствует оригинальному. Пробую записать данные опять - hash поменялся! Вспоминаю про page cache, чищу (echo 3 > /proc/sys/vm/drop_caches) - hash старый. Т.е. всё, что я пишу в блочное устройство улетает без ошибок в /dev/null и иногда оседает в Linux cache. Но обновление прошивки ведь как-то происходит? И пользовательские данные как-то записываются во внутреннюю память. Надо копать дальше.

Пробуем отключить SELinux

На тот момент я думал, что все ошибки об отсутствии привилегий вызваны SELinux (я полностью забыл о том, что могут быть урезаны capabilities). Логов dmesg я не видел, logcat ничего релевантного не показывал. И я начал думать как отключить SELinux.


Первая зацепка, которую я смог найти:


$ grep -A2 reload_policy boot/ramfs/init.rc on property:selinux.reload_policy=1 restart ueventd restart installd

Т.е. перед тем как применить ZIP, recovery отмонтирует все разделы, но в моём случае что-то идёт не так.

Копаем исходники ядра

Лицензия GPL обязывает производителей смартфонов выкладывать исходники ядра. Спасибо Линусу и Столлману за это. Иногда производители выкладывают что-то левое, иногда правильные исходники, но без defconfig файла, иногда правильные и очень редко с инструкцией как их собирать (например LG).


В моём случае были исходники с правильным defconfig но без инструкции. Немного попотев я смог собрать ядро и убедился, что это не полная липа.


Через продолжительное время я остановился на двух файлах:

hooks

Kyocera долго не думала, а просто запилила хуки на потенциально опасные операции в Android: mount , umount , insmod (к загрузке разрешен всего один модуль - wlan и только если его загрузит init процесс), и прочее. Вот где крылась проблема recovery. Он не мог отмонтировать файловую систему /system ! Эти операции позволялись только init процессу. В том числе я не мог отключить SELinux потому что эта возможность была отключена при компиляции ядра. Обойти эти хуки можно было только, если ядро загружено с определенными параметрами (kcdroidboot.mode=f-ksg или androidboot.mode=kcfactory , о них чуть позже).

restart

Тоже интересный для изучения файл. В нем описываются возможные варианты загрузки телефона:

  • adb reboot bootloader - режим fastboot, в моём телефоне не доступен (0x77665500 - hex метка 00556677 в разделе sbl1)
  • adb reboot recovery - режим recovery (0x77665502 - hex метка 02556677 в разделе sbl1)
  • adb reboot rtc - так называемый ALARM_BOOT. Так и не понял для чего, метки в sbl1 нет. Возможно имеется в виду https://developer.android.com/reference/android/app/AlarmManager.html
  • adb reboot oem-X (в моём случае oem-1, 0x6f656d01 - hex метка 016d656f в разделе sbl1). Что происходит во время этого режима устанавливается производителем. Судя по исходникам, в этот режим телефон перезагружается при ошибке аутентификации прошивок из раздела modem.
  • adb reboot edl - emergency download, переводит телефон в штатный qualcomm"овский download mode. Телефон определяется как QHSUSB__BULK COM port, по которому можно передать подписанный загрузчик (если не ошибаюсь, то каждый загрузчик предназначен для одного типа SoC и производителя телефонов) и выполнять низкоуровневые операции с телефоном, в том числе и прошить. Обычно используется вкупе с QPST. Для некоторых телефонов загрузчики утекают в сеть, например для Kyocera KYL22. Откуда они берутся - мне неизвестно.
  • Некий download mode , в который через adb reboot не зайти. Вот тут интересно… Но об этом позже.

Немного о том, как происходит загрузка на телефонах с процессором Qualcomm:


Встроенный ROM загрузчик Qualcomm (pbl - primary bootloader) загружает раздел sbl1 (secondary bootloader). sbl1 загружает tz (trust zone), затем aboot (android boot, little kernel, lk). Aboot в свою очередь загружает boot, recovery или fota.


Описание разделов, участвующих при загрузке:

  • tz - Qualcomm Trust Zone. Выполняет низкоуровневые операции, в том числе работает с QFuses (раздел rpmb).
  • rpm - Resource and Power Manager firmware. Прошивка для специализированного SoC, отвечающего за ресурсы и питание.
  • sdi - trust zone storage partition. Данные, которые используются Trust Zone.

Все эти разделы подписаны цепочкой сертификатов.

fota

В некоторых случаях полезно игнорировать обновления прошивки.


FOTA - firmware over the air. В отличие от boot и recovery, fota - это неофициальный режим загрузки Android. Задача fota - обновить прошивку. В Kyocera для этого используется решение от компании Red Bend , которое в 35Mb умещает обновление не только ядра но и раздела /system . Потому запись в раздел /system запрещена, иначе наложение патча на неправильные данные может окирпичить телефон.


На мой телефон имелось обновление. Отважиться на него я мог потому, что я уже имел возможность писать в /cache и прервать обновление в любой момент.


Изучив исходники отвечающего за обновление Java приложения , мне стало ясно как оно происходит:

  • Java приложение скачивает специальный файл /cache/delta/boot_delta.bin , создает файл /cache/delta/Alt-OTA_dlcomplete , подтверждающий успешную загрузку файла, и другие файлы с header"ами.
  • При подтверждении обновления еще раз проверяется наличие этих файлов.
  • Если файлы на месте, то через библиотеку libjnialtota.so происходит модификация раздела fotamng .

Пишу команду, которая непрерывно делает дамп раздела и переименовывает /cache/delta/boot_delta.bin . Запускаю её сразу после соглашения о перезагрузки телефона. Телефон перезагружается в режим FOTA, рапортует об отсутствии обновления и перезагружается в обычный режим.


Начинаю изучать данные, которые сдампил. В разделе /cache бонусом получаю логи fota, в которых даже есть логи dmseg! Сама перезагрузка в fota инициализируется байтами "1" в разделе fotamng:


$ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=16 bs=1 count=1 $ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=24 bs=1 count=1 $ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=131088 bs=1 count=1 $ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=131096 bs=1 count=1

После перезагрузки они обнуляются. В dmesg я обратил внимание на наличие параметра ядра kcdroidboot.mode=f-ksg . Вот оно! Т.е. загрузчик снимает защиту для fota. И чисто теоретически, если я запишу раздел boot в fota и перезагружу телефон в этот режим, то я получу ядро с отключенной защитой Kyocera. Но писать в системные разделы я всё еще не могу.

Изучение исходников little kernel (lk)

То, что находится в разделе aboot - загрузчик Android, ванильные исходники которого находятся по адресу:


Там можно найти и информацию как происходит загрузка в некоторые из режимов. Например я нашел информацию о том, что если в раздел misc записать "boot-recovery", то без adb reboot recovery . При загрузке в recovery эта . И если recovery загрузиться не может, то телефон попадёт в boot loop и вы его потеряете. Так что будьте осторожны, а лучше избегайте этого варианта перезагрузки.


Там же можно найти код, который переводит системную область emmc в режим . Ответ на вопрос, почему невозможно перезаписать recovery. Эту защиту можно отключить из ядра Linux , если написать соответствующий модуль ядра. Уже всё написано товарищем из страны восходящего солнца, который, похоже, тоже неровно дышит к телефонам компании Kyocera. Модуль с первого раза не сработал, иногда подвешивает mmc в claim mode. Возможно не всё так однозначно и требуется детальное исследование.


Вот так происходит проверка подписи загрузочных разделов:

Первые успехи

dmesg

Google мне помог ответить на вопрос, почему я не могу прочитать логи ядра: /proc/sys/kernel/dmesg_restrict . Значение этого параметра задается в 1 во время загрузки телефона. Если у пользователя нет CAP_SYS_ADMIN capability, то логи ему не доступны.

uevent_helper

В моём случае, на удивление, была возможность задать /sys/kernel/uevent_helper . Если в этот параметр записать путь до executable файла (shell script тоже сойдёт), то он с определенным интервалом будет запускаться от процесса init в контексте init и что самое важное с full capabilities.


Я написал скрипт:


#!/system/bin/sh echo 0 > /proc/sys/kernel/dmesg_restrict

Загрузил его на телефон и записал его путь в /sys/kernel/uevent_helper . У меня появилась возможность видеть dmesg!

Патченный adbd


Т.к. мне надоело иметь доступ к урезанной консоли Android, а патчить бинарник adbd мне лень, то я решил собрать свой adbd с блэкджеком и шлюхами. Для этого пришлось скачать 70 Gb исходников Android, чтобы не возиться с каждой зависимостью по отдельности. Убрал проверку при которой происходит урезание capabilities, скомпилировал, подменил /sbin/adbd и получил полноценную root консоль. Теперь я могу монтировать файловые системы, смотреть dmesg без отключения dmesg_restrict , спокойно просматривать и редактировать файлы, которые не принадлежат root и многое другое. Но я пока не могу монтировать /system раздел и загружать модули в ядро.


Кстати, этой процедуры можно избежать, скомпилировав lsh и подставить его путь в /sys/kernel/uevent_helper . Желательно обернув запуск lsh в скрипт, который задаёт PATH environment, иначе придется задавать полный путь к каждой команде.

WiFi

WiFi в моем телефоне работает через модуль ядра. WiFi включен - модуль загружен. WiFi выключен - модуль выгружен. Если подменить модуль на свой, то при включении WiFi должен загрузиться подставной модуль. На моё счастье цифровая подпись модулей не проверялась. Первое, что я попробовал, это собрать и загрузить модуль, который отключает SELinux путем замены памяти ядра на Amazon Fire Phone: https://github.com/chaosmaster/ford_selinux_permissive


Чтобы собрать модуль, требуется более-менее соответствующие исходники ядра и файл Module.symvers. Если исходники точно соответствуют тому ядру, что используется на телефоне, то Module.symvers , сгенерированный автоматически при сборке ядра должен подойти.


Если при загрузке модуля ядро будет ругаться (disagrees about version of symbol module_layout ), то потребуется извлечь Module.symvers из boot раздела. Это можно сделать, используя скрипт https://github.com/glandium/extract-symvers :


$ unpackbootimg -i boot.img -o boot $ extract-symvers.py -e le -B 0xc0008000 boot/boot.img-zImage > %PATH_TO_KERNEL%/Module.symvers

Нельзя просто так взять и собрать свой модуль для телефона Kyocera.




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


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


P.S. Огромное спасибо Николаю Еленкову (Nikolay Elenkov), автору книги Android security internals . Его пояснения о работе bootloader"а помогли понять процесс загрузки Android.


P.P.S. Еще один специалист по мобильной ИБ, Justin Case, сказал, что он знает уязвимость, которой подвержены все современные процессоры Qualcomm, но раскрывать её детали он не будет.

Теги:

  • android
  • bootloader Отправить анонимно