Анализ логов с помощью dmesg. Получение информации об аппаратном обеспечении Linux-компьютера без использования отвертки Dmesg linux что делает

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

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

Dmesg - что это за утилита и с чем ее едят?

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

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

1. Просмотр сообщений во время загрузки

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

$ dmesg | more [ 0.000000] microcode: CPU0 microcode updated early to revisio n 0x29, date = 2013-06-12 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.1.20-11-default () (gcc version 4.8.5 (SUSE Linux)) #1 SMP PREEMPT Fri Mar 18 14:42:07 UTC 2016 (0a392b2)

2. Просмотр памяти

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

$ dmesg | grep Memory

0.000000] Memory: 3848228K/4006256K available (6567K kernel code, 1085K rwdata, 4852K rodata, 1560K init, 1520K bss, 158028K reserved, 0K cma-reserved)

3. Просмотр состояния сетевых адаптеров

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

$ dmesg | grep eth [ 101.043873] tg3 0000:02:00.0 eth0: Link is up at 100 Mbps, full duplex [ 101.043885] tg3 0000:02:00.0 eth0: Flow control is off for TX and off for RX [ 101.043889] tg3 0000:02:00.0 eth0: EEE is disabled [ 101.043909] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

4. Изменение размера буфера dmesg

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

$ vi /boot/config-4.1.20-11-default CONFIG_LOG_BUF_SHIFT=18

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

5. Очистить буфер dmesg

Иногда может понадобится очистить буфер Dmesg, чтобы ненужные сообщения не путались под руками. Вы можете это сделать следующей командой:

$ dmesg -c

Теперь если еще раз выполнить команду dmesg, буфер будет пуст.

6. Дата и время в dmesg

Как видите, по умолчанию в dmesg нет никаких дат, используется просто метка, сдвиг времени от начала загрузки. Но также есть возможность увидеть полноценную дату и время каждого сообщения. Для этого смотрите файл /var/log/kern.log:

$ dmesg | grep "L2 cache" Oct 18 23:55:40 ubuntu kernel: [ 0.014681] CPU: L2 cache: 2048K

Чтобы все работало должна быть настроена и запущенна служба klogd.

7. Просмотр ошибок dmesg

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

$ dmesg | grep error

Рассмотрим небольшой пример. Вот допустим, у меня не работает Wifi. Я знаю что адаптер в компьютере есть, он включен и в Windows все работает. Но сейчас никак. Смотрим лог dmesg и видим:

[ 21.772824] b43-phy0 ERROR: Firmware file "b43/ucode15.fw" not found [ 21.772842] b43-phy0 ERROR: Firmware file "b43-open/ucode15.fw" not found [ 21.772852] b43-phy0 ERROR: Please open a terminal and enter the command "sudo /usr/sbin/install_bcm43xx_firmware" to download the correct firmware for this driver version. For an off-line installation, go to and follow the instructions in the "Installing firmware from RPM packages" section.

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

В данной статье я хочу написать о консольных программах, которые помогут выдать полную информацию о “железе” вашего ПК (фирма-изготовитель, марка, 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

Источник: Finding Hardware Details of your Linux Machine without Using Screw Driver
Перевод: В.Костромин , 11.01.2007 г.

Многие неопытные пользователи Linux затрудняются, если им необходимо определить какие-то характеристики аппаратной части их Linux-компьютера, пользуясь только командами, доступными в консоли (в командной строке). Графические оболочки в последнее время имеют в своем составе специальные утилиты, которые предоставляют такую информацию в достаточно удобном виде. Однако администраторы и пользователи домашних компьютеров не всегда имеют возможность ими воспользоваться.

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

Часть 1: Получение информации об оборудовании с помощью команды lspci

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

# /sbin/lspci
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
03:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 02)
....

Теперь я знаю, что у меня стоит графический чип Intel Corporation 82865G Integrated Graphics Controller и могу поискать драйвер для него в Интернет. Посмотрим, какую информацию содержит строка, соответствующая этому чипу:

Чтобы получить больше информации, вы можете воспользоваться опциями -v или -vv. Например, когда я задал команду lspci -v , я получил следующий результат:

00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) (prog-if 00 )
Subsystem: IBM Unknown device 0285
Flags: bus master, fast devsel, latency 0, IRQ 185
Memory at f0000000 (32-bit, prefetchable)
Memory at e8000000 (32-bit, non-prefetchable)
I/O ports at 1800
Capabilities: Power Management version 1

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

# cat /usr/share/hwdata/pci.ids | grep "82865G Integrated Graphics Controller"
82865G Integrated Graphics Controller

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

Часть 2: Получение информации об оборудовании с помощью команды dmesg

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

Утилита lspci хорошо помогает при обнаружении PCI-устройств, однако нам часто требуется список всех устройств в системе. Используя dmesg мы можем просмотреть характеристики всех устройств, которые обнаружены нашей операционной системой.

# dmesg | less
Normal zone: 59248 pages, LIFO batch:15
DMI present.
Allocating PCI resources starting at 20000000 (gap: 10000000:eec00000)
Detected 2793.055 MHz processor.
Built 1 zonelists. Total pages: 63344
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet
Enabling fast FPU save and restore... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c07ae000 soft=c078e000

.....

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

# dmesg | grep -i memory
Memory: 244136k/253376k available (2139k kernel code, 8732k reserved, 866k data, 240k init, 0k highmem)
Freeing initrd memory: 2124k freed
Total HugeTLB memory allocated, 0
Non-volatile memory driver v1.2
agpgart: Detected 8060K stolen memory.
Freeing unused kernel memory: 240k freed
.....

Подобным образом вы можете вычленить информацию о любом устройстве, которое вас интересует или с которым в данный момент возникли проблемы, например, о центральном процессоре (CPU), USB-устройствах и т.д.

Часть 3: Получение информации об оборудовании из /proc

Иногда вам может потребоваться получить информацию об оперативной памяти или центральном процессоре в реальном времени на работающей системе. Для того, чтобы сделать это, вы можете воспользоваться виртуальной файловой системой /proc . Может быть вы вспомните и об утилите top , но знайте, что она просто считывает данные из файловой системы /proc . Только помните, что не следует вносить какие-либо изменения в файлы, расположенные в каталоге /proc , можно только воспользоваться командой cat для просмотра этих файлов.

Выполнив команду ls в каталоге /proc , вы увидите различные каталоги и файлы, которые содержат информацию о вашей системе.

Давайте посмотрим, что в этих файлах содержится, начиная, например, с cpuinfo.

# cat /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 15
model: 2
model name: Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping: 9
cpu MHz: 2793.055
cache size: 512 KB
....

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

# cat /proc/ide/ide0/hda/driver
ide-disk version 1.18
# cat /proc/ide/ide0/hda/capacity
78156288
# cat /proc/ide/ide0/hda/model
IC35L060AVV207-0

Часть 4: Получение дополнительной информации о вашем жестком диске, используя fdisk

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

Программа fdisk - это инструмент для работы с таблицей разбиения диска. Физические диски обычно разбиваются на несколько логических дисков, которые называются разделами диска. Информация о разбиении физического диска на разделы хранится в таблице разбиения диска, которая находится в нулевом секторе физического диска.

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

# fdisk -l
Disk /dev/hda: 40.0 GB, 40016019456 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 13 104391 83 Linux
/dev/hda2 14 4865 38973690 8e Linux LVM

Если у вас два или более дисков (например, hda и hdb), и вы хотите получить данные о конкретном диске, укажите в команде желаемый диск, например, fdisk -l /dev/hda

Часть 5 (ДОБАВЛЕНА по откликам читателей) : Вывод информации BIOS с помощью команды dmidecode

Утилита dmidecode выводит содержимое таблицы DMI (Desktop Management Interface) вашей системы в формате, предназначенном для восприятия человеком. Эта таблица содержит информацию, относящуюся к компонентам аппаратного обеспечения системы, а также сведения о версии BIOS и т.д. В выводе dmidecode не только содержится описание текущей конфигурации системы, но и приводятся данные о максимально допустимых значениях параметров, например, о поддерживаемых частотах работы CPU, максимально возможном объеме памяти и так далее.

Если я хочу ограничить выводимую информацию только какими определенными областями DMI, я могу сделать это, используя опцию ─ t и указав какого типа информация меня нтересует. Например, информация о процессоре имеет тип 4, а информация о памяти имеет в DMI тип 17.

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

Из откликов читателей

Finding hardware details without using screwdriver

Спасибо за отличную и очень информативную статью. Теперь я могу, наконец, закрыть крышку корпуса на своем компьютере:-)
TonyH

Попробуй DMIDECODE

С помощью dmidecode вы можете получить гораздо больше информации, причем в одном отчете.
Без подписи

В действительности возможно узнать гораздо больше о том, какой тип памяти используется в вашем компьтере, например, no. pins и скорость и тип...
Скажем, если я сижу на работе и могу удаленно залогироваться на свой домашний компьютер смогу ли я собрать достаточно данных для того, чтобы определить возможность апгрейда моей оперативной память...?
Я пытлся однажды это сделать и не смог - я подобрался довольно близко к решению этой проблемы, у меня осталось на выбор всего два варианта для типа чипсета материнской платы, я наугад выбрал один из них и... не угадал:-(!!
Без подписи

Попробуй что-нибудь еще!

lshw - отличное средство для этого.
Для него также есть GTK-интерфейс.
Без подписи

Другие хорошие утилиты

Попробуй еще dmidecode . В системах на основе RedHat/Fedora она обычно находится в каталоге /usr/sbin , а также доступна через портежи или в исходных кодах (www.nongnu.org/dmidecode/). Она многое расскажет тебе о твоей системе.

Для получения информации о дисках можно использовать smartd и smartctl .

Christopher Arnold (arnoldch AT yahoo-inc DOT com)

lsusb и файловая система /sys

Не забудь просмотреть файловую систему /sys . Кое в чем информация может быть избыточной... но не все.

Для обнаружения USB-устройств есть lsusb .

sensors раскроет детали относительно чипа вашего ОЗУ.

dmesg : иногда информация оказывается перезаписана более новыми сообщениями ядра. Если так, смотри /var/log/boot.log .

В SUSE системах: вы имеете инструмент с названием "yast2" для выполнения обычных администраторских задач. Он выдает и сведения об аппаратном обеспечении.

Без подписи

А как насчет dmidecode?

Взято из man-страницы по dmidecode .

dmidecode - это инструмент для вывода содержимого DMI-таблицы (иногда говорят SMBIOS-таблицы) вашего компьютера в формате, приспособленном для восприятия человеком. Эта таблица содержит описание компонент аппаратного обесечения системы, а также другоую полезную информацию, например, серийные номера и версию BIOS.

dmidecode

Выдает информацию bios на работающей ОС.
Работает не на всех аппаратных платформах.

Без подписи

Еще

смотри lshw и dmidecode

Без подписи

Еще одна...

Не забудь про lsusb ! Очень полезная утилита. Просто установи пакет usbutils из своего дистрибутива (есть по крайней мере в Ubuntu и Fedora, вероятно в других тоже).

Без подписи

hdparm

Для получения детальной информации о жестких дисках можно использовать hdparm .

Без подписи

А что же HAL?

Надо бы упомянуть еще, что если используется современная графическая оболочка (a modern desktop environment), команда lshal выдаст массу информации из HAL (the Hardware Abstraction Layer, иначе говоря, проект Utopia).

Без подписи

lshw

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


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

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