[G4 Q&A, Help & Troubleshooting] bigalex:
I've bought an Italian TIM branded H815, got root access through send_command.exe exploit, and within the root shell I got, I've made a backup of the system and "cust" (the branding) partitions; then downloaded the image, injected root and used dd to overwrite the sytem partition with the rooted one.

After that, I've disabled OTAs, installed ssh server (dropbear), removed TIM branding and put back the stock unbranded stuff, removed all the bloatware, changed the dialer with the one shipped with the lollipop nexus 5 and everything works very nicely.

That's when, while exploring the partitions, I've found that the recovery seems to be in /dev/block/mmcblk0p39.

Being the bootloader still locked (and I'd like to keep it that way), I was pretty sure I couldn't write to the partition, BUT I've run dd to fetch the first bytes of the partition, wrote that to a file, and flashed the file back, overwriting what was there. *So, it was possible*.

Here's what I've done:

dd if=/dev/block/platform/f9824900.sdhci/by-name/recovery bs=1 count=70 of=/sdcard/recovery.partial.img

dd of=/dev/block/platform/f9824900.sdhci/by-name/recovery if=/sdcard/recovery.partial.img

Now here're the questions:

- What would happen if I would just write TWRP through dd over the partition from the running system? (ex.: dd if=/sdcard/twrp.img bs=8192 of=/dev/block/mmcblk0p39)... it seems I wouldn't be blocked by anything in doing so!

- Can you see my very same partitions inside the directory /dev/block/platform/f9824900.sdhci/by-name/ ? (at the end of the post the node listing) -- in case you can't, I've tought they could be useful to you to determine where they are in first place: I've read of people that couldn't find the node "recovery", thus couldn't write to it. Anyway, in that case, there are some tools to explore drive images in GPT form like testdisk and they could be used to find the location of that partition and write over it through dd using the "seek=" parameter.

- In case you already know all that, I presume there is a protection system that runs a checksum of the recovery partition on boot and would argue "hey, what's that? here, eat this bootloop!", otherwise I really can't imagine why I can't change the bootloader.

Thanks in advance! :)

Alessio

PS, here are the GPT partitions:

lrwxrwxrwx 1 root root 21 Jan 4 2015 DDR -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 20 Jan 4 2015 aboot -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 21 Jan 4 2015 abootbak -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 Jan 4 2015 apdp -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 Jan 4 2015 boot -> /dev/block/mmcblk0p38
lrwxrwxrwx 1 root root 21 Jan 4 2015 cache -> /dev/block/mmcblk0p49
lrwxrwxrwx 1 root root 21 Jan 4 2015 cust -> /dev/block/mmcblk0p48
lrwxrwxrwx 1 root root 21 Jan 4 2015 devinfo -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 Jan 4 2015 dpo -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 21 Jan 4 2015 drm -> /dev/block/mmcblk0p40
lrwxrwxrwx 1 root root 21 Jan 4 2015 eksst -> /dev/block/mmcblk0p33
lrwxrwxrwx 1 root root 21 Jan 4 2015 encrypt -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 21 Jan 4 2015 factory -> /dev/block/mmcblk0p43
lrwxrwxrwx 1 root root 21 Jan 4 2015 fota -> /dev/block/mmcblk0p44
lrwxrwxrwx 1 root root 21 Jan 4 2015 fsc -> /dev/block/mmcblk0p27
lrwxrwxrwx 1 root root 21 Jan 4 2015 fsg -> /dev/block/mmcblk0p26
lrwxrwxrwx 1 root root 21 Jan 4 2015 grow -> /dev/block/mmcblk0p51
lrwxrwxrwx 1 root root 20 Jan 4 2015 hyp -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 21 Jan 4 2015 hypbak -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 Jan 4 2015 keystore -> /dev/block/mmcblk0p29
lrwxrwxrwx 1 root root 21 Jan 4 2015 laf -> /dev/block/mmcblk0p37
lrwxrwxrwx 1 root root 21 Jan 4 2015 limits -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 21 Jan 4 2015 misc -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 20 Jan 4 2015 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 21 Jan 4 2015 modemst1 -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 Jan 4 2015 modemst2 -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 Jan 4 2015 mpt -> /dev/block/mmcblk0p42
lrwxrwxrwx 1 root root 21 Jan 4 2015 msadp -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 Jan 4 2015 persist -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 Jan 4 2015 persistent -> /dev/block/mmcblk0p35
lrwxrwxrwx 1 root root 20 Jan 4 2015 pmic -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 21 Jan 4 2015 pmicbak -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 21 Jan 4 2015 raw_resources -> /dev/block/mmcblk0p45
lrwxrwxrwx 1 root root 21 Jan 4 2015 raw_resourcesbak -> /dev/block/mmcblk0p46
lrwxrwxrwx 1 root root 21 Jan 4 2015 rct -> /dev/block/mmcblk0p34
lrwxrwxrwx 1 root root 21 Jan 4 2015 recovery -> /dev/block/mmcblk0p39
lrwxrwxrwx 1 root root 20 Jan 4 2015 rpm -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 Jan 4 2015 rpmbak -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 20 Jan 4 2015 sbl1 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 Jan 4 2015 sbl1bak -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 20 Jan 4 2015 sdi -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 Jan 4 2015 sdibak -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 21 Jan 4 2015 sec -> /dev/block/mmcblk0p31
lrwxrwxrwx 1 root root 21 Jan 4 2015 sns -> /dev/block/mmcblk0p41
lrwxrwxrwx 1 root root 21 Jan 4 2015 spare1 -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 Jan 4 2015 spare2 -> /dev/block/mmcblk0p36
lrwxrwxrwx 1 root root 21 Jan 4 2015 ssd -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 21 Jan 4 2015 system -> /dev/block/mmcblk0p47
lrwxrwxrwx 1 root root 20 Jan 4 2015 tz -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 21 Jan 4 2015 tzbak -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 21 Jan 4 2015 userdata -> /dev/block/mmcblk0p50