Je utilise Android 8 pour un appareil intégré, avec Android Verified Boot 2.0 sécurisé via des clés matérielles, et A/B mise à jour OTA (pas de streaming). Je veux m'assurer que le logiciel sur l'appareil est bien sécurisé; cependant, j'ai du mal à retracer les étapes individuelles que la mise à jour effectue. Un indice serait les métadonnées contenues dans la mise à jour payload.bin.
Malheureusement, il semble n'y avoir aucune documentation sur le format de fichier payload.bin et son contenu. Y a-t-il une documentation officielle sur le format de fichier? Ou y a-t-il un morceau de code précis (par exemple, des outils de construction) que je n'ai pas encore découvert? Les outils pour "dumper" payload.bin me donnent les images contenues, mais pas les métadonnées. Ce que j'aimerais comprendre est le suivant:
- Quelles parties de
payload.binsont signées avec quelle clé? - Y a-t-il des parties qui ne sont pas signées?
- Quels éléments de vérification supplémentaires sont contenus dans
payload.bin, et comment leupdate_engineles utilise? Par exemple: il y a des hachages pour vérifier les partitions cibles après l'installation - Pour une mise à jour différentielle, il doit y avoir un moyen de garantir que le système sur l'appareil est exactement le même que celui utilisé comme source pour la différence de mise à jour. Où sont ces valeurs de hachage?
- Qu'en est-il d'une mise à jour complète - l'outil de mise à jour peut-il garantir que la mise à jour est installée uniquement sur une version spécifique de l'appareil?
Je m'excuse si j'ai manqué des sources qui répondent à ces questions. Les livres sur la programmation système Android que j'ai trouvés sont maintenant obsolètes. Toute indication de documentation pertinente au-delà des documents Android de base serait grandement appréciée.
1 votes
Ce que je comprends, c'est que Google a transféré l'infrastructure des mises à jour A/B de leur système Chrome OS à code source fermé vers AOSP. Mais ils veulent que les OEM utilisent le client de mises à jour A/B de Google (intégré dans Play Service) et donc les serveurs de mises à jour de Google ainsi que l'hébergement cloud. Après tout, il s'agit de business. Il n'existe aucune documentation claire, mais pour les âmes technophiles, le code complet est disponible dans
update_engine, suffisant pour comprendre et mettre en œuvre à partir de zéro. Il s'agit plutôt d'une question liée au développement.0 votes
"Les OEM qui n'utilisent pas l'infrastructure OTA de Google pourront réutiliser le code système AOSP mais devront fournir leur propre client." source.android.com/devices/tech/ota/ab#overview