[UNLOCK] Technical steps to make an unlocked bootloader

Search This thread
By:
Advanced…
K

KonterBiER

Senior Member
Dec 17, 2010
104
93
Kaiserslautern
Hello everyone!

First: This is not about how you could unlock your bootloader in a few steps! Specially for the LG G4, now where we have root.
This is a technical basic knowledge question to experienced developers in this topic!

I wanted to know how one of the experienced devs would act in his first steps to get an unlocked bootloader.
What knowledges are needed?

  • Opening the device to get physical access to the flash memory?
  • Connection probably hidden or physically disabled (by burned fuse) JTAG to dump the flash?
  • Just dd the bootloader partition?
  • Is bootloader signed and/or compressed and/or encrypted?
  • How would you proceed this way (when bootloader is encrypted)? Would you try to get out some secrets from the (probably used) high security cryptography co-processor chips by very expensive equipment? Or am I expecting way too much by the manufacturers?:D
  • When bootloader is a plain binary file: Is it enough to throw it into IDA Pro ARM disassembler and analyse where the kernel signature is validated to place some jump instructions there?
  • Or would it just be enough to compare a T-Mobile bootloader binary (which seems to be factory unlocked) with an locked bootloader from other carriers and find out whats the magic (maybe just a bit flag)?
And after you have done a successful unlock, how to write it back into flash with a proper and safe method? I guess this partition has special security and write permissions? Or is this also very simple by writing it from inside the running android system by dd?
I expect this last step is the most difficult and complicated step? And probably the most risky step.

I'm interested in this because I'm currently studying computer science, but didn't go that deep into the android device world :(
We mostly see the finished product of very skilled developers here, but I'm interested in how to start such a project. Where can you get the important informations you need to know to make the bootloader loading an unsigned kernel image and so on...

So, what's the common thread to bring such a thing to success?

I can understand if these devs don't want to discuss this in public, because they fear that the manufacturers will use this knowledge as well to make their devices even harder to unlock. But maybe you can give me some hints :)

Thank you!
 
Last edited:
  • Like
Reactions: Diatomix98, khoailang2500, crazylife and 4 others
Hashbang173

Hashbang173

Inactive Recognized Developer / Contributor
May 6, 2012
2,446
3,893
KonterBiER said:
Okay thank you!
Do you have any ideas about how to get the bootloader Image?
Is it possible to dump it with root and dd?
Click to expand...
Click to collapse
Yes, you can back it up to your sdcard using dd, and you can pull it to your computer using and pull. I can't give you the specific commands unless you give me a the partitions in /dev/block/
 
K

KonterBiER

Senior Member
Dec 17, 2010
104
93
Kaiserslautern
Hashbang173 said:
Yes, you can back it up to your sdcard using dd, and you can pull it to your computer using and pull. I can't give you the specific commands unless you give me a the partitions in /dev/block/
Click to expand...
Click to collapse
Okay, I've some linux knowledges.

I'm just interested to see if the official unlock.bin of LG is encrypted in some way (what implies that the bootloader has some decryption code in it), and if it is possible to make some changes on the raw dump.
 
Last edited:
  • Like
Reactions: TheMadScientist and Slovan_A3
Hashbang173

Hashbang173

Inactive Recognized Developer / Contributor
May 6, 2012
2,446
3,893
If you give me the output of

ls -l /dev/block/platform/f9824900.sdhci/by-name

I can give you the dd command to backup a bootloader partition such as aboot
 
2nd Sky

2nd Sky

Senior Member
Jun 15, 2013
1,083
310
My City
KDZ has all partitions inside, not spezific like imei, so bootloader also. why is there noone who can bring unlocked BL and pack it into a kdz again to flash for all... (and btw with root and twrp)

on nx4 i mean there where people who can modify bl? right? mhmmm letz discuss more about, its interesting :)
 
  • Like
Reactions: KonterBiER
esmenikmatixx

esmenikmatixx

Senior Member
Sep 28, 2012
138
36
For Sprint LS991, this command autoprime suggested worked to pull boot.img to sd

su
dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot-ls991zv5.img
 
  • Like
Reactions: KonterBiER
S1L3nTShaDoWz

S1L3nTShaDoWz

Senior Member
Dec 25, 2013
429
90
2nd Sky said:
KDZ has all partitions inside, not spezific like imei, so bootloader also. why is there noone who can bring unlocked BL and pack it into a kdz again to flash for all... (and btw with root and twrp)

on nx4 i mean there where people who can modify bl? right? mhmmm letz discuss more about, its interesting :)
Click to expand...
Click to collapse
That will not work @ flashforall because the bootloader will reject anything that is not signed by the Carrier/LG, so if you tried to flash it it would automatically reject it due to the non C/LG signed signature and would potentially leave you in some sort of emergency mode. At least this is how my other phones have worked, I can't verify it does it like this on LG phones but yeah. If anything, from my post here you at least learned how other BL's work haha.
 
Last edited:
K

Knowbody42

Senior Member
Jul 1, 2015
196
55
Melbourne
What exactly does the signature prevent you from doing?
Does it prevent installing a modified bootloader in the first place, or does it prevent a modified bootloader from working if it is installed?
 
K

KonterBiER

Senior Member
Dec 17, 2010
104
93
Kaiserslautern
Knowbody42 said:
What exactly does the signature prevent you from doing?
Does it prevent installing a modified bootloader in the first place, or does it prevent a modified bootloader from working if it is installed?
Click to expand...
Click to collapse
I guess it is preventing to install a modified one.
The old bootloader seems to have some loading code for new bootloaders. This code creates a checksum of the new bootloader code and uses a public key to decrypt a special pre or appended area in which a precalculated checksum was placed, encrypted by an unknow private key.

The interesting question is: Is it possible to write into the bootloader memory from an upstartet system, e.g. with dd? Or is some special procedure needed to disable a write protection?
 
K

KonterBiER

Senior Member
Dec 17, 2010
104
93
Kaiserslautern
It looks like the bootloader code is not encrypted on the first view:
 

Attachments

  • bl-hex.png
    bl-hex.png
    67.7 KB · Views: 1,308
2nd Sky

2nd Sky

Senior Member
Jun 15, 2013
1,083
310
My City
New idea (remember: i flashed on my e975 optimus G (rollout with jb) a F180 (korean, hw more or less same..) ics kdz. Most worked (no signalwrong modem..)


What if we flash tmobile kdz? Is hardware same enough? Cause when we flash we should have unlocked bl. Then we need only to root and flash recovery then we can flash right modemandall should work...?

But dont know difference between h815 and the unlocked tmobile g4...

Thx for reading and hope u understand what i mean @KonterBiER my german friend xD
Griang ma scho hi dass ma wos findn zum unlocken... ;)
 
  • Like
Reactions: KonterBiER
K

KonterBiER

Senior Member
Dec 17, 2010
104
93
Kaiserslautern
Hi 2nd Sky,

I don't know much about the LG KDZ files, what they contain and how important it is to have the correct one for your device model. The G4 is my first LG device. The last 5 years I used a HTC Desire HD ;)

But if the devices are identical from the hardware site, and the KDZ contains the bootloader, it should be worth to try.

But who want's to test it? Is there a risk to brick the device?

OT:
Oha, auch noch bayerisch :)
 
2nd Sky

2nd Sky

Senior Member
Jun 15, 2013
1,083
310
My City
When u look in the folder: all images are in kdz:http://downloads.codefi.re/autoprime/LG/LG_G4/H815/H81510C/ (not the zip files)

Theres also kdz extractor at xda. Dont know if he works on g4 kdz's

I think my option is one of the only ways to become unlocked bl because of signature u cant edit kdz


But if the methode like low effort root works for other partitions its also way...


When u try somethink i would first backup efs partitions (imei and othrs) and have all files on sd so ucan put out sd...

And if you brick it, go to service and say update failed ;) normally u will become new mainboard. So try and risk something:p

OT ja bayrisch ;) hoffe dass ich bald an meinen pc kann und werd mich mal mit dem irc?! channel/chat auseinandersetzen und mit den chefs hier mal reden
 
K

KonterBiER

Senior Member
Dec 17, 2010
104
93
Kaiserslautern
I just downloaded the "LG-H81510C-Flashable.Bootloader.zip" and extracted it.
How is this file created?

It seems like aboot.bin contains some references to lg root certificates. Maybe such a dump of the T-Mobile variant would be very interesting!
 
  • Like
Reactions: 2nd Sky
You must log in or register to reply here.

Similar threads

V
LG G4 stuck in bootloop
Replies
2K
Views
532K
L
lRaziel1
I
(Q) Unlock Bypass Google Account LG G4 H818P lolipop?
Replies
49
Views
126K
C
captbear
M
How to unlock *.dm files on other phones (Not LG)
Replies
19
Views
89K
A
AlexGiancarlo
ajamils
Unlock code prompt on H811 (LG G4 - Tmobile)
Replies
84
Views
61K
M
mayanks7
B
adb reboot bootloader (Unlocking the Bootloader)
Replies
11
Views
22K
Milimbar
Milimbar

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 37
    xrad
    xrad
    Here's a bit of brain dump to help me not forget my findings and to share the knowledge.

    When you're requesting your unlock key from LG, and if you're lucky enough to own an EUR or SEA phone, this is what happens behind LG's firewall:

    • A 128 byte buffer is formed which contains your 64 byte device ID and the 15 byte IMEI. Let's call this buffer unlock.id:
      Code: 
      00000000  33 41 38 43 38 45 46 34  42 36 46 41 41 41 41 38  |3A8C8EF4B6FAAAA8|
00000010  31 35 34 42 45 33 34 31  33 31 44 46 34 45 43 42  |154BE34131DF4ECB|
00000020  38 43 43 39 33 33 34 30  44 37 37 36 36 35 37 31  |8CC93340D7766571|
00000030  38 34 42 33 36 45 46 44  44 35 36 41 44 35 34 46  |84B36EFDD56AD54F|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
[...all zero...]
00000060  33 35 39 38 37 32 30 36  32 32 30 32 37 33 33 00  |359872062202733.|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    • The sha256 sum (digest) is generated for this buffer:
      Code: 
      openssl dgst -sha256 binary <unlock.id >unlock.sha256
00000000  9c a8 74 02 34 f9 38 c6  15 62 53 61 9a 07 dc 14  |..t.4.8..bSa....|
00000010  07 7b dd 13 6f 48 7f 0e  ff a4 cb ce bd 40 7a ff  |.{..oH.......@z.|
    • The sha256 digest is signed using the private key:
      Code: 
      openssl rsautl -inkey UNLOCK_RSA_02_PRIV.pem -sign <unlock.sha256  >unlock.bin
    • A header is prepended to unlock.signed:
      Code: 
      9e15b78d -> magic #1
6bd37e2d -> magic #2 
00000001 -> magic #3 
00000002 -> sha method (1=sha1, 2=sha256) 
00000100 -> size of key (256 bytes)
    • The result of this process is the unlock.bin they send to you and which you can flash in fastboot (if you have enabled the OEM unlock option in the developer settings).

    Now, when the phone boots, the following happens:

    • The unlock.bin is checked to have the proper magic IDs at the beginning
    • Using the phone's device ID and IMEI, the unlock.id buffer is built as described above and the SHA256 sum is generated
    • The unlock.bin key is verified using the public key. This recovers the sha-256 encoded unlock.id as it was initially prep'ed at LGr:
      Code: 
      openssl rsautl -verify <UNLOCK_RSA_02.pem -inkey pub.pem -pubin
    • If the locally generated buffer and the verified one match -> You're UNLOCKED!

    Things to note:
    • We do have the public key UNLOCK_RSA_02.pem, but we lack the private key UNLOCK_RSA_02_PRIV.pem.
    • The 4th word encodes the SHA method that is used to generate the signed digest. Currently LG seems to issue unlock.bins with SHA256, but from the code I think SHA1 should also work. Perhaps this is easier to attack.
    • We can't change any of the code because the bootloader, kernel, device tree and initial ramdisk are protected with similar SSL keys forming a chain of trust. We would need to find a hole here (aka Jailbreak)
    • Some of the values (IMEI, Device ID I'm not yet sure) are retrieved using a function called ftm_get_item(). I guess this refers to a thing called Field Test Mode which keeps a large number of device specific values. @autoprime once documented them somehwere here on XDA. Perhaps thare is a way to inject values here. AFAIU older LG phones could boot into something called MiniOS. Perhaps this is also possible on the G4 and gives access to those variables. If that was possible, we could perhaps force the phone to use a known combination of device ID, IMEI and unlock.bin -> unlock -> inject root -> restore original settings.
    That's all folks for today. Perhaps this helps to further our efforts.
    View
    13
    IllegalArgument
    IllegalArgument
    xrad said:
    Here's a bit of brain dump to help me not forget my findings and to share the knowledge.

    When you're requesting your unlock key from LG, and if you're lucky enough to own an EUR or SEA phone, this is what happens behind LG's firewall:

    • A 128 byte buffer is formed which contains your 64 byte device ID and the 15 byte IMEI. Let's call this buffer unlock.id:
      Code: 
      00000000  33 41 38 43 38 45 46 34  42 36 46 41 41 41 41 38  |3A8C8EF4B6FAAAA8|
00000010  31 35 34 42 45 33 34 31  33 31 44 46 34 45 43 42  |154BE34131DF4ECB|
00000020  38 43 43 39 33 33 34 30  44 37 37 36 36 35 37 31  |8CC93340D7766571|
00000030  38 34 42 33 36 45 46 44  44 35 36 41 44 35 34 46  |84B36EFDD56AD54F|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
[...all zero...]
00000060  33 35 39 38 37 32 30 36  32 32 30 32 37 33 33 00  |359872062202733.|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    • The sha256 sum (digest) is generated for this buffer:
      Code: 
      openssl dgst -sha256 binary <unlock.id >unlock.sha256
00000000  9c a8 74 02 34 f9 38 c6  15 62 53 61 9a 07 dc 14  |..t.4.8..bSa....|
00000010  07 7b dd 13 6f 48 7f 0e  ff a4 cb ce bd 40 7a ff  |.{..oH.......@z.|
    • The sha256 digest is signed using the private key:
      Code: 
      openssl rsautl -inkey UNLOCK_RSA_02_PRIV.pem -sign <unlock.sha256  >unlock.bin
    • A header is prepended to unlock.signed:
      Code: 
      9e15b78d -> magic #1
6bd37e2d -> magic #2 
00000001 -> magic #3 
00000002 -> sha method (1=sha1, 2=sha256) 
00000100 -> size of key (256 bytes)
    • The result of this process is the unlock.bin they send to you and which you can flash in fastboot (if you have enabled the OEM unlock option in the developer settings).

    Now, when the phone boots, the following happens:

    • The unlock.bin is checked to have the proper magic IDs at the beginning
    • Using the phone's device ID and IMEI, the unlock.id buffer is built as described above and the SHA256 sum is generated
    • The unlock.bin key is verified using the public key. This recovers the sha-256 encoded unlock.id as it was initially prep'ed at LGr:
      Code: 
      openssl rsautl -verify <UNLOCK_RSA_02.pem -inkey pub.pem -pubin
    • If the locally generated buffer and the verified one match -> You're UNLOCKED!

    Things to note:
    • We do have the public key UNLOCK_RSA_02.pem, but we lack the private key UNLOCK_RSA_02_PRIV.pem.
    • The 4th word encodes the SHA method that is used to generate the signed digest. Currently LG seems to issue unlock.bins with SHA256, but from the
    • code I think SHA1 should also work. Perhaps this is easier to attack.
    • We can't change any of the code because the bootloader, kernel, device tree and initial ramdisk are protected with similar SSL keys forming a chain of trust. We would need to find a whole here (aka Jailbreak)
    • Some of the values (IMEI, Device ID I'm not yet sure) are retrieved using a function called ftm_get_item(). I guess this refers to a thing called Field Test Mode which keeps a large number of device specific values. @autoprime once documented them somehwere here on XDA. Perhaps thare is a way to inject values here. AFAIU older LG phones could boot into something called MiniOS. Perhaps this is also possible on the G4 and gives access to those variables. If that was possible, we could perhaps force the phone to use a known combination of device ID, IMEI and unlock.bin -> unlock -> inject root -> restore original settings.
    That's all folks for today. Perhaps this helps to further our efforts.
    Click to expand...
    Click to collapse

    Excellent analysis, all of the info you've shared looks accurate to me. I just had a couple notes I wanted to add regarding the device ID, IMEI, and ftm_get_item().

    First, to compute the device ID, you start by reading the SoC serial number from QFPROM. The serial number is eight bytes long and is stored as two 32-bit words (in order): QFPROM_RAW_SERIAL_NUM_LSB at physical address 0xFC4B81F0 and QFPROM_RAW_SERIAL_NUM_MSB at physical address 0xFC4B81F4. Next, you convert the serial number to an uppercase hex string, i.e., sprintf(buf, "%08X%08X", QFPROM_RAW_SERIAL_NUM_LSB, QFPROM_RAW_SERIAL_NUM_MSB). Then you compute the SHA-256 hash of the hex string from the previous step. Finally, you convert the hash to another uppercase hex string, which becomes the 64 byte device ID used to form the unlock token.

    As for the IMEI used in generating and validating the unlock token, it is not read from the modem, but from an ftm_item, as you noted. But what is an ftm_item? On LG devices, ftm_items are stored in the misc partition. Each ftm_item has an ID associated with it; for example, the ftm_imei item, which is used to generate and validate the unlock token, has ID 0xD. To compute the offset an ftm_item in the misc partition, simply multiply its ID by 0x800; continuing the previous example, this puts the ftm_imei item at byte offset 0x6800 in the misc partition.

    While having the IMEI part of the token in the misc partition does give you easy control over it, the QFPROM serial number is quite challenging, since it physically cannot be modified. Downgrading the hash to SHA-1 instead of SHA-256 may be possible, but even SHA-1 isn't very fun to attack. That's not to say the scheme used here is unbreakable - there may very well be some weakness that hasn't been noticed yet. If there is such a weakness, analysis like that which you're doing is the best way to discover it.
    View
    11
    xrad
    xrad
    So I've been looking at MM20B's aboot.img today. I was able to extract a number of keys and certificates, find them here. They're all in DER format (ie. binary). Unfortunately I'm not a crypto expert, but perhaps one it out there reading this.

    Dump keys like this:
    Code: 
    openssl  asn1parse -inform der -in KEYFILE

    The rootca and one of the "LG attestation" certs are x509:
    Code: 
    openssl x509 -inform der -in lgroot.crt 
openssl x509 -inform der -in lgattest.georgia.crt -text

    Here are some thoughts and observations I made:
    • Funniest one first, one x509 certificate has a CN id of "georgia.park" which seems really odd, perhaps even a hint to some pass-phrase?
    • The androidlk keys seems to be related to the Android Little Kernel boot loader code.
    • On of the keys is is named UNLOCK_RSA_02, I'll be damned if this doesn't have to do anything with unlock.bin
    • I could imagine that the unlock.bin is encrypted with a public key at LG's site. Then you flash it to a dedicated partition. aboot.img grabs unlock.bin, decrypts it with one of its private keys and checks it. I could imagine if we get to decrypt an existing unlock.bin, it just contains the device id and IMEI.
    • More generally, I think the process and keys is independent of the phone hardware. Every phone has to have identical boot loader and verification code. They will use the (unalterable) device id and IMEI to bind the process to devices

    Next steps could be:
    • give those keys some more meaning and relate them to each other / other artifacts
    • most likely the unlock key is encrypted, so we'd need to find the pass phrase
    • some ARM guru could try to disassemble aboot.img to learn how those keys are used. Perhaps even find additional pass phrases embedded in the code

    Spread the word. I'm new to the LG/LG4 community but I already learned that guy @autoprime is doing lots of gory work. Let's jailbreak this together and then donate the bounty to some noble cause!
    View
    9
    D
    devilh
    Step by step to current status

    Hey,
    I want to try my best with unlocking the bootloader.
    I am experienced with C , encryptions and exploits, but not so much with android low level hierarchy(boot flow) or with G4 terms (as I just got mine and want to give this a shot).
    I read through this thread,
    But couldn't get all what I needed. will be happy to a short step-by-step guide on how to get the dev environment to the "current status" where I can:
    1. See a dissasebmly of the bootloader
    2. Activate commands in download mode(writing to serial?)
    3. Have all the required testing files(such as working unlocked.img with its matching ID and IMEI)
    thanks
    View
    9
    xrad
    xrad
    xrad said:
    So I've been looking at MM20B's aboot.img today. [...]
    Click to expand...
    Click to collapse
    Here's a quick update. I've spent a lot of time reverse engineering the bootloader and I have now a pretty solid picture how things work. With the valid combination of an unlock.bin and device-id/IMEI I was able to reproduce the stages the code takes to validate the key. Indeed the unlock key I recovered from the binary is a public key which the loader verifies the unlock.bin key. It then compares the digest thus recovered with a locally generated one and if they match - you're unlocked. So far for the good news. As expected, the bad news is that the corresponding private key is not in our hands, but needed to create valid unlock.bin files. So as of now there's still no hope to break in, but at least I know how the lock works. And I learned a bit about openssl, which has its own merits.
    View

New posts