bytespider / Meross

Investigating the Meross/Refoss MSS310 Smart Plug and getting these devices to communicate with our private MQTT brokers
113 stars 19 forks source link

Support encrypted wifi password on Appliance.Config.WifiX namespace #60

Closed DominikGebhart closed 1 year ago

DominikGebhart commented 1 year ago

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[bot] commented 1 year ago

⚠️ 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 | | | -------------- | ------------------------- | ---------------- | --------------- | -------------------- | | [-](https://dashboard.gitguardian.com/incidents/secrets) | Generic Password | 0cc23001c586669e6d2472ee847feafa8321be78 | lib/api.js | [View secret](https://github.com/bytespider/Meross/commit/0cc23001c586669e6d2472ee847feafa8321be78#diff-9ccb9b0bdd7e6cd41dfc6512731c2719L355) |
🛠 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](https://blog.gitguardian.com/secrets-api-management?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) the best practices. 3. Revoke and [rotate this secret](https://docs.gitguardian.com/secrets-detection/detectors/generics/generic_password#revoke-the-secret?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment). 4. If possible, [rewrite git history](https://blog.gitguardian.com/rewriting-git-history-cheatsheet?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment). 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](https://blog.gitguardian.com/secrets-api-management/?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) for managing and storing secrets including API keys and other credentials - install [secret detection on pre-commit](https://https://docs.gitguardian.com/ggshield-docs/integrations/git-hooks/pre-commit?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) to catch secret before it leaves your machine and ease remediation.

🦉 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!

DominikGebhart commented 1 year ago

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

RaoulSargent commented 1 year ago

@DominikGebhart Thank you for pointing me at this PR.

RaoulSargent commented 1 year ago

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 commented 1 year ago

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 image

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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.