network lock hash found, but the SALT is unknown...
Well, I worked a little bit on the sim unlock code reverse engineering. The responsible bml file is bml25. The NCK and MCK codes are there, but they are hashed and they are hashed using a SALT code.
Because the length of the hash is 32 bytes for each of the 2 codes, the hash type is SHA256.
MCK code starts at offset 0x01421 and is 32 bytes long
NCK code starts at offset 0x01441 and is also 32 bytes long.
The NCK code for a NEVERLOCKED phone is:
CA E2 01 A8 B7 91 CA 25 B8 1B 04 87 6C AC D6 28 97 88 3E E4 C1 90 7D 2B D5 1D 56 71 FE EC 75 62
(this should be the hashed output string for the 00000000 input value)
The NCK code for a simlocked phone is:
A1 26 42 5F 6D 07 A2 DE 4C 75 F1 69 D0 CB F0 73 23 9E F5 1E CE C4 6B F3 C7 1F 1B D1 5D 02 9C 0E
(this is the hashed output string for the 24830530 input value)
When a simlocked phone is unlocked by code, the first two bytes of the bml25 file are changed from 01 01 to 00 00.
The problem is that I don't know the salt that Samsung uses when hashing the sim unlock code, so I cannot do a brute force based decryption on the hash.
On the other hand, it is most likely the salt has a constant value for all Xcover phones. That is because the hash corresponding to the "00000000" value (see above) is also present in a simlocked phone, 4 times in a row, right after the NCK hash. In a neverlocked phone, it appears 5 times in a row (the extra occurence is actually the NCK hash). See the attached picture for more details.
Does anyone know what salt usually Samsung uses for their Galaxy models?
ANOTHER SOLUTION would be to find a way to write back the bml25/stl25 image file, after we modify the value of the first two bytes from 01 to 00 or after we change the NCK hash to a known-by-us value (such as the one stated above). The stl25 cannot be dumped (via dd command), I get this error message: /dev/block/stl25: cannot open for read: Invalid argument
Well, I worked a little bit on the sim unlock code reverse engineering. The responsible bml file is bml25. The NCK and MCK codes are there, but they are hashed and they are hashed using a SALT code.
Because the length of the hash is 32 bytes for each of the 2 codes, the hash type is SHA256.
MCK code starts at offset 0x01421 and is 32 bytes long
NCK code starts at offset 0x01441 and is also 32 bytes long.
The NCK code for a NEVERLOCKED phone is:
CA E2 01 A8 B7 91 CA 25 B8 1B 04 87 6C AC D6 28 97 88 3E E4 C1 90 7D 2B D5 1D 56 71 FE EC 75 62
(this should be the hashed output string for the 00000000 input value)
The NCK code for a simlocked phone is:
A1 26 42 5F 6D 07 A2 DE 4C 75 F1 69 D0 CB F0 73 23 9E F5 1E CE C4 6B F3 C7 1F 1B D1 5D 02 9C 0E
(this is the hashed output string for the 24830530 input value)
When a simlocked phone is unlocked by code, the first two bytes of the bml25 file are changed from 01 01 to 00 00.
The problem is that I don't know the salt that Samsung uses when hashing the sim unlock code, so I cannot do a brute force based decryption on the hash.
On the other hand, it is most likely the salt has a constant value for all Xcover phones. That is because the hash corresponding to the "00000000" value (see above) is also present in a simlocked phone, 4 times in a row, right after the NCK hash. In a neverlocked phone, it appears 5 times in a row (the extra occurence is actually the NCK hash). See the attached picture for more details.
Does anyone know what salt usually Samsung uses for their Galaxy models?
ANOTHER SOLUTION would be to find a way to write back the bml25/stl25 image file, after we modify the value of the first two bytes from 01 to 00 or after we change the NCK hash to a known-by-us value (such as the one stated above). The stl25 cannot be dumped (via dd command), I get this error message: /dev/block/stl25: cannot open for read: Invalid argument
Attachments
Last edited:
