In short:

• The SELinux process context can be changed if such an operation is described in the sepolicy rules. IN Android versions 4.4 (KitKat) it is possible to escalate privileges by changing the context. But starting from 5.x this can no longer be done.
• there are file contexts.
• In addition to the context of files and processes, Android implements contexts for parameters property_contexts.

adbd and console

The only one affordable way getting a relatively privileged shell in production Android devices- developer mode. Developer mode launches the adbd daemon, which can also act as an analogue of ssh/telnet. In Android KitKat it is located in the initramfs at /sbin/adbd and is not readable by non-root users. Initially, adbd runs as root and runs in the SELinux context/init domain (used by the init process and typically has more privileges than other domains). If the process context is explicitly specified in /init.rc, e.g. seclabel u:r:adbd:s0, then the process starts immediately in the specified context. When initializing adbd, depending on the compilation parameters ( and Android parameters (properties), it lowers privileges, namely changes the current user from root to shell, sets the SELinux context to shell and cuts all system capabilities except CAP_SETUID And CAP_SETGID(which is required for debugging applications via run-as). The so-called Capability Bounding Set does not allow child applications to increase capabilities, only to decrease them. These privileges allow you to do little more than nothing on your phone. You can view the capabilities of the current process with the command cat /proc/self/status | grep CapBnd . And you can decrypt them using the capsh command (not available on Android), for example:

$ capsh --decode=0000001ffffffffff

The current SELinux context can be viewed with the command id or cat /proc/self/attr/current . The previous process context can be viewed with the command cat /proc/self/attr/prev .

View context files: ls -Z
View the context of running processes: ps -Z

Getting root access

root, but not that one

The first thing I did was use dirtycow for its intended purpose - I replaced /system/bin/run-as , which set the UID/GID to 0 (su does the same). However, mount file system I couldn't even tmpfs. I couldn't load kernel modules either. View dmesg - no. I couldn't even browse directories that had 700 permissions and were owned by other system users. I could only read and write to block devices, and viewing files or directories was possible by setting the UID/GID of a specific user (I wrote my own bicycle - an analogue of su, which could set selinux context and user/group).

First of all, I dumped the entire firmware, boot and 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

You can study the dump using the kpartx and unpackbootimg utilities. The kpartx -a mmbblk0.img command creates a virtual block device accessible at /dev/mapper/loop0 . You can work with it like any other block device. The dumps of the boot and recovery partitions were unpacked using the unpackbootimg utility.

Then I tried to write it to recovery /dev/zero , check it and immediately restore it from the dump.

Since I could write to block devices, then I could write custom recovery. I found TWRP from Brigadier, flashed it into recovery and rebooted into adb reboot recovery. I didn’t see TWRP, but only the Android icon with an exclamation mark. This is what the standard recovery looks like, which means TWRP was not flashed.

I reboot into normal mode, I launch the exploit, check the recovery hash of the partition - the hash matches the original one. I try to write the data again - the hash has changed! I remember about the page cache, I clear it (echo 3 > /proc/sys/vm/drop_caches) - the hash is old. Those. everything that I write to the block device flies without errors to /dev/null and sometimes ends up in the Linux cache. But does the firmware update somehow happen? And the user data is somehow written to internal memory. We need to dig further.

Trying to disable SELinux

At that time, I thought that all the errors about the lack of privileges were caused by SELinux (I completely forgot that capabilities could be truncated). I didn’t see any dmesg logs, logcat didn’t show anything relevant. And I started thinking about how to disable SELinux.

The first clue I could find:

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

Those. Before applying the ZIP, recovery will unmount all partitions, but in my case something goes wrong.

Digging the kernel sources

The GPL license obliges smartphone manufacturers to release kernel sources. Thanks to Linus and Stallman for this. Sometimes manufacturers post something wrong, sometimes the correct sources, but without a defconfig file, sometimes they are correct and very rarely with instructions on how to assemble them (for example, LG).

In my case, there were sources with the correct defconfig but without instructions. After a little sweat, I was able to assemble the core and was convinced that it was not a complete linden.

After a long time I settled on two files:

hooks

Kyocera didn’t think for a long time, but simply added hooks for potentially dangerous operations in Android: mount, umount, insmod (only one module is allowed to be loaded - wlan and only if the init process loads it), and so on. This is where the recovery problem lay. It couldn't unmount the /system filesystem! These operations were only allowed by the init process. Among other things, I could not disable SELinux because this feature was disabled when the kernel was compiled. It was possible to bypass these hooks only if the kernel was loaded with certain parameters ( kcdroidboot.mode=f-ksg or androidboot.mode=kcfactory, more on them later).

restart

Also an interesting file to study. It describes possible options phone download:

• adb reboot bootloader- fastboot mode, not available on my phone (0x77665500 - hex label 00556677 in the sbl1 section)
• adb reboot recovery - recovery mode(0x77665502 - hex label 02556677 in section sbl1)
• adb reboot rtc- the so-called ALARM_BOOT. I still don’t understand why, there is no label in sbl1. Perhaps this means https://developer.android.com/reference/android/app/AlarmManager.html
• adb reboot oem-X(in my case oem-1, 0x6f656d01 - hex label 016d656f in the sbl1 section). What happens during this mode is determined by the manufacturer. Judging by the source code, the phone reboots into this mode when there is an error in authenticating the firmware from the modem section.
• adb reboot edl- emergency download, switches the phone to the standard Qualcomm download mode. The phone is defined as QHSUSB__BULK COM port, through which you can transfer a signed bootloader (if I’m not mistaken, each bootloader is designed for one type of SoC and phone manufacturer) and perform low-level operations with the phone, including flashing. Typically used in conjunction with QPST. For some phones, bootloaders leak online, for example for Kyocera KYL22. I don't know where they come from.
• Some download mode, into which through adb reboot don't come in. This is where it’s interesting... But more on that later.

A little about how loading occurs on phones with a Qualcomm processor:

Qualcomm's built-in ROM bootloader (pbl - primary bootloader) loads the sbl1 (secondary bootloader) partition. sbl1 loads tz (trust zone), then aboot (android boot, little kernel, lk). Aboot in turn loads boot, recovery or fota.

Description of sections involved in loading:

• tz - Qualcomm Trust Zone. Performs low-level operations, including working with QFuses (rpmb section).
• rpm - Resource and Power Manager firmware. Firmware for a specialized SoC responsible for resources and power.
• sdi - trust zone storage partition. Data used by Trust Zone.

All these sections are signed with a certificate chain.

fota

In some cases, it is useful to ignore firmware updates.

FOTA - firmware over the air. Unlike boot and recovery, fota is an unofficial boot mode for Android. Fota's task is to update the firmware. For this purpose, Kyocera uses a solution from Red Bend, which fits in 35Mb to update not only the kernel but also the /system partition. Therefore, writing to the /system partition is prohibited, otherwise applying a patch to incorrect data may brick the phone.

There was an update for my phone. I could dare to do it because I already had the opportunity to write to /cache and interrupt the update at any time.

Having studied the source code of the Java application responsible for updating, it became clear to me how it happens:

• The Java application downloads a special file /cache/delta/boot_delta.bin, creates a file /cache/delta/Alt-OTA_dlcomplete, confirming the successful download of the file, and other files with headers.
• When confirming the update, the presence of these files is checked again.
• If the files are in place, then the fotamng section is modified through the libjnialtota.so library.

I am writing a command that continuously dumps the partition and renames /cache/delta/boot_delta.bin . I launch it immediately after agreeing to reboot the phone. The phone reboots into FOTA mode, reports no update and reboots into normal mode.

I begin to study the data that I dumped. In the /cache section, as a bonus, I receive fota logs, which even contain dmseg logs! The reboot itself in fota is initialized with "1" bytes in the fotamng section:

$ 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

After a reboot they are reset. In dmesg I noticed the presence of a kernel parameter kcdroidboot.mode=f-ksg. Here it is! Those. The bootloader removes protection for fota. And purely theoretically, if I write the boot partition to fota and reboot the phone into this mode, then I will get a kernel with Kyocera protection disabled. But write to system partitions I still can't.

Studying the little kernel (lk) sources

What is in the aboot section is the Android bootloader, the vanilla sources of which are located at:

There you can also find information on how loading into some of the modes occurs. For example, I found information that if you write “boot-recovery” in the misc section, then without adb reboot recovery. When loading into recovery this . And if recovery cannot boot, then the phone will go into the boot loop and you will lose it. So be careful and better avoid this reboot option.

There you can also find code that switches the emmc system area to mode. The answer to the question why it is impossible to overwrite recovery. This protection can be disabled from Linux kernels, if you write the corresponding kernel module. Everything has already been written by a comrade from the land of the rising sun, who, it seems, also has a soft spot for Kyocera phones. The module did not work the first time, sometimes it freezes mmc in claim mode. Perhaps not everything is so simple and a detailed study is required.

This is how boot partition signatures are verified:

First successes

dmesg

Google helped me answer the question why I can’t read the kernel logs: /proc/sys/kernel/dmesg_restrict . The value of this parameter is set to 1 when the phone boots. If the user does not have CAP_SYS_ADMIN capability, then the logs are not available to it.

uevent_helper

In my case, surprisingly, it was possible to set /sys/kernel/uevent_helper . If you write the path to the executable file in this parameter (a shell script will also work), then it will be launched at a certain interval from the init process in the init context and, most importantly, with full capabilities.

I wrote the script:

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

I downloaded it to my phone and wrote down its path in /sys/kernel/uevent_helper. I now have the opportunity to see dmesg!

Patched adbd

Because I'm tired of having access to the stripped-down Android console, and I'm too lazy to patch the adbd binary, so I decided to build my own adbd with blackjack and whores. To do this, I had to download 70 Gb of Android sources so as not to tinker with each dependency separately. I removed the check that reduces capabilities, compiled it, replaced /sbin/adbd and got a full-fledged root console. Now I can mount filesystems, watch dmesg without disconnecting dmesg_restrict, quietly view and edit files that do not belong to root and much more. But I can't mount the /system partition and load modules into the kernel yet.

By the way, this procedure can be avoided by compiling lsh and substituting its path in /sys/kernel/uevent_helper . It is advisable to wrap the lsh launch in a script that specifies the PATH environment, otherwise you will have to specify the full path to each command.

WiFi

WiFi on my phone works through the kernel module. WiFi is on - the module is loaded. WiFi is turned off - the module is unloaded. If you replace the module with your own, then when you turn on WiFi, the substitute module should load. Luckily for me digital signature modules have not been checked. The first thing I tried was to build and load a module that disables SELinux by replacing the kernel memory with Amazon Fire Phone: https://github.com/chaosmaster/ford_selinux_permissive

To build a module, you need more or less corresponding kernel sources and the Module.symvers file. If the sources exactly match the kernel used on the phone, then Module.symvers generated automatically when building the kernel should be suitable.

If the kernel complains when loading a module ( disagrees about version of symbol module_layout), then you will need to extract Module.symvers from the boot partition. This can be done using the script 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

You can’t just pick up and assemble your own module for a Kyocera phone.

With each solution to another problem, the process becomes more and more reminiscent of the aporia of Achilles and the tortoise. I don’t know how much longer my enthusiasm will last. Perhaps there are knowledgeable people here who can help you reach the bottom of the rabbit hole.

I would like to take this opportunity to express my gratitude to the developers from Kyocera for their excellent devices and their protection. Otherwise this article would not exist. On the other hand, the lack of regular updates is very disappointing. If you get a phone model with the ability to unlock the bootloader, I will definitely buy it.

P.S. Many thanks to Nikolay Elenkov, author of the book Android security internals. His explanations about the operation of the bootloader helped to understand the Android boot process.

P.P.S. Another mobile security specialist, Justin Case, said that he knows the vulnerability to which all modern Qualcomm processors are susceptible, but he will not disclose its details.

Tags:

• android
• bootloader Submit anonymously

Problem
For all its advantages, the PCI bus is a thing of the past. More often you need to get a list of all devices in the system, not just PCI devices: this and USB devices,
and SCSI devices, memory configuration and even processor.
Solution
Use the dmesg program. The program displays a list of all hardware detected by the kernel.
To view all dmesg output, enter the command
$dmesg | less
The dmesg output can also be filtered to find specific
devices. So, the following command lists all PCI devices:
$ dmesg I grep -i usb
Listing ISA devices:
$ dmesg ] grep -i isa
isapnp: Scanning for PnP cards...
isapnp: SB audio device quirk - increasing port range
isapnp: Card "SupraExpress 56i Voice"
Determining the amount of physical memory in the system:
$dmesg | grep -i memory
Memory: 256492/262080k available (1467k kernel code. 5204 reserved. 516k data. 96k
i n i t . OK highmem)
List IDE devices that use the SCSI emulation subsystem in kernel 2.4 and earlier:
$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
And here’s what “real”, non-emulated SCST devices look like:
$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 >
The following shows information about the USB camera connected to the system, including
its location in the file system. Typically USB device information
takes a dozen lines or more:
% 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
Display information about serial ports:
$dmesg | grep -i tty
ttySOO at 0x03f8 (irq = 4) is a 16550A
Displaying information about the processor (or processors):
$dmesg | grep -i cpu
Initializing CPU#0
CPU: LI 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
Please note that the search returns only those rows that contain the searched substring. Often additional information is provided
in the adjacent lines and is found by directly viewing the file:
Initializing CPU#0
Detected 801.446 MHz processor.

Source: Finding Hardware Details of your Linux Machine without Using Screw Driver
Translation: V. Kostromin, January 11, 2007

Many inexperienced Linux users find it difficult if they need to determine some characteristics of the hardware of their Linux computer, using only the commands available in the console (on the command line). Graphical shells have recently included special utilities that provide such information in a fairly convenient form. However, administrators and home computer users do not always have the opportunity to use them.

In this short tutorial, we will learn how you can get the specification of your Linux computer from the command line. After reading this manual to the end, you will be able to get a complete list of all the components of your computer with their characteristics within a minute. This can, for example, help you search necessary drivers and support addresses for your equipment.

Part 1: Getting Hardware Information Using the lspci Command

Utility lspci is designed to display information about all PCI buses in the system, as well as about all devices connected to these buses. By default, it shows a short list of such devices. However, you can use numerous options lspci for more detailed information or information aimed at subsequent processing using other programs.

# /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)
....

Now I know that I have an Intel Corporation 82865G Integrated Graphics Controller graphics chip and I can look for a driver for it on the Internet. Let's see what information the line corresponding to this chip contains:

To get more information, you can use the -v or -vv options. For example, when I issued the command lspci -v, I got the following result:

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

Utility lspci first reads information from the PCI bus, and then looks for additional information in its own database, which is located in the file /usr/share/hwdata/pci.ids and contains data such as equipment identifier, manufacturer, devices, classes and subclasses. Team

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

allows us to make sure that our device is also included in this database. This list of equipment is supported on the page, and you can use the utility update-pciids in order to get the latest version.

Part 2: Getting Hardware Information Using the dmesg Command

Team dmesg Typically used on Linux to view the contents of the kernel ring buffer. It allows the user to display the contents of messages issued during the system boot process.

Utility lspci works well for detecting PCI devices, but we often need a list of all devices on the system. Using dmesg we can view the characteristics of all devices that are detected by our operating system.

#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

.....

As you can see, dmesg produces a lot of data, so you need to use grep to limit the output to exactly the data that interests us. Let's assume that in this moment We are interested in information about the memory installed in the system.

#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
.....

In a similar way, you can isolate information about any device that interests you or that is currently having problems, for example, central processor(CPU), USB devices, etc.

Part 3: Getting hardware information from /proc

Sometimes you may need to get real-time RAM or CPU information on a running system. To do this, you can use a virtual file system /proc. Maybe you will remember about the utility top, but be aware that it simply reads data from the file system /proc. Just remember not to make any changes to the files located in the directory /proc, you can only use the command cat to view these files.

By executing the command ls in the catalog /proc, you will see various directories and files that contain information about your system.

Let's look at what these files contain, starting with cpuinfo, for example.

# 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
....

Let's look deeper and open some folder. Let's go, for example, to the folder ide and read information about my hard drive.

# 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

Part 4: Getting More Information About Your Hard Drive Using fdisk

In the previous step, using /proc, we received only basic, but rather limited information about the parameters of our hard drive. Now let's get more complete data using the command available in Linux fdisk. With its help, you can get information about hard disk partitions, the amount of available space, the amount of occupied space, swap and much more.

Program fdisk is a tool for working with a disk partition table. Physical disks are usually divided into multiple logical disks called disk partitions. Information about how a physical disk is partitioned is stored in the disk partitioning table, which is located in sector zero of the physical disk.

To see what partitions are on your disk, simply enter the command:

# 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

If you have two or more disks (for example, hda and hdb) and you want to get data about a specific disk, specify the desired disk in the command, for example, fdisk -l /dev/hda

Part 5 (ADDED based on reader feedback): Displaying BIOS information using the dmidecode command

Utility dmidecode displays the contents of your system's DMI (Desktop Management Interface) table in a human-readable format. This table contains information related to the system hardware components, BIOS version information, etc. In output dmidecode not only does it contain a description of the current system configuration, but also provides information about the maximum permissible parameter values, for example, supported CPU frequencies, the maximum possible amount of memory, and so on.

If I want to limit the output information to only certain areas of the DMI, I can do this using the option ─ t and indicating what type of information interests me. For example, the processor information is type 4, and the memory information is type 17 in the DMI.

I hope this guide will help you as much as it helped a friend of mine who was installing MythTV on a Fedora based system and, until reading this guide, kept his computer open so that he could determine the parameters of some devices :)

From reader responses

Finding hardware details without using screwdriver

Thank you for an excellent and very informative article. Now I can finally close the case lid on my computer :-)
TonyH

Try DMIDECODE

With dmidecode you can get much more information, all in one report.
Without a signature

In fact, it is possible to find out much more about what type of memory your computer uses, such as no. pins and speed and type...
Let's say, if I'm sitting at work and can remotely log into my home computer, will I be able to collect enough data to determine the possibility of upgrading my RAM...?
I tried this once and failed - I got pretty close to solving this problem, I was left with only two options for the chipset type to choose from motherboard, I chose one of them at random and... didn’t guess :-(!!
Without a signature

Try something else!

lshw- an excellent tool for this.
There is also a GTK interface for it.
Without a signature

Other good utilities

Try again dmidecode. On RedHat/Fedora based systems it is usually located in the directory /usr/sbin, and is also available through Portage or at source codes(www.nongnu.org/dmidecode/). It will tell you a lot about your system.

To obtain information about disks, you can use smartd And smartctl.

Christopher Arnold (arnoldch AT yahoo-inc DOT com)

lsusb and the /sys file system

Don't forget to browse the file system /sys. Some information may be redundant... but not all.

To detect USB devices there is lsusb.

sensors will reveal details regarding your RAM chip.

dmesg: Sometimes information is overwritten by newer kernel messages. If so, look /var/log/boot.log.

On SUSE systems: you have a tool called "yast2" to perform common administrative tasks. It also provides information about the hardware.

Without a signature

What about dmidecode?

Taken from the man page for dmidecode.

dmidecode is a tool for displaying the contents of the DMI table (sometimes called SMBIOS tables) of your computer in a format suitable for human perception. This table contains a description of the system's hardware components, as well as other useful information, such as serial numbers and BIOS version.

dmidecode

Displays bios information on a running OS.
Does not work on all hardware platforms.

Without a signature

More

Look lshw And dmidecode

Without a signature

Another one...

Don't forget about lsusb! A very useful utility. Just install the package usbutils from your distribution (at least in Ubuntu and Fedora, probably in others too).

Without a signature

hdparm

For getting detailed information O hard drives can be used hdparm.

Without a signature

What about HAL?

It should also be mentioned that if you are using a modern desktop environment, the command lshal will produce a lot of information from the HAL (the Hardware Abstraction Layer, in other words, the Utopia project).

Without a signature

lshw

You can also use the utility lshw, which allows you to display information from all these sources in the form of a single list (can be displayed).

System administrators, and regular Linux users, often need to look at log files to troubleshoot problems. In fact, this is the first thing any system administrator should do when any error occurs in the system.

Herself operating system Linux and running applications generate Various types messages that are logged in various log files. Linux uses a special software, files and directories for storing log files. Knowing which files contain the logs of which programs will help you save time and solve the problem faster.

In this article we will look at the main parts of the Linux logging system, log files, as well as utilities with which you can view Linux logs.

Most files Linux logs are located in the /var/log/ folder. You can list the log files for your system using the ls command:

Rw-r--r-- 1 root root 52198 May 10 11:03 alternatives.log
drwxr-x--- 2 root root 4096 Nov 14 15:07 apache2
drwxr-xr-x 2 root root 4096 Apr 25 12:31 apparmor
drwx------ 2 root root 4096 May 5 10:15 audit
-rw-r--r-- 1 root root 33100 May 10 10:33 boot.log

Below we will look at 20 different Linux log files located in the /var/log/ directory. Some of these logs are only found on certain distributions, for example dpkg.log is only found on Debian based systems.

/var/log/messages- contains global Linux system logs, including those that are recorded at system startup. Several types of messages are recorded in this log: mail, cron, various services, kernel, authentication and others.

/var/log/dmesg- contains messages received from the kernel. Logs many messages during the boot phase, they display information about hardware devices that are initialized during the boot process. You can say this is another log of the Linux system. The number of messages in the log is limited, and when the file is full, with each new message the old ones will be overwritten. You can also view messages from this log using the dmseg command.

/var/log/auth.log- contains information about user authorization in the system, including user logins and authentication mechanisms that were used.

/var/log/boot.log- Contains information that is logged when the system boots.

/var/log/daemon.log- Includes messages from various background daemons

/var/log/kern.log- Also contains messages from the kernel, useful in troubleshooting errors in custom modules built into the kernel.

/var/log/lastlog- Displays information about the last session of all users. This is a non-text file and you must use the lastlog command to view it.

/var/log/maillog /var/log/mail.log- server logs Email running on the system.

/var/log/user.log- Information from all logs at the user level.

/var/log/Xorg.x.log- X server message log.

/var/log/alternatives.log- Information about the operation of the update-alternatives program. These are symbolic links to default commands or libraries.

/var/log/btmp- log Linux file contains information about failed login attempts. To view the file, it is convenient to use the command last -f /var/log/btmp

/var/log/cups- All messages related to printing and printers.

/var/log/anaconda.log- all messages recorded during installation are saved in this file

/var/log/yum.log- Logs all information about package installations using Yum.

/var/log/cron- Whenever the Cron daemon starts executing a program, it writes a report and messages from the program itself in this file.

/var/log/secure- contains information related to authentication and authorization. For example, SSHd logs everything here, including failed login attempts.

/var/log/wtmp or /var/log/utmp - Linux system logs , contain a log of user logins. Using the wtmp command you can find out who is logged in and when.

/var/log/faillog- Linux system log, contains unsuccessful login attempts. Use the faillog command to display the contents of this file.

/var/log/mysqld.log- Linux log files from the MySQL database server.

/var/log/httpd/ or /var/log/apache2- log files of linux11 Apache web server. Access logs are in the access_log file, and error logs are in the error_log

/var/log/lighttpd/ - linux logs lighttpd web server

/var/log/conman/- ConMan client log files,

/var/log/mail/- this directory contains additional mail server logs

/var/log/prelink/- Prelink links libraries and executables to speed up the loading process. /var/log/prelink/prelink.log contains information about .so files that were modified by the program.

/var/log/audit/- Contains information generated by the auditd daemon.

/var/log/setroubleshoot/ - SE Linux uses the setroubleshootd daemon (SE Trouble Shoot Daemon) to report security problems. This log contains messages from this program.

/var/log/samba/- contains information and logs from the Samba file server that is used to connect to shared folders Windows.

/var/log/sa/- Contains .cap files, assembled in a package Sysstat.

/var/log/sssd/- Used by the system security daemon that manages remote access to directories and authentication mechanisms.

Viewing logs in Linux

To view logs on Linux it is convenient to use several command line utilities Linux strings. It could be anyone text editor, or special utility. Most likely, you will need superuser rights to view logs in Linux. Here are the commands that are most often used for these purposes:

• zgrep
• zmore

I will not go into detail on each of these commands, since most of them have already been discussed in detail on our website. But I will give a few examples. Viewing Linux logs is very simple:

We look at the log /var/log/messages, with the ability to scroll:

less /var/log/messages

View Linux logs in real time:

tail -f /var/log/messages

Open the dmesg log file:

cat /var/log/dmesg

First lines of dmesg:

head /var/log/dmesg

We only output errors from /var/log/messages:

grep -i error /var/log/messages

In addition, you can view logs on Linux using graphical utilities. System program Log Viewer can be used for easy viewing and tracking system logs on a laptop or personal computer with Linux.

You can install the program on any system with an X server installed. Also, any graphical test editor can be used to view logs.

conclusions

In the /var/log directory you can find all the necessary information about Linux work. From today's article you have learned enough to know where to look and what to look for. Now viewing logs in Linux will not cause you problems. If you have any questions, ask in the comments!

It is at the loading stage that many errors in services or equipment can occur. Viewing these messages can be very useful. But they go by very quickly and we cannot always have time to read them. But all of them can be viewed using the command dmesg.

Dmesg - what kind of utility is this and what is it used for?

During system boot, while the kernel, initialization system, drivers, kernel modules are loaded, and the hardware is initialized, a large number of messages are displayed on the screen that display information about the state of the kernel, the boot process, and the state of devices.

It is at the loading stage that many errors in services or equipment can occur. Viewing these messages can be very useful. But they go by very quickly and we cannot always have time to read them. But they can all be viewed using the dmesg command.

1. View messages while downloading

By running the dmesg command with superuser rights, you will get all the messages that the kernel output during boot. Here you can see a lot useful information. You can just look at them one line at a time and try to figure out what they mean. Now that you know what boot messages look like, you can easily deal with many problems if they arise.

$dmesg | more [ 0.000000] microcode: CPU0 microcode updated early to revision 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. View memory

Using dmesg you can see the amount of memory available on the system:

$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. View the status of network adapters

Since dmesg stores all device status messages, we can view the status network adapter, or perhaps errors that occurred during its initialization:

$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. Changing the dmesg buffer size

If you think that the default dmesg buffer size is not enough, you can change its size to increase the number of messages that can be there at once. To do this, just edit the file and restart the computer.

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

Change the value of the parameter of this line to the desired one, by default I use 18, this means that a buffer of 18 kilobytes in size will be created. But you can specify the buffer size to be whatever you want.

5. Clear dmesg buffer

Sometimes you may need to clear the Dmesg buffer to keep unnecessary messages from getting tangled up. You can do this with the following command:

$dmesg -c

Now if you run the dmesg command again, the buffer will be empty.

6. Date and time in dmesg

As you can see, by default there are no dates in dmesg, just a label is used, a time shift from the start of the download. But it is also possible to see the full date and time of each message. To do this, see the file /var/log/kern.log:

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

For everything to work, the klogd service must be configured and running.

7. View dmesg errors

With this simple combination you can see all the errors that occurred during boot or system operation:

$dmesg | grep error

Let's look at a small example. Let's say my Wifi doesn't work. I know that there is an adapter in the computer, it is turned on and everything works in Windows. But not now. We look at the dmesg log and see:

[ 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.

From the message we understand that the problem here is in the firmware, and the system even tells us which command can be used to solve it, or where to read about setting up this matter and download necessary files. Thus, a problem that seemed unsolvable was solved in a few minutes. Viewing Linux logs is a very useful thing, don't forget to use it. That's all, if you have any questions, write in the comments!