[G4 Q&A, Help & Troubleshooting] 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:

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:

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:

openssl rsautl -inkey UNLOCK_RSA_02_PRIV.pem -sign <unlock.sha256 >unlock.bin

A header is prepended to unlock.signed:

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:

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. [MENTION=2684188]autoprime[/MENTION] 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.