gree.py - "The length of the provided data is not a multiple of the block length" exception on initial search

[marius-nicolae]

Hi,
First, thanks for your great initiative!

When using gree.py to discover my Gree devices (the search command) it first successfully decrypt my Cooper & Hunder's returned pack JSON field. Still, then it returns The length of the provided data is not a multiple of the block length exception while attempting to decrypt the pack field returned by the second Gree Soyal device (might be a newer model!!). I've tried to apply padding, using Python's PKCS7(128).padder(), it doesn't crash anymore but the decrypted data seems garbage and not a valid JSON.

Are the new Gree models make use of other generic keys? Can you, please provide some guidance, on how to investigate further?

Thanks!

[tomikaa87]

@marius-nicolae please try the script with --verbose and paste its output here.

python3 gree.py --verbose -b <broadcast address> search

[marius-nicolae]

As I wrote in the other issue ( #48 (comment) ) the --verbose flag doesn't add much of a detail:

python3 ./gree.py search --broadcast 10.0.5.255 --verbose
Searching for devices using broadcast address: 10.0.5.255
Traceback (most recent call last):
  File "./gree.py", line 245, in <module>
    search_devices()
  File "./gree.py", line 109, in search_devices
    pack = json.loads(decrypt_generic(resp['pack']))
  File "./gree.py", line 73, in decrypt_generic
    return decrypt(pack_encoded, GENERIC_KEY)
  File "./gree.py", line 66, in decrypt
    pack_decrypted = decryptor.update(pack_decoded) + decryptor.finalize()
  File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/base.py", line 159, in finalize
    data = self._ctx.finalize()
  File "/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/ciphers.py", line 178, in finalize
    raise ValueError(
ValueError: The length of the provided data is not a multiple of the block length.

[tomikaa87]

@marius-nicolae I've updated the script to print more details before trying to decrypt the response. Please run the verbose search command again and paste the whole output here. It should print the raw response packet now.

[marius-nicolae]

Indeed, I was running an older version. Here is the new output:

python3 ./gree.py search --broadcast 10.0.5.255 --verbose
Searching for devices using broadcast address: 10.0.5.255
search_devices: data=b'{"t":"pack","i":1,"uid":0,"cid":"502cc697d12f","tcid":"","tag":"UO+i92tMrddr39Az5C/S7w==","pack":"JtoKliwtrZWlpNCVOSARFZVjvdMQgUTwOVMwDOiNhOTTdG5N10OhtRdqKHNblRpBHGBvzVlwLvpUoMiLLqrWjKOY3wm/f0Jpc5AgXOKjc9kcuKHBT9Com8Xm5Ml/trwJCr+4qnpNA+LDG3HzzAut6DajQD0Unesye5fOVuITjYRj/S48EhXvMPf+uFR7BOq8wq3jRUvZweGu4Xuu19I3Y3C7wX1l3Q+V4pXFeTxudKE6Tqj62cJ3P6Mpx+gX8F0RFP+PoO155Efh8BcvfyRatHw="}\n', raw_json=b'{"t":"pack","i":1,"uid":0,"cid":"502cc697d12f","tcid":"","tag":"UO+i92tMrddr39Az5C/S7w==","pack":"JtoKliwtrZWlpNCVOSARFZVjvdMQgUTwOVMwDOiNhOTTdG5N10OhtRdqKHNblRpBHGBvzVlwLvpUoMiLLqrWjKOY3wm/f0Jpc5AgXOKjc9kcuKHBT9Com8Xm5Ml/trwJCr+4qnpNA+LDG3HzzAut6DajQD0Unesye5fOVuITjYRj/S48EhXvMPf+uFR7BOq8wq3jRUvZweGu4Xuu19I3Y3C7wX1l3Q+V4pXFeTxudKE6Tqj62cJ3P6Mpx+gX8F0RFP+PoO155Efh8BcvfyRatHw="}'
Traceback (most recent call last):
  File "./gree.py", line 245, in <module>
    search_devices()
  File "./gree.py", line 109, in search_devices
    pack = json.loads(decrypt_generic(resp['pack']))
  File "./gree.py", line 68, in decrypt_generic
    return decrypt(pack_encoded, GENERIC_KEY)
  File "./gree.py", line 62, in decrypt
    pack_decrypted = decryptor.update(pack_decoded) + decryptor.finalize()
  File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/base.py", line 159, in finalize
    data = self._ctx.finalize()
  File "/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/ciphers.py", line 178, in finalize
    raise ValueError(
ValueError: The length of the provided data is not a multiple of the block length.

[bwibwi13]

Hello,
I face the same issue with a newly installed model.
Is there anything I can do to help progress on this problem?
Thanks a lot for this great repo ;)

[tomikaa87]

Unfortunately, I've disassembled the latest version of the Android app but didn't manage to find out if there is a new encryption key for these new units. There is a libGree.so library which I've tried to dissect with Ghidra, but it only finds a huge number of randomly named functions without any instructions in them, which doesn't seem to be right. Last time I've found the generic encryption key in the same library. If you have the time, you could try to disassemble the app.

[tg44]

I tried doing this, my thought process was; I should find the old key somewhere for backward compatibility, if I found it, I will find the new key somewhere around. This was the first time I used disassemblers. I had no success with the latest version.

I found the already known key in an 1.7 version. As I understand this list they did some drastic changes in 1.8.0, going further they consolidated the imports (number of so-s in the lib dir) too, but the disassembled code looks kinda the same in 1.8 and 1.11 (lot of function with strange names).

The TOSOT+ seems as a rebranded GREE+ after a disassembly.

I also tried the invmateii app, but as I understand the code that interest us is probably in the java/kotlin land. (I found it mentioned in an other issue.) I'm almost sure that this app is a rebrand of the midea app. And after checking their site I'm not convinced that they do anything with Gree.

Do we have firmwares available for decompile too?

[tomikaa87]

After a few months of pause, I took down the project from the shelf and tried to approach the problem from a different angle. Instead of trying to disassemble the Android app, I'm dissecting the iOS version. Since the GREE+ app can be installed on an M1 MacBook from the AppStore, I can access the internals of the app. I've started looking into the main executable with Ghidra and found a few different encryption and decryption methods.

One of them looks like this (decompiled Swift/Objective-C code, the function and variable names are added by me by analyzing the calls and contexts, so they can be inaccurate):

  dataObject = 0;
  __stubs::_objc_storeStrong(&dataObject,dataParam);
  local_88 = param_5;
  key = msgSend_class(local_68,dataToDecrypt);
  cancelPreviousPerformRequestsWithTarget(key,dataToDecrypt,local_68);
  __stubs::_NSLog(&::cf_=);
  key = dataObject;
  if (*(int *)(local_68 + 0x10) == 1) {
    length = getLength(dataObject,dataToDecrypt);
    length = length + -0x27;
    local_58 = 0x27;
    local_50 = 0x27;
    local_a0 = 0x27;
    local_60 = length;
    local_48 = length;
    subdataWithRange(key,dataToDecrypt,0x27,length);
    key = __stubs::_objc_retainAutoreleasedReturnValue();
    local_90 = key;
    stringWithFormat(&_OBJC_CLASS_$_NSString,dataToDecrypt,&cf_%s);
    uVar1 = __stubs::_objc_retainAutoreleasedReturnValue();
    AES128DecryptData:WithKey(&objc::class_t::SecurityUtil,dataToDecrypt,key);
    local_a8 = __stubs::_objc_retainAutoreleasedReturnValue();
    __stubs::_objc_release(uVar1);
    ::socket(local_68,dataToDecrypt);

I've tried to translate this to a python code and feed the data pack @marius-nicolae found:

def decrypt_aes128ecb(data, key):
    decryptor = Cipher(algorithms.AES(key), modes.ECB(), backend=default_backend()).decryptor()
    decrypted = decryptor.update(data) + decryptor.finalize()
    return decrypted

tag = 'UO+i92tMrddr39Az5C/S7w=='
pack = 'JtoKliwtrZWlpNCVOSARFZVjvdMQgUTwOVMwDOiNhOTTdG5N10OhtRdqKHNblRpBHGBvzVlwLvpUoMiLLqrWjKOY3wm' \
       '/f0Jpc5AgXOKjc9kcuKHBT9Com8Xm5Ml/trwJCr+4qnpNA+LDG3HzzAut6DajQD0Unesye5fOVuITjYRj/S48EhXvMPf' \
       '+uFR7BOq8wq3jRUvZweGu4Xuu19I3Y3C7wX1l3Q+V4pXFeTxudKE6Tqj62cJ3P6Mpx+gX8F0RFP+PoO155Efh8BcvfyRatHw='

dpack = base64.b64decode(pack)
print('dpack', dpack.hex(','), len(dpack))
data = dpack[0x27:]
print('data', data.hex(','), len(data))
key = dpack[:16]
print('key', key.hex(','), len(key))
clear = decrypt_aes128ecb(data[:16], key)
print('clear', clear, len(clear))

Unfortunately I only got garbage as output, so something is not right. But the fact that these new packs can't be decrypted due to alignment issues proves that they attach some kind of extra data to the encrypted blocks and that extra info can be the decryption key for the scan response.

I've also found a few new master keys in the code:

a3K8Bx%2r8Y7GREE

// This was found in the context of "Gree Business" devices
WQNMLGBDGREECTMD

// These were obfuscated in the code and seem like used by Qualcomm devices
gvhL/#)^4s9t*255
{yxAHAY_Lm6pbC/<

In addition I've found out that devices which have tag in their reponses use a seemingly complicated method to decrypt the data. According to the code, these are some kind of Qualcomm-based devices (the string "$bMqualcomm-test_101108551" in one of the functions makes me think that).

I can share the Ghidra disassembly project if someone wants to experiment.

[tomikaa87]

@tg44 The pack you've posted on the other issue seem to be decryptable with the generic key using the old method:

Any progress on this? I have the same issue, I can send the broadcast, get a response, but the
pack: 'LP24Ek0OaYogxs3iQLjL4BZGC1L9UK8LWYY9r9h4dgWMa9lM2RqI/KytvJ32IsGSZXrOr+MakVzzXHbghPeyijnWMzaLQaaw1aFXlE9k71L0cMm8bsr/y4FkxumpRg1t0xV8+/m47OTBNaX/8aUl1ZJhYuNQNgXxv5Sro8mBB9BzMQoS41XpnORSG7+GfavhnKYbt0iIDsdp8/ftXlA9Hi9SYH2dzE8EeLZzuqwrQT280gq9HxK8Loa8WXVjgZcP4Vf5MjKxa60Xt5J1oI+lsxUuXTHkgunLg76WWGy+euo='
has "invalid key len"

b'{"t":"dev","cid":"502cc65816e6","bc":"000000000000000000000000000000","brand":"gree","catalog":"gree","mac":"502cc65816e6","mid":"10001","model":"gree","name":"c65816e6","series":"gree","vender":"1","ver":"V1.2.1","lock":0}\x01'