Support encrypted wifi password on Appliance.Config.WifiX namespace

[DominikGebhart]

Support for Wifi configuration on the Appliance.Config.WifiX namespace which needs an encrypted password.

Adds --use-wifi-x commandline argument.

Once more thoroughly testet, we might think about using the Appliance.Config.WifiX way per default to make it harder to snoop the actual wifi password by someone listening in on that unsecured access point dataframes.

Successfully tested on a mss310eu plug version 6, firmware version 6.1.12

hardware: {
          type: 'mss310',
          subType: 'un',
          version: '6.0.0',
          chipType: 'rtl8710cf',
          uuid: 'XXXXXXXXXXXXXXXXXXXXXXXXXXX',
          macAddress: 'XX:XX:XX:XX:XX'
        },
        firmware: {
          version: '6.1.12',
          compileTime: '2022/05/26-15:39:26',
          encrypt: 1,
          wifiMac: '',
          innerIp: '10.10.10.1',
          server: 'X.X.X.X',
          port: 8883,
          userId: 0
        }

Feedback or pull appreciated

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	Secret	Commit	Filename
-	Generic Password	0cc2300	lib/api.js	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

<sup>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sup>

[DominikGebhart]

The detected secret is the AES256 initialization vector (iv), which is hardcoded to a fixed value by meross.

[RaoulSargent]

@DominikGebhart Thank you for pointing me at this PR.

[RaoulSargent]

SUCCESS - THANK YOU :-)

MSS310 Hardware v6 Firmware 6.3.6 WORKED
MSS310 Hardware v6 Firmware 6.1.12 WORKED (sign errors, see below)

MSS310 Hardware v6 Firmware 6.3.6
2x Devices connected to local MQTT Broker and happily updating in HomeAssistant with Meross Lan local integration.

MSS310 Hardware v6 Firmware 6.1.12
1x Device connected to local MQTT Broker and happily updating in HomeAssistant with Meross Lan local integration.
(I have another 5x devices on 6.1.12 to be configured shortly)

However, for the Firmware 6.1.12 device I am seeing these "SIGN ERROR" messages in MQTT at every update interval:

Examples:

{"header":{"messageId":"15419275f57bebee8720af506f2b5438","namespace":"Appliance.Control.Bind","method":"ERROR","payloadVersion":1,"from":"/appliance/OBFUSCATED/publish","uuid":"OBFUSCATED","timestamp":1676972478,"timestampMs":366,"sign":"efa361abcOBFUSCATED2b0e0cf"},"payload":{"error":{"code":5001,"detail":"sign error"}}}

{"header":{"messageId":"4eb42fb6c584409aa9c6eaf78af9d334","namespace":"Appliance.Control.Electricity","method":"ERROR","payloadVersion":1,"from":"/appliance/OBFUSCATED/publish","uuid":"OBFUSCATED","timestamp":1676972663,"timestampMs":888,"sign":"ebbOBFUSCATEDcdbf605f"},"payload":{"error":{"code":5001,"detail":"sign error"}}}

{"header":{"messageId":"2d088ea94d7b4ce89cd33a3f000721d8","namespace":"Appliance.Control.ConsumptionX","method":"ERROR","payloadVersion":1,"from":"/appliance/OBFUSCATED/publish","uuid":"OBFUSCATED","timestamp":1676972635,"timestampMs":434,"sign":"4ca46OBFUSCATEDfb66d"},"payload":{"error":{"code":5001,"detail":"sign error"}}}

[DominikGebhart]

I think the sign issue is separate from this PR since this PR only adds the code to join Wifi networks via the new wifiX path. It might have to do with the sign key set in the meross lan integration. Make sure it is completely empty

When i was trying to debug something i once set it to "0" and added devices, they never showed up until i set it to empty again. I think i also read an error like those you mentioned in some logs.

[wsw70]

@bytespider would you mind considering merging the pull? It works great and is (at least for me) the solution for 4.x 3.3.x Meross firmware

@DominikGebhart thank you very much for this addition!

[bytespider]

@wsw70 thanks for reminding me about this. I'm unable to test this as all my devices are FW v2 and v4.

@DominikGebhart do we know which versions work with the new command? It might be worth documenting it somewhere like the command help.

[DominikGebhart]

@DominikGebhart do we know which versions work with the new command? It might be worth documenting it somewhere like the command help.

No, i don't have a list. I assume it's all newish firmware versions.

[wsw70]

do we know which versions work with the new command?

I have a device with 3.1.5 that I paired with a previous version. This did not work for another device I upgraded to 3.2.2, but worked with @DominikGebhart PR.

This is one data point and it was about 2 years that I did not pair anything so I may be wrong. One thing is for sure: using --use-wifi-x works fine.