Диагностика оборудования — достаточно важный вопрос, который никак нельзя упускать. Именно поэтому в серию «Шпаргалка сисадмина» для ОС Debian я не могу не добавить статью о средствах получения информации об устройствах. На этот раз я постараюсь коротко рассказать об основных утилитах для диагностики тех или иных компонентов сервера. Начну конечно же со встроенных по умолчанию в систему средств, поскольку знать их и уметь пользоваться должен любой сисадмин. Далее будет обзор пакетов с общим назначением. В конечно счете подойдем к знакомству с дополнительными расширенными инструментами, которые каждый может поставить по желанию.

Узнать информацию о процессоре можно с помощью команды:
root@debian7:~# cat /proc/cpuinfo

Или некоторые другие данные:
root@debian7:~# lscpu

Оперативная память

Краткая информация об использовании памяти:
root@debian7:~# free -m

Утилита также выводит информацию об использовании свопа. Вместо ключа -m, может быть даже лучше использовать -h — получите данные с обозначениями объема.

Расширенная информация:
root@debian7:~# cat /proc/meminfo

Жесткие диски

Отобразить список существующих разделов:
root@debian7:~# fdisk -l

Стоит отметить, что основное назначение утилиты fdisk — управление разделами дисков.

Вывести UUID и тип файловой системы для каждого раздела можно с помощью команды:
root@debian7:~# blkid

Информацию о разделах, точках монтирования и некоторые другие данные можно получить с помощью утилиты lsblk
root@debian7:~# lsblk

Команда отображает все блочные устройства в древовидной структуре.

Сеть

Информация об интерфейсах:
root@debian7:~# ifconfig

Подробная информация о сетевой карте
root@debian7:~# mii-tool -v

Для проверки доступности узлов используйте общеизвестную утилиту ping.

Утилиты общего назначения

top

Утилита top служит для отображения информации о процессах и ресурсах, которые они потребляют. Информация обновляется с определенной периодичностью. Данные можно отсортировать, например, по использованию процессорной мощности или оперативной памяти (по умолчанию идет сортировка по CPU).
root@debian7:~# top

dmidecode

Получить подробную информацию об аппаратном обеспечении можно с помощью dmidecode. Утилита предоставляет данных, полученные от BIOS. В описании пакета приводится следующая справка:

Эта информация обычно включает в себя производителя системы, название модели, серийный номер, версию BIOS, дескриптор ресурса (asset tag) а также другую информацию различного уровня интереса и достоверности, устанавливаемую производителем. Часто содержит состояние занятых процессорных сокетов, слотов расширения (например, AGP, PCI, ISA), слотов памяти и список портов ввода/вывода (например, последовательные и параллельные порты, USB).

Помните, что данные, выдаваемые DMI, не настолько надёжные, чтобы им слепо доверять. Dmidecode не сканирует аппаратное обеспечение, он просто выводит те данные, которые ему предоставляет BIOS.

root@debian7:~# dmidecode

Вывод команды без аргументов слишком объемный, лучше использовать ключ —type и получать только необходимые разделы, например:
root@debian7:~# dmidecode —type 5,6

Команда выведет тип контроллера памяти и используемые модули RAM.

dmesg

Команда используется для вывода буфера сообщений ядра. С точки зрения аппаратного обеспечения, вывод может быть полезен для анализа проблем с оборудованием, да и вообще для полного представления имеющегося «железа». Вывод команды слишком объемный и для его анализа могут понадобиться другие инструменты, например, можно воспользоваться выводом в файл, можно перенаправить вывод команде less, а можно с помощью grep найти необходимые вам аппаратные компоненты.
root@debian7:~# dmesg | grep processor

Команда выведет только строки, содержащие слово processor.

lspci

Утилитой удобно пользоваться для вывода списка всех устройств, подключенных к pci-шине. Информация может быть использована в диагностических целях, а также для определения установленных устройств.
root@debian7:~# lspci

Используйте ключ -t для отображения информации в древовидном представлении, в котором будут отображены все шины и устройства, подключенные к ним. Ключи -v, -vv, -vvv отображают дополнительную информацию по каждому устройству; чем больше «v», тем более подробно выводятся данные.

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

vmstat

Показывает сводную информацию о состоянии виртуальной памяти, а также о свопе.
root@debian7:~# vmstat 2

Команда выше будет выводить обновленные данные каждые 2 секунды (вместо 2 можете указать любое другое число).

sysctl

Хоть и утилита предназначена главным образом для управления параметрами ядра на лету, анализ установленных значений может помочь в диагностике проблем.
root@debian7:~# sysctl -a

Команда отобразит все переменные и их значения.

Дополнительные утилиты

Все описанные ниже утилиты не входят в стандартную конфигурацию Debian, придется из ставить отдельно.

htop

Более сильная замена штатной утилиты top. В стандартной конфигурации с системой не поставляется. Предоставляет удобный интерактивный интерфейс со встроенной справкой и обновлением данных в реальном времени.
root@debian7:~# htop -d 10

Ключ -d выставляет значение в десятых долях секунды для обновления данных. Ключ -c переключает программу в монохромный режим работы.

lshw

Утилита предназначена для вывода подробной информации об аппаратном обеспечении. Наиболее удобно экспортировать данные в.html-вид и просматривать в браузере. Такой способ, конечно же, исключается при работе в консольном режиме, разве что если просматривать данные на другой системе.
root@debian7:~# lshw -C network

Команда выведет данные только о сетевой плате.

smartmontools

Пакет состоит из двух утилит (smartctl и smartd), которые следят за S.M.A.R.T-показателями жестких дисков. Для запуска демона необходимо произвести ряд настроек:

Раскомментировать строки и в скобках указать через пробел все устройства, на которых необходимо отслеживать состояние.

enable_smart=»/dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde»
start_smartd=yes
smartd_opts=»—interval=1800″

Однако при запуске службы на виртуальной машине с Debian 7.7 у меня выдал ошибку (надо сказать, что отслеживание S.M.A.R.T на виртуальных жестких дисках достаточно бредовая идея, я это сделал лишь с целью протестировать):

Просмотреть состояние диска можно командой:
root@debian7:~# smartctl -a /dev/sda

Несмотря на это, утилита является достаточно распространенной и однозначно рекомендуется к использованию. Кроме того, в сети есть масса инструкций по настройке e-mail-уведомлений в случае проблем с жесткими дисками.

hdparm

Главное предназначение программы — тонкая настройка параметров IDE/SATA жестких дисков, тюнинг производительности. Помимо этого также можно просматривать характеристики устройств командой (укажите свой диск):
root@debian7:~# hdparm -i /dev/sda

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

ethtool

Произвести диагностику сетевой платы вам поможет утилита ethtool. Конечно вытянуть информацию можно и с помощью ifconfig, и dmesg и др., но несравнимо больше полезных данных вы получите именно от ethtool. Надо отметить, что с виртуальными сетевыми интерфейсами программа работает достаточно криво. Например отображение статистики по интерфейсу у меня вообще было пустое:
root@debian7:~# ethtool -S eth0
no stats available

Общая информация об интерфейсе была примерно настолько же скудной:
root@debian7:~# ethtool eth0
Settings for eth0:
Link detected: yes

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

sysstat

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

Я перечислил далеко не все основные инструменты, знакомство с которыми так необходимо, но по мере возможности собираюсь дополнять статью необходимым материалом.

Знаете ли вы, что ядро Linux загружает несколько драйверов устройств при загрузке системы?

Фактически, когда ваша система запущена и работает, и вы подключаете аппаратное устройство, то также загружается соответствующий драйвер устройства.

Конечно, ядро также делает много других вещей.

Что делать, если вы хотите узнать информацию, связанную с этими действиями ядра?

Что ж, существует команда — dmesg — которую вы можете использовать, если хотите получать доступ к сообщениям, выведенные ядром.

В этом уроке мы поймем, как работает инструмент dmesg, используя несколько простых для понимания примеров.

Команда Linux dmesg

Синтаксис команды dmesg:

Dmesg

Ниже приведены примеры Вопрос & Ответ, которые помогут вам лучше понять, как работает команда dmesg.

В1. Как использовать команду dmesg?

Вы можете начать использовать команду dmesg без любой опции командной строки.

Например, вот небольшая часть вывода команды, созданной в моем случае:

В2. Как ограничить вывод только ошибками и предупреждениями?

Если вы запустите dmesg в своей системе, вы увидите, что он выводит множество информации.

В зависимости от того, что вы ищете, вы можете фильтровать или ограничивать вывод.

Со своей стороны, dmesg предлагает вам эту способность через «уровни».

Ниже приведен полный список уровней (вместе с их объяснением):

Emerg - system is unusable alert - action must be taken immediately crit - critical conditions err - error conditions warn - warning conditions notice - normal but significant condition info - informational debug - debug-level messages

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

Dmesg --level=err,warn

В моем случае, вот часть вывода выведенной выше команды:

В3. Как создать dmesg для создания временных меток?

Иногда вам может понадобиться связать временную метку с сообщениями, которые создает dmesg.

Это можно сделать, используя опцию командной строки -T, которая создает человекочитаемые метки времени.

Dmesg -T

Пример вывода:

В4. Как сделать, что dmesg отображал информацию об определенном устройстве?

Предположим, вы хотите, чтобы dmesg отображал только информацию, связанную с интерфейсом eth0.

Вот как вы можете это сделать:

Dmesg | grep -i eth0

Пример вывода:

В5. Как заставить dmesg отображать только сообщения в пользовательском пространстве?

Если вы хотите ограничить вывод dmesg только сообщениями пользовательского пространства, используйте параметр командной строки -u.

Dmesg -u

Согласитесь, dmesg — это не та команда, которая вам понадобится каждый день.

Но это инструмент, к которому нужно обратиться, когда кто-то (которого вы попросили о помощи по определенной теме) просит вас предоставить сообщения ядра.

В основном я видел этот случай на форумах онлайн-пользователей, где опытные пользователи просят вывод ядра.

Проблема
При всех своих достоинствах шина PCI - день вчерашний. Чаще требуется полу чить список всех устройств в системе, не только устройств PCI: это и устройства USB,
и устройства SCSI, конфигурация памяти и даже процессор.
Решение
Воспользуйтесь программой dmesg. Программа выводит список всего оборудова ния, обнаруженного ядром.
Чтобы просмотреть весь вывод dmesg, введите команду
$ dmesg | less
Выходные данные dmesg также можно отфильтровать для поиска конкретных
устройств. Так, следующая команда выводит список всех устройств PCI:
$ dmesg I grep -i usb
Вывод списка устройств ISA:
$ dmesg ] grep -i isa
isapnp: Scanning for PnP cards...
isapnp: SB audio device quirk - increasing port range
isapnp: Card "SupraExpress 56i Voice"
Определение объема физической памяти в системе:
$ dmesg | grep -i memory
Memory: 256492/262080k available (1467k kernel code. 5204 reserved. 516k data. 96k
i n i t . OK highmem)
Вывод списка устройств IDE, использующих подсистему эмуляции SCSI в яд ре 2.4 и более старых версий:
$ dmesg | grep -i scsi
Kernel command line: root=/dev/hda6 ro hdb=scsi hdc=scsi
ide_setup: hdb=scsi
ide_setup: hdc=scsi

hdb: attached ide-scsi driver
hdc: attached ide-scsi driver
scsio: SCSI host adapter emulation for IDE ATAPI devices
А вот как выглядят «настоящие», не эмулированные устройства SCST:
$ dmesg | grep -i scsi
SCSI subsystem driver Revision: 1.00
scsiO: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev. 6.2.8
aic7892: Ultral60 Wide Channel A, SCSI Id=7. 32/253 SCBs
...Vendor: IBM-PSG Model:DPSS-336950M M Rev: S9HA
Attached scsi disk sda at scsiO, channel 0. id 0. lun 0
(scsi0:A:0): 160.000MB/S transfers (80.000MHz DT. offset 63. 16bit)
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
Partition check:
sda: sdal sda2sda3 sda4 < sda5 sda6 >
Далее показана информация о камере USB, подключенной к системе, включая
ее местонахождение в файловой системе. Обычно информация об устройстве USB
занимает десяток строк и более:
% dmesg | grep -i usb
. . .
usb.с: registered new d r i v e r ibmcam
icmcam.c: IBM PC Camera USB camera found (model 2. rev. 0x030a)
usbvideo.c: ibmcam on /dev/videoO: canvas=352x240 videosize=352x240
Вывод информации о последовательных портах:
$ dmesg | grep -i tty
ttySOO at 0x03f8 (irq = 4) is a 16550A
Вывод информации о процессоре (или процессорах):
$ dmesg | grep -i cpu
Initializing CPU#0
CPU: LI I Cache: 64K (64 bytes/line). D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0183f9ff clc7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff clc7f9ff 00000000 00000000
CPU: AMD Duron(tm) Processor stepping 01
Обратите внимание: при поиске возвращаются только те строки, в которых при сутствует искомая подстрока. Часто дополнительная информация содержится
в соседних строках и находится прямым просмотром файла:
Initializing CPU#0
Detected 801.446 MHz processor.

В данной статье я хочу написать о консольных программах, которые помогут выдать полную информацию о “железе” вашего ПК (фирма-изготовитель, марка, ID устройства и другие данные про оборудование). Многие пользователи, которые перешли в Линукс с ОС корпорации зла, привыкли работать в графических программах, но с годами работы в Linux понимаешь, что в Терминале все работает быстрее, выдаваемая информация полнее и гибче.

Утилита lspci — утилита Unix, которая выводит детальную информацию о всех PCI шинах и устройствах на них. Утилита lspci сначала читает информацию с PCI-шины, а потом дополнительную информацию ищет в собственной базе данных, которая находится в файле /usr/share/hwdata/pci.ids и содержит такие данные как идентификатор оборудования, производитель, устройства, классы и подклассы. Чтобы запустить программу выполните в Терминале:

lspci

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
04:00.0 SATA controller: JMicron Technology Corp. JMB362 SATA Controller (rev 10)
05:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
06:00.0 SATA controller: JMicron Technology Corp. JMB362 SATA Controller (rev 10)

07:06.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 IEEE 1394 OHCI Controller (rev c0)

Чтобы получить расширенную информацию выполните:

lspci -v

03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller (prog-if 30 )

Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at fe500000 (64-bit, non-prefetchable)
Capabilities:

05:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller (prog-if 30 )
Subsystem: ASUSTeK Computer Inc. P8B WS Motherboard
Flags: bus master, fast devsel, latency 0, IRQ 50
Memory at fe300000 (64-bit, non-prefetchable)
Capabilities:
Kernel driver in use: xhci_hcd

07:05.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
Flags: bus master, medium devsel, latency 32, IRQ 20
Memory at fb000000 (32-bit, non-prefetchable)
Capabilities:
Kernel driver in use: cx8800

07:06.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 IEEE 1394 OHCI Controller (rev c0) (prog-if 10 )
Subsystem: ASUSTeK Computer Inc. Motherboard
Flags: bus master, medium devsel, latency 32, IRQ 21
Memory at fc000000 (32-bit, non-prefetchable)
I/O ports at a000
Capabilities:
Kernel driver in use: firewire_ohci
В итоге текста станет намного больше, но и информация про оборудование будет более объемная. Можно даже узнать, например, номер IRQ, на котором висит нужное устройство. Если нужно узнать информацию про конкретное оборудование, например видео карту Nvidia, тогда нужно применить команду поиска с командой grep. В итоге наша команда будет следующей:

lspci | grep NVIDIA

Следует обратить внимание на то, что команда grep чувствительна к регистру символов, поэтому если с первого разу вы не нашли нужную информацию, то следует менять слова для поиска, например: nvidia, NVIDIA либо часть слова — idia или IDIA.

Вывод команды был следующий:

01:00.0 VGA compatible controller: NVIDIA Corporation GF108 (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio Controller (rev a1)

Если хотите получить информацию про оборудование в текстовый файл, то выполните команду:

lspci > lspci.txt

В итоге в вашем Домашнем каталоге появится текстовый файлик lspci.txt

Если нужно получить список всех устройств в системе, в том числе USB и SCSI, конфигурация памяти, узнать тип процессора, то можно воспользоваться программой dmesg . Она выводит список всего оборудования, которое будет обнаружено ядром системы.

Выполните команду в Терминале:

dmesg

Если выполнить команду:

dmesg | less

то список найденного оборудования будет весьма большим. Поэтому для анализа всей информации советую сохранить вывод этой команды в текстовый файл. Для этого выполните команду:

dmesg | less > dmesg.txt

Выходные данные dmesg можно также фильтровать для поиска нужных устройств. Следующая команда покажет список всех устройств USB в системе:

dmesg | grep -i usb

Также можно использовать утилиту lshw . Если не установлена, то выполните команду:

sudo apt-get install lshw

Чтобы ее запустить выполните команду:

sudo lshw

Программа выводит структурированный список оборудования вместе с информацией об устройствах. Информация получается весьма емкой и полезный. Часть информации из вывода утилиты:

*-cdrom
описание: DVD-RAM writer
продукт: DRW-24B5ST
производитель: ASUS
физический ID: 0.0.0
сведения о шине: scsi@3:0.0.0
логическое имя: /dev/sr1

версия: 1.00
возможности: removable audio cd-r cd-rw dvd dvd-r dvd-ram
конфигурация: ansiversion=5 mount.fstype=iso9660 mount.options=ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500 state=mounted status=ready
*-medium
физический ID: 0
логическое имя: /dev/sr1
логическое имя: /media/dm/disk
конфигурация: mount.fstype=iso9660 mount.options=ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500 state=mounted

Еще можно вытянуть мнго полезной информации из системного каталога /proc. Он является неким «слепком» состояния системы и её переменных, в котором хранится очень много полезной информации о системе, а именно: уровень заряда батарей ноутбука, инфа о процессоре, скорости вращения вентиляторов, информация о подключённых устройствах, а также многое чего еще. Чтобы просмотреть какие файлы находятся в каталоге /proc нужно выполнить команду:

ls /proc/

Чтобы узнать информацию о процессоре выполните команду:

cat /proc/cpuinfo

В моем случае вывод был такой (показана лишь часть текстовой информации):

processor: 0
vendor_id: AuthenticAMD
cpu family: 21
model: 1
model name: AMD FX(tm)-6100 Six-Core Processor
stepping: 2
microcode: 0x6000629
cpu MHz: 1400.000
cache size: 2048 KB
physical id: 0
siblings: 6
core id: 0
cpu cores: 3
apicid: 16
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes

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

cat /proc/acpi/battery/BAT0/info

Чтобы узнать информацию о всех подключенных USB устройствах нужно воспользоваться утилитой lsusb . Выполните команду:

lsusb

Bus 003 Device 004: ID 13fe:4100 Kingston Technology Company Inc.
Bus 003 Device 003: ID 125f:c96a A-DATA Technology Co., Ltd. C906 Flash Drive
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 004: ID 058f:6361 Alcor Micro Corp. Multimedia Card Reader
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 011 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 010 Device 003: ID 04d9:1702 Holtek Semiconductor, Inc.
Bus 010 Device 002: ID 046d:0829 Logitech, Inc.
Bus 010 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

И напоследок пару утилит для получения информации о жестких дисках. Утилита hdparm регулирует и просматривает параметры жестких дисков с интерфейсом ATA. Она может установить такие параметры как объём кеш-памяти накопителя, спящий режим, управление питанием, управление акустикой и настройки DMA.Чтобы узнать информацию о подключенных жестких дисках выполните команду:

sudo hdparm -I /dev/sda

Данной командой мы узнаем информацию о вашем винчестере /dev/sda. Привожу часть вывода:

ATA device, with non-removable media
Model Number: WDC WD6400AARS-00Y5B1
Serial Number: WD-WCAV5D714851
Firmware Revision: 80.00A80
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
—
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1250263728
Logical/Physical Sector size: 512 bytes
Если программа не установлена, то выполните команду в Терминале:

sudo apt-get install hdparm

fdisk -l

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

Диск /dev/sda: 640.1 Гб, 640135028736 байт
255 головок, 63 секторов/треков, 77825 цилиндров, всего 1250263728 секторов
Units = секторы of 1 * 512 = 512 bytes
Размер сектора (логического/физического): 512 байт / 512 байт
I/O size (minimum/optimal): 512 bytes / 512 bytes
Идентификатор диска: 0x0009d6f7

Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1 * 2048 61441501 30719727 83 Linux
/dev/sda2 61442048 73730031 6143992 82 Linux своп / Solaris
/dev/sda3 73730048 1250263039 588266496 83 Linux

На этом все и удачи всем!

—————————————————————————

Красавчик ÁKOS из популярной венгерской группы Bonanza Banzai

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

• контекст процесса 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 Отправить анонимно