I only read the first page and last 5 pages of this thread, though obviously noone has a working solution that is also free, not yet anyway
So far it seems like the moto g bootloader (unless otherwise, everything below refers to both the XT1028 and XT1031) resembles it's n4 and n5 contemporaries:
The lock state is stored in
/dev/block/platform/msm_sdcc.1/by-name/misc -> /dev/block/mmcblk0p30
The lock state itself is at 0x1503
, a value of 0x30 indicates it's currently locked, 0x31 is unlocked.
The tamper flag itself is not stored in misc, as this bit is the only difference between my XT1028 which is locked/untampered,
and my XT1031 which is locked/unlocked and tampered.
As previously seen, the lockstate goes from:
- Status code 0: locked + untampered
- Status code 1: unlocked + untampered(?) - no way to test this currently
- Status code 2: locked + tampered
- Status code 3: unlocked + tampered
You go from code 0
to code 3
by using fastboot oem unlock <unlock code>
on the XT1031, and fastboot oem lock begin
and fastboot oem lock
returns you to code 2
, as there are no other modified bits in misc from locked -> unlocked -> relocked, there's no way to return to code 0
or code 1
You can't simply change the contents of misc with root on the moto g, unlike the N4/N5/etc, something (possibly some kernel and/or bootloader protection) is preventing you from directly modifying that value.
What I do know is that even inside CWM you still can't directly modify that partition, though I don't actually know if the copy of CWM I used is based on a stock kernel or CM/QAF based, not that you can even boot it on a locked device
Unlike the N4/N5/etc, the moto g bootloader seems to enter a special mode to do the actual unlocking.
Snapdragons definitely have memory (both ram and nand) protection due to the fact it needs to protect multiple decryption keys (DRM media, cellular encryption, etc), and I wouldn't be surprised at all that this is (at least partly) why I cant directly write to it, and that there have definitely been exploits in the past to modify protected memory to bypass these restrictions.
Perhaps when it enters unlock/relock mode, that is the only time the bootloader can modify the contents of misc, at least under normal conditions.
I do believe that in the past, it has been documented that snapdragon based platforms additionally allow/disallow bootloader unlocking by flags/fuses that are not mapped to the partitioned parts of the nand. As the bootloaders on the XT1028/1031/1032 are (bit) identical, this is the reason the latter two can be unlocked, while the former cannot.
I would assume that sunshine uses some sort of lower level firmware exploit to modify the tamper flag and/or flip the bootloader lock bit. If you already had code that can bypass the security restrictions on the secured portions of memory on snapdragon based devices, I wouldn't be surprised if it's that simple to make a relock/unlock tool for moto g's that have already been unlocked with the unlock code. (ie switch from mode 2 ↔ 3)
I can't say I know how you would unlock an untampered bootloader, obviously it's possible due to sunshine already existing, but I don't have any further leads on how exactly they do what they do beyond this, assuming this is even on the right track.
Even if you can only switch from mode 2 ↔ 3, this would still be useful in the same way that it's useful for nexus devices: to both have a custom/modified rom and also have a way to secure user data. A custom rom is not by definition any less secure then a stock rom, but the ability to load a custom recovery can allow you to bypass security and read user data (either online or offline, depending on data encryption)
Additionally, you can re-unlock a nexii without wiping data. The moto g requires you flashing a signed motorola rom before it will let you relock, so you cannot have any changes while also being safe from offline attacks.