yashsingh1/xdaforums huggingface dataset:
[G4 General] Zenns:
Yeah we know you are LG users but since the method can work on LG G5 Or G6 why not share it :) Im sure most of people will be happy and who knows all if us might come together
[G4 General] steadfasterX:
Do you know if the g5 and g6 can be forced into QDL/EDL/9008 mode? On the g4 you can do so by bridging 2 pins on the mainboard..

And yes ARB is something important when your device has this implemented.
[G4 General] GabrielJr:
Hello, I own a LG G6 and I was interested in this topic. Is EDL(Emergency Download Mode) the same as Download Mode?
[G4 General] steadfasterX:
no.

what i was refering to is the

QDL (Qualcomm Download Mode)

which is also named:

EDL (Emergency Download Mode)

which is also named:

9008

QDL, EDL and 9008 are all the same and a special low level way for device communication.

Download mode is the mode where u see the Firmware Update screen and where u can use LGUp and such.
[G4 General] Tinyshy:
If it requires bridging pins inside the phone... We likely can but we'd have to break our waterproof seals.. it seems a desperate procedure
[G4 General] GabrielJr:
I see... At home, I'll try this.... Thanks for the reply.
[G4 General] chucky43:
Şu işlemi yapabilen türk vatandaşı var mı bi yardım etsin hayrına
[G4 General] rizkhan999:
I want to convert an H815T (HongKong) to H811 in order to unlock H815T. But the problem is that all H815T KDZ's seem to be on ARBv0 while the oldest H811 KDZ that I can find online is 10H here which is on ARBv1.

I wanted to ask you that when you bricked flashing H811 ARBv1 over H815 ARBv0, how did you recover your H815 back to its state i.e. H815 later on, if you even did so? And if you got it repaired from LG, did they change its board or what?
[G4 General] steadfasterX:
Once you have triggered the a r b there is no way back so you will never ever can go back to 815 anymore after doing this. Well you can with physical replacements.

What they have done to recover my device? I guess that they have just replaced the chip or whatever where the fuses are in and reflashed and that's all. What I can say for sure is that they did not replace the main board at least this last time they didn't

EDIT

And yes it is true that there is no arb with 0 available for the 811 the initial version of the 811 was 0 but T-Mobile Force updated every device to at least 1 so if you find a device which was never connected to the Internet and never updated you will be my hero
[G4 General] rizkhan999:
I was wondering how to identify the device model e.g. h815 as well as the firmware version e.g. 20g from KDZ or from the phone's partitions in download mode. Any clue about that?
[G4 General] onotor:
İşlem hem zahmetli hem de riskli, ayrıca dezavantajları var (şebeke çekmemesi vs). Bence boş ver gitsin
[G4 General] steadfasterX:
lol u stil even not started SALT yet right?

.
[G4 General] steadfasterX:
https://xdaforums.com/announcement.php?a=81

-> Point 4.
[G4 General] rizkhan999:
I have opened it. Here is my screenshot. And have already started loving it. It read the phone model and firmware correctly. So i was wondering in which partition this information is stored.

Just for info, it didnt read my unlock status correctly and couldnt read my arb version at all.

EDIT: I guess this information is taken from the system partition because i got the following upon executing cat /system/build.prop | grep 815:

ro.product.model=LG-H815

ro.lge.swversion=H81520g

ro.lge.factoryversion=LGH815AT-00-V20g-GLOBAL-COM-JUL-20-2016+0
[G4 General] steadfasterX:
Can not see the linked screenshot..

the unlock state was just a guess i will rename it as my first thought about that parsed value seems to be wrong.

Just open the Update Manager in SALT and click the update button.

Close SALT afterwards and then start it again. open the debug log (button in SALT) and copy & paste that to me in a PM.

It will give me some more insights about why the ARB does not get detected.

Those informations are coming from the LAF partition plus MISC. If you want to trick LGUp it is enough to modify the misc partition with another model ;)

nope.

.
[G4 General] rizkhan999:
Here is where i attached it.

EDIT 1: This post was pertaining to force flash using SALT in cases where LGUP gives some error and refuses to flash. Btw i have come to know here about patching LGUP to unlock its developer mode which also allows dumping and flashing selected partitions. Much useful in Nougat roms in which LGLAF (and thus SALT & KDZ MANAGER) is not supported.

EDIT 2: Attaching screenshots of dumping a selected partition of H815 using unlocked LGUP..... ;)

Ok will do it in sha Allah.

Okay. Thanx.
[G4 General] onotor:
I quoted exactly "him" since he could be not able to talk english. Otherwise, it's none of their business who are insisting on talking "English"...

Regards
[G4 General] rizkhan999:
My question is that do TWRP flashable ZIPs also blow fuses? For example if I flash 20o v3 zip through TWRP in H811, then if I wipe it in TWRP and then flash 20i v2 zip through TWRP, would the phone brick?
[G4 General] scholbert:
What is pkcs8_private_key_boot_2048 ?

Hi steadfasterX,

thanks a lot for all this interesting stuff!

I followed this thread for while now and i'd like to figure out something.

In all aboot images of H815 up to version 20D i found a small set of keys or certificates,

e.g. in aboot version 20D starting at offset 0x6c4d4.

You may search for the following strings in the aboot binary:

pkcs8_private_key_boot_2048

UNLOCK_RSA_02

ksut_global_msm8992

I tried to extract these and fired some openssl commands from the linux console, but as i'm no security expert i got nothing useful out of it :angel: .

While searching the web... i found this as well:

https://gist.github.com/genesixx/c0cd5e1814d2586f89f2b727d2cd8e6d

... which seems the boot message of an unlocked H815, so i may refer to this:

In line 858:

UNLOCK_RSA_02 is loaded

unlock verified

Further on in line 999:

ksut_global_msm8992 is loaded

No unlock key!

Nothing about pkcs8_private_key_boot_2048 here...

Anyway, would be nice if someone may shed some light on these parts of aboot :o.

Cheers,

scholbert
[G4 General] steadfasterX:
if you flash the bootloader yes.

pls share that unlocked lgup ;)

btw any idea about "chipErase" ???
[G4 General] steadfasterX:
yes I was aware of these but I cant make any use out of it.

My first thoughts have been that this may even be the private key but I'm not a crypto expert and I can disassemble the code but I'm not an assembly guru to read assembly code enough to make use of it.

so at the end that is useless for me.

btw you can even parse that strings like this:

binwalk -e aboot.image --dd=".*"

openssl asn1parse -inform DER -in _aboot.image.extracted/6BA4C

.
[G4 General] scholbert:
Prevent fuse programming by hardware hack?

Hi steadfasterX,

thanks for your immediate reply!

Could be some private key or maybe a hash???

Maybe i am able to make some use of it. Thanks for the hints.

I got another wicked idea, which may prevent unwanted write access to the fuse bank.

While looking in the schematics i found an interesting pin which is part of the MSM8992 power domain.

It is pin H1 of MSM8992 which is named VDD_QFPROM_PRG.

This pin is connected to the +1V8_VREG_L15A domain of the PM8994 with a zero ohm resistor (R2308).

EDIT:

In fact this is a simple solder bridge nearby the CPU, not a resistor. So opening up this connection should leave the QFPROM PRG domain unpowered (if there's interest i may post the position on the mainboard).

Could be, that this technique was also used during software engineering, because as steadfasterX already stated,

if you make a mistake while fiddling around with low level code, some fuse bits might get blown and leave the hardware unresponsive.

I found a reference for VDD_QFPROM_PRG in another snapdragon datasheet:

Power for programming the QFPROM; otherwise ground

EDIT:

Found another hint in reference board schematic for MSM8974 (not MSM8992, i know, but the QFPROM domain works quite similar in thoose).

What if we unsolder resistor R2308 and leave the QFPROM PRG domain unpowered?

AFAIK the fuse bank is part of this section...

EDIT:

Yes it is :D

I never tried this and i don't know if the phone will even boot with this pin unpowered :confused:

Just an idea.

Best regards,

scholbert
[G4 General] rizkhan999:
You just have to run the patch provided in this post and your currently installed lgup will be unlocked!!! But for that your 03 x files (which this patch actually patches) should be of the same version which this patch is meant for.

The versions are:

LGUP 1.14.0.3

8994 DLL 0.0.3.23

Common DLL 1.0.28.5

So check your installed versions first before running this patch. And if your existing versions mismatch with these ones, as was also the case with me, uninstall them and install the required versions from here. And then run the patch.

ChipErase sounds like wiping all partitions of emmc. But not sure.
[G4 General] rizkhan999:
VS986 & H818N Unlock Testing using LS991 Method

Dear sfX!

I have tested the LS991 unlock method on vs986 and h818n. Both proved to be encountering severe ilapo issue later on so services could not be tested at the end and phones continued to boot-loop or turn-off. However the unlock process completed on both phones successfully from the start (i.e. flashing of QFIL files) to the end (i.e. flashing of TWRP and your boot permissive image, not the stock image). For information, I flashed required partitions from H818N 10L ARBv0 KDZ in H818N while VS986 13B ARBv2 KDZ in VS986.

I have attached the screenshots of both phones in fastboot mode after QFIL files were already flashed. They show SECURE BOOT as "disabled" while the LOCK STATE is still shown as "locked". Since I was able to flash custom recovery and custom boot image afterwards, without having the phones bricked, I guess it is enough to show that the unlock was achieved successfully regardless of the bootloader lock status which continued to be shown as "locked". Is that correct? Means the LOCK STATE does not need to be shown as "unlocked". Right? This is my first question.

My second question is that, is there any way to get rid of the Secure Booting Error OFFICIAL with 1009 error code (screenshot also attached) that keep showing up on LG logo screen on boot, after completion of whole process?

Lastly, special thanks to the_naxhoo who guided me through the whole process selflessly. Without him the said testing would not have been possible.:good:

EDIT: And ofcourse, all credit of us even being able to perform all these testings, goes to none other than steadfasterX, who discovered all of this, and made possible in actual, which seems completely impossible by all means, and who is also supporting each one of us for getting this unlock on our devices. :good::good::good:;)
[G4 General] steadfasterX:
Many thanks for sharing your thoughts here!

Unfortunately you're alone on this as I cant help you with that hardware level stuff.

If something should be tested let us know but make a new post otherwise no one get a message/info when you do so (just saw that you edited your post but I get no notification from XDA about this)

thx and I hope that you find something ;) :fingers-crossed:

sfX

> They show SECURE BOOT as "disabled" while the LOCK STATE is still shown as "locked".

> Means the LOCK STATE does not need to be shown as "unlocked". Right?

correct. the unlock here means we disable the enforcement of secure boot which in fact allows to flash and boot everything.

> is there any way to get rid of the Secure Booting Error OFFICIAL with 1009 error code

thats written in aboot and as we cant change aboot ... so no.

on nougat there is another option by modifying raw_resources partition. In theory it should be possible to show nothing instead (so black screen) but as that may require nougat I'm not sure if we can achieve this.

Pls do a quick test and flash the raw_resources partition of nougat and see what happens. If you still get that text message then: no but if you get a the nougat one with picture etc then: yes very likely we can do so.

.
[G4 General] rizkhan999:
I have extracted raw_resources and raw_resourcesbak from the official 30b KDZ of F500L. And flashed in fastboot mode. But the same message continues to show up on boot. Then I erased both the said partitions by fastboot erase command and then flashed both images again. But the message is still there. Means would have to live with it. Not a big deal though.
[G4 General] rizkhan999:
I just erased both raw_resources partitions in fastboot and rebooted. LG logo was gone but the secure booting error continues to be displayed (as attached). It shows that the logo does belong to the raw_resources partition while the error message is coming from someother partition (like you said aboot), so it stays there.
[G4 General] steadfasterX:
ok thx. yes its known that the second Logo is related to that partition. well then we have to live with it

Cheers
[G4 General] rizkhan999:
I guess ARB must be <= 2. Being 0 is not a must. May be the change is not updated here...

It is understandable that there is no way back for models that are always on ARB v0 like H815 and F500 etc. But isn't there a way back for models which have roms with ARB >= 2 ? e.g. vs986 13b is on ARB v2! So after converting vs986 to ls991, can't we convert it back to vs986 by flashing all partitions of vs986 13b one by one in either download mode or fastboot mode?
[G4 General] steadfasterX:
the problem of this is not the ARB...

the firehose will blow a fuse and only the given aboot will accept this and allows booting.

So at this step it is not ARB but the userdebug fuse which prevents as well.

.
[G4 General] bayr691@gmail.com:
Hi i have a question. If i unlock bootloader can I install nougat rom. In some way install nougat rom requires nougat bootloader. So if i want to install nougat rom will i have to flash nougat bootloader right? But there is so interesting thing after flash ls991 firehose we get the arb v2 device. But nougat bootloader only available for h815 eu and it's unblown fuse basically arb v0. So if we install nougat bootloader maybe we will get bricked device.So can we install nougat based rom on converted ls991 and official ls991?
[G4 General] steadfasterX:
After using this method you cannot install any other Bootloader stack than the one I provide but you can of course boot nougat.

I have done so already for 29a and it boots fine.

the only reason why you have to install the nougat Bootloader Stack is because of the modem / firmware partition which must be compatible with the ROM in order to function correctly.

And exactly here the current problem occurs because you can flash any modem partition after unlocking but it seems that it can't get initialised correctly so you have to use the one coming with the unlocking Bootloader stack which means for some countries or I don't know what you will not get cell signal
[G4 General] bayr691@gmail.com:
Thanks for your reply.but unfortunately my device has damaged and cannot access anymore because of display FCP connector. If i understood your reply.may i still have cellular wifi bt like when it was on vs986 firmware? Before i bricked my device (VS986) i fixed it ls991 firehose then i flashed VS986 V28A MM kdz. Everything was fine all was working. So after install H815 rom especially H Rom V30 nougat will i still have cellular connection?
[G4 General] steadfasterX:
There are two fire hoses out there and depending on which you have used all is fine or not. I cannot say anything without seeing the files you have used.

This unlock here will let you boot nougat stock and you will have WiFi and Bluetooth (at least that has worked for all) . VS986 may even have cell service but I can't promise anything. And even IF that works when it comes to mobile Internet you may have no 3G or 4G.

The only thing I can say for sure is that the unlock in general works for that device. I cannot say anything else bc I had no tester for vs986 yet (only an already bootlooped one which was able to get unlocked but not to boot due to the hardware defect)
[G4 General] terence.tan:
Hi all, I've written a small script to inspect "aboot.bin" and extract the certificate files. I know you can already use "binwalk" to do this, but I prefer to do it with standard utilities like "grep" and "openssl". The script is:

#/bin/sh

if [ -z "$1" -o ! -f "$1" ]
then
echo "Usage: $0 filename"
exit
fi

# Find binary offset of "SW_ID"
OFFSET=`LANG=C grep --only-matching --byte-offset --binary --text "[0-9] SW_ID" "$1" | head -n 1 | cut -d ":" -f 1`
# Rewind approx. 540 bytes to before start of certificate
let "OFFSET = OFFSET - 540"
dd if="$1" of=certs0 bs=1 skip=$OFFSET count=8192

# "certs0" contains certificates 1-3 somewhere starting in the first 100 or so bytes

# Find start of certificate: match "\x30\x82"
OFFSET=`LANG=C grep --only-matching --byte-offset --binary --text --perl-regexp "\x30\x82" certs0 | head -n 1 | cut -d ":" -f 1`
dd if=certs0 of=certs1 bs=1 skip=$OFFSET

# "certs1" contains certificates 1-3 starting in byte 0.

openssl x509 -in certs1 -inform der -out "$1.1.der" -outform der
openssl x509 -in certs1 -inform der -out "$1.1.pem" -outform pem
dd skip=`du -b "$1.1.der" | cut -f1` bs=1 if=certs1 of=certs2

# "certs2" contains certificates 2-3 starting in byte 0; $1.1.der and .pem contains certificate 1

openssl x509 -in certs2 -inform der -out "$1.2.der" -outform der
openssl x509 -in certs2 -inform der -out "$1.2.pem" -outform pem
dd skip=`du -b "$1.2.der" | cut -f1` bs=1 if=certs2 of=certs3

# "certs3" contains certificate 3 starting in byte 0; $1.2.der and .pem contains certificate 2

openssl x509 -in certs3 -inform der -out "$1.3.der" -outform der
openssl x509 -in certs3 -inform der -out "$1.3.pem" -outform pem

# $1.3.der and .pem contains certificate 3

rm certs0 certs1 certs2 certs3

After you run it, you can inspect individual certificates. For example if your file is "aboot.H81010o.bin" and you want to look at the attestation cert:

tt@dev:~$ openssl x509 -in aboot.H81010o.bin.1.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 429591 (0x68e17)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = LGE attestation CA, OU = General LGE attestation CA, O = LGE, L = GEUMCHEON, ST = SEOUL, C = KR
(etc. etc. etc.)

To check the certs' validity (i.e. the chain of trust):

tt@dev:~$ openssl verify -CAfile aboot.H81010o.bin.3.pem -untrusted aboot.H81010o.bin.2.pem aboot.H81010o.bin.1.pem
aboot.H81010o.bin.1.pem: OK

To get the certificate hashes:

tt@dev:~$ sha256sum aboot.H81010o.bin.*.der
0e6ebeb97bc794b050a443401206370b02ab7bbdb5c170cd763556d8564734b8 aboot.H81010o.bin.1.der
0f6fed6a9a154b0e13ed63011814786837a6a008c4b6db8ea61a5c8dd6739e31 aboot.H81010o.bin.2.der
b5baca995aec012db32eb9e49ca340f7d4c26153aaa60c5a82a03f99afc698e3 aboot.H81010o.bin.3.der

Note the last hash (b5ba...98e3) is for the root certificate. This hash is (I believe) hard-coded into the device ROM, and it checks that hash to validate that the certificate chain is valid.

Hope this is useful to someone! Thanks for all the work in this thread, I find it interesting.
[G4 General] steadfasterX:
Nice thx for writing it down.

Actually my upcoming project SALT is able to read the ARB with just a grep. ;) but I'm thinking of maybe implementing that very validation somehow into SALT.. Maybe as another step of verification or just as an info box..

Anyways thx for sharing!

sfX
[G4 General] terence.tan:
Thank you! You can take any code or concepts you like from the above. Also (in very quick testing) the same script should work on "sbl1" to extract certificates.

Now I have an H810 and am thinking about the method in post 196.

However I have a question about MODEL_ID. Here are some attestation certificates taken from aboot.img from various ROMs:

From H810 (10o):

Subject: CN = hg.choi, OU = General LGE attestation, O = LGE, L = GEUMCHEON, ST = SEOUL, C = KR, OU = 07 0001 SHA256, OU = 06 [B][COLOR="Red"]0000[/COLOR][/B] MODEL_ID, OU = 05 000000a8 SW_SIZE, OU = 04 0031 OEM_ID, OU = 03 0000000000000002 DEBUG, OU = 02 009690E10031[B][COLOR="Red"]0000[/COLOR][/B] HW_ID, OU = 01 [COLOR="Blue"][B]00000002[/B][/COLOR]00000009 SW_ID

From H810 (20n):

Subject: CN = hg.choi, OU = General LGE attestation, O = LGE, L = GEUMCHEON, ST = SEOUL, C = KR, OU = 07 0001 SHA256, OU = 06 [B][COLOR="Red"]0000[/COLOR][/B] MODEL_ID, OU = 05 0008d500 SW_SIZE, OU = 04 0031 OEM_ID, OU = 03 0000000000000002 DEBUG, OU = 02 009690E10031[B][COLOR="Red"]0000[/COLOR][/B] HW_ID, OU = 01 [COLOR="Blue"][B]00000002[/B][/COLOR]00000000 SW_ID

From H811 (20i):

Subject: CN = jungho.kong, OU = General LGE attestation, O = LGE, L = GEUMCHEON, ST = SEOUL, C = KR, OU = 07 0001 SHA256, OU = 06 [B][COLOR="red"]0265[/COLOR][/B] MODEL_ID, OU = 05 000000a8 SW_SIZE, OU = 04 0031 OEM_ID, OU = 03 0000000000000002 DEBUG, OU = 02 009690E10031[B][COLOR="red"]0265[/COLOR][/B] HW_ID, OU = 01 [COLOR="Blue"][B]00000002[/B][/COLOR]00000009 SW_ID

From H815 (20g):

Subject: CN = jiye.won, OU = General LGE attestation, O = LGE, L = GEUMCHEON, ST = SEOUL, C = KR, OU = 07 0001 SHA256, OU = 06 [B][COLOR="Red"]0000[/COLOR][/B] MODEL_ID, OU = 05 000000a8 SW_SIZE, OU = 04 0031 OEM_ID, OU = 03 0000000000000002 DEBUG, OU = 02 009690E10031[B][COLOR="Red"]0000[/COLOR][/B] HW_ID, OU = 01 [B][COLOR="Blue"]00000000[/COLOR][/B]00000009 SW_ID

Above I highlighted the MODEL_ID in red (in 2 places per line) and the ARB (or what Qualcomm calls the "software version") in blue. Note that H815 (20g) is ARBv0 and the others are ARBv2, this is well-known.

The MODEL_ID appears to be:

H810: 0000

H811: 0265

H815: 0000

VS986/LS991/F500/everything else: don't know, haven't downloaded these images :)

According to Qualcomm, the MODEL_ID needs to match otherwise you get a brick. (Also the ARB needs to match. And probably a lot of other conditions...) From Secure Boot and Image Authentication Technical Overview page 11:

This strongly implies that you can flash an H810 bootstack onto H815 hardware (and vice-versa) because they share a common MODEL_ID (however the ARB must also match, otherwise you still get a brick).

However it implies that you can not flash an H811 bootstack onto H810/H815 because MODEL_ID is different.

What do we think?
[G4 General] steadfasterX:
Well ok.. But... You CAN flash h811 on h810 (proven).. That stands against the above theory then.

The problem is not just ARB and maybe Model id must match but also the certificate chain starting at the PBL (which we cannot view).
[G4 General] scholbert:
QFPROM PRG solder bridge

Hey!

Cool things are going on here...

Apart form all this software stuff, signed binaries and other cruel things, i just wanted to add some hardware related things for completeness.

As i already stated in this post:

https://xdaforums.com/showpost.php?p=74669939&postcount=223

There is a simple solder bridge nearby the CPU which is used to power the QFPROM PRG domain.

Please see the attached pic of the H815 mainboard area with some comments (it's the same on H818 mainboard).

My H815 is in use right now and so the base picture has been stolen shameless from this thread:

https://xdaforums.com/g4/help/lg-g4-stuck-bootloop-t3268734/page123

I'm pretty sure that during software engineering, this connection has been left open, to prevent some fuses to be blown by accident.

Maybe some of the low level routines in the boot code may cause errors, or the device won't start with this domain unpowered.

We need some testing here.

So as i stated initially... this is just for completeness.

Could be of no use in the end :o

Cheers,

scholbert
[G4 General] steadfasterX:
Update:

Forget to mention that but the above way is not working.

The hope was that these other leaked files will not just disable the cores but also leaving the fastboot in secureboot disabled as for the ls991.

Unfortunately this is not the case sorry.

So the state is still: unofficial unlock means full convert

sfX