Le diagnostic des équipements est une question assez importante à ne pas négliger. C'est pourquoi je ne peux m'empêcher d'ajouter un article sur les moyens d'obtenir des informations sur les appareils à la série « Sysadmin Cheat Sheet » pour le système d'exploitation Debian. Cette fois, je vais essayer de parler brièvement des principaux utilitaires de diagnostic de certains composants du serveur. Je commencerai bien sûr par les outils intégrés par défaut au système, puisque tout administrateur système doit les connaître et pouvoir les utiliser. Sera ensuite un aperçu des packages à usage général. En fin de compte, nous connaîtrons des outils avancés supplémentaires que chacun peut installer à volonté.
Vous pouvez trouver des informations sur le processeur à l'aide de la commande :
racine@debian7 :~# chat /proc/cpuinfo
Ou d'autres données :
racine@debian7 :~# lscpu
RAM
Brèves informations sur l'utilisation de la mémoire :
racine@debian7 :~# libre -m
L'utilitaire affiche également des informations sur l'utilisation du swap. Au lieu du commutateur -m, il peut être encore préférable d'utiliser -h - obtenir des données avec des notations de volume.
Informations étendues :
racine@debian7 :~# chat /proc/meminfo
Disques durs
Afficher une liste des partitions existantes :
racine@debian7 :~# fdisk -l
Il convient de noter que l'objectif principal de l'utilitaire fdisk est de gérer les partitions de disque.
Vous pouvez afficher l'UUID et le type de système de fichiers pour chaque partition à l'aide de la commande :
racine@debian7 :~# enfant noir
Des informations sur les partitions, les points de montage et certaines autres données peuvent être obtenues à l'aide de l'utilitaire lsblk
racine@debian7 :~# lsblk
La commande affiche tous les périphériques bloc dans une arborescence.
Filet
Informations sur les interfaces :
racine@debian7 :~# siconfig
Détails de la carte réseau
racine@debian7 :~# mii-tool -v
Pour vérifier la disponibilité des hôtes, utilisez l'utilitaire ping bien connu.
Utilitaires à usage général
haut
L'utilitaire supérieur est utilisé pour afficher des informations sur les processus et les ressources qu'ils consomment. Les informations sont mises à jour à intervalles réguliers. Les données peuvent être triées, par exemple, en utilisant la puissance du processeur ou la RAM (la valeur par défaut est triée par CPU).
racine@debian7 :~# haut
dmidecode
Vous pouvez obtenir des informations détaillées sur le matériel en utilisant dmidecode. L'utilitaire fournit des données obtenues à partir du BIOS. La description du package fournit l'aide suivante :
Ces informations incluent généralement le fabricant du système, le nom du modèle, le numéro de série, la version du BIOS, l'étiquette d'actif et d'autres informations présentant différents niveaux d'intérêt et de fiabilité, déterminés par le fabricant. Contient souvent l'état des sockets de processeur occupés, des emplacements d'extension (par exemple, AGP, PCI, ISA), des emplacements de mémoire et une liste des ports d'E/S (par exemple, ports série et parallèle, USB).
N'oubliez pas que les données produites par DMI ne sont pas si fiables que vous devriez leur faire aveuglément confiance. Dmidecode ne scanne pas le matériel, il affiche simplement les données que le BIOS lui fournit.
racine@debian7 :~# dmidecode
La sortie de la commande sans arguments est trop volumineuse, il est préférable d'utiliser le commutateur -type et d'obtenir uniquement les sections nécessaires, par exemple :
racine@debian7 :~# dmidecode --type 5,6
La commande affichera le type de contrôleur de mémoire et les modules RAM utilisés.
message
La commande est utilisée pour imprimer le tampon de messages du noyau. D'un point de vue matériel, le résultat peut être utile pour analyser les problèmes matériels et même pour fournir une image complète de votre matériel existant. La sortie de la commande est trop volumineuse et vous aurez peut-être besoin d'autres outils pour l'analyser. Par exemple, vous pouvez utiliser la sortie vers un fichier, vous pouvez rediriger la sortie vers la commande less ou vous pouvez utiliser grep pour rechercher les composants matériels. vous avez besoin.
racine@debian7 :~# dmesg | processeur grep
La commande n'affichera que les lignes contenant le traitement de texte.
lspci
L'utilitaire est pratique à utiliser pour afficher une liste de tous les périphériques connectés au bus PCI. Les informations peuvent être utilisées à des fins de diagnostic, ainsi que pour identifier les appareils installés.
racine@debian7 :~# lspci
Utilisez le commutateur -t pour afficher les informations dans une arborescence, qui affichera tous les bus et les appareils qui y sont connectés. Les commutateurs -v, -vv, -vvv affichent des informations supplémentaires pour chaque périphérique ; Plus le « v » est grand, plus les données affichées sont détaillées.
En général, l'utilitaire est extrêmement utile lorsque vous travaillez avec des composants matériels et vous permet d'obtenir un maximum de données.
vmstat
Affiche des informations récapitulatives sur l'état de la mémoire virtuelle ainsi que sur l'échange.
racine@debian7 :~# vmstat2
La commande ci-dessus affichera des données mises à jour toutes les 2 secondes (vous pouvez spécifier n'importe quel autre nombre au lieu de 2).
système
Bien que l'utilitaire soit principalement destiné à gérer les paramètres du noyau à la volée, l'analyse des valeurs définies peut aider à diagnostiquer les problèmes.
racine@debian7 :~# sysctl -a
La commande affichera toutes les variables et leurs valeurs.
Utilitaires supplémentaires
Tous les utilitaires décrits ci-dessous ne sont pas inclus dans la configuration standard de Debian ; ils devront être installés séparément.
htop
Un remplacement plus puissant pour l'utilitaire supérieur standard. Non fourni avec le système en configuration standard. Fournit une interface interactive conviviale avec une aide intégrée et des mises à jour des données en temps réel.
racine@debian7 :~# htop -d 10
Le commutateur -d définit la valeur en dixièmes de seconde pour mettre à jour les données. Le commutateur -c fait passer le programme en mode monochrome.
lshw
L'utilitaire est conçu pour afficher des informations détaillées sur le matériel. Il est plus pratique d’exporter les données vers une vue .html et de les afficher dans un navigateur. Cette méthode est bien entendu exclue lorsque vous travaillez en mode console, sauf si vous visualisez des données sur un autre système.
racine@debian7 :~# réseau lshw -C
La commande affichera uniquement des informations sur la carte réseau.
outils intelligents
Le package se compose de deux utilitaires (smartctl et smartd) qui surveillent les indicateurs S.M.A.R.T des disques durs. Pour démarrer le démon, vous devez effectuer un certain nombre de paramètres :
Décommentez les lignes et indiquez entre parenthèses, séparés par un espace, tous les appareils dont vous souhaitez surveiller l'état.
activer_smart=”/dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde”
start_smartd=oui
smartd_opts=”—intervalle=1800″
Cependant, lorsque j'ai démarré le service sur une machine virtuelle avec Debian 7.7, j'ai eu une erreur (je dois dire que suivre S.M.A.R.T sur des disques durs virtuels est une idée assez folle, je l'ai fait uniquement à des fins de tests) :
Vous pouvez afficher l'état du disque avec la commande :
racine@debian7 :~# smartctl -a /dev/sda
Malgré cela, l'utilitaire est assez courant et son utilisation est définitivement recommandée. De plus, il existe de nombreuses instructions sur Internet pour configurer des notifications par e-mail en cas de problèmes avec les disques durs.
hdparm
L'objectif principal du programme est d'affiner les paramètres des disques durs IDE/SATA et d'optimiser les performances. De plus, vous pouvez également visualiser les caractéristiques de l'appareil avec la commande (précisez votre lecteur) :
racine@debian7 :~# hdparm -i /dev/sda
Il n'est pas prévu d'aborder les problèmes de configuration du disque dans le cadre de cet article.
outil eth
L'utilitaire ethtool vous aidera à diagnostiquer votre carte réseau. Bien sûr, vous pouvez extraire des informations en utilisant ifconfig, dmesg, etc., mais vous obtiendrez des données incomparablement plus utiles grâce à ethtool. Il convient de noter que le programme fonctionne de manière plutôt tordue avec les interfaces réseau virtuelles. Par exemple, l'affichage des statistiques sur l'interface était complètement vide :
racine@debian7 :~# ethtool -S eth0
aucune statistique disponible
Les informations générales sur l'interface étaient tout aussi rares :
racine@debian7 :~# ethtool eth0
Paramètres pour eth0 :
Lien détecté : oui
Avec les interfaces physiques, la situation est bien meilleure. En plus des diagnostics, l'utilitaire est également conçu pour configurer les interfaces.
statistique système
Le package contient un certain nombre d'utilitaires pouvant fournir des informations sur les performances de certains composants du système. iostat peut être particulièrement utile lorsque vous devez analyser la charge du disque dur en termes d'opérations d'E/S.
Je n'ai pas répertorié tous les outils de base qu'il est si nécessaire de connaître, mais dans la mesure du possible je vais compléter l'article avec le matériel nécessaire.
Source : Recherche des détails matériels de votre machine Linux sans utiliser de tournevis
Traduction: V. Kostromine, 11 janvier 2007
De nombreux utilisateurs Linux inexpérimentés ont du mal à déterminer certaines caractéristiques du matériel de leur ordinateur Linux en utilisant uniquement les commandes disponibles dans la console (sur la ligne de commande). Les shells graphiques ont récemment inclus des utilitaires spéciaux qui fournissent ces informations sous une forme assez pratique. Cependant, les administrateurs et les utilisateurs d'ordinateurs personnels n'ont pas toujours la possibilité de les utiliser.
Dans ce court didacticiel, nous apprendrons comment obtenir les spécifications de votre ordinateur Linux à partir de la ligne de commande. Après avoir lu ce manuel jusqu'au bout, vous pourrez obtenir en une minute une liste complète de tous les composants de votre ordinateur avec leurs caractéristiques. Cela peut, par exemple, vous aider à trouver les bons pilotes et adresses d'assistance pour votre équipement.
Partie 1 : Obtenir des informations sur le matériel à l'aide de la commande lspci
Utilitaire lspci est conçu pour afficher des informations sur tous les bus PCI du système, ainsi que sur tous les périphériques connectés à ces bus. Par défaut, il affiche une courte liste de ces appareils. Cependant, vous pouvez utiliser de nombreuses options lspci pour des informations plus détaillées ou des informations destinées à un traitement ultérieur à l'aide d'autres programmes.
# /sbin/lspci
00:00.0 Pont hôte : contrôleur DRAM Intel Corporation 82865G/PE/P/interface hôte-Hub (rév. 02)
00:02.0 Contrôleur compatible VGA : Contrôleur graphique intégré Intel Corporation 82865G (rév 02)
00:1d.0 Contrôleur USB : Contrôleur USB UHCI Intel Corporation 82801EB/ER (ICH5/ICH5R) n°1 (rév. 02)
Pont PCI 00:1e.0 : Pont PCI Intel Corporation 82801 (rév. c2)
Interface IDE 00:1f.1 : Contrôleur IDE Intel Corporation 82801EB/ER (ICH5/ICH5R) (rév. 02)
03:08.0 Contrôleur Ethernet : Contrôleur Ethernet Intel Corporation 82562EZ 10/100 (rév. 02)
....
Maintenant, je sais que j'ai une puce graphique Intel Corporation 82865G Integrated Graphics Controller et je peux rechercher un pilote pour celle-ci sur Internet. Voyons quelles informations contient la ligne correspondant à cette puce :
Pour obtenir plus d'informations, vous pouvez utiliser les options -v ou -vv. Par exemple, lorsque j'ai émis la commande lspci -v, j'obtiens le résultat suivant :
00:02.0 Contrôleur compatible VGA : Contrôleur graphique intégré Intel Corporation 82865G (rév 02) (prog-if 00)
Sous-système : Périphérique IBM inconnu 0285
Indicateurs : bus maître, développement rapide, latence 0, IRQ 185
Mémoire à f0000000 (32 bits, pré-récupérable)
Mémoire à e8000000 (32 bits, non pré-récupérable)
Ports E/S à 1800
Capacités : Gestion de l'alimentation version 1
Utilitaire lspci lit d'abord les informations du bus PCI, puis recherche des informations supplémentaires dans sa propre base de données, située dans le fichier /usr/share/hwdata/pci.ids et contient des données telles que l'identifiant de l'équipement, le fabricant, les appareils, les classes et sous-classes. Équipe
# cat /usr/share/hwdata/pci.ids | grep "Contrôleur graphique intégré 82865G"
Contrôleur graphique intégré 82865G
nous permet de nous assurer que notre appareil est également inclus dans cette base de données. Cette liste d'équipements est prise en charge sur la page, et vous pouvez utiliser l'utilitaire mise à jour-pciids afin d'obtenir la dernière version.
Partie 2 : Obtenir des informations sur le matériel à l'aide de la commande dmesg
Équipe message Généralement utilisé sous Linux pour afficher le contenu du tampon en anneau du noyau. Il permet à l'utilisateur d'afficher le contenu des messages émis lors du processus de démarrage du système.
Utilitaire lspci fonctionne bien pour détecter les périphériques PCI, mais nous avons souvent besoin d'une liste de tous les périphériques du système. En utilisant message nous pouvons visualiser les caractéristiques de tous les appareils détectés par notre système d'exploitation.
# dmesg | moins
Zone normale : 59 248 pages, lot LIFO : 15
DMI présent.
Allocation de ressources PCI à partir de 2 000 000 (écart : 1 000 000 : eec00000)
Processeur 2793,055 MHz détecté.
Construit 1 liste de zones. Nombre total de pages : 63 344
Ligne de commande du noyau : ro root=/dev/VolGroup00/LogVol00 rhgb quiet
Activation de la sauvegarde et de la restauration rapides du FPU... terminé.
Initialisation du processeur n°0
CPU 0 irqstacks, dur = c07ae000 logiciel = c078e000
.....
Comme vous pouvez le voir, message produit beaucoup de données, vous devez donc utiliser grep pour limiter la sortie exactement aux données qui nous intéressent. Supposons qu'à l'heure actuelle nous soyons intéressés par des informations sur la mémoire installée dans le système.
# dmesg | grep -i mémoire
Mémoire : 244 136 Ko/253 376 Ko disponibles (2 139 Ko de code noyau, 8 732 Ko réservés, 866 Ko de données, 240 Ko d'initialisation, 0 Ko de mémoire élevée)
Libération de la mémoire initrd : 2 124 Ko libérés
Mémoire HugeTLB totale allouée, 0
Pilote de mémoire non volatile v1.2
agpgart : Détection de 8 060 Ko de mémoire volée.
Libération de la mémoire noyau inutilisée : 240 Ko libérés
.....
De la même manière, vous pouvez isoler les informations sur tout appareil qui vous intéresse ou qui rencontre actuellement des problèmes, par exemple l'unité centrale (CPU), les périphériques USB, etc.
Partie 3 : Obtenir des informations sur le matériel à partir de /proc
Parfois, vous devrez peut-être obtenir des informations en temps réel sur la RAM ou le processeur sur un système en cours d'exécution. Pour ce faire, vous pouvez utiliser un système de fichiers virtuel /proc. Peut-être vous souviendrez-vous de l'utilitaire haut, mais sachez qu'il lit simplement les données du système de fichiers /proc. N'oubliez pas de ne pas apporter de modifications aux fichiers situés dans le répertoire /proc, vous ne pouvez utiliser que la commande chat pour visualiser ces fichiers.
En exécutant la commande ls dans le catalogue /proc, vous verrez divers répertoires et fichiers contenant des informations sur votre système.
Regardons ce que contiennent ces fichiers, en commençant par cpuinfo par exemple.
# chat /proc/cpuinfo
processeur : 0
id_vendeur : AuthentiqueIntel
famille de processeurs : 15
modèle : 2
Nom du modèle : Processeur Intel(R) Pentium(R) 4 2,80 GHz
pas à pas : 9
processeur MHz : 2 793,055
taille du cache : 512 Ko
....
Regardons plus profondément et ouvrons un dossier. Allons, par exemple, dans le dossier idée et lire les informations sur mon disque dur.
# cat /proc/ide/ide0/hda/driver
disque ide version 1.18
# chat /proc/ide/ide0/hda/capacité
78156288
# chat /proc/ide/ide0/hda/model
IC35L060AVV207-0
Partie 4 : Obtenir plus d'informations sur votre disque dur à l'aide de fdisk
À l'étape précédente, en utilisant /proc, nous n'avons reçu que des informations basiques, mais plutôt limitées, sur les paramètres de notre disque dur. Obtenons maintenant des données plus complètes en utilisant la commande disponible sous Linux fdisque. Avec son aide, vous pouvez obtenir des informations sur les partitions du disque dur, la quantité d'espace disponible, la quantité d'espace occupé, l'échange et bien plus encore.
Programme fdisque est un outil pour travailler avec une table de partition de disque. Les disques physiques sont généralement divisés en plusieurs disques logiques appelés partitions de disque. Les informations sur la manière dont un disque physique est partitionné sont stockées dans la table de partitionnement de disque, située dans le secteur zéro du disque physique.
Pour voir quelles partitions se trouvent sur votre disque, entrez simplement la commande :
# fdisk -l
Disque /dev/hda : 40,0 Go, 40016019456 octets
255 têtes, 63 secteurs/piste, 4865 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Démarrage du périphérique Début Fin Blocs Système d'identification
/dev/hda1 * 1 13 104391 83 Linux
/dev/hda2 14 4865 38973690 8e Linux LVM
Si vous disposez de deux disques ou plus (par exemple, hda et hdb) et que vous souhaitez obtenir des données sur un disque spécifique, spécifiez le disque souhaité dans la commande, par exemple : fdisk -l /dev/hda
Partie 5 (AJOUTÉE en fonction des commentaires des lecteurs) : Affichage des informations du BIOS à l'aide de la commande dmidecode
Utilitaire dmidecode affiche le contenu du tableau DMI (Desktop Management Interface) de votre système dans un format lisible par l'homme. Ce tableau contient des informations relatives aux composants matériels du système, aux informations sur la version du BIOS, etc. En sortie dmidecode non seulement il contient une description de la configuration actuelle du système, mais fournit également des informations sur les valeurs de paramètres maximales autorisées, par exemple les fréquences de processeur prises en charge, la quantité maximale de mémoire possible, etc.
Si je souhaite limiter les informations de sortie à certaines zones du DMI, je peux le faire en utilisant l'option ─ t et en indiquant quel type d'informations m'intéresse. Par exemple, les informations sur le processeur sont de type 4 et les informations sur la mémoire sont de type 17 dans le DMI.
J'espère que ce guide vous aidera autant qu'il a aidé un de mes amis qui installait MythTV sur un système basé sur Fedora et, jusqu'à la lecture de ce guide, gardait son ordinateur ouvert afin de pouvoir déterminer les paramètres de certains appareils :)
D'après les réponses des lecteurs
Trouver des détails sur le matériel sans utiliser de tournevis
Merci pour cet article excellent et très instructif. Maintenant, je peux enfin fermer le couvercle du boîtier de mon ordinateur :-)
TonyH
Essayez DMIDECODE
Avec dmidecode, vous pouvez obtenir beaucoup plus d'informations, le tout dans un seul rapport.
Sans signature
En fait, il est possible d’en savoir beaucoup plus sur le type de mémoire utilisé par votre ordinateur, par exemple non. broches, vitesse et type...
Disons que si je suis assis au travail et que je peux me connecter à distance à mon ordinateur personnel, pourrai-je collecter suffisamment de données pour déterminer la possibilité de mettre à niveau ma RAM... ?
J'ai essayé de le faire une fois et j'ai échoué - j'étais sur le point de résoudre ce problème, il ne me restait que deux options parmi lesquelles choisir pour le type de chipset de la carte mère, j'en ai choisi une au hasard et... je n'ai pas deviné :-( !!
Sans signature
Essayez autre chose !
lshw- un excellent outil pour cela.
Il existe également une interface GTK pour cela.
Sans signature
Autres bons utilitaires
Essayer à nouveau dmidecode. Sur les systèmes basés sur RedHat/Fedora, il se trouve généralement dans le répertoire /usr/sbin, et est également disponible via Portage ou en code source (www.nongnu.org/dmidecode/). Cela vous en dira beaucoup sur votre système.
Pour obtenir des informations sur les disques, vous pouvez utiliser intelligent Et smartctl.
Christopher Arnold (arnoldch AT Yahoo-inc DOT com)
lsusb et le système de fichiers /sys
N'oubliez pas de parcourir le système de fichiers /sys. Certaines informations peuvent être redondantes… mais pas toutes.
Pour détecter les périphériques USB, il existe lsusb.
capteurs révélera des détails concernant votre puce RAM.
message: Parfois, les informations sont écrasées par des messages plus récents du noyau. Si c'est le cas, regarde /var/log/boot.log.
Sur les systèmes SUSE : vous disposez d'un outil appelé "yast2" pour effectuer les tâches administratives courantes. Il fournit également des informations sur le matériel.
Sans signature
Et le dmidecode ?
Extrait de la page de manuel de dmidecode.
dmidecode est un outil permettant d'afficher le contenu de la table DMI (parfois appelée tables SMBIOS) de votre ordinateur dans un format adapté à la perception humaine. Ce tableau contient une description des composants matériels du système, ainsi que d'autres informations utiles telles que les numéros de série et la version du BIOS.
dmidecode
Affiche les informations du BIOS sur un système d'exploitation en cours d'exécution.
Ne fonctionne pas sur toutes les plates-formes matérielles.
Sans signature
Plus
Regarder lshw Et dmidecode
Sans signature
Un autre...
N'oublie pas lsusb! Un utilitaire très utile. Installez simplement le package utilitaires usb depuis votre distribution (au moins dans Ubuntu et Fedora, probablement dans d'autres aussi).
Sans signature
hdparm
Pour obtenir des informations détaillées sur les disques durs, vous pouvez utiliser hdparm.
Sans signature
Et HAL ?
Il convient également de mentionner que si vous utilisez un environnement de bureau moderne, la commande lshal va produire beaucoup d’informations à partir du HAL (le Hardware Abstraction Layer, autrement dit le projet Utopia).
Sans signature
lshw
Vous pouvez également utiliser l'utilitaire lshw, qui permet d'afficher les informations de toutes ces sources sous la forme d'une liste unique (affichable).
En bref:
- Le contexte du processus SELinux peut être modifié si une telle opération est décrite dans les règles de politique de sécurité. Dans Android 4.4 (KitKat), il est possible d'élever les privilèges en modifiant le contexte. Mais à partir de la version 5.x, cela ne peut plus être fait.
- il existe des contextes de fichiers.
- En plus du contexte des fichiers et des processus, Android implémente des contextes pour les paramètres contextes_propriétés.
adbd et console
Le seul moyen disponible pour obtenir un shell relativement privilégié sur les appareils Android de production est le mode développeur. Le mode développeur lance le démon adbd, qui peut également agir comme un analogue de ssh/telnet. Dans Android KitKat, il se trouve dans le fichier initramfs dans /sbin/adbd et n'est pas lisible par les utilisateurs non root. Initialement, adbd s'exécute en tant que root et s'exécute dans le domaine contexte/init SELinux (utilisé par le processus init et dispose généralement de plus de privilèges que les autres domaines). Si le contexte du processus est explicitement spécifié dans /init.rc, par ex. séclabel u:r:adbd:s0, le processus démarre immédiatement dans le contexte spécifié. Lors de l'initialisation d'adbd, en fonction des paramètres de compilation (et des paramètres Android (propriétés), il diminue les privilèges, à savoir change l'utilisateur actuel de root à shell, définit le contexte SELinux sur coquille et coupe toutes les capacités du système, sauf CAP_SETUID Et CAP_SETGID(ce qui est requis pour le débogage des applications via run-as). Le soi-disant ensemble de limites de capacités ne permet pas aux applications enfants d'augmenter les capacités, mais uniquement de les diminuer. Ces privilèges vous permettent de faire à peine plus que rien sur votre téléphone. Vous pouvez visualiser les capacités du processus en cours avec la commande cat /proc/self/status | grep CapBnd . Et vous pouvez les décrypter à l'aide de la commande capsh (non disponible sur Android), par exemple :
$ capsh --decode=0000001ffffffffff
Le contexte SELinux actuel peut être visualisé avec la commande id ou cat /proc/self/attr/current . Le contexte du processus précédent peut être visualisé avec la commande cat /proc/self/attr/prev .
Afficher les fichiers contextuels : ls -Z
Afficher le contexte des processus en cours d'exécution : ps -Z
Obtenir un accès root
racine, mais pas celle-là
La première chose que j'ai faite a été d'utiliser dirtycow aux fins prévues - j'ai remplacé /system/bin/run-as , qui définit l'UID/GID sur 0 (su fait de même). Cependant, je n'ai pas pu monter le système de fichiers, pas même tmpfs. Je n'ai pas non plus pu charger les modules du noyau. Voir dmesg - non. Je ne pouvais même pas parcourir les répertoires disposant de 700 autorisations et appartenant à d'autres utilisateurs du système. Je ne pouvais lire et écrire que sur des périphériques bloqués, et l'affichage de fichiers ou de répertoires était possible en définissant l'UID/GID d'un utilisateur spécifique (j'ai écrit mon propre vélo - un analogue de su, qui pouvait définir le contexte selinux et l'utilisateur/groupe).
Tout d'abord, j'ai vidé l'intégralité du firmware, du démarrage et de la récupération :
$ 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
Vous pouvez étudier le dump à l'aide des utilitaires kpartx et unpackbootimg. La commande kpartx -a mmbblk0.img crée un périphérique de bloc virtuel accessible à /dev/mapper/loop0 . Vous pouvez travailler avec lui comme n’importe quel autre périphérique bloc. Les sauvegardes des partitions de démarrage et de récupération ont été décompressées à l'aide de l'utilitaire unpackbootimg.
Ensuite, j'ai essayé de l'écrire dans recovery /dev/zero , de le vérifier et de le restaurer immédiatement à partir du dump.
Puisque je peux écrire sur des périphériques bloqués, cela signifie que je peux écrire une récupération personnalisée. J'ai trouvé TWRP de Brigadier, je l'ai flashé en récupération et j'ai redémarré en récupération de redémarrage adb. Je n'ai pas vu TWRP, mais seulement l'icône Android avec un point d'exclamation. Voici à quoi ressemble la récupération standard, ce qui signifie que TWRP n'a pas été flashé.
Je redémarre en mode normal, lance l'exploit, vérifie la récupération du hachage de la partition - le hachage correspond à celui d'origine. J'essaye d'écrire à nouveau les données - le hachage a changé ! Je me souviens du cache de page, je l'efface (echo 3 > /proc/sys/vm/drop_caches) - le hachage est ancien. Ceux. tout ce que j'écris sur le périphérique bloc vole sans erreur vers /dev/null et finit parfois dans le cache Linux. Mais la mise à jour du firmware se produit-elle d’une manière ou d’une autre ? Et les données utilisateur sont en quelque sorte écrites dans la mémoire interne. Il faut creuser davantage.
Essayer de désactiver SELinux
A cette époque, je pensais que toutes les erreurs concernant le manque de privilèges étaient causées par SELinux (j'avais complètement oublié que les capacités pouvaient être tronquées). Je n'ai vu aucun journal dmesg, logcat n'a rien montré de pertinent. Et j'ai commencé à réfléchir à la façon de désactiver SELinux.
Le premier indice que j'ai pu trouver :
$ grep -A2 reload_policy boot/ramfs/init.rc sur la propriété :selinux.reload_policy=1 redémarrer ueventd redémarrer installd
Ceux. Avant d'appliquer le ZIP, la récupération démontera toutes les partitions, mais dans mon cas, quelque chose ne va pas.
Creuser les sources du noyau
La licence GPL oblige les fabricants de smartphones à publier les sources du noyau. Merci à Linus et Stallman pour cela. Parfois, les fabricants publient quelque chose de mal, parfois ils publient les bonnes sources, mais sans fichier defconfig, parfois ils publient les bonnes et très rarement avec des instructions sur la façon de les assembler (par exemple, LG).
Dans mon cas, il y avait des sources avec le bon defconfig mais sans instructions. Après un peu de sueur, j'ai pu assembler le noyau et m'assurer qu'il ne s'agissait pas d'un tilleul complet.
Après un long moment, j'ai opté pour deux fichiers :
crochets
Kyocera n'a pas réfléchi longtemps, mais a simplement ajouté des hooks pour les opérations potentiellement dangereuses sous Android : mount, umount, insmod (un seul module est autorisé à être chargé - wlan et seulement si le processus d'initialisation le charge), et ainsi de suite . C'est là que réside le problème de la récupération. Il n'a pas pu démonter le système de fichiers /system ! Ces opérations n'étaient autorisées que par le processus d'initialisation. Entre autres choses, je n'ai pas pu désactiver SELinux car cette fonctionnalité a été désactivée lors de la compilation du noyau. Il n'était possible de contourner ces hooks que si le noyau était chargé avec certains paramètres ( kcdroidboot.mode=f-ksg ou androidboot.mode=kcfactory, nous y reviendrons plus tard).
redémarrage
C'est aussi un dossier intéressant à étudier. Il décrit les options de démarrage possibles pour le téléphone :
- adb redémarrer le chargeur de démarrage- mode fastboot, non disponible sur mon téléphone (0x77665500 - étiquette hexadécimale 00556677 dans la section sbl1)
- récupération de redémarrage adb- mode de récupération (0x77665502 - étiquette hexadécimale 02556677 dans la section sbl1)
- adb redémarrer rtc- ce qu'on appelle ALARM_BOOT. Je ne comprends toujours pas pourquoi, il n'y a pas de label dans sbl1. Cela signifie peut-être https://developer.android.com/reference/android/app/AlarmManager.html
- adb redémarrer OEM-X(dans mon cas oem-1, 0x6f656d01 - étiquette hexadécimale 016d656f dans la section sbl1). Ce qui se passe pendant ce mode est déterminé par le fabricant. À en juger par le code source, le téléphone redémarre dans ce mode s'il y a une erreur lors de l'authentification du micrologiciel à partir de la section modem.
- adb redémarrer edl- téléchargement d'urgence, fait passer le téléphone en mode de téléchargement standard Qualcomm. Le téléphone est défini comme QHSUSB__BULK Port COM, via lequel vous pouvez transférer un chargeur de démarrage signé (si je ne me trompe pas, chaque chargeur de démarrage est destiné à un type de SoC et de fabricant de téléphone) et effectuer des opérations de bas niveau avec le téléphone, y compris le flashage. Généralement utilisé en conjonction avec QPST. Pour certains téléphones, les chargeurs de démarrage fuient en ligne, par exemple pour Kyocera KYL22. Je ne sais pas d'où ils viennent.
- Quelques mode de téléchargement, dans lequel à travers redémarrage de la BAD n'entre pas. C’est là que c’est intéressant… Mais nous y reviendrons plus tard.
Un peu sur la façon dont le chargement s'effectue sur les téléphones équipés d'un processeur Qualcomm :
Le chargeur de démarrage ROM intégré de Qualcomm (pbl - chargeur de démarrage principal) charge la partition sbl1 (chargeur de démarrage secondaire). sbl1 charge tz (zone de confiance), puis aboot (démarrage Android, petit noyau, lk). Aboot charge à son tour le démarrage, la récupération ou la fota.
Description des sections impliquées dans le chargement :
- tz - Zone de confiance Qualcomm. Effectue des opérations de bas niveau, notamment en travaillant avec QFuses (section rpmb).
- rpm - Micrologiciel Resource et Power Manager. Firmware pour un SoC spécialisé responsable des ressources et de l'alimentation.
- sdi - partition de stockage de zone de confiance. Données utilisées par Trust Zone.
Toutes ces sections sont signées avec une chaîne de certificats.
photo
Dans certains cas, il est utile d’ignorer les mises à jour du firmware.
FOTA - firmware par liaison radio. Contrairement au démarrage et à la récupération, fota est un mode de démarrage non officiel pour Android. La tâche de Fota est de mettre à jour le firmware. Pour cela, Kyocera utilise une solution de Red Bend, qui tient dans 35 Mo pour mettre à jour non seulement le noyau mais aussi la partition /system. Par conséquent, l'écriture sur la partition /system est interdite, sinon l'application d'un correctif à des données incorrectes pourrait endommager le téléphone.
Il y a eu une mise à jour pour mon téléphone. Je pouvais oser le faire car j'avais déjà la possibilité d'écrire dans /cache et d'interrompre la mise à jour à tout moment.
Après avoir étudié le code source de l'application Java chargée de la mise à jour, il m'est apparu clairement comment cela se passe :
- L'application Java télécharge un fichier spécial /cache/delta/boot_delta.bin, crée un fichier /cache/delta/Alt-OTA_dlcomplete, confirmant le téléchargement réussi du fichier et d'autres fichiers avec en-têtes.
- Lors de la confirmation de la mise à jour, la présence de ces fichiers est à nouveau vérifiée.
- Si les fichiers sont en place, alors la section fotamng est modifiée via la bibliothèque libjnialtota.so.
J'écris une commande qui vide continuellement la partition et renomme /cache/delta/boot_delta.bin . Je le lance immédiatement après avoir accepté de redémarrer le téléphone. Le téléphone redémarre en mode FOTA, ne signale aucune mise à jour et redémarre en mode normal.
Je commence à étudier les données que j'ai vidé. Dans la section /cache, en bonus, je reçois des logs fota, qui contiennent même des logs dmseg ! Le redémarrage lui-même dans fota est initialisé avec "1" octets dans la section 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 de=/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/ par nom/fotamng seek=131096 bs=1 count=1
Après un redémarrage, ils sont réinitialisés. Dans dmesg j'ai remarqué la présence d'un paramètre noyau kcdroidboot.mode=f-ksg. C'est ici! Ceux. Le chargeur de démarrage supprime la protection de fota. Et purement théoriquement, si j'écris la partition de démarrage sur fota et que je redémarre le téléphone dans ce mode, j'obtiendrai alors un noyau avec la protection Kyocera désactivée. Mais je ne parviens toujours pas à écrire sur les partitions système.
Étudier les sources du petit noyau (lk)
Ce qui se trouve dans la section aboot est le chargeur de démarrage Android, dont les sources Vanilla se trouvent à l'adresse :
Vous y trouverez également des informations sur la manière dont se déroule le chargement dans certains modes. Par exemple, j'ai trouvé des informations selon lesquelles si vous écrivez « boot-recovery » dans la section divers, alors sans récupération de redémarrage adb. Lors du chargement dans la récupération, ce fichier . Et si la récupération ne peut pas démarrer, le téléphone entrera dans la boucle de démarrage et vous le perdrez. Soyez donc prudent et évitez mieux cette option de redémarrage.
Vous y trouverez également du code qui fait passer la zone système emmc en mode . La réponse à la question de savoir pourquoi il est impossible d'écraser la récupération. Cette protection peut être désactivée depuis le noyau Linux en écrivant un module de noyau correspondant. Tout a déjà été écrit par un camarade du pays du soleil levant, qui, semble-t-il, a aussi un faible pour les téléphones Kyocera. Le module n'a pas fonctionné du premier coup, parfois il bloque mmc en mode réclamation. Peut-être que tout n'est pas si simple et qu'une étude détaillée est nécessaire.
Voici comment les signatures des partitions de démarrage sont vérifiées :
Premiers succès
message
Google m'a aidé à répondre à la question de savoir pourquoi je ne peux pas lire les journaux du noyau : /proc/sys/kernel/dmesg_restrict . La valeur de ce paramètre est définie sur 1 au démarrage du téléphone. Si l'utilisateur n'a pas CAP_SYS_ADMIN capacité, alors les journaux ne lui sont pas disponibles.
uevent_helper
Dans mon cas, étonnamment, il était possible de définir /sys/kernel/uevent_helper . Si vous écrivez le chemin d'accès au fichier exécutable dans ce paramètre (un script shell fonctionnera également), alors il sera lancé à un certain intervalle à partir du processus d'initialisation dans le contexte d'initialisation et, surtout, avec toutes les capacités.
J'ai écrit le scénario :
#!/system/bin/sh echo 0 > /proc/sys/kernel/dmesg_restrict
Je l'ai téléchargé sur mon téléphone et j'ai noté son chemin dans /sys/kernel/uevent_helper. J'ai maintenant l'occasion de voir dmesg !
Adbd corrigé
Parce que J'en ai marre d'avoir accès à la console Android allégée et je suis trop paresseux pour patcher le binaire adbd, j'ai donc décidé de créer mon propre adbd avec du blackjack et des putes. Pour ce faire, j'ai dû télécharger 70 Go de sources Android afin de ne pas bricoler chaque dépendance séparément. J'ai supprimé la vérification qui réduit les capacités, je l'ai compilé, j'ai remplacé /sbin/adbd et j'ai obtenu une console racine à part entière. Maintenant, je peux monter des systèmes de fichiers, regarder Dmesg sans me déconnecter dmesg_restrict, affichez et modifiez tranquillement les fichiers qui n'appartiennent pas à root et bien plus encore. Mais je ne peux pas encore monter la partition /system et charger les modules dans le noyau.
À propos, cette procédure peut être évitée en compilant lsh et en remplaçant son chemin dans /sys/kernel/uevent_helper . Il est conseillé d'envelopper le lancement de lsh dans un script qui spécifie l'environnement PATH, sinon vous devrez spécifier le chemin complet de chaque commande.
Wifi
Le WiFi sur mon téléphone fonctionne via le module noyau. Le WiFi est activé - le module est chargé. Le WiFi est désactivé - le module est déchargé. Si vous remplacez le module par le vôtre, lorsque vous activez le WiFi, le module de remplacement devrait se charger. Heureusement pour moi, la signature numérique des modules n'a pas été vérifiée. La première chose que j'ai essayée a été de créer et de charger un module qui désactive SELinux en remplaçant la mémoire du noyau sur un Amazon Fire Phone : https://github.com/chaosmaster/ford_selinux_permissive
Pour construire un module, vous avez besoin des sources du noyau plus ou moins correspondantes et du fichier Module.symvers. Si les sources correspondent exactement au noyau utilisé sur le téléphone, alors Module.symvers généré automatiquement lors de la construction du noyau devrait convenir.
Si le noyau se plaint lors du chargement d'un module ( n'est pas d'accord sur la version du symbole module_layout), vous devrez alors extraire Module.symvers de la partition de démarrage. Cela peut être fait en utilisant le 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
Vous ne pouvez pas simplement récupérer et assembler votre propre module pour un téléphone Kyocera.
À chaque solution d’un autre problème, le processus rappelle de plus en plus l’aporie d’Achille et de la tortue. Je ne sais pas combien de temps durera mon enthousiasme. Peut-être y a-t-il ici des personnes compétentes qui peuvent vous aider à atteindre le fond du terrier du lapin.
Je voudrais profiter de cette occasion pour exprimer ma gratitude aux développeurs de Kyocera pour leurs excellents appareils et leur protection. Sinon cet article n'existerait pas. En revanche, le manque de mises à jour régulières est très décevant. Si vous obtenez un modèle de téléphone avec la possibilité de déverrouiller le chargeur de démarrage, je l'achèterai certainement.
P.S. Un grand merci à Nikolay Elenkov, auteur du livre Android security internals. Ses explications sur le fonctionnement du bootloader ont permis de comprendre le processus de démarrage d'Android.
P.P.S. Un autre spécialiste de la sécurité mobile, Justin Case, a déclaré qu'il connaissait la vulnérabilité à laquelle sont sensibles tous les processeurs Qualcomm modernes, mais il ne divulguera pas ses détails.
Mots clés:
- Android
- bootloader Soumettre anonymement
Problème
Malgré tous ses avantages, le bus PCI appartient au passé. Le plus souvent, vous avez besoin d'obtenir une liste de tous les périphériques du système, pas seulement des périphériques PCI : ceux-ci incluent également les périphériques USB,
et périphériques SCSI, configuration de la mémoire et même processeur.
Solution
Utilisez le programme dmesg. Le programme affiche une liste de tous les matériels détectés par le noyau.
Pour afficher toutes les sorties dmesg, entrez la commande
$dmesg | moins
La sortie dmesg peut également être filtrée pour trouver des
dispositifs. Ainsi, la commande suivante répertorie tous les périphériques PCI :
$ dmesg je grep -i usb
Liste des appareils ISA :
$ dmesg ] grep -i isa
isapnp : Recherche de cartes PnP...
isapnp : bizarrerie du périphérique audio SB - augmentation de la plage de ports
isapnp : Carte "SupraExpress 56i Voice"
Détermination de la quantité de mémoire physique dans le système :
$dmesg | grep -i mémoire
Mémoire : 256 492/262 080 Ko disponibles (1 467 Ko de code noyau. 5 204 réservés. 516 Ko de données. 96 Ko
je n'ai pas. OK, haute mémoire)
Répertoriez les périphériques IDE qui utilisent le sous-système d'émulation SCSI dans le noyau 2.4 et versions antérieures :
$dmesg | grep -i scsi
Ligne de commande du noyau : root=/dev/hda6 ro hdb=scsi hdc=scsi
ide_setup : hdb=scsi
ide_setup : hdc=scsi
hdb : pilote ide-scsi joint
hdc : pilote ide-scsi joint
scsio : émulation d'adaptateur hôte SCSI pour les périphériques IDE ATAPI
Et voici à quoi ressemblent les « vrais » appareils SCST non émulés :
$dmesg | grep -i scsi
Pilote du sous-système SCSI Révision : 1.00
scsiO : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rév. 6.2.8
...Fournisseur : IBM-PSG Modèle : DPSS-336950M M Rév : S9HA
Disque scsi attaché sda à scsiO, canal 0. id 0. lun 0
(scsi0:A:0): transferts 160.000 mo/s (80.000 MHz DT. offset 63. 16 bits)
Périphérique SCSI sda : 71096640 secteurs hdwr de 512 octets (36 401 Mo)
Vérification des partitions :
sda : sdal sda2sda3 sda4< sda5 sda6 >
Ce qui suit montre des informations sur la caméra USB connectée au système, y compris
son emplacement dans le système de fichiers. Informations généralement sur le périphérique USB
prend une douzaine de lignes ou plus :
% message | grep -i usb
. . .
usb.с : nouveau pilote enregistré ibmcam
icmcam.c : Caméra USB IBM PC Camera trouvée (modèle 2. rév. 0x030a)
usbvideo.c : ibmcam sur /dev/videoO : canvas=352x240 videosize=352x240
Afficher des informations sur les ports série :
$dmesg | grep -i tty
ttySOO à 0x03f8 (irq = 4) est un 16550A
Affichage des informations sur le ou les processeurs :
$dmesg | grep -i processeur
Initialisation du processeur n°0
CPU : LI Cache : 64 Ko (64 octets/ligne). Cache D 64 Ko (64 octets/ligne)
CPU : Cache L2 : 64 Ko (64 octets/ligne)
Rapport de vérification de la machine Intel activé sur le processeur n°0.
CPU : Après générique, majuscules : 0183f9ff clc7f9ff 00000000 00000000
CPU : Caps communs : 0183f9ff clc7f9ff 00000000 00000000
CPU : Processeur AMD Duron(tm) pas à pas 01
Veuillez noter que la recherche renvoie uniquement les lignes contenant la sous-chaîne recherchée. Des informations supplémentaires sont souvent fournies
dans les lignes adjacentes et se retrouve en visualisant directement le fichier :
Initialisation du processeur n°0
Processeur 801,446 MHz détecté.