[Fire Android Development] hwmod:
Updates on the Test Points and other sotware info

Unfortunately, due to heat and retries, I ripped off some of the pads, precisely the VccQ 1.8V TP pad and (worst) the DATA0 TP pad which seems to be available in only one place on the PCB.

However that has given me the opportunity to take off (desolder) both the Samsung EMMC chip and the Mediatek MT8127A from the PC and confirm the recently found Test Points positions.

Just before ripping the two small pads I briefly had the opportunity to see the 13 partitions of the EMMC chip mounted on my Linux machine. Here is an excerpt of the relevant log lines:

Oct 3 19:28:45 ns kernel: usb 1-10.2: new high-speed USB device number 8 using xhci_hcd
Oct 13 19:28:45 ns kernel: usb 1-10.2: New USB device found, idVendor=8564, idProduct=4000, bcdDevice= 0.38
Oct 13 19:28:45 ns kernel: usb 1-10.2: New USB device strings: Mfr=3, Product=4, SerialNumber=5
Oct 13 19:28:45 ns kernel: usb 1-10.2: Product: Transcend
Oct 13 19:28:45 ns kernel: usb 1-10.2: Manufacturer: TS-RDF5
Oct 13 19:28:45 ns kernel: usb 1-10.2: SerialNumber: 000000000037
Oct 13 19:28:45 ns kernel: usb-storage 1-10.2:1.0: USB Mass Storage device detected
Oct 13 19:28:45 ns kernel: scsi host5: usb-storage 1-10.2:1.0
Oct 13 19:28:46 ns kernel: scsi 5:0:0:0: Direct-Access TS-RDF5 SD Transcend TS38 PQ: 0 ANSI: 6
Oct 13 19:28:46 ns kernel: sd 5:0:0:0: Attached scsi generic sg3 type 0
Oct 13 19:28:47 ns kernel: sd 5:0:0:0: [sdd] 15269888 512-byte logical blocks: (7.82 GB/7.28 GiB)
Oct 13 19:28:47 ns kernel: sd 5:0:0:0: [sdd] Write Protect is off
Oct 13 19:28:47 ns kernel: sd 5:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Oct 13 19:28:47 ns kernel: sdd: sdd1 sdd2 sdd3 sdd4 sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12 sdd13
Oct 13 19:28:47 ns kernel: sd 5:0:0:0: [sdd] Attached SCSI removable disk

Immediately after I started getting errors probably due to excessive length of cables and/or the fact I didn't disable the CPU clock as for instructions from the Exploitee.rs docs.

From this test session I realized that the two more important partitions where not accessible and after reading a bit I learned that an SDIO interface is needed to achieve that.

Without access to "mmcblk0boot0" and "mmcblk0boot1" there isn't much gain over current status, so I believe a software root/unlock would still be a much better solution.

On a completely different set of software tests I have come to know that (at least on version 5.0.1 and 5.1.1 of the firmware) the "kernel cmdline" can be passed "cumulatively".

This means that also if Amazon did limit to 64 the max number of characters given to overwrite the kernel "cmdline", we can bypass that limitation using multiple commands:

fastboot oem append-cmdline "androidboot.unlocked_kernel=true"
fastboot oem append-cmdline "androidboot.secure_cpu=0"
fastboot oem append-cmdline "androidboot.prod=0"
fastboot continue

This will provide a temporary "root" (already known) on a "non production", "non secure" and "unlocked kernel" for firmware versions 5.0.1 and 5.1.1

I hoped this would work on later firmware versions (5.4.0), but was just another dream, it doesn't work, also it opens up to other testing areas.

Have fun !

.:HWMOD:.