1. Trouvez une référence à GND
   • En utilisant les composants précédemment trouvés
   • Habituellement, les plaques métalliques sont à GND
2. Trouvez une référence à VCC
   • En utilisant les composants précédemment trouvés
   • Recherchez des condensateurs, ils ont généralement un point à VCC
3. Testez les broches candidates UART en remplissant le tableau ci-dessous (les puces correspondent respectivement à chaque colonne du tableau)
   1. Testez la résistance des broches UART par rapport à GND (multimètre en mesure de résistance, généralement 200k)
   2. Testez la résistance des broches UART par rapport à VCC (multimètre en mesure de résistance, généralement 200kOhm)
   3. Mettez l'appareil sous tension et testez la tension des broches UART par rapport à GND (multimètre en mesure de tension, généralement 20V)
   4. Mettez l'appareil sous tension et PENDANT LE BOOT, testez la tension de la broche UART suspectée d'être TX par rapport à GND (multimètre en mesure de tension, généralement 20V) ; si la tension oscille, cette broche est probablement TX (car elle envoie des données)
   5. Mettez l'appareil sous tension et PENDANT LE BOOT, testez la tension de la broche UART suspectée d'être RX par rapport à GND (multimètre en mesure de tension, généralement 20V) ; si la tension reste bloquée à 0, cette broche est probablement RX (car elle attend de recevoir des données)

   • Tableau

1. Connectez-le à l'ordinateur (débit en bauds : 115200)
2. IMPORTANT : H est la fonction d'affichage de l'aide, utilisez-la partout
3. Connectez le GND de la carte au GND du Jtagulator, les broches 1,2,3 de la carte aux canaux 1,2,3 du Jtagulator
4. V : régler la tension de fonctionnement
5. U : entrer dans le menu d'identification UART
6. U : démarrer l'identification
7. Text string to output : par défaut
8. Starting channel : canal où nous avons mis la broche 1 de la carte
9. Ending channel : canal où nous avons mis la broche 3 de la carte
10. Ignore non-printable characters : Oui
11. Terminé !

• Adaptateur série choisi : FT232H + Focaccia Board

1. Choisissez la tension appropriée (3.3V ou 5V), sinon la carte ou l'adaptateur série seront endommagés
2. Connectez la RX de la carte à la TX de l'adaptateur et la TX de la carte à la RX de l'adaptateur
   • REMARQUE : généralement, connecter la broche VCC n'est pas nécessaire
3. Connectez l'adaptateur à l'ordinateur
   1. sudo lsusb pour localiser l'adaptateur
   2. ls -lart /dev pour localiser tous les fichiers de périphériques ; le nôtre devrait être parmi les derniers, généralement ttyUSB0
   3. Pour accéder à ce périphérique, nous devons faire partie du groupe dialout (ou être root) ; pour vérifier nos groupes groups $USER
   4. screen /dev/ttyUSB0 $BAUDRATE pour s'attacher au TTY
      • $BAUDRATE peut être l'un de ceux trouvés ici
      • Les $BAUDRATE les plus courants
        • 115200
        • 9600
        • 57600
        • 38400
        • 19200
      • IMPORTANT : si on foire le $BAUDRATE, on pourrait voir du charabia ou même RIEN
      • ctrl + a -> k -> y : fermer screen

• Si la broche RX semble ne pas fonctionner (vous tapez et appuyez sur Entrée mais rien ne se passe), il se peut que la valeur de « retour » soit incorrecte : \r\n ou \n ?
  • Pour résoudre ce problème, utilisez pyserial, la bibliothèque Python pour la communication série, exemple :
    root@kitploit:~

    #!/usr/bin/env python3
    
    import serial
    
    ser = serial.Serial('/dev/ttyUSB0', 115200, tmieout = 0.1)
    ser.write(b"HELLO\r\n")
    ser.write(b"HELLO\n")
    

  • Si le problème persiste, utilisez un analyseur logique (ici un modèle pas cher)

• Qu'est-ce que JTAG : l'interface JTAG offre aux fabricants un moyen de tester les connexions physiques entre les broches d'une puce. Lorsque les ingénieurs électriciens parlent d'utiliser JTAG pour « déboguer » une puce, ils parlent de quelque chose de très différent du débogage logiciel traditionnel. Ils veulent s'assurer que la broche A de la puce A est physiquement connectée à la broche B de la puce B, et que toutes ces broches fonctionnent correctement. Étant donné que JTAG donne un accès matériel direct à un appareil, c'est aussi un outil fantastique pour la recherche en sécurité.
• Propriétés de JTAG
  • Contrôlabilité : régler les bits internes à 0 ou 1
  • Observabilité : vérifier la valeur des bits internes
  • ... donc lire/écrire l'EEPROM
  • Débogage in-circuit : déboguer le code sur le circuit (en utilisant par exemple OpenOCD et GDB)
• Recherchez sur Internet
• Recherchez sur le PCB les mentions TCK, TDI, TDO, TMS et TRST (facultatif)
  • TCK (Test Clock) : le batteur, ou métronome qui dicte la vitesse du contrôleur. La tension sur cette broche pulse simplement de haut en bas à un rythme régulier et constant. À chaque « battement » de l'horloge, le contrôleur effectue une seule action.
  • TMS (Test Mode Select) : les tensions sur la broche Mode Select contrôlent l'action que JTAG effectue. En manipulant la tension sur cette broche, vous dites à JTAG ce que vous voulez qu'il fasse.
  • TDI (Test Data-In) : la broche qui achemine les données vers la puce. La norme JTAG ne définit pas de protocoles de communication pour cette broche. Cela est laissé au fabricant. En ce qui concerne JTAG, cette broche est simplement une méthode d'entrée pour des 1 et des 0 dans la puce. Ce que la puce en fait est sans importance pour JTAG.
  • TDO (Test Data-Out) : la broche pour les données sortant de la puce. Comme pour la broche Data-In, les protocoles de communication ne sont pas définis par JTAG.
  • TRST (Test Reset, facultatif) : ce signal est utilisé pour réinitialiser JTAG à un état sain connu.
• Recherchez une rangée de 5/6 broches ou une double rangée de 10, 12, 14, 20 broches sur le PCB
  1. Trouvez une référence à GND
     • En utilisant les composants précédemment trouvés
     • Habituellement, les plaques métalliques sont à GND
  2. Trouvez une référence à VCC
     • En utilisant les composants précédemment trouvés
     • Recherchez des condensateurs, ils ont généralement un point à VCC
  3. Testez les broches candidates JTAG en remplissant le tableau ci-dessous (les puces correspondent respectivement à chaque colonne du tableau)
     1. Testez la résistance des broches JTAG par rapport à GND (multimètre en mesure de résistance, généralement 200k)
     2. Testez la résistance des broches JTAG par rapport à VCC (multimètre en mesure de résistance, généralement )
• Utiliser Jtagulator
  1. Connectez-le à l'ordinateur (débit en bauds : 115200)
  2. IMPORTANT : H est la fonction d'affichage de l'aide, utilisez-la partout
  3. Connectez la broche GND de la carte à GND du Jtagulator, les broches 1,2,3... de la carte aux canaux 1,2,3... du Jtagulator
  4. V : régler la tension de fonctionnement
  5. J : entrer dans le menu d'identification JTAG
  6. Là, nous avons deux options
     • I : identifier avec un scan IDCODE, ne trouvera pas TDI (rapide), mieux si j'ai beaucoup de broches à identifier
     • B : identifier avec un scan BYPASS, trouvera (lent), mieux si j'ai moins de broches à identifier
• TODO: - Utiliser BurtleinaBoard + Busside
• IMPORTANT
  • Le JTAG peut avoir été désactivé (matériel, en retirant une résistance) il est donc possible que ce que vous trouvez avec le multimètre et le Jtagulator ne soit pas cohérent ; nous pouvons résoudre ce problème en plaçant une résistance d'environ 300Ohm ou 1kOhm entre cette broche et VCC
  • Le JTAG peut avoir été désactivé (matériel, en retirant une résistance) ; ce problème peut être résolu en remettant cette résistance ou en faisant une connexion directe en court-circuitant les pastilles de la résistance
  • Le JTAG peut avoir été désactivé (logiciel, en définissant certaines valeurs)
  • Le JTAG peut avoir été désactivé (matériel, en grillant un fusible... dans ce cas, il n'y a aucun espoir)

• "Adaptateur série" choisi : FT232H + Focaccia Board

1. Choisissez la tension appropriée (3.3V ou 5V), sinon la carte ou l'adaptateur série sera endommagé
2. En utilisant le brochage JTAG trouvé précédemment, connectez tout ensemble
3. Gardez la connexion UART ouverte (comme expliqué précédemment) pour interagir avec le périphérique et observer son comportement
4. Lancez OpenOCD
   • Première fenêtre (serveur OpenOCD) : openocd -f $FT232HCONFIGFILE -f $BOARDCONFIGFILE
     • $FT232HCONFIGFILE : référence de la carte Focaccia
     • $BOARDCONFIGFILE : le fichier de configuration de la carte que vous piratez (utile, mais vous ne l'aurez peut-être pas ; optionnel)
       • Remarques
         • Les fichiers de configuration se trouvent dans /usr/local, vous pourriez peut-être y trouver un $BOARDCONFIGFILE utile
         • Sinon, vous pouvez chercher sur Internet
         • Sinon, vous pouvez l'écrire vous-même
         • TODO (écrivez-le vous-même)
   • Deuxième fenêtre (client OpenOCD) : telnet localhost 4444
     • Commandes utiles
       • halt : arrête le CPU (comme un gel)
         • DOIT ÊTRE FAIT AVANT CHAQUE OPÉRATION DE DÉBOGAGE
       • reset : réinitialise le CPU
       • reg : lit les registres du CPU
       • flash info bank $BANKID ou flash info $BANKID : affiche des informations sur la banque de mémoire flash $BANKID (je pense que les banques = blocs de mémoire)
       • flash list : récupère une liste de tableaux associatifs pour chaque périphérique déclaré avec flash bank (dans $BOARDCONFIGFILE), numérotée à partir de zéro
       • flash banks : affiche un résumé sur une ligne de chaque périphérique déclaré avec flash bank (dans $BOARDCONFIGFILE), numéroté à partir de zéro

• Possibilités (le firmware et le système de fichiers peuvent être chiffrés)
  • Le télécharger depuis le site Web du fabricant
  • Si seul l'appareil peut télécharger le firmware (via une mise à jour), reniflez le réseau avec wireshark pour recueillir des informations
  • Lire l'EEPROM directement à l'aide d'un programmateur de puce flash et d'une pince de test
  • Commande de dump du bootloader
    1. Analyser le journal de démarrage imprimé sur l'interface UART
       • Informations qui peuvent être imprimées et qui nous intéressent (les valeurs sont des exemples mais expliquent ce que nous recherchons)
         • Informations générales sur le bootloader
           • Rechercher le nom et la version du bootloader (ex. : U-Boot 1.1.3)
         • Informations sur le SoC
           • Informations supplémentaires sur les cartes (wifi, ethernet...), elles peuvent embarquer leur propre bootloader
           • Modèle du SoC (ex. : ASIC MT7621A...)
           • Fréquence du CPU
         • Informations sur la RAM
           • mtd->writesize=2048 : taille de page (octets)
           • mtd->oobsize=64 : données utilisées pour la correction d'erreurs (octets)
           • devinfo.iowidth=8 : données écrites/lues par opération (octets)
           • Quantité de RAM
         • Informations sur l'EEPROM
           • mtd->erasesize=131072 : écritures restantes de l'EEPROM ? (plus ou moins)
         • Informations sur le noyau OS
           • Rechercher les informations de chargement du bootloader, ici vous pourriez trouver des informations sur le système de fichiers
           • Rechercher la version de buildroot, cela nous aidera à émuler le circuit et à effectuer divers tests
         • Informations sur le système de fichiers
           • Rechercher les informations de chargement du bootloader et le processus de démarrage de l'OS, ici vous pourriez trouver des informations sur le système de fichiers
         • Partitions de l'EEPROM
           • Rechercher le processus de démarrage de l'OS, ici vous pourriez trouver des informations sur les partitions de l'EEPROM, leurs noms, points de montage et longueur en RAM
           • Si vous voyez des partitions dupliquées, c'est probablement pour les mises à jour du firmware, vous pouvez deviner pourquoi
         • Informations sur le processus init
           • Recherchez init started ou quelque chose de similaire, cela se trouvera probablement près de la chaîne BusyBox ou quelque chose d'analogue
         • Le bootloader a-t-il une CLI ?
           • Cherchez le menu du bootloader, ici nous pourrions probablement trouver la réponse à cette question
    2. Essayez d'obtenir un shell du bootloader (automatiquement ou via un menu affiché via UART)
    3. Explorez le shell du bootloader
       • La commande help est votre amie
       • Essayez de trouver un moyen de vider le contenu de la mémoire, python est votre ami
       • Les données OOB (correction de code d'erreur) ne sont pas très utiles à vider
    4. Analyse des données extraites
       • Utilisez binwalk, file et hexdump -C pour vérifier si le fichier extrait est bon ou non et s'il est compressé ou chiffré
         • Avec binwalk -E, nous analysons l'entropie du fichier
           • Entropie PROCHE de 1 : fichier aléatoire, compressé ou chiffré
           • Entropie INFÉRIEURE à 1 : exécutable ou fichier normal
       • Utilisez binwalk -e pour extraire les segments identifiables du fichier
    5. Si binwalk ne comprend pas entièrement l'image extraite, nous pouvons utiliser la table des partitions de l'EEPROM (si elle a été trouvée précédemment) pour diviser manuellement l'image extraite en plusieurs images utiles
       • dd if=$IN_DUMPED_IMAGE of=$OUT_FILE bs=1024 skip=$BYTES_TO_SKIP_FROM_THE_START count=$HOW_MANY_BYTES_TO_WRITE
       • sha1sum, md5sum ou binwalk -W -i pour comparer des images (si par exemple nous pensons qu'elles pourraient être la même image)
    6. La dernière opération peut être exécutée plusieurs fois selon ce que contient l'image extraite ; si par exemple nous avons l'image du noyau, nous pourrions extraire ses composants une autre fois avec binwalk (ou dd si nous pouvons trouver en ligne comment notre image de noyau spécifique est structurée) pour lire le système de fichiers racine
    7. Extraire le système de fichiers
       • Exemple de commande (selon le type de système de fichiers) : fakeroot -s fakeroot.dat usquashfs -d squashfs-root u04-sqfs.dat
         • fakeroot : créer un environnement racine factice, utile pour émuler les permissions de fichiers, les fichiers de périphériques...
           • -s fakeroot.dat : enregistrer l'environnement racine factice pour le restaurer ensuite avec la commande fakeroot -i fakeroot.dat bash
         • usquashfs : extraire le système de fichiers squashfs (peut être différent dans votre cas)
           • -d squashfs-root : dossier de destination
           • u04-sqfs.dat : image du système de fichiers à extraire

• Recherchez les fichiers intéressants démarrés par le processus init et en général ne vous arrêtez pas aux noms, examinez en profondeur quel binaire est exécuté et analysez-les ; les plus intéressants sont les non standard
• Recherchez la chaîne factory mode ; si nous réussissons à mettre l'appareil en mode usine (s'il existe), alors le pirater est beaucoup plus facile
• Commandes utiles
  • Éditeur de texte
  • grep
  • find
  • xargs
  • strings

Construire à l'aide d'un système de build (sélectionner les fonctionnalités et suivre automatiquement les dépendances)

• Meilleurs choix de systèmes de build
  • Le projet Yocto
  • Buildroot (le meilleur)
  • Système de build OpenWRT

Commencer l'émulation

• Script d'émulation QEMU
  root@kitploit:~

  #!/bin/bash
  # This script will build an environment without password for the user root
  export QEMU_AUDIO_DRV="none" # ignore audio drivers
  
  qemu-system-${PROCESSOR}${ARCHITECTURE} -M $CPUFAMILY \ # See point 2
                                          -m $RAMSIZE \
                                          -kernel $KERNELPATH \
                                          -nographic \ # No GUI
                                          -hda $FILESYSTEM \
                                          -net nic,model=$NETCARDMODEL \ # Model of net card, driver must be included in kernel
                                          -net user, hostfw=tcp::2222-:22, hostfw=tcp::9000-:9000 \ # 2222 as ssh and 9000 for GDB server
                                          -no-reboot \ # Terminate the machine when is halted
                                          -append "root=/dev/hda console=uart0" # Set root filesystem and console
  

  • Si lors de l'exécution d'un binaire, une erreur concernant des bibliothèques manquantes s'affiche, définissez LD_LIBRARY_PATH comme suit (dans la machine) : export LD_LIBRARY_PATH=/lib:/usr/lib:$PATHTOORIGINALFILESYSTEMLIBFOLDER
• Nous pourrions aussi émuler l'EEPROM NAND
  root@kitploit:~

  #!/bin/bash
  
  # Part 1: Identify bytes for kernel module
  modprobe nandsim first_id_byte=$FIRSTBYTE \
                      second_id_byte=$SECONDBYTE \
                      third_id_byte=$THIRDBYTE \
                      fourth_id_byte=$FOURTHBYTE \
                      cache_file=/root/nandsim.bin \
                      parts=x,y,z,... # Define partitons size in number of erase blocks; the number of partitions depends on your device, partitions are usually print on boot
  
  # Part 2: Erase partitions created (analyze EEPROM partitions)
  flash_erase /dev/mtd0 0 8 
  flash_erase /dev/mtd1 0 20
  # ...
  
  # Part 3: Load partitions dumped from device in the ones just created
  nandwrite /dev/mtd0 part0.bin
  nandwrite /dev/mtd1 part1.bin
  # ...
  
  # Part 4: Create mountpoint for filesystem and attach (if UBIFS)
  mkdir /mnt/filesystem
  ubiattach -O $N -m $MTDDVENUM -d $UBIDEVNUM
  ```# Partie 5 : Montage
  mount -tubifs /dev/ubi${UBIDEVNUM}_0 /mnt/filesystem
  

  1. Identifier les octets pour le module noyau
     • Pendant le démarrage, les informations sur la NAND sont généralement affichées, observez-les (étapes ci-dessus) et recherchez NAND ID ; les octets affichés sont dans l'ordre premier, deuxième et quatrième octet
     • On peut aussi trouver ces informations en consultant la datasheet de l'EEPROM
     • On peut aussi utiliser writesize, oobsize, erasesize, iowidth pour trouver ici la commande correcte
     • Sinon, essai et erreur
  2. Analyser les partitions EEPROM affichées au démarrage pour trouver leurs tailles et noms ; le dernier nombre de la commande flash_erase correspond à leur taille corrélée au erasesize (comme parts=x,y,z,...)
  3. Charger les partitions dumpées depuis le périphérique dans celles qui viennent d'être créées
  4. Créer un point de montage pour le système de fichiers et attacher
     • -O : spécifier l'offset de l'en-tête d'ID de volume ; si la valeur est fausse, le système devrait vous indiquer la bonne valeur, sinon vous pouvez essayer différentes valeurs comme 512, 1024, 2048 (essai et erreur)
     • -m : numéro du périphérique mtd (voir point 3)

• Notes
  • Pas très stable
  • Peut donner des résultats étranges
• Comment faire
  1. Localiser le format exécutable QEMU : qemu-$PROCESSOR$ARCHITECTURE
     • Exemple : qemu-mips64
  2. Si QEMU se plaint d'un interpréteur manquant, passez le chemin DU DOSSIER CONTENANT cet interpréteur avec -L (ou consultez man)
     • Pour savoir quel interpréteur est utilisé par un exécutable, utilisez readelf -l $EXECUTABLE

• Notre noyau construit devrait avoir (par rapport au noyau d'origine)
  • Même version du noyau
  • Même version de libc (uClibc, uClibc-ng, musl, dietlibc...)
  • Mêmes versions des bibliothèques (de l'exécutable qui nous intéresse)

1. Rechercher la version de buildroot la plus proche des versions de notre périphérique
   • Parfois, pendant le démarrage ou l'exploration de la mémoire dumpée, on peut trouver la version de buildroot utilisée (si le périphérique a été construit avec buildroot)
2. Trouver une version de linux compatible avec la version de buildroot trouvée et créer un conteneur docker, ici un exemple de dockerfile (les paquets sont importants pour exécuter buildroot)
3. Télécharger la version de buildroot sélectionnée depuis ici et la placer dans le dossier partagé du conteneur docker
4. Lancer le conteneur docker et basculer dessus
5. Extraire buildroot et lancer make manual pour créer le manuel de buildroot
6. Avec make help, buildroot affiche tous les périphériques pris en charge (cartes) ; make $YOURBOARDNAME pour créer un fichier de configuration buildroot de votre carte
7. make menuconfig (en mode texte) ou make xconfig (GUI) pour sélectionner les modules noyau à ajouter à notre compilation ; nous utiliserons make xconfig
   • Voici un exemple/guide, mais vous devrez découvrir par vous-même quels modules en particulier seront nécessaires pour exécuter vos applications
   • Astuce : Edit->Find pour rechercher des modules
   • Options
     • Target options
       • Cocher Show options and packages that are deprecated or obsolete
       • Cocher Build packages with debugging symbols avec le debug level le plus élevé
       • Cocher Strip command for binaries on target sur None
       • Cocher GCC optimization level sur 0
     • Toolchain
       • Cocher Toolchain type sur Buildroot toolchain
8. Pour enregistrer définitivement la configuration que vous venez de définir, utilisez make savedconfig
9. Configurer le noyau avec make linux-menuconfig (mode texte) ou make linux-xconfig (GUI) ; ici nous utiliserons la version CLI
   • Voici un exemple/guide, mais vous devrez découvrir par vous-même quels modules en particulier seront nécessaires pour exécuter vos applications
   • Options
     • Kernel type -> Preemption model (Preemptible Kernel (Low-Latency Desktop)) -> Preemptible Kernel (Low-Latency Desktop)
     • Kernel type -> Device drivers -> Memory technology device (MTD) support -> NAND device support -> Support for NAND flash simulator
     • Kernel type -> Device drivers -> -> ->
10. Configurer uClibc (ou votre bibliothèque C) avec uclibc-menuconfig (comme toujours)
    • Activer le débogage : Development/Debugging options -> Enable debugging symbols ; si cela ne fonctionne pas (erreurs de compilation), alors Development/Debugging options -> (Wall) compiler warnings -> ajouter -Wall -ggdb -g3
      • -ggdb : fournit les informations de débogage à utiliser avec GDB
      • -g3 : fournit des informations de débogage supplémentaires
    • Save
    • Activer les fonctionnalités comme sur notre périphérique (essai et erreur ; si vous obtenez des erreurs, enquêtez puis reconstruisez avec les fonctionnalités nécessaires)
11. make ; en cas de problèmes, revenez en arrière
    • Erreurs de compilation possibles
      • Need to use -fPIC
        • Ajouter --enable-shared dans les modules noyau (point 7) sous Toolchain -> Additional gcc options ou patcher buildroot

• Sauvegarder les fichiers de configuration pour buildroot avec git
  • Configuration de l'arbre externe (arborescence des fichiers à faire comprendre à buildroot) (br2)
    root@kitploit:~

    +-- board/
    |   +-- <company>/ (not always used)
    |       +-- <boardname>/
    |           +-- linux.config
    |           +-- busybox.config
    |           +-- kernel-defconfig (kernel config file)
    |           +-- <other configuration files>
    |           +-- post_build.sh (executed just before building the image, useful to copy root filesystem into the image)
    |           +-- post_image.sh
    |           +-- rootfs_overlay/ (everythin here will be copied in the final image)
    |           |   +-- etc/
    |           |   +-- <some file>
    |           +-- patches/
    |               +-- foo/
    |               |   +-- <some patch>
    |               +-- libbar/
    |                   +-- <some other patches>
    |
    +-- configs/
    |   +-- <boardname>_defconfig (buildroot config for our board)
    |   +-- uClibc.config (optional)
    +-- patches/
    |   +-- (here patches to be applied)
    |
    +-- Config.in (if using a br2-external tree)
    +-- external.mk (if using a br2-external tree)
    +-- external.desc (if using a br2-external tree)
    

  • Pour utiliser un arbre externe, invoquez buildroot comme ceci : make BR2_EXTERNAL=$PATHTOEXTTREE $COMMAND
  • Pour sauvegarder la configuration buildroot dans notre arbre externe : make BR2_EXTERNAL=$PATHTOEXTTREE savedefconfig

• $BINTOWRITE : peut être bin (binaire), ihex (Intel hex), elf (fichier ELF), s19 (Motorola s19), mem...
• $ADDRTOSTART : adresse où commencer l'écriture (je pense que la valeur par défaut est 0)

• $OUTFILE : fichier binaire dans lequel enregistrer le dump
• $ADDRTOSTART : adresse où commencer la lecture (je pense que la valeur par défaut est 0)
• $SIZETODUMP : nombre d'octets à vider

• OpenOCD PDF
• OpenOCD HTML

• Cocher Passwords encoding sur MD5
• Cocher Init system sur $DEVICEINITSYSTEM (ou BusyBox)
• Cocher /dev management sur Dynamic using devtmpfs only
• Cocher /bin/sh sur Busybox default shell
• Cocher Install timezone info

• Définir Kernel version sur $DEVICEKERNELVERSION
• Cocher Kernel binary format sur vmlinux

• Compressors and decompressors
  • bzip2 et xz-utils
• Debugging profiling and benchmark
  • Cocher gdb et full debugger
• Development tools
  • Ce dont vous aurez besoin
• Filesystem and flash utilities
  • mtd, jffs2 and ubi/ubifs tools (ou ce dont vous aurez besoin)
• Libraries
  • En général, ce dont vous avez besoin (suggestions ci-dessous)
  • Crypto
    • libsha1
    • libssh2
    • openssl
  • JSON/XML
    • expat
    • json-c

• rsync et ce dont vous avez besoin

• file

• ext2

• host mtd, jffs2 and ubi/ubifs tools
• host util-linux