Get best of the week

Descripción general de la seguridad del software del procesador S905X (arranque seguro)

Este artículo discutirá la protección del software en el procesador S905X. El objetivo final es lanzar software no autorizado.

S905X


El procesador S905X es un ARM Cortex-A53 con una frecuencia de reloj de hasta 1.5 GHz, repleto de todo tipo de decodificadores para transmisiones de video y audio, como H.265 4K, VP9, ​​compatible con 4KUHD, etc. En general, no es una mala elección. A diferencia de su predecesor, AMLogic integró el llamado "sistema de seguridad Advanced TrustZone" en este procesador, que controla todas las operaciones críticas del sistema, como acceder a áreas protegidas de la memoria ROM, verificar la firma y descifrar software, etc. Puede encontrar documentación detallada sobre este tema en el sitio web del fabricante . SecureOS actúa como ATOS-V1.5-g3e467d9 (no lo afirmaré, no lo verifiqué).

Formación


Después de desmontar el prefijo, encontré fácilmente los pines RxD, TxD y GND para UART. En el reverso había un conector para el botón de reinicio (no verificado) y un lugar para el conector. A juzgar por la ubicación, el conector parecía una placa a placa para una tarjeta eMMS alternativa (el pinout está naturalmente ausente).



La documentación de libre acceso para el S905 cubría temas tan críticos como, por ejemplo, la secuencia de arranque, un poco menos que completamente y era prácticamente inútil desde el punto de vista de RE. Dejando a un lado la documentación, conecté UART y ... me sorprendió gratamente la velocidad de carga del procesador. Pero eso es probablemente todo. U-Boot no reaccionó en absoluto al teclado y, después de algunas configuraciones de hardware, cargó de forma inteligente y lanzó el kernel de Android.

Registro de arranque de U-Boot'a
 GXL:BL1:9ac50e:bb16dc;FEAT:BDFC31BC:0;POC:3;RCY:0;EMMC:0;READ:0;0.0;0.0;CHK:0;
TE: 351954

BL2 Built : 16:42:36, Nov  3 2016. 
gxl g3eddb43 - xiaobo.gu@droid05

set vcck to 1120 mv
set vddee to 1000 mv
Board ID = 4
CPU clk: 1200MHz
DQS-corr enabled
DDR scramble enabled
DDR3 chl: Rank0+1 @ 768MHz - FAIL
DDR3 chl: Rank0 @ 768MHz - PASS
Rank0: 1024MB(auto)-2T-11
DataBus test pass!
AddrBus test pass!
-s
Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x00004000
aml log : R2048 check pass!
New fip structure!
Load bl30 from eMMC, src: 0x00010200, des: 0x01700000, size: 0x0000d600
aml log : R2048 check pass!
Load bl31 from eMMC, src: 0x00020200, des: 0x01700000, size: 0x00015400
aml log : R2048 check pass!
Load bl32 from eMMC, src: 0x00038200, des: 0x01700000, size: 0x00035a00
aml log : R2048 check pass!
Load bl33 from eMMC, src: 0x00070200, des: 0x01700000, size: 0x000aa200
aml log : R2048 check pass!
NOTICE:  BL3-1: v1.0(debug):fb68908
NOTICE:  BL3-1: Built : 18:30:11, Nov  1 2016
aml log : bl31 detect secure boot !
[Image: gxl_v1.1.3154-065f772 2016-09-29 14:08:54 yan.wang@droid05]

OPS=0x84

bc fc af 5f a2 b4 4d 4b 1c 91 59 9f [1.280536 Inits done]

secure task start!
high task start!
low task start!
INFO:    BL3-1: Initializing runtime services
INFO:    BL3-1: Initializing BL3-2
INFO:    BL3-2: ATOS-V1.5-g3e467d9 #1 Mon Aug 22 17:11:43 CST 2016 arm
INFO:    BL3-2: chip version = RevC (21:C - 0:0)
INFO:    BL3-2: crypto engine DMA
INFO:    BL3-2: secure time TEE
INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BL3-1: Next image address = 0x1000000
INFO:    BL3-1: Next image spsr = 0x3c9


U-Boot 2015.01 (Nov 23 2018 - 15:50:35)

DRAM:  1 GiB
Relocation Offset is: 36ec8000
register usb cfg[0][1] = 0000000037f5e258
[CANVAS]canvas init
vpu: error: vpu: check dts: FDT_ERR_BADMAGIC, load default parameters
vpu: clk_level = 7
vpu: set clk: 666667000Hz, readback: 666660000Hz(0x300)
vpp: vpp_init
boot_device_flag : 1
Nand PHY Ver:1.01.001.0006 (c) 2013 Amlogic Inc.
init bus_cycle=6, bus_timing=7, system=5.0ns
reset failed
get_chip_type and ret:fffffffe
get_chip_type and ret:fffffffe
chip detect failed and ret:fffffffe
nandphy_init failed and ret=0xfffffff1
MMC:   aml_priv->desc_buf = 0x0000000033ec86b0
aml_priv->desc_buf = 0x0000000033eca9d0
SDIO Port B: 0, SDIO Port C: 1
emmc/sd response timeout, cmd8, status=0x1ff2800
emmc/sd response timeout, cmd55, status=0x1ff2800
[mmc_startup] mmc refix success
[mmc_init] mmc init success
mmc read lba=0x14000, blocks=0x400
      Amlogic multi-dtb tool
      Multi dtb detected
      Multi dtb tool version: v2 .
      Support 2 dtbs.
        aml_dt soc: gxl platform: sx6b6x variant: 1g
        dtb 0 soc: gxl   plat: sx6b6x   vari: 1g
        dtb 1 soc: gxl   plat: sx6b6x   vari: 2g
      Find match dtb: 0
start dts,buffer=0000000033ecd270,dt_addr=0000000033ecda70
parts: 11
00:      logo	0000000002000000 1
01:  recovery	0000000002000000 1
02:       rsv	0000000000800000 1
03:       tee	0000000000800000 1
04:     crypt	0000000002000000 1
05:      misc	0000000002000000 1
06: instaboot	0000000020000000 1
07:      boot	0000000002000000 1
08:    system	0000000050000000 1
09:     cache	0000000040000000 2
10:      data	ffffffffffffffff 4
get_dtb_struct: Get emmc dtb OK!
overide_emmc_partition_table: overide cache 
[mmc_get_partition_table] skip partition cache.
Partition table get from SPL is : 
        name                        offset              size              flag
===================================================================================
   0: bootloader                         0            400000                  0
   1: reserved                     2400000           4000000                  0
   2: cache                        6c00000          40000000                  2
   3: env                         47400000            800000                  0
   4: logo                        48400000           2000000                  1
   5: recovery                    4ac00000           2000000                  1
   6: rsv                         4d400000            800000                  1
   7: tee                         4e400000            800000                  1
   8: crypt                       4f400000           2000000                  1
   9: misc                        51c00000           2000000                  1
  10: instaboot                   54400000          20000000                  1
  11: boot                        74c00000           2000000                  1
  12: system                      77400000          50000000                  1
  13: data                        c7c00000         10a400000                  4
mmc read lba=0x12000, blocks=0x2
mmc read lba=0x12002, blocks=0x2
mmc_read_partition_tbl: mmc read partition OK!
eMMC/TSD partition table have been checked OK!
mmc env offset: 0x47400000 
WARNING: 'recovery_from_sdcard' neither in running nor in imported env!
WARNING: 'recovery_from_udisk' neither in running nor in imported env!
In:    serial
Out:   serial
Err:   serial
hpd_state=0
cvbs performance type = 6, table = 0
[store]To run cmd[emmc dtb_read 0x1000000 0x40000]
read emmc dtb
      Amlogic multi-dtb tool
      Multi dtb detected
      Multi dtb tool version: v2 .
      Support 2 dtbs.
        aml_dt soc: gxl platform: sx6b6x variant: 1g
        dtb 0 soc: gxl   plat: sx6b6x   vari: 1g
        dtb 1 soc: gxl   plat: sx6b6x   vari: 2g
      Find match dtb: 0
Net:   dwmac.c9410000
wipe_data=successful
wipe_cache=successful
upgrade_step=2
[OSD]load fb addr from dts
[OSD]failed to get fb addr for logo
[OSD]use default fb_addr parameters
[OSD]fb_addr for logo: 0x3d800000
[OSD]load fb addr from dts
[OSD]failed to get fb addr for logo
[OSD]use default fb_addr parameters
[OSD]fb_addr for logo: 0x3d800000
[CANVAS]addr=0x3d800000 width=3840, height=2160
amlkey_init() enter!
[EFUSE_MSG]keynum is 4
[BL31]: tee size: 0
[KM]Error:f[key_manage_query_size]L507:key[deviceid] not programed yet
gpio: pin GPIOAO_2 (gpio 102) value is 1
get_cpu_id flag_12bit=1
SARADC channel(0) is 0x3e1.
SARADC closed.
Hit Enter or space or Ctrl+C key to stop autoboot -- :  0 
[imgread]szTimeStamp[2019121002280214]
[imgread]secureKernelImgSz=0x977000
aml log : R2048 check pass!
aml log : R2048 check pass!
aml log : R2048 check pass!
ee_gate_off ...
## Booting Android Image at 0x01080000 ...
reloc_addr =33f4d440
copy done
      Amlogic multi-dtb tool
      Single dtb detected
load dtb from 0x1000000 ......
   Uncompressing Kernel Image ... OK
   kernel loaded at 0x01080000, end = 0x02258fd0
   Loading Ramdisk to 33d12000, end 33eb6000 ... OK
   Loading Device Tree to 000000001fff3000, end 000000001ffff8f4 ... OK
signature: 
fdt_instaboot: no instaboot image

Starting kernel ...


Vale la pena señalar que U-Boot (bl33) ya se estaba ejecutando en el entorno del "mundo normal" (BL3-1 cambió el modo inmediatamente antes de transferirle el control). Aquellos. incluso si de alguna manera tomamos el control de U-Boot, solo tendremos acceso limitado al sistema. En principio, esto no es tan importante. Después de todo, incluso si elimina el volcado de ROM, extraiga las teclas AES y abra RSA del fusible, entonces no tendrá mucho sentido, porque Todavía no hay una clave privada RSA.

U-Boot en sí no leyó ninguna clave. Cargó el núcleo en la memoria y llamó al Monitor de seguridad para descifrar y verificar el código. Security Monitor hizo todo lo necesario y le dijo a U-Boot que cargara el kernel o no. En general, un enfoque serio para la protección de software con su propio TrustedOS y algún tipo de funcionalidad como BIOS.

Mi plan adicional era acceder a la memoria eMMC.

eMMC


Para conectarse a eMMC, era necesario encontrar al menos los pines DAT_0, CLK, CMD y GND. Y también descubra a qué voltaje funcionaba el controlador eMMC (1V8 o 3V3). Era imposible hacer esto visualmente y para las pistas de rastreo saqué yo mismo eMMC. Como el chip estaba en mis manos, después de rastrearlo lo conecté al adaptador y arrojé un volcado completo. Desafortunadamente, no tenía equipo profesional y usé materiales improvisados ​​para esto. El resultado es un "insecto muerto".


Bueno, en realidad el pinout del conector:



Después de que se realizó el pinout, observé cómo se comporta el procesador sin eMMC. A juzgar por el registro, ROM después de un intento fallido de arranque desde eMMC intentó cargar el código de la tarjeta mSD. Esto fue alentador. Subí rápidamente el volcado a la tarjeta mSD y encendí la consola. Una pequeña sorpresa me esperaba aquí. ROM descargó el código BL2 de la tarjeta y le transfirió el control (eso significa que la sección de "arranque" en eMMC no estuvo involucrada y no hubo necesidad de acceso de root). Bueno, cuando llegó el turno de U-Boot, se quejó un par de veces por la falta de eMMC (dev 1) y durante mucho tiempo sin pensar que se detuvo en la terminal.

cmd store failed 
Err imgread(L132):Fail to read 0x100000B from part[recovery] at offset 0
gxl_sx6b6x_768_v2#version


U-Boot 2015.01 (Nov 23 2018 - 15:50:35)
aarch64-none-elf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.11 - Linaro GCC 2013.10) 4.8.3 20131111 (prerelease)
GNU ld (crosstool-NG linaro-1.13.1-4.8-2013.11 - Linaro GCC 2013.10) 2.23.2.20130610 Linaro 2013.10-4
gxl_sx6b6x_768_v2#

Para empezar, no estuvo nada mal. Después de algunos experimentos con el terminal, agregué el parámetro bootdelay = 5 a la sección "env", calculé la nueva suma de verificación y solde el eMMC. Con la nueva opción, esperaba que el U-Boot pudiera detenerse. Pero en la práctica, todo era diferente. Parece que U-Boot no estaba interesado en este parámetro y el proceso de arranque no era diferente del normal. Es triste porque Para mí era necesario un terminal con un eMMC conectado para otras acciones. Con un poco de pensamiento, cerré DAT_0 a tierra e inserté mi tarjeta mSD. ROM ahora no pudo cargar el código de eMMC y cambió a mSD. Después de cargar U-Boot de esta manera, abrí los contactos y pregunté:

gxl_sx6b6x_768_v2#mmc dev 1

emmc/sd response timeout, cmd8, status=0x1ff2800
emmc/sd response timeout, cmd55, status=0x1ff2800
[mmc_startup] mmc refix success
[mmc_init] mmc init success
mmc read lba=0x14000, blocks=0x400
      Amlogic multi-dtb tool
      Multi dtb detected
      Multi dtb tool version: v2 .
      Support 2 dtbs.
        aml_dt soc: gxl platform: sx6b6x variant: 1g
        dtb 0 soc: gxl   plat: sx6b6x   vari: 1g
        dtb 1 soc: gxl   plat: sx6b6x   vari: 2g
      Find match dtb: 0
start dts,buffer=0000000033ee4050,dt_addr=0000000033ee4850
parts: 11
00:      logo	0000000002000000 1
01:  recovery	0000000002000000 1
02:       rsv	0000000000800000 1
03:       tee	0000000000800000 1
04:     crypt	0000000002000000 1
05:      misc	0000000002000000 1
06: instaboot	0000000020000000 1
07:      boot	0000000002000000 1
08:    system	0000000050000000 1
09:     cache	0000000040000000 2
10:      data	ffffffffffffffff 4
get_dtb_struct: Get emmc dtb OK!
overide_emmc_partition_table: overide cache 
[mmc_get_partition_table] skip partition cache.
Partition table get from SPL is : 
        name                        offset              size              flag
===================================================================================
   0: bootloader                         0            400000                  0
   1: reserved                     2400000           4000000                  0
   2: cache                        6c00000          40000000                  2
   3: env                         47400000            800000                  0
   4: logo                        48400000           2000000                  1
   5: recovery                    4ac00000           2000000                  1
   6: rsv                         4d400000            800000                  1
   7: tee                         4e400000            800000                  1
   8: crypt                       4f400000           2000000                  1
   9: misc                        51c00000           2000000                  1
  10: instaboot                   54400000          20000000                  1
  11: boot                        74c00000           2000000                  1
  12: system                      77400000          50000000                  1
  13: data                        c7c00000         10a400000                  4
mmc read lba=0x12000, blocks=0x2
mmc read lba=0x12002, blocks=0x2
mmc_read_partition_tbl: mmc read partition OK!
eMMC/TSD partition table have been checked OK!
switch to partitions #0, OK
mmc1(part 0) is current device
gxl_sx6b6x_768_v2#

U-Boot no se resistió y felizmente cambió a eMMC. Miré, por supuesto, qué había en el parámetro bootdelay. Y en lugar de mis cinco, vi allí nuevamente 0. Parece que U-Boot en algún momento escribió 0 allí, en caso de que alguien cambie repentinamente algo allí. Pero ya no me interesaba y el tema con eMMC estaba cerrado.

Nota: al tener un pinout del conector, puede conectarse a eMMC sin soldar el chip. Para hacer esto, necesita un adaptador especial con un convertidor de voltaje, porque El controlador eMMC se ejecuta en 1V8 y si conecta un adaptador SD común a 3V3, existe el riesgo de quemar componentes que se encuentran en el bus 1V8.

También será necesario quitar esta resistencia, de lo contrario el procesador interferirá con el adaptador.


Componentes faltantes


Al tener acceso completo al terminal U-Boot, tuve que hacer dos cosas: llegar al decodificador DeviceTree y convencer a U-Boot de que abandonara los servicios de Security Monitor relacionados con las pruebas de kernel. Para el primer lanzamiento, sería bueno tener el kernel original, para no perder el tiempo depurando uno nuevo.

Fue extremadamente fácil obtener DeviceTree. Yo pregunté:

gxl_sx6b6x_768_v2#emmc dtb_read 0x1000000 0x40000

read emmc dtb
gxl_sx6b6x_768_v2#

y él estaba en mi bolsillo.

U-Boot requirió un análisis detallado. Del registro se dedujo que U-Boot se cargó y descifró inicialmente en 0x1000000, y luego se transfirió a 0x36ES8000 (desplazamiento). Dejé U-Boot y lo analicé en IDA.

Por supuesto, estaba interesado en el lugar donde se accedía al Monitor de seguridad desde el comando bootm. Aquí es


donde
X0 - AML_D_P_IMG_DECRYPT
X1 - nLoadAddr
X2 - GXB_IMG_SIZE
X3 - GXB_IMG_DEC_ALL

Para eliminar el volcado del núcleo original, tenía que cargarlo en la memoria a través de la función de agregación y modificar bootm para que inmediatamente después de llamar a aml_sec_boot_check se emitiera memoria comenzando desde la dirección 0x1080000 al terminal (esta ciertamente no es la única forma). Para hacer esto, escribí un código y lo descargué en el lugar correcto. Esto es lo que sucedió (por supuesto, no puedo dar un registro completo):

gxl_sx6b6x_768_v2#imgread kernel boot

[imgread]szTimeStamp[2019121002280214]
[imgread]secureKernelImgSz=0x977000
gxl_sx6b6x_768_v2#bootm

aml log : R2048 check pass!
aml log : R2048 check pass!
aml log : R2048 check pass!

Ready for dumping kernel

41 4e 44 52 4f 49 44 21 20 d8 7b 20 20 20 08 01  | ANDROID!

Además del kernel, también obtuve ramdisk (puede ser útil en caso de que haya controladores o firmware importantes, por ejemplo, para WiFi).

Ya no soy Android


Para el primer lanzamiento de mi software, hice uImage desde el núcleo original, construí mis rootfs sobre la base de Busybox y usé mi propio dtb. Cargué las tres partes directamente desde la unidad USB y ejecuté el comando "bootm", deshabilitando el descifrado y la verificación de imágenes antes.

gxl_sx6b6x_768_v2#usb start
(Re)start USB...
USB0:   USB3.0 XHCI init start
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
gxl_sx6b6x_768_v2#mw.l 0x37ed240c 0xd2800000
gxl_sx6b6x_768_v2#fatload usb 0:1 0x1000000 dtb.img
reading dtb.img
40960 bytes read in 43 ms (929.7 KiB/s)
gxl_sx6b6x_768_v2#fatload usb 0:1 0x2000000 uImage
reading uImage
8116288 bytes read in 4197 ms (1.8 MiB/s)
gxl_sx6b6x_768_v2#fatload usb 0:1 0x3000000 rootfs.img.uboot
reading rootfs.img.uboot
1041462 bytes read in 563 ms (1.8 MiB/s)
gxl_sx6b6x_768_v2#bootm 0x2000000 0x3000000 0x1000000

ee_gate_off ...
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   S905X Original
   Image Type:   AArch64 Linux Kernel Image (gzip compressed)
   Data Size:    8116224 Bytes = 7.7 MiB
   Load Address: 01080000
   Entry Point:  01080000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 03000000 ...
   Image Name:   Root Filesystem
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    1041398 Bytes = 1017 KiB
   Load Address: 033d1200
   Entry Point:  033d1200
   Verifying Checksum ... OK
      Amlogic multi-dtb tool
      Single dtb detected
load dtb from 0x1000000 ......
## Flattened Device Tree blob at 01000000
   Booting using the fdt blob at 0x1000000
   Uncompressing Kernel Image ... OK
   kernel loaded at 0x01080000, end = 0x02258fd0
   Loading Ramdisk to 33db8000, end 33eb63f6 ... OK
   Loading Device Tree to 000000001fff3000, end 000000001ffff8f4 ... OK
fdt_instaboot: no instaboot image

Starting kernel ...

uboot time: 136710682 us
[    0.000000@0] Initializing cgroup subsys cpu
[    0.000000@0] Initializing cgroup subsys cpuacct
[    0.000000@0] Linux version 3.14.29 (build@build2) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #1 SMP PREEMPT Thu Sep 12 21:24:53 MSK 2019
[    0.000000@0] CPU: AArch64 Processor [410fd034] revision 4

[    6.302659@2] meson_uart c81004c0.serial: ttyS0 use xtal(8M) 24000000 change 115200 to 115200
# cat /proc/cpuinfo
Processor	: AArch64 Processor rev 4 (aarch64)
processor	: 0
processor	: 1
processor	: 2
processor	: 3
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 wp half thumb fastmult vfp edsp neon vfpv3 tlsi vfpv4 idiva idivt 
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

Hardware	: Amlogic
Serial		: 210c84009f59911c4b4db4a25faffcbc
#

Fuga


Debido al hecho de que U-Boot estaba inmunizado contra el cambio de los parámetros env (esto no solo se refería al "retraso de arranque"), era imposible influir en el proceso de arranque a través de env, y para cargar su software, el prefijo tenía que estar conectado a la computadora. Esta opción no me convenía en absoluto. Después de analizar toda la cadena de carga, este comando me llamó la atención:

init_display=osd open;osd clear;imgread pic logo bootup $loadaddr;bmp display $bootup_offset;bmp scale

en particular:

imgread pic logo bootup $loadaddr

donde U-Boot estaba cargando un determinado recurso de "arranque" en la dirección loadaddr = 0x1080000. El recurso en sí mismo fue descrito por dicha estructura:

struct resource_header{
	unsigned int 	magic;		/* Image Header Magic Number	*/
	unsigned int 	hcrc;		/* Image Header CRC Checksum	*/
	unsigned int	size;		/* Image Data Size		*/
	unsigned int	start;		/* item data offset in the image*/
	unsigned int	end;		/* Entry Point Address		*/
	unsigned int	next;		/* Next item head offset in the image*/
	unsigned int	dcrc;		/* Image Data CRC Checksum	*/
	unsigned char	index;		/* Operating System		*/
	unsigned char	nums;		/* CPU architecture		*/
	unsigned char   type;		/* Image Type			*/
	unsigned char 	comp;		/* Compression Type		*/
	char 	name[32];		/* Image Name			*/
}

Por supuesto, los parámetros "tamaño" y "inicio" fueron interesantes. Partiendo de ellos y también del parámetro "loadaddr", U-Boot resolvió tres nuevos parámetros para la lectura directa desde eMMC. Idealmente, por supuesto, descargó una imagen de la sección "logo" en 0x000B00C0 en la memoria a 0x1130000 ... Creo que el curso de mis pensamientos ahora está claro. Resolví los nuevos parámetros "tamaño" y "inicio" y escribí mi código, que se guardó en eMMC. Después de tales manipulaciones, U-Boot ya no estaba leyendo una imagen, sino una hazaña, que inmediatamente ganó el control. El exploit consistió en varias líneas en ensamblador.

LDR X21, printf
ADR X0, .message
BLR X21

LDR X21, run_command
ADR X0, .command
MOV X1,#0x0
BLR X21

.align 4
printf: .quad 0x37EE50A0
.align 4
run_command: .quad 0x37EE9BA0

.align 4
.message: .string "\nJailbreaking BL3-3...\n"
.align 4
.command: .string "fatload mmc 0:1 0x1000000 uboot.bin; go 0x1000000"


Leyó uboot.bin de la primera sección de la tarjeta mSD y le transfirió el control (uboot.bin era un U-Boot recién encriptado. Por supuesto, era posible usar uno modificado nativo). Resulta que el proceso de arranque regresó al lugar donde BL3-1 descifró el U-Boot original y le transfirió el control. Solo que esta vez, el código sin firmar ya se estaba ejecutando. Y ahora la descarga de eMMS se veía así (el último fragmento):

Hit Enter or space or Ctrl+C key to stop autoboot -- :  0

Jailbreaking BL3-3...
card in
[mmc_init] mmc init success
reading uboot.bin
408579 bytes read in 28 ms (13.9 MiB/s)
## Starting application at 0x01000000 ...


U-Boot 2017.11-02414-g9b5924abf2-dirty (Mar 01 2020 - 22:17:58 +0100) p212

DRAM:  1 GiB
MMC:   mmc@72000: 0, mmc@74000: 1
reading uboot.env
In:    serial@4c0
Out:   serial@4c0
Err:   serial@4c0
[BL31]: tee size: 0
[BL31]: tee size: 0
Net:   
Warning: ethernet@c9410000 (eth0) using random MAC address - 22:10:89:5b:74:85
eth0: ethernet@c9410000
Hit any key to stop autoboot:  2 0
=> version
U-Boot 2017.11-02414-g9b5924abf2-dirty (Mar 01 2020 - 22:17:58 +0100) p212

aarch64-elf-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706
=>

Conclusión


Para que el prefijo no quede inactivo en el estante, decidí poner LibreElec en él. Imagen recién ensamblada lanzada casi de inmediato sin ningún problema. El kernel se finalizó con un archivo pequeño, se instalaron controladores para WiFi y control remoto, y se rehizo la función de apagado. Y todo funcionó bien, pero luego recordé que la consola también es compatible con Bluetooth, que naturalmente no funcionaba en LibreElec. Aunque no lo necesitaba, decidí configurarlo para complementar la imagen.
A bordo estaba el chip AP6255 de Ampak, que es responsable de WiFi y Bluetooth. UART Bluetooth estaba conectado a ttyS1, pero el chip no respondió a ningún comando de HCI y fingió estar muerto. Además, en el núcleo nativo, el chip, como se esperaba, respondió al equipo.
La documentación para este chip es muy pobre y todo lo que se puede extraer de allí es un pinout. En primer lugar, verifiqué la potencia del chip y el pin BT_WAKE. Todo fue normal. Después de experimentar con el controlador y el puerto ttyS1, no obtuve ningún resultado: el chip permaneció silencioso como partisano y le conecté un osciloscopio. En él, verifiqué y comparé todas las señales electrónicas de UART (RTS, TXD, RXD, CTS). Todo fue normal. Luego, verifiqué la secuencia de reinicio, que se controla a través de rfkill (estos fueron los pines BT_WAKE y BT_REGON). Pero aquí todo estaba bien. Luego verifiqué el pin LPO, donde según la documentación debería ingresar una señal con una frecuencia de 32.768KHz, pero incluso aquí vi una señal en el osciloscopio. En general, todo estaba en orden, pero el chip no funcionaba con mi núcleo. Después de pasar un par de días desmontando el controlador UART original, volví a la señal LPO y medí su frecuencia.El resultado mostró 26KHz. Oh, cómo.
El controlador wifi_dt fue responsable de esta señal, que en mi núcleo no generó correctamente la frecuencia. Desmonté el controlador original y me hice cargo de la inicialización de la señal pwm desde allí y ... el chip cobró vida (más tarde encontré una versión de este controlador con la señal correcta). Y así, el chip estaba listo para un nuevo ajuste, pero no tenía idea de cómo ponerlo en alerta, porque No encontré ningún controlador / firmware / documentación para ello. En el Android original, no había nada en el registro del kernel excepto rfkill cuando se trabajaba con Bluetooth. Esto es comprensible, porque no había controlador de kernel, y el lanzamiento se realizó a nivel de usuario. Era necesario acceder de alguna manera al registro de Android, y para esto, se necesitaba acceso de root al dispositivo. Para hacer esto, en mi ingenuidad, agregué la configuración necesaria a la sección del sistema y activé adb.Pero con este escenario, Android notó que algo andaba mal y se negó a comenzar, refiriéndose a algunas manipulaciones allí ... Bueno, no, no. Restablecí la partición del sistema y rehice rootfs simplemente incluyendo sh allí. Después del lanzamiento posterior, tuve acceso de root en la terminal.
Así es como se inicializó el chip.

5759  5781 I bt_hci_h4: hal_open
5759  5781 I bt_userial_vendor: userial vendor open: opening /dev/ttyS1
5759  5781 E bt_userial_vendor: userial vendor open success!!
5759  5781 I bt_userial_vendor: device fd = 52 open
5759  5781 I bt_hwcfg: bt vendor lib: set UART baud 2000000
5759  5781 I bt_hwcfg: FW prepatch file: /etc/bluetooth/4335/bcm4335_prepatch.hcd
5759  5781 I bt_hwcfg: bt vendor lib: loading prepatch /etc/bluetooth/4335/bcm4335_prepatch.hcd
5759  5781 D bt_hwcfg: Chipset BCM4335A0
5759  5781 D bt_hwcfg: Target name = [BCM4335A0]
5759  5781 I bt_hwcfg: FW patchfile: /etc/bluetooth/4335/bcm4335.hcd
5759  5781 I bt_hwcfg: bt vendor lib: set UART baud 115200
5759  5781 D bt_hwcfg: Settlement delay -- 200 ms
5759  5781 I bt_hwcfg: Setting fw settlement delay to 200 
5759  5781 I bt_hwcfg: bt vendor lib: set UART baud 2000000
5759  5781 I bt_hwcfg: Setting local bd addr to 22:22:99:F7:B6:BD
5759  5781 I bt_hwcfg: vendor lib fwcfg completed


Esta información fue suficiente para escribir un programa que hizo lo mismo. El último paso fue iniciar hciattach y LibreElec reconoció Bluetooth correctamente. Ahora el dispositivo ha sido completamente configurado. Si alguien está interesado, aquí está la imagen terminada.

More articles:


All Articles