unicode decode error - v09e - Encrypted messages from juicebox

[wozz]

I updated to the newest release and I'm getting:

2024-06-04 21:34:32  ERROR     [__main__] A JuicePass Proxy task failed: UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 33: invalid start byte

With debug logging on, I see this as the last logged line: https://github.com/snicker/juicepassproxy/blob/master/juicebox_mqtthandler.py#L500, and the first non-ascii byte is \x8b

[wozz]

I suspect that my device may have updated and now it's using a new protocol, possibly encrypted. the format appears to be <device id>:v09e<binary>

I haven't been logging all the packets previously, but it was working previously and I saw others with a format like <device id>:v09u:<plaintext>

[jeffml42]

Yes. My older device started doing the same thing yesterday but the newer one is still ok. I won't be able to give debug or anything until tomorrow evening but at least your report helped with my sanity.

[jeffml42]

By blocking traffic out to Enel X and rebooting, I was able to have it stay at v07 instead of getting updated to v08 (which is what it looks like my older unit changed to yesterday). I have both EXPERIMENTAL and IGNORE_ENELX enabled but unsure how they play into it. Will try to get more info later.

[wozz]

I was able to get my system back into the mode where it's sending v09u messages - I rebooted several times, but not sure what may have finally triggered it back to that mode.

I also did some debugging of the "encrypted" messages and it seems unlikely to me that it couldn't be decoded with some effort. The data doesn't look completely random to me, so probably just xor'd with a key known to both sides or something like that.

[Snuffy2]

Can you provide a few example strings you are now getting?

[wozz]

It's not doing it anymore - but here's one of the packets I captured:

        0x0000:  4500 00dc 1a9e 0000 8011 99fc ac11 16b6  E...............
        0x0010:  ac11 169e 1656 1f6a 00c8 0000 3039 3130  .....V.j....0910
        0x0020:  3034 3230 3031 3238 3036 3630 3432 3733  0420012806604273
        0x0030:  3233 3632 3035 3335 3a76 3039 6512 b10a  23620535:v09e...
        0x0040:  0000 0071 6b14 9327 0404 a809 cbcb b799  ...qk..'........
        0x0050:  5fd8 6b39 1e4b 5e60 6fd5 153a 81ec d625  _.k9.K^`o..:...%
        0x0060:  1eb2 bf87 da82 db9c eaef b268 caa8 f0c0  ...........h....
        0x0070:  1b53 8af4 8e45 d1ef 3ad2 8ca7 2a4f df05  .S...E..:...*O..
        0x0080:  2617 80fd 753b 3619 0636 8634 821b f6ca  &...u;6..6.4....
        0x0090:  da56 24ba e11f eb7d c975 cfe1 4e2c 305e  .V$....}.u..N,0^
        0x00a0:  b01a dcc7 b396 87dd c130 d66c c39b c2cc  .........0.l....
        0x00b0:  ac7f 903c b9b5 0adb 9a77 b95b 77bd 364b  ...<.....w.[w.6K
        0x00c0:  82dc be85 99dc 9a8a 880c c44e b0f0 4e8a  ...........N..N.
        0x00d0:  1d9f 4a63 0597 8a7f 3e3c 58d5            ..Jc....><X.

I was hesitant to share, since this leaks my unique id - but I guess there isn't any harm in it

I also have hex values from two separate packets after the v09e part:

12b10a000000716b1493270404a809cbcbb7995fd86b391e4b5e606fd5153a81ecd6251eb2bf87da82db9ceaefb268caa8f0c01b538af48e45d1ef3ad28ca72a4fdf05261780fd753b361906368634821bf6cada5624bae11feb7dc975cfe14e2c305eb01adcc7b39687ddc130d66cc39bc2ccac7f903cb9b50adb9a77b95b77bd364b82dcbe8599dc9a8a880cc44eb0f04e8a1d9f4a6305978a7f3e3c58d5

12b10a00000073480d38833df8ebed8add322332c5c9f0501b32e9b35b71d1d8d3e389f5b9002b42ee953b5d9f712ddd36ebcb9f0a8973eba739f388583429d3fcd4cd135f9e4d437ad6ad21c11ad8e89369252ada194b52436beeb67a15b4a24f85eae07ebeeb6270588c94e390fa6da00c831e290a8552bd49ce014db1aa70843ebb5db2b0dea0fa20d0ed00714ae3001c895bf54779d5d1449ee15bf486

They both start with a common prefix, and there are some common bytes throughout.

[ivanfmartinez]

I was able to get my system back into the mode where it's sending v09u messages - I rebooted several times, but not sure what may have finally triggered it back to that mode.

As it returned just with reboots I suppose the firmware can send in both formats and depending of server response it will change the format.

[wozz]

That does seem likely, however if that's the case, it would be good to know more about which message does that so it could be blocked.

One thing I did change is that originally I was using juicenet-udp-prod5-usa.enelx.com as the target host and intercepting DNS for that. During my testing though, I also noticed juicenet-udp-prod3-usa.enelx.com being used, so I added that to my domain intercept list, and then rebooted and I think that's when it came back to the v09u messages.

I'm assuming the v09u means v9 unencrypted and v09e means v9 encrypted. Which would imply the version didn't actually change.

[jeffml42]

Removed the firewall blocks and rebooted again and I'm staying on v07 but ... I noticed something new. My older unit (haven't checked the newer one) is now reaching out and getting what look like normal certs and what might be two new URLs:

https://juicenet-prod3-usa.enelx.com/v2/unit/[ MY ID ]/data

https://juicenet-prod3-usa.enelx.com/v1/unit/[ MY ID ]/keys

the key one returned a 64 hex character key and an expiration date of 2025-06-04T12:43:10.079Z which looks to be pretty close to one year from when things changed yesterday (edit: yes, exactly the date/time). Maybe they turned on some testing a bit early?

[ivanfmartinez]

to keep for reference, this URL on directory service that have an encrypted element that changes the juicebox to encrypted protocol mode

https://directory-api.emotorwerks.com/v1/profiles/juicebox/DEVICE_ID/

sample response available on wiki : https://github.com/JuiceRescue/JuiceboxRescueWiki/wiki/Directory-API