J'essaie de recueillir des données sur mon téléphone en analysant les fichiers journaux /dev/log. Je regarde spécifiquement /dev/log/main. J'ai toujours pensé que tout format de journal sain serait du texte brut, mais ces fichiers semblent être soit binaires, soit dans un jeu de caractères que ni moi ni mes éditeurs de texte Linux ne pouvons identifier.

Quel est le format?

Voici quelques captures d'écran:

• Tout d'abord, voici un extrait du journal tel qu'interprété par vim( ^@fait référence à l'octet nul; je ne suis pas sûr des autres séquences de contrôle colorées):

• Ensuite, voici à quoi ressemble le journal dans un éditeur hexadécimal:

J'utilise un Galaxy Nexus exécutant Jelly Bean. Les journaux ont été collectés à l'aide de root et d'un émulateur de terminal, car aLogcat ne semble pas utiliser root et ne peut donc pas accéder à toutes les informations de journalisation.

Si vous voulez des informations sensées, je recommande des commandes sensées :) (aucune infraction ne signifie, je plaisante). La question devrait donc se lire:

Comment obtenir des informations de journal depuis un appareil Android?

Et maintenant, nous sommes du meilleur côté. Il existe plusieurs approches qui peuvent être utilisées:

• utiliser des applications pour afficher les informations de journal (codées par couleur)
• utiliser ADB (partie du SDK Android) pour extraire à distance les mêmes informations
• utiliser ssh à distance (ou une application de terminal local) pour acquérir les informations directement à partir de l'appareil

Pour gérer complètement ce sujet, il faut plus que cette simple réponse (si vous êtes intéressé, vous pouvez par exemple trouver des informations plus détaillées sur de nombreux sites Web, ou dans le livre d'Andrew Hoog Android Forensics: Investigation, Analysis and Mobile Security for Google Android , que j'avais le honneur de traduire en allemand. Il existe probablement bien d'autres sources également.

Je vais donc donner quelques exemples ici pour vous aider à démarrer:

Utilisation d'applications

L'application probablement la plus connue dans ce contexte est aLogcat , disponible gratuitement dans le Playstore (et le développeur acceptera volontiers votre don pour l'autre variante de la même application). Vous trouverez une capture d'écran ci-dessous ¹ . L'application vous permet de filtrer les journaux, de démarrer / arrêter l'enregistrement des messages de journal et même de stocker les extraits enregistrés sur votre carte SD - bien sûr en texte brut, comme vous l'avez demandé.

Une autre application de cette section est Log Collector , qui essaie simplement de récupérer l'intégralité du journal disponible et de l'envoyer via le menu de partage ² .

Le pont de débogage Android (ADB)

Le Kit de développement logiciel Android (SDK) comprend la adbcommande pour diverses tâches. Entre autres, il propose adb shelld'exécuter des commandes sur l'appareil. En utilisant cela, vous pouvez également rassembler les informations de journal souhaitées: préfixez simplement les commandes ci-dessous avec adb shell.

Invite de commande sur l'appareil

En utilisant une application de terminal (par exemple Android Terminal Emulator ou Terminal IDE ), vous pouvez accéder aux journaux directement à l'invite de commande, localement sur votre appareil. Un peu plus confortable, cela peut être fait en exécutant un serveur ssh (par exemple DroidSSHd ou DropBear SSH Server ) sur votre appareil, et y accéder depuis votre ordinateur. De cette façon, vous pouvez travailler sur un grand écran, tout en examinant vos journaux.

Commandes pour accéder à vos informations de journal

Il existe de nombreuses commandes puissantes que vous pouvez utiliser pour accéder à vos informations de journal à partir de la ligne de commande, et je ne donnerai ici que quelques exemples.

dmesg

La dmesgcommande extrait le journal du noyau:

$ dmesg
<6>[82839.126586] PM: Syncing filesystems ... done.
<7>[82839.189056] PM: Preparing system for mem sleep
<4>[82839.189361] Freezing user space processes ... (elapsed 0.05 seconds) done.
<4>[82839.240661] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
<7>[82839.242279] PM: Entering mem sleep
<4>[82839.242889] Suspending console(s) (use no_console_suspend to debug)
<7>[82839.252410] vfp_pm_save_context: saving vfp state
<6>[82839.252716] PM: Resume timer in 26 secs (864747 ticks at 32768 ticks/sec.)
<6>[82842.091369] Successfully put all powerdomains to target state
<6>[82842.092468] wakeup wake lock: wifi_wake

logcat

Avec logcat, vous pouvez accéder à de nombreuses informations de journalisation - mais la plupart du temps, cela nécessite un root. Il possède certains paramètres pour filtrer les informations, par exemple en sélectionnant le tampon de journal avec lequel lire -b. Veuillez lire les informations fournies sur la page des développeurs sur logcat pour plus de détails. Pour vous donner deux exemples: logcat -b eventsrépertorierait des événements ou des logcat -b radioinformations sur le module radio de votre appareil.

dumpsys et dumpstate

Les deux commandes dumpsyset dumpstatevous donnent des informations détaillées sur le système:

$ dumpsys
Currently running services:
    LocationProxyService
    SurfaceFlinger
    accessibility
    account
    activity
<snip>
DUMP OF SERVICE account:
Accounts: 1
    Account {[email protected], type=com.google}
<snip>
DUMP OF SERVICE alarm:

$ dumpstate
========================================================
== dumpstate: 2012-08-18 23:39:53
========================================================
Build: Gingerbread GWK74 - CyanogenMilestone2
Bootloader: 0x0000
Radio: unknown
<snip>
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 487344 kB
MemFree:   10436 kB
Buffers:   14136 kB
Cached:    145460 kB
<snip>

rapport d'erreur

Et si vous êtes trop paresseux pour vous souvenir de tous, utilisez simplement la bugreportcommande - qui appelle tout ci-dessus et la regroupe pour un joli rapport de bogue au développeur ...

Bien sûr, vous pouvez rediriger la sortie de toutes ces commandes vers un fichier à copier sur votre ordinateur, et dans la plupart des cas, vous devez le faire - car votre mémoire tampon d'écran serait beaucoup trop petite pour tout gérer: bugreport > /mnt/sdcard/bugreport.txtserait un exemple pour cette partie.

Pour les développeurs (ou autres parties intéressées) qui ont besoin d'analyser ce fichier brut, voici quelques ressources:

• logcat (le programme qui peut générer des journaux binaires), il appelle android_logger_list_read()pour rassembler les entrées de journal: https://android.googlesource.com/platform/system/core/+/master/logcat/logcat.cpp
• Informations sur la journalisation Android en général: http://elinux.org/Android_Logging_System
• La bibliothèque de journalisation de bas niveau pour lire / écrire des journaux: https://android.googlesource.com/platform/system/core/+/master/liblog
• Un utilitaire pour vider les journaux bruts (binaires), en changeant éventuellement de version: https://lekensteyn.nl/files/logread.c
• Source du noyau pour l'enregistreur: https://github.com/android/kernel_common/blob/android-3.10/drivers/staging/android/logger.c

Le format réel du format de journal est détaillé à:

• https://android.googlesource.com/platform/system/core/+/master/include/log/logger.h

Une copie des pièces pertinentes, légèrement annotée et réorganisée pour votre commodité:

#define LOGGER_ENTRY_MAX_LEN (5*1024)

struct log_msg {
    union {
        /* Maximum size of entry: 5121 bytes */
        unsigned char buf[LOGGER_ENTRY_MAX_LEN + 1];

        struct logger_entry_v3 entry;
        struct logger_entry_v3 entry_v3;
        struct logger_entry_v2 entry_v2;
        struct logger_entry entry_v1;
    } __attribute__((aligned(4)));
}
/*
 * The userspace structure for version 1 of the logger_entry ABI.
 * This structure is returned to userspace by the kernel logger
 * driver unless an upgrade to a newer ABI version is requested.
 */
struct logger_entry {
    uint16_t    len;    /* length of the payload */
    uint16_t    __pad;  /* no matter what, we get 2 bytes of padding */
    int32_t     pid;    /* generating process's pid */
    int32_t     tid;    /* generating process's tid */
    int32_t     sec;    /* seconds since Epoch */
    int32_t     nsec;   /* nanoseconds */
    char        msg[0]; /* the entry's payload */
} __attribute__((__packed__));

/*
 * The userspace structure for version 2 of the logger_entry ABI.
 * This structure is returned to userspace if ioctl(LOGGER_SET_VERSION)
 * is called with version==2; or used with the user space log daemon.
 */
struct logger_entry_v2 {
    uint16_t    len;    /* length of the payload */
    uint16_t    hdr_size; /* sizeof(struct logger_entry_v2) */
    int32_t     pid;    /* generating process's pid */
    int32_t     tid;    /* generating process's tid */
    int32_t     sec;    /* seconds since Epoch */
    int32_t     nsec;   /* nanoseconds */
    uint32_t    euid;   /* effective UID of logger */
    char        msg[0]; /* the entry's payload */
} __attribute__((__packed__));

struct logger_entry_v3 {
    uint16_t    len;    /* length of the payload */
    uint16_t    hdr_size; /* sizeof(struct logger_entry_v3) */
    int32_t     pid;    /* generating process's pid */
    int32_t     tid;    /* generating process's tid */
    int32_t     sec;    /* seconds since Epoch */
    int32_t     nsec;   /* nanoseconds */
    uint32_t    lid;    /* log id of the payload */
    char        msg[0]; /* the entry's payload */
} __attribute__((__packed__));

Vous pouvez distinguer les versions des différences en regardant les troisième et quatre octets. Le format dépend apparemment aussi de l'endianité de votre plateforme. Pour les messages v1, __padest égal à 0. les messages v2 (et v3) utilisent 24 ( 0x18).

Pour main, radioet les systemjournaux msgchamp est interprété comme suit ( la source ):

• priorité: 1 octet
• tag: 0 ou plusieurs octets
• littéral \0comme séparateur
• message: 0 ou plusieurs octets
• littéral \0comme terminateur

Si ce message est tronqué, la fin \0peut être manquante.

eventsCependant, pour le journal, le msgchamp contient les données binaires suivantes:

• Tag: clé entière de 4 octets du fichier "/ system / etc / event-log-tags".
• Message: arborescence sérialisée à partir du nœud racine. Chaque nœud d'arbre commence par une valeur d'un octet issue de l'énumération AndroidEventLogType:
  • EVENT_TYPE_INT - la valeur du nœud est un entier de 4 octets
  • EVENT_TYPE_LONG - la valeur du nœud est un entier de 8 octets
  • EVENT_TYPE_STRING - la valeur du nœud est un entier de 4 octets length, suivi des lengthoctets contenant une chaîne encodée en UTF8
  • EVENT_TYPE_LIST - la valeur du nœud est un octet unique length, suivi par les lengthnœuds d'arborescence chacun des siens AndroidEventLogType.