Hi, I’m very interested to hear more about this. Is there already an update for the implementation?
And how can I determine/extract the client-id and client-secret from the Adnroid Api? I didn’t quite understand that.
Thanks
Martin
1 Like
I was reading through the de-obfuscated code using jadx but I think it’s easier to just sniff the communication using mitmproxy. Since the client_id and client_secret are sent in plain-text it’s possible to extract. Unfortunately Velux has certificate pinning enabled which means sniffing the traffic requires patching the APP.
Steps required for patching the Android APK:
- Get the APK (either download it form some shady websites or use some apk share/backup app)
- Get apktool
- unpack with
apktool d com.velux.active_1.5.0.7-all-arm64-v8a.apk - Remove certificate pinning from
com.velux.active_1.5.0.7-all-arm64-v8a/res/xml/network_security_config.xml- remove
pin-set - add instead
<trust-anchors><certificates src="system" /><certificates src="user" /></trust-anchors>
- remove
- Build the apk again with
apktool b -o /tmp/test.apk com.velux.active_1.5.0.7-all-arm64-v8a - Sign the apk with a developer key:
apksigner sign -ks ~/android.jks --in /tmp/test.apk --out /tmp/com.velux.active_1.5.0.7-all-arm64-v8a_signed.apk - install the APK
adb install /tmp/com.velux.active_1.5.0.7-all-arm64-v8a_signed.apk
Now the network sniffing part:
- start mitmproxy on your laptop (for example on ip 192.168.1.10)
- Install the mitmproxy certificate in android as user certificate (you can find it in
~/.mitmproxy) - set android proxy ip to your laptop:
adb shell settings put global http_proxy 192.168.1.10:8080
You should see network traffic coming through the mitmproxy and you can see the oauth token exchange when you open the velux app and all other API calls.
In case you have blinds and windows I would be interested how the API looks like. I would be very happy if you have any mitmproxy traces for me! (double check if they contain any private data before sending! I will not publish any traces but you can’t trust strangers).
Once you’re done delete the proxy settings, restart your phone double check there are no new calls in mitmproxy and stop the proxy. Uninstall the patched velux app and reinstall from the play store.
You can delete proxy settings using:
$ adb shell settings delete global http_proxy 192.168.1.10:8080
$ adb shell settings delete global global_http_proxy_host
$ adb shell settings delete global global_http_proxy_port
I can understand this all looks incredible complicated but I was surprised to be easier than expected. Nevertheless I hope there will be a easier way eventually.
1 Like
@nougad: I just got my Velux window rollershutter installed and have a KIX 300 now. You mentioned earlier you want to have something done for openhab using the exec binding. Do you have something done already?
Thanks so far for the effort you spend on this!
Sorry for the month of silence. I was finally able to put everything together and publish a early state on github: https://github.com/nougad/velux-cli
It contains the API documentation and a go client. I documented the openHab integration using exec binding here: https://github.com/nougad/velux-cli/blob/master/openhab.md
I still haven’t published the ClientID and ClientSecret from the Velux App. You still require extracting this yourself. I know, that’s not a awesome experience but I don’t want to publish private keys.
For the same reason I’m not working on a openHab binding at the moment.
Contributions welcome.
Thanks will check it out as soon as I find time. Regarding the keys … the question is how private is private if it is part of every application installed on customers devices 
yes, that’s correct the keys are kind of public by including it into a obfuscated Android app. It’s not on me to define “private” Feel free to publish the keys but I will not take the risk
@nougad
How you solve the issue with the Gateway pairing at the first login.
How you get the sign_key_id to open a window?
Hey @tombox. I don’t fully understand what you mean with sign_key_id and opening a window. My code works by getting the oAuth2 keys and directly talking with the Velux backend.
Ok this means you never open a Velux window with your code.
@tombox Ah, now I understand. I only own Velux roller shutter which don’t require a sign_key_id. Right now the code does not support windows since I can’t try it. It would require someone with a window to captures the network traffic and either create a pull request to the swagger definition or to provide me the wire dump of the network traffic.
Unfortunately there is only encrypted communication between the gateway and the phone nothing capturable via https
@tombox that’s correct. I described above how you can remove the certificate pinning and route the network traffic through a mitm proxy. It’s a bit tricky to setup but I think the only way to get the necessary data.
This is not the issue because the the is no traffic via https is looks like a direct connection between gateway and phone. The Gateway sends a broadcast and the app on the receive the package and generate a hash. This hash will be send to the gateway with a hashed target position. But the decompiled hash algorithm are hard to reproduce.
@nougad:
Finally found the time to go through your howTo and got everything working. Great Kudos!
Is it ok for you if I cut you a PR with some improvement ideas?
Sure, all contributions are welcome. Right now the velux-cli is just an example for accessing the Velux CLI and it works pretty well for me in combination with OpenHab.
Hello there,
I am very interested in this topic, as I was really unhappy that velux-active is such a closed system without any public api. I currently have 8 windows, 2 blackout blinds and 6 sun screens/awning blinds running. As someone said before, the system works perfectly, but the automation features are poor and I want to log the sensor data in openhab.
I tried @nougad’s manual for retrieving the client_id and client_secret - but I’m stuck. I should add that I have no experience with java or android develepement. Maybe someone could give me a hint? 
Current status:
- I decompiled the app, changed the xml file (2 occurences), built it again
- signed it with a developer key (using apk signer)
- installed the apk on an android device
- changed the proxy settings, but via android ui, not with adb
- i get http requests of the browser on the android device in mitmproxy ->should work?
the app starts, but fails to connect to netatmo-server at login (brief error message at the bottom of the screen).
UPDATE: right after posting this I found my error (it always works…) – I didn’t install the mitm-certs. It works now!
I will test @nougad’s velux-cli in the next few days.
1 Like
Many thanks @nougad for all your reverse engineering! Out of curiosity: Are the KIX 300 APIs the same as the ones of the KLF 200?
A link to the fully documented KLF 200 APIs can be found in the docs of the Velux binding. On that note: Based on my understanding of the API docs, KLF 200 supports more than 5 devices (up to 200 if I get it right).
I could imagine that Velux is using parts of the KLF 200 code base for the KIX 300 (this would mean that the existing integration could be amended without too much effort). And given that Velux documented the KLF 200 APIs I could further imagine that they would eventually do the same thing for the KIX 300.
I will certainly follow this discussion with high interest! I just installed a Somfy Connexoon to control my two Velux roller shutters (the rest of my apartment is KNX), just to find out that things are controlled through the Somfy cloud (which I don’t really like). Setting the Connexoon up with my OpenHAB Raspberry worked like a charm, but I will eventually replace it with a solution with more privacy.
Hey @peter.janes. As far as I know the KIX300 API has nothing to do with the KLF 200 API. The KLF 200 API is a local wire protocol with the hub while the KIX 300 API ist talking with an Cloud-based endpoint. THE KIX 300 API has some overlap with the netatmo API. Therefore the marketing name VELUX ACTIVE with NETAMO - which I personally find quiet a stretch since the the only overlap between the two products is some common terms in an undocumented API. In addition the KIX 300 supports homekit which I personally haven’t tried.
Thanks for your quick feedback @nougad!
In another forum article (#11) I read that Velux Active can be operated without the Velux cloud (only HomeKit local) - so I would assume there must be locally available APIs, at least for HomeKit.
Did you compare your reverse engineered APIs with the KLF 200 documentation?
Yes, as I mentioned the KIX 300 has HomeKit support which I didn’t tried. Above Connecting Velux Active KIX 300 mentioned HomeKit simulators/bridges which probably work completely local.
The API I use is the cloud-based-Netatmo-like-API which is also used in the Velux APP.
And then again there is the KLF200 which has absolutely nothing to do with the KLX 200 (neither netatmo cloud nor homekit API)