MT8135

[R0rt1z2]

• My Fire HD6 2014 (MT8135) seems to use 3000 instead of the (common) 2000 seen across other MTK devices.

[R0rt1z2]

Saving here a few notes regarding this SoC. It's the weirdest MTK SoC I've had the opportunity to mess with. Bootrom mode is disabled with fuses (not sure if this is Amazon specific) and Preloader is split in two different parts:

• PL0: Found in /dev/block/mmcblk0boot0 (BOOT0 region is permanently locked and set to RO).
• PL1: Found at the end of (both) TEE(1, 2) (in my case, located at offset 0x300000).

Looks like bootrom loads PL0, which initializes the basic hardware like DRAM and eMMC and then loads PL1 from the end of TEE, which seems to contain the USB command handler & other important stuff. This basically means that if you somehow break the GPT / erase (both) TEE1/2 you will hard brick the device.

[PL0] loading partition 'TEE1' offset=00300000 at address=12001000
[PART] Image with part header
[PART] name : PL1
[PART] addr : FFFFFFFFh
[PART] size : 112636
[PART] magic: 58881688h

[PART] load "2" from 0x0000000001800200 (dev) to 0x12001000 (mem) [SUCCESS]
[PART] load speed: 9999KB/s, 112636 bytes, 11ms
[PL0] Load PL1 from  partition 'TEE1'@ 8X: err=3145728
[PL0]RSA2048 signature for PL1[key0]: (img_size 112380)
[PL0]image verification passed for PL1[key0]
[PL0] PL1 Load OK from TEE1: err=0

[PL0] jump to 12001000
[PWRAP] pwrap_init_preloader

Preloader exposes both WRITE32 and READ32 so direct access to the eMMC (with shitty speeds) is possible (I will try to make a PR for this soon). I tried to replicate amonet in Preloader mode but I couldn't get aes_read16 / aes_write16 to work (they always return 0) and therefore, I can't load a custom payload to read arbitrary addresses (and dump bootrom, which was my main goal).

[bkerler]

Thanks !

[R0rt1z2]

@bkerler Sorry for the ping, but do you have any idea why aes_read16 always returns a block of 16 zeros for me on MT8135? I've been trying to figure out what's wrong for weeks and haven't found a solution. It's like the IV is completely empty after executing 0x7E, which is what aes_read16 seems to use. I've already checked my Preloader, and everything matches my local Python setup. I even managed to attach a serial console, but GCPU doesn't seem to print anything to UART. Could it be using a different baud rate?

[bkerler]

Depending on where you are, brom has 115200 and lk has 921600 baudrate. If you get zeros out of the aes engine, you probably either didn't set up the registers or you didn't enable the crypto clock settings.

[R0rt1z2]

Depending on where you are, brom has 115200 and lk has 921600 baudrate. If you get zeros out of the aes engine, you probably either didn't set up the registers or you didn't enable the crypto clock settings.

I can see (PL) output at 115200 baud, but nothing related to the crypto engine. I know my Preloader uses it, but I can't get it to work. I've replicated the init(), hw_acquire(), and hw_release() functions with no success. Is there another CMD I can use to arbitrarily read/write data without worrying about range checks?

[R0rt1z2]

As a side note, I managed to find a way to upload (and execute) payloads in Preloader mode. I might do a PR soon so people with MT8135 (and possibly other similar SoCs) can benefit from this. Apparently aes_read16 / aes_write16 have been working since the beginning, the only issue is they (only) let you read / write starting from 0x80000000.