Get best of the week

Présentation de la sécurité du logiciel du processeur S905X (démarrage sécurisé)

Cet article traite de la protection logicielle du processeur S905X. Le but ultime est de lancer un logiciel non autorisé.

S905X


Le processeur S905X est un ARM Cortex-A53 avec une fréquence d'horloge allant jusqu'à 1,5 GHz, bourré de toutes sortes de décodeurs pour les flux vidéo et audio, tels que H.265 4K, VP9, ​​prenant en charge 4KUHD, etc. En général, ce n'est pas un mauvais choix. Contrairement à son prédécesseur, AMLogic a intégré le soi-disant «système de sécurité Advanced TrustZone» dans ce processeur, qui contrôle toutes les opérations critiques du système, telles que l'accès aux zones protégées de la mémoire ROM, la vérification du logiciel de signature et de décryptage, etc. Une documentation détaillée sur ce sujet est disponible sur le site Web du fabricant . SecureOS agit comme ATOS-V1.5-g3e467d9 (je n'affirmerai pas, je n'ai pas vérifié).

Entraînement


Après avoir démonté le préfixe, j'ai facilement trouvé les broches RxD, TxD et GND pour UART. Au dos, il y avait un connecteur pour le bouton de réinitialisation (non vérifié) et une place pour le connecteur. À en juger par l'emplacement, le connecteur ressemblait à une carte à carte pour une autre carte eMMS (le brochage est naturellement absent).



La documentation en accès libre pour le S905, des sujets critiques tels que, par exemple, la séquence de démarrage n'a pas beaucoup touché et était pratiquement inutile du point de vue de RE. Mis à part la documentation, j'ai connecté UART et ... a été agréablement surpris par la vitesse de chargement du processeur. Mais c'est probablement tout. U-Boot n'a pas réagi du tout au clavier et, après certains paramètres matériels, a intelligemment chargé et lancé le noyau Android.

Journal de démarrage 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 ...


Il convient de noter que U-Boot (bl33) lui-même fonctionnait déjà dans l'environnement du «monde normal» (BL3-1 a changé de mode immédiatement avant de lui transférer le contrôle). Ceux. même si nous prenons en quelque sorte le contrôle de l'U-Boot, nous n'aurons qu'un accès limité au système. En principe, ce n'est pas si important. Après tout, même si vous supprimez le vidage de la ROM, retirez les clés AES et ouvrez RSA du fusible, cela n'aura aucun sens, car il n'y a toujours pas de clé privée RSA.

U-Boot lui-même n'a lu aucune clé. Il a chargé le noyau en mémoire et a appelé Security Monitor pour déchiffrer et vérifier le code. Security Monitor a fait tout ce qui était nécessaire et a dit à U-Boot de charger le noyau ou non. En général, une approche sérieuse de la protection logicielle avec son propre TrustedOS et une sorte de fonctionnalité comme le BIOS.

Mon autre plan était d'accéder à la mémoire eMMC.

eMMC


Pour se connecter à eMMC, il fallait trouver au moins les broches DAT_0, CLK, CMD et GND. Et découvrez également à quelle tension le contrôleur eMMC fonctionnait (1V8 ou 3V3). Il était impossible de le faire visuellement et pour les traces, j'ai moi-même retiré eMMC. Comme la puce était entre mes mains, après le traçage, je l'ai connectée à l'adaptateur et j'ai vidé une décharge complète. Malheureusement, je n'avais pas d'équipement professionnel et j'ai utilisé du matériel improvisé pour cela. Le résultat est un «Dead Bug».


Eh bien, en fait, le brochage du connecteur:



Une fois le brochage terminé, j'ai examiné le comportement du processeur sans eMMC. À en juger par le journal, la ROM, après une tentative infructueuse de démarrage à partir d'eMMC, a tenté de charger le code à partir de la carte mSD. C'était encourageant. J'ai rapidement téléchargé le vidage sur la carte mSD et allumé la console. Une petite surprise m'attendait ici. La ROM a téléchargé le code BL2 de la carte et lui a transféré le contrôle (cela signifie que la section «boot» sur eMMC n'était pas impliquée et qu'il n'y avait pas besoin d'accès root). Eh bien, quand le tour est arrivé à U-Boot, il s'est plaint à quelques reprises du manque d'eMMC (dev 1) et s'est arrêté pendant longtemps dans le terminal sans réfléchir.

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#

Pour commencer, ce n'était pas mal du tout. Après quelques expériences avec le terminal, j'ai ajouté le paramètre bootdelay = 5 à la section «env», calculé la nouvelle somme de contrôle et soudé l'eMMC. Avec la nouvelle option, j'espérais que le U-Boot pourrait être arrêté. Mais dans la pratique, tout était différent. Il semble que U-Boot n'était pas intéressé par ce paramètre et le processus de démarrage n'était pas différent du processus normal. C'est triste, car un terminal avec un eMMC connecté m'a été nécessaire pour de nouvelles actions. Avec un peu de réflexion, j'ai fermé DAT_0 à la masse et inséré ma carte mSD. La ROM ne pouvait plus charger le code depuis eMMC et est passée à mSD. Après avoir chargé U-Boot de cette manière, j'ai ouvert les contacts et demandé:

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 n'a pas résisté et est heureux de passer à eMMC. J'ai regardé, bien sûr, ce qui était dans le paramètre bootdelay. Et au lieu de mes cinq, j'ai encore vu 0. Il semble que U-Boot ait écrit un 0 à un moment donné, au cas où quelqu'un changerait soudainement quelque chose là-bas. Mais cela ne m'intéressait plus et le sujet avec eMMC était fermé.

Remarque: ayant un brochage du connecteur, vous pouvez vous connecter à eMMC sans souder la puce. Pour ce faire, vous avez besoin d'un adaptateur spécial avec un convertisseur de tension, car Le contrôleur eMMC fonctionne sur 1V8 et si vous connectez un adaptateur SD ordinaire à 3V3, il y a un risque de brûler des composants se trouvant sur le bus 1V8.

Il sera également nécessaire de retirer cette résistance, sinon le processeur interférera avec l'adaptateur.


Composants manquants


Ayant un accès complet au terminal U-Boot, je devais faire deux choses: accéder au décodeur DeviceTree et convaincre U-Boot d'abandonner les services Security Monitor liés aux tests du noyau. Pour le premier lancement, ce serait bien d'avoir le noyau d'origine, afin de ne pas perdre de temps à en déboguer un nouveau.

Il était extrêmement facile d'obtenir DeviceTree. J'ai demandé:

gxl_sx6b6x_768_v2#emmc dtb_read 0x1000000 0x40000

read emmc dtb
gxl_sx6b6x_768_v2#

et il était dans ma poche.

U-Boot a nécessité une analyse détaillée. Du journal, il s'ensuit que U-Boot lui-même a été chargé et déchiffré initialement à 0x1000000, puis s'est transféré à 0x36ES8000 (offset). J'ai vidé U-Boot et l'ai analysé dans IDA.

Bien sûr, je m'intéressais à l'endroit où le moniteur de sécurité était accessible à partir de la commande bootm. Ici , il est


où
X0 - AML_D_P_IMG_DECRYPT
X1 - nLoadAddr
X2 - GXB_IMG_SIZE
X3 - GXB_IMG_DEC_ALL

Pour supprimer le vidage du noyau d'origine, vous avez dû le charger en mémoire via la fonction imgread et modifier bootm afin qu'immédiatement après l'appel de aml_sec_boot_check, la mémoire soit émise à partir de l'adresse 0x1080000 vers le terminal (ce n'est certainement pas le seul moyen). Pour ce faire, j'ai écrit un morceau de code et l'ai téléchargé au bon endroit. Voici ce qui s'est passé (bien sûr, je ne peux pas donner un journal complet):

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!

En plus du noyau, j'ai également obtenu un disque virtuel (il peut être utile en cas de pilotes ou de micrologiciels importants, par exemple pour le WiFi).

Je ne suis plus Android


Pour le premier lancement de mon logiciel, j'ai créé uImage à partir du noyau d'origine, construit mes rootfs sur la base de Busybox et utilisé ma propre dtb. J'ai chargé les trois parties directement à partir du lecteur USB et j'ai exécuté la commande «bootm», désactivant le décryptage et la vérification d'image auparavant.

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
#

Jailbreak


En raison du fait que U-Boot était immunisé contre les changements de paramètres env (cela ne concernait pas seulement le «bootdelay»), il était impossible d'influencer le processus de démarrage via env, et pour charger son logiciel, le préfixe devait être connecté à l'ordinateur. Cette option ne me convenait pas du tout. Après avoir analysé toute la chaîne de chargement, cette commande a retenu mon attention:

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

en particulier:

imgread pic logo bootup $loadaddr

où U-Boot chargeait une certaine ressource de «démarrage» à l'adresse loadaddr = 0x1080000. La ressource elle-même a été décrite par une telle structure:

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			*/
}

Bien sûr, les paramètres «taille» et «début» étaient intéressants. En partant d'eux et également du paramètre «loadaddr», U-Boot a résolu trois nouveaux paramètres pour une lecture directe depuis eMMC. Idéalement, bien sûr, il a téléchargé une image de la section «logo» à 0x000B00C0 en mémoire à 0x1130000 ... Je pense que le cours de mes pensées est maintenant clair. J'ai résolu de nouveaux paramètres «taille» et «démarrer» et écrit mon code, qui a été enregistré sur eMMC. Après de telles manipulations, U-Boot ne lisait plus une image, mais un exploit, qui a immédiatement pris le contrôle. L'exploit consistait en plusieurs lignes en assembleur.

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"


Il a lu uboot.bin à partir de la première section de la carte mSD et y a transféré le contrôle (uboot.bin était un U-Boot non crypté fraîchement collecté. Bien sûr, il était possible d'utiliser un natif modifié). Il s'avère que le processus de démarrage est revenu à l'endroit où BL3-1 a déchiffré le U-Boot d'origine et lui a transféré le contrôle. Seulement cette fois, le code non signé était déjà en cours d'exécution. Et maintenant, le téléchargement depuis eMMS ressemblait à ceci (le dernier fragment):

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
=>

Conclusion


Pour que le préfixe ne reste pas inactif sur l'étagère, j'ai décidé d'y mettre LibreElec. Image fraîchement assemblée lancée presque immédiatement sans aucun problème. Le noyau a été finalisé avec un petit fichier, des pilotes pour le WiFi et la télécommande ont été installés et la fonction de mise hors tension a été refaite. Et tout a bien fonctionné, mais je me suis souvenu que la console prend également en charge Bluetooth, ce qui naturellement ne fonctionnait pas dans LibreElec. Même si je n'en avais pas besoin, j'ai tout de même décidé de l'installer pour compléter l'image.
À bord se trouvait la puce AP6255 d'Ampak, qui est responsable à la fois du WiFi et du Bluetooth. UART Bluetooth était connecté à ttyS1, mais la puce n'a répondu à aucune commande HCI et a fait semblant d'être morte. De plus, sur le noyau natif, la puce, comme prévu, a répondu à l'équipe.
La documentation de cette puce est très pauvre et tout ce qui pourrait en être extrait est un brochage. Tout d'abord, j'ai vérifié la puissance de la puce et la broche BT_WAKE. Tout était normal. Après avoir expérimenté avec le pilote lui-même et le port ttyS1, je n'ai obtenu aucun résultat - la puce était silencieuse en tant que partisan et je lui ai connecté un oscilloscope. J'ai vérifié et comparé tous les signaux électroniques UART (RTS, TXD, RXD, CTS). Tout était normal. Ensuite, j'ai vérifié la séquence de réinitialisation, qui est contrôlée via rfkill (il s'agissait des broches BT_WAKE et BT_REGON). Mais ici, tout allait bien. Ensuite, j'ai vérifié la broche LPO, où, selon la documentation, un signal avec une fréquence de 32,768 KHz devrait entrer, mais même ici, j'ai vu un signal sur l'oscilloscope. En général, tout était en ordre, mais la puce ne fonctionnait pas avec mon cœur. Après avoir passé quelques jours à démonter le pilote UART d'origine, je suis retourné au signal LPO et j'ai mesuré sa fréquence.Le résultat a montré 26KHz. Oh comment.
Le pilote wifi_dt était responsable de ce signal, qui dans mon cœur n'a pas correctement généré la fréquence. J'ai démonté le pilote d'origine et repris l'initialisation du signal pwm à partir de là et ... la puce a pris vie (plus tard, j'ai trouvé une version de ce pilote avec le bon signal). Et donc, la puce était prête pour un réglage ultérieur, mais je ne savais pas comment la mettre en alerte, car Je n'ai trouvé aucun pilote / firmware / documentation pour cela. Dans Android d'origine, il n'y avait rien dans le journal du noyau, sauf rfkill lorsque vous travaillez avec Bluetooth. C'est compréhensible, car il n'y avait pas de pilote de noyau et le lancement a eu lieu au niveau utilisateur. Il fallait en quelque sorte accéder au journal d'Android lui-même, et pour cela, un accès root à l'appareil était nécessaire. Pour ce faire, dans ma naïveté, j'ai ajouté les paramètres nécessaires à la section système et activé adb.Mais avec ce scénario, Android a remarqué que quelque chose n'allait pas et a refusé de commencer, faisant référence à certaines manipulations là-bas ... Eh bien, non, non. J'ai restauré la partition système et refait rootfs en y incluant simplement sh. Après le lancement suivant, j'avais un accès root dans le terminal.
C'est ainsi que la puce a été initialisée.

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


Cette information était suffisante pour écrire un programme qui faisait de même. La dernière étape a été de lancer correctement hciattach et LibreElec reconnu Bluetooth. Maintenant, l'appareil est entièrement configuré. Si quelqu'un est intéressé, voici l' image finie.

More articles:


All Articles