[G4 Q&A, Help & Troubleshooting] RenaKunisaki:
The unlock.bin definitely isn't a full bootloader. It's only 256 bytes of "something" (probably a crypto key or encrypted payload), a header, and a lot of zeros for padding. aboot.img is 2MB; laf.img is 48MB; boot.img and recovery.img are 40MB.

Since I don't have an unlockable model, I'm not entirely sure how unlock.bin is used. If I understand correctly, you enter your IMEI (and other info?) and get this file, put it on your SD card and do something, and it unlocks?

Just to speculate: if I were designing this system, here's how I'd do it:

unlock.bin contains the device's unique ID (the first field) and an encrypted message (the 256 bytes)

the unique ID is only for telling the user "this key isn't for your device"; changing it won't help (except to let it try that key anyway and fail)

the message is encrypted with a per-device private key which only LG has (they need your IMEI to look up the corresponding key)

the keys are generated randomly and saved in a database (not computed from the IMEI, so you can't create a keygen)

the bootloader contains the corresponding per-device public key (can be used to decrypt but not encrypt, so even having it won't allow you to generate an unlock.bin)

the message, when decrypted with your device's key, is a code (similar to e.g. a CD key for a game) telling the bootloader that unlocking is authorized

this message is stored (encrypted) on the device's internal storage, and the bootloader looks for it there (it doesn't just set some flag which any user could set themselves)

the bootloader itself is signed (so a user can't just patch the unlock check)

the "bootloader" is a second stage in the boot process; the first stage is a ROM, built into the CPU, which loads the second stage and verifies the signature

That design should be pretty much impenetrable. Of course that doesn't mean unlocking is impossible, just that we'd have to attack from another angle. (And I don't know if this is the design they use, it's just what I think would be the most secure design.) Angles I'd look at in this scenario would be:

Weak signing of the bootloader, that would allow it to still be modified (or trick it into verifying one image but executing another)

Possibility to hijack the boot process and have an unsigned bootloader executed (including by hardware attacks)

Timing attacks that might allow to deduce, one byte at a time, a valid unlock.bin

Weak crypto (e.g. poor random number generator, info leaks, keys accidentally given away, possibility to change the public key to one we control)

Poor validation of the unlock message (that might allow generating a "valid" unlock.bin even without the keys, or even hijacking the bootloader itself)

Alternative unlock methods (e.g. factory backdoor)

Possibility to hijack a later stage, such that unlocking is not even necessary

Whether the very first from-power-on code is actually stored in ROM or can be modified (I don't think it could be signed/encrypted since you'd have a bootstrap problem, unless the decryption/verification is done in hardware by the CPU)

At this point I'm mostly curious what those other unknown fields are, whether the first field is in fact a device ID, and what exactly the message is. This is where it'd be nice to compare other unlock.bin files.