Skip to content

LG V10

Jump to bottom Edit New page
Elliott Mitchell edited this page Dec 3, 2016 · 7 revisions

#LG V10

There are several variants of the LG V10. This is a pretty good device, but so far LGE has only unlocked the bootloader for the H901 (T-Mobile version) and H960A (European, requires generation of an unlock key).

##Notes

Potentially unlocking the bootloader: http://forum.xda-developers.com/lg-v10/help/flash-h901-kdz-to-bootloader-unlocked-t3401036 This seems plausible for the H962 since the GPT is nearly identical. The partition Ids differ and the H962 includes /cust, which may be needed for the dual-SIM functionality. The layout of the bootloader slices is identical though.

A key question is how do the bootloader stages find each other? On all devices "sbl1", the first on-flash stage is at the same location on the flash, this is almost certainly dictated by the Qualcomm 808 chip. If the stages after locate each other by having their block numbers hard-coded then moving the bootloader is impossible, though devices with the bootloader located in the same areas have no problem. If the stages after locate each other by looking themselves up in the GPT, what are they looking for? Do they have indices into the table hard-coded? Do they look for the type UUID? The identifier UUID? The label? Do any of these do a checksum of the table to check for modification?

One method of rescuing from Qualcomm 9008 mode: http://forum.xda-developers.com/tmobile-lg-v10/development/debrick-phone-h901-qualcomm-9008-t3440359 Apparently this needs a full phone image and merely generating an image from a KDZ file is insufficient. Based on some of the reports I'm also suspecting engineers at LGE made their bootloader insist upon loading some portions being read strictly off the internal flash, thus damaging a valuable feature from Qualcomm.

##Proposed Procedure

###Basic Method 0. Turn off cellphone portion of device ("airplane mode"), I advise against turning on the cellphone portion on until this process is completed.

  1. Overwrite with H901 KDZ (modify slightly to mark as for target device) The chkdzdev script is targeted at remarking a KDZ so LG's tools will write it to the "wrong" device.

  2. fastboot oem unlock This is required to be done before the next step! Following steps involve installing software from the original device, and these will not match the H901's signatures.

  3. Merge original GPT (notably /cust)
    Issue here is, how sensitive are LGE's bootloader and Android boot process to the particulars of the GPT? They shouldn't do something like this, but it would be a functional way of discouraging modifications to devices they design. mergegpt has been written for this purpose and it is able to preserve the CRC32s, so merely checking a CRC32 will miss the modification. As of now a bit more testing is still needed.

  4. Rewrite original image (until someone develops a new one)
    This could either be done by saving images of /dev/block/mmcblk0p* before step 1, or else using KDZTools to extract images of the flash slices and simply overwriting the appropriate portion of /dev/mmcblk0p*. I'm pretty sure there is a "proper" way to do this so the risk of power loss during flashing is reduced (Cyanogenmod should know).

I believe only /dev/mmcblk0p1 "modem", /dev/mmcblk0p26 "persist", /dev/mmcblk0p34 "sec", /dev/mmcblk0p39 "laf", /dev/mmcblk0p40 "boot", /dev/mmcblk0p41 "recovery" /dev/mmcblk0p51 "system", and optionally /dev/mmcblk0p52 "cust" will need to be restored from original device. I suspect it is unnecessary to preserve persist as the content is ultimately identical (it is a filesystem with the same content, but differing times so the raw data differs), but in the interest of not antagonizing anything that is hashed, I tend to restore it.

###KDZ Modification Method

This is an alternative method which takes advantage of the KDZ Tools. Problem is there appears to be some extra verification of KDZ files and so the KDZ Tools are rather unreliable, though there is a good chance the modifications being done here won't effect the verification. The advantage of this method is we merge steps 1 and 3, making the process simpler. This also has the advantage of using existing tools, rather than needing to wait for the LGE Tools to be functional. So, checkout the KDZ Tools and then the commands should create an adjusted KDZ file:

$ unkdz -f H96210b_00.kdz -s 0
$ unkdz -f H90120e_00_0316.kdz -x
$ sed -i -es/H901/H962/ kdzextracted/.kdz.params
$ undz -f kdzextracted/H90120e_00.dz -x
$ mv dzextracted/.dz.params dzextracted/.dz.params.save
$ rm dzextracted/PrimaryGPT_0.bin.chunk dzextracted/BackupGPT_122141696.bin.chunk
$ undz -f kdzextracted/H962210b_00.dz -x 0 68
$ rm dzextracted/.dz.params
$ mv dzextracted/.dz.params.save dzextracted/.dz.params
$ sed -i -es/H901/H962/ dzextracted/.dz.params
$ mkdz -f kdzextracted/H96220e_00.dz -m
$ mkkdz -f H96220e_00_0316.kdz -m

I'm using a system with a Unix-flavor so folks on other OS will need minor modifications to the commands. The two "sed" commands are doing simple text replacement on the specified files, you can readily do this with a text editor (the .params files are text files containing instructions for mkdz/mkkdz). At this point in theory "H96220e_00_0316.kdz" should contain a KDZ which features GPTs appropriate for a H962 and marked for a H962, but the image is from a H901.

##LGE Disk slices^W^WPartitions

Issue is which to use from original device, which to use from H901:

  1. /dev/mmcblk0p1 modem [from original device]
  2. /dev/mmcblk0p2 spare1 [untouched by KDZ, leave untouched]
  3. /dev/mmcblk0p3 pmic [from H901]
  4. /dev/mmcblk0p4 sbl1 [from H901] ("Second Boot Loader 1"?; first on-flash bootloader stage)
  5. /dev/mmcblk0p5 tz [from H901]
  6. /dev/mmcblk0p6 sdi [from H901]
  7. /dev/mmcblk0p7 hyp [from H901] (hypervisor; isolates core(s) used by modem from cores used by Android)
  8. /dev/mmcblk0p8 rpm [from H901]
  9. /dev/mmcblk0p9 aboot [from H901] (Android bootloader)
  10. /dev/mmcblk0p10 sbl1bak [from H901] ("sbl1", backup)
  11. /dev/mmcblk0p11 pmicbak [from H901] (pmic, backup)
  12. /dev/mmcblk0p12 hypbak [from H901] (hypervisor, backup)
  13. /dev/mmcblk0p13 tzbak [from H901] (tz, backup)
  14. /dev/mmcblk0p14 rpmbak [from H901] (rpm, backup)
  15. /dev/mmcblk0p15 abootbak [from H901] (Android bootloader, backup)
  16. /dev/mmcblk0p16 sdibak [from H901] (sdi, backup)
  17. /dev/mmcblk0p17 limits [untouched by KDZ, leave untouched]
  18. /dev/mmcblk0p18 apdp [untouched by KDZ, leave untouched]
  19. /dev/mmcblk0p19 msadp [untouched by KDZ, leave untouched]
  20. /dev/mmcblk0p20 dpo [untouched by KDZ, leave untouched]
  21. /dev/mmcblk0p21 spare2 [untouched by KDZ, leave untouched]
  22. /dev/mmcblk0p22 persistent [untouched by KDZ, leave untouched]
  23. /dev/mmcblk0p23 devinfo [untouched by KDZ, leave untouched]
  24. /dev/mmcblk0p24 spare3 [untouched by KDZ, leave untouched]
  25. /dev/mmcblk0p25 misc [untouched by KDZ, leave untouched]
  26. /dev/mmcblk0p26 persist [from original device or leave untouched] (EXT4 filesystem, file sensors/sensors_settings)
  27. /dev/mmcblk0p27 modemst1 [untouched by KDZ, leave untouched] (modem state 1?)
  28. /dev/mmcblk0p28 modemst2 [untouched by KDZ, leave untouched] (modem state 2?)
  29. /dev/mmcblk0p29 fsg [untouched by KDZ, leave untouched]
  30. /dev/mmcblk0p30 fsc [untouched by KDZ, leave untouched]
  31. /dev/mmcblk0p31 ssd [untouched by KDZ, leave untouched]
  32. /dev/mmcblk0p32 keystore [untouched by KDZ, leave untouched]
  33. /dev/mmcblk0p33 DDR [untouched by KDZ, leave untouched]
  34. /dev/mmcblk0p34 sec [??? unsure, likely original??]
  35. /dev/mmcblk0p35 encrypt [untouched by KDZ, leave untouched]
  36. /dev/mmcblk0p36 eksst [untouched by KDZ, leave untouched]
  37. /dev/mmcblk0p37 rct [identical, leave untouched] (similar to factory except smaller)
  38. /dev/mmcblk0p38 spare4 [untouched by KDZ, leave untouched]
  39. /dev/mmcblk0p39 laf [from original device] (Android bootimg)
  40. /dev/mmcblk0p40 boot [from original device] (Android bootimg)
  41. /dev/mmcblk0p41 recovery [from original device] (Android bootimg)
  42. /dev/mmcblk0p42 drm [untouched by KDZ, leave untouched]
  43. /dev/mmcblk0p43 sns [untouched by KDZ, leave untouched]
  44. /dev/mmcblk0p44 mpt [untouched by KDZ, leave untouched]
  45. /dev/mmcblk0p45 raw_resources [from H901] (late bootloader stage/images)
  46. /dev/mmcblk0p46 raw_resourcesbak [from H901] (late bootloader stage/image, backup)
  47. /dev/mmcblk0p47 factory [identical, leave untouched]
  48. /dev/mmcblk0p48 spare5 [untouched by KDZ, leave untouched]
  49. /dev/mmcblk0p49 fota [untouched by KDZ, leave untouched]
  50. /dev/mmcblk0p50 fau [untouched by KDZ, leave untouched]
  51. /dev/mmcblk0p51 system [from original device] (EXT4 filesystem, /system)
  52. /dev/mmcblk0p52 cache [wiped during process]
  53. /dev/mmcblk0p53 userdata [wiped during process]
  54. /dev/mmcblk0p54 grow [untouched by KDZ, leave untouched]

On devices with /cust, that is /dev/mmcblk0p52. userdata is shrunk by the size of cust. What is in brackets is where I would get everything. Notably I'd leave everything bootloader related from the H901, much of the rest I'd copy from the original device.

I'm less sure of "sec", "raw_resources", and "laf". "laf" appears to be an Android boot image, so I'm pretty sure it should be taken from the original device. "raw_resources" appears to be images to used by bootloader stages, notably images indicating battery status or various warnings before the Android kernel is loaded. Given how similar this area is between devices, I suspect either image could be used, but I'm pretty sure using the image from the H901 is the safer choice. Someone could have some real fun figuring out the format and modifying the images displayed during startup.

I'm very unsure of "sec". "sec" has the text "default dat file" near its top, but this tells us almost nothing about what role it plays. On the principle of it having no backup, I'm left suspecting this is used after Android is loaded and thus using the original device's version is the safer choice. I'm very unsure of this and this seems the most worrisome part of the process.

Looking at the list, it seems only /dev/mmcblk0p1 "modem", /dev/mmcblk0p26 "persist", /dev/mmcblk0p34 "sec", /dev/mmcblk0p39 "laf", /dev/mmcblk0p40 "boot", /dev/mmcblk0p41 "recovery" /dev/mmcblk0p51 "system", and optionally /dev/mmcblk0p52 "cust" will need to be restored from original device, a fairly short list. I suspect it is unnecessary to preserve persist as the content is ultimately identical (it is a filesystem with the same content, but differing times so the image on the phone differs), but in the interest of not antagonizing anything that could be verified by hash, I tend to restore it.

##Device-specific Issues

###H960 (Europe)

###H960A (Europe)

###H961N/H962 (Hong Kong, Taiwan and Sovereign States, dual-SIM)

These were the original target for this project. The only difference between these and the H901 is these have an extra "cust" slice. From what is present there I'm guessing this is extra software used in conjunction with dual-SIM functionality. As such this needs to be recreated, which was what mergegpt was developed for.

###RS987 (Sprint) and VS990 (Verizon)

RS987 and VS990 devices have a flash-memory layout rather distinct from other LG V10s and for our purposes that is a rather Bad Thing(tm). Of crucial note there are extra slices "eri" and "operatorlogging", and raw_resources is in a different location from other devices.

This results in several crucial problems. Are "eri" and "operatorlogging" required for proper operation of the CDMA modem? (I fear the answer is likely to be "yes" at which point this approach may be impossible) How do the various pieces find each other? Via the GPT? (no problem, we win!) Via hard-coded block number? (problem!) In the latter case the RS990 may well end up having to slowly corrupt the "factory" slice.

##Alternative Procedure

I've proposed an alternative procedure. This is pretty similar to the above, but instead of dumping a full KDZ onto the target, it might be possible to merely overwrite the backup copy of the bootloader. Given the Qualcomm chips will boot via the external micro-SD card as a backup, generating two images, one which boots the device's main bootloader on the primary areas, and one of which boots the H901 bootloader on the backup areas; should allow for a better fallback. Given the size of the bootloader areas, it is quite likely they find each other via the GPT, tricks include: Do they check the CRC of the GPT? Do they check the slice identifier for consistency? The former is easily bypassed, the latter needs more work to bypass. They might also check the slice identifier of the Linux target to load. Right now the -U strategy can be used to copy these identifiers even though this wasn't what mergegpt was originally designed for.

Add a custom footer
Add a custom sidebar
Clone this wiki locally