[Upgrading, Modifying and Unlocking] 999repeating:
Alright boys, believe it or not I am making an enormous amount of progress in determining how Motorola selects the alphanumeric string that unlocks the bootloader. With the ~10 devices I have unlocked via their online tool over the years I inherited a device not eligible for unlock, it also returns a complete error when using the url trick. This is where my journey begins, upon EXTENSIVE analysis of the keys and the data from each device I have determined that generating the key ourselves IS POSSIBLE. WHAT DOES THIS MEAN? I now believe all devices, even if ineligible, can be unlocked in a safe and controlled manner. It also means their key selection process hasn't changed since they implemented the bootloader unlock website. The keys ARE CONSISTENT and follow a process that I am slowly uncovering thanks to the many many insights and data given in these threads, this thread especially. PARTICULARLY the get_unlock_data and the resulting key. This is a long process and I've only been at it for under a week.

What do I need? I need more data.

10 sets of unlock data and 14 keys in which only 10 have corresponding unlock data for further analysis is all I have.

For those new to this the first of the 4 strings in get_unlock_data are MEID, SECdata, ProcessorUID, Bootloader Hash) SecData appears to be unused in the retrieval of the key, which is interesting. This is a valuable insight, considering its name and the fact some of the different URL tricks have a place to input the string, yet it isnt needed. Perhaps that string is more important than it appears.

With this extremely small data set, This is what I've found SO FAR:

The keys are in fact related to the IMEI FOR ABSOLUTE SURE. Why do I suspect this? It turns out any digits present in the key are also present in the IMEI. If a digit does NOT appear in the IMEI, IT IS NOT observed in the resulting keys, Nope, I came across a single key that included a digit not present in the IMEI. 🤔

THE HIGHEST OBSERVED DIGIT SO FAR is a 7 believed to range as high as 9 and as low as 2 although 8 or 9 have not yet been observed. The keys also omit the digits 1 & 0, lending credit that they are generated in binary and some conversion process is applied. With that being said, an alternative attack vector could be to issue a string of binary as the unlock code. Anything longer than 20 characters hangs the console, which leads me to believe a buffer overflow is a possibility with a specially crafted string. All letters A-Z are present and used in key generation. Why am I making a post? Because I need more data. I have created a custom ML, also using other artificial intelligence tools to help me analyze and determine the algorithm applied. The key is always 20 characters in length and being verified in the bootloader somewhere. The bootloader hash (4th string in the unlock data) is ALWAYS 40 bytes lending credit that it is sha-256 I also think the hash isn't used to generate the key, but the other way around. It's also worth noting that the maximum amount of digits in the keys so far is 5 digits with 3 digits being the most common.

This thread alone had a lot of data, with everybody posting their get_unlock_data and the revelation of this data present in /cid.

This entire post is just to show people my progress and that I think this is indeed possible and to ask for more data from others. A complete dataset includes the /cid partition and your get_unlock_data string with the resulting key.

Please also include the entire string that includes the SecData string (String #2)

and if possible post the /cid partition for further investigation.

I havent even begun to dissect the raw partitions but after analyzing all the data I get from others, my next step is to evaluate the partitions /cid /aboot and others in hex to see if the key is already present in the form of binary or hex.

The fact that it is verifying the code in fastboot gives us a way to test our results.

If/when we discover an exploit or uncover the actual method by which the string is selected, it will definitely NOT be public at first. It WILL be FREE, but we all know the moment it goes public they will patch it.

It does appear our very first step will be to brute force the unlock string on an ineligible device. (The one I have is the perfect candidate)

Then once we get some other ineligible devices unlocked we should be able to collect and IDENTIFY whether the device specific partitions contain or omit anything in them that determines eligibility.

I suspect it's just a generic database on their server, but since they only seem to have eligible device unlock strings on their server, this should be an interesting project.

I am posting my own get_unlock_data already concatenated.

I receive and error unlike all other reported errors. No it's not eligible and the url trick results in this error. (See attached.)

3A85829933902136/8B674B3D75384CB20000000000000000/5FCFE5C91F27D0886EFAA24876B524CCB9E5BFD633C1075CC65F55401BFFB71D

If you do post your get_unlock_data and resulting key, keep in mind it does contain your MEID which is crucial to this process. If you prefer to PM me, that is also acceptable. Thank you.