Estoy usando Android 8 para un dispositivo embebido, con Android Verified Boot 2.0 asegurado a través de teclas HW, y actualización A/B OTA (sin streaming). Quiero asegurarme de que el software en el dispositivo está bien asegurado; sin embargo, estoy teniendo un tiempo difícil de rastrear los pasos individuales que la actualización realiza. Una pista sería los metadatos contenidos en la actualización payload.bin
.
Lamentablemente, parece que no hay documentación sobre el payload.bin
formato de archivo y su contenido. ¿Existe una documentación oficial para el formato de archivo? ¿O hay una pieza de código crujiente (por ejemplo, herramientas de construcción) que aún no he descubierto? Las herramientas para el "dumping" payload.bin
me da las imágenes contenidas, pero no los metadatos. Lo que me gustaría entender es lo siguiente:
- ¿Qué partes de
payload.bin
¿están firmados con qué clave? - ¿Hay partes que no están firmadas?
- Qué elementos de verificación adicionales contiene
payload.bin
y cómo elupdate_engine
¿las utilizas? Por ejemplo: hay hashtags para verificar las particiones de destino tras la instalación - Para una actualización diferencial, debe haber un medio para asegurar que el sistema en el dispositivo es exactamente el que se utiliza como fuente para la actualización diff. ¿Dónde están esos valores hash?
- ¿Qué tal una actualización completa? ¿Puede el actualizador garantizar que la actualización se instale sólo sobre una versión específica en el dispositivo?
Pido disculpas si he omitido fuentes que respondan a estas preguntas. Los libros sobre programación de sistemas Android que he encontrado están ya obsoletos. Cualquier indicación de documentación relevante más allá de los documentos básicos de Android sería muy apreciada.
1 votos
Lo que entiendo es que Google trasladó la infraestructura de actualizaciones A/B de su sistema operativo Chrome de código cerrado a AOSP. Pero quieren que los OEMs utilicen el cliente de actualizaciones A/B de Google (integrado en Play Service) y por tanto los servidores de actualización de Google junto con el alojamiento en la nube. Al fin y al cabo se trata de un negocio. No hay una documentación clara disponible, pero para las almas conocedoras de la tecnología el código completo está disponible en
update_engine
lo suficiente como para entenderlo y ponerlo en práctica desde el principio. Esta es una pregunta más relacionada con el desarrollo.0 votos
"Los OEM que no utilicen la infraestructura OTA de Google podrán reutilizar el código del sistema AOSP, pero tendrán que suministrar su propio cliente". source.Android.com/devices/tech/ota/ab#overview