[G4 Q&A, Help & Troubleshooting] jjbredesen:
Ah, I see, was not aware that the community had a go at this...

So after reading the thread my understanding is basically that the unlock.bin is a standard action authorization token. Used in an OEM action authorization protocol.

So the unlock.bin would normally be generated with a action authorization nonce (It takes the form "::<8 bit action id>:<16 client random bytes>" with all fields hex encoded.) It looks like in this case LG has opted to use the Device ID and IMEI instead of the AAN.

The AAN would be signed to a OAK. (Override Authorization Key, basically it is a public key that is set in the device during manufacturing and that is used to validate action authorization tokens. It is stored as the OAK time-based authenticated EFI variable under the Fastboot GUID of 1ac80a82-4f0c-456b-9a99-debeb431fcc1. The content of this variable is the SHA256 sum of the OAK certificate., and as I understand the developers in the thread you linked to have been able to crack it.)

The AAT token (unlock.bin) should then be a PKCS #7 signed document, where the body takes the form "::<8 bit action id>:<16 client random bytes>:<16 auth agent random bytes>" with all fields hex encoded. The auth agent random bytes added when creating the authorization is to prevent an attacker from mounting an attack by supplying known plain-text values. (this fits perfectly with what we have seen when trying to read the unlock.bin files using HEX editors)

The token must contain all certificates required to validate the signature chain of the token.

The action authorization agent must verify that the nonce is exactly in the prescribed format. (LG website when requesting IMEI and Device ID)

The action authorization agent must verify that the action ID in nonce is a recognized value. (Valid IMEI and Device ID)

If possible, the action authorization agent should verify that the serial number of the G4 is valid. (So custom Device-ID's and IMEI's will not save us)

So what LG is doing here is a a OEM action authorization protocol, basically it is a simple challenge response where the device's Fastboot generates a nonce in this case they just use the Device ID and IMEI, then the OEM action authorization agent signs the nonce and approved action using its private override authorization key (OAK) to generate an authorization token, (this would be the developer.lge.com side of things and the private key is the one the developers in the thread need, but can't crack) and then the device's Fastboot validates the action authorization token (unlock.bin) and executes the action. (bootloader=unlocked)

Now we understand the policy, but even if we got the private key, when flashing a modified unlock.bin fastboot would need to validate that there is no extra data after parsing the token,verify that the signature's certificate chains to the OAK set at manufacturing, verify that all values in the token body have the prescribed values and verify that the value returned by the "oem get-action-nonce " command matches the value in the token body (IMEI and Device-ID)

So to my knowledge we have no chance to unlock the dam thing, that is unless we can find a backdoor to change the bootloader policy mask from state 0 to 1, then the signature enforcement chain described in the thread you linked too would be disabled, but I don't know how this could be done.