Mobile Alerts Temperatur und Luftfeuchte Sensoren in Fhem

[alterma]

Hab doch mal schnell nen Blick reingeworfen.

Also: auf iOS ist 'devicetoken' = 'empty'. Aber: Wichtig scheint die richtige 'phoneid' zu sein, wie in der Original App angegeben. Früher war der Wert dafür uninteressant, d.h. man konnte ein x-beliebige Phone ID nehmen. Jetzt muss die 'echte' genommen werden. Warum das jetzt so ist, weiß ich nicht. Vorallem: woher weiß der Server, welche Phone ID die richtige ist? Vielleicht über den 'Requesttoken', der evtl. ein Hash der Phone ID ist...

Ansonsten habe ich die Anfrage genau wie in Wireshark angegeben 'kopiert': dann klappt's. Also noch keine globale Hash-Sicherung, wie ich vermutete.

Zu mehr komme ich heute aber nichtt - ich schau' morgen wieder rein.

[alterma]

OK, also:

'requesttoken' scheint ein Hash aus 'phoneid', 'timestamp', 'build' und eventuell anderen Werten zu sein. Also teilweise ist die Abfrage damit gesichert.

Es wird schwierig zu sein, den 'requesttoken' selbst zu generieren - ich vermute es ist unmöglich, da wir die Reihenfolge der gehashten Strings nicht kennen, ebensowenig wie einen eventuell hinzugefügten 'unbekannten' String.

Stefan

[costa2]

Ist der 'requesttoken' denn tatsächlich relevant?
Unter Fhem wird er ja auch irgendwie generiert, beziehungsweise gar nicht benötigt.
Ich werde das mal per Wireshark kontrollieren.

Edit:

Unter Fhem taucht der 'requesttoken' nirgendwo im Wireshark auf.
Demnach läuft es auch Ohne.

[alterma]

Hab' ein bißchen Zeit abgezweigt und mir das nochmal angeschaut. Ich habe ein Test-POST-Formular gebaut mit allen Werten, so wie durch Wireshark abgefangen. Festgestellt habe ich folgendes:

Die ganze Abfrage muss gehasht sein. Denn:

1.) lasse ich 'requesttoken' leer: Fehlermeldung vom Server
2.) Ändere ich auch nur einen der anderen übermittelten Werte leicht (außer 'measurementfroms', 'measurementcounts', 'deviceids'): Fehlermeldung vom Server

Ändere ich im Gegenzug den Wert in 'requesttoken', gibt es auch eine Fehlermeldung zurück.

technoline hat also die Datenabfrage per Hash gesichert. Hier werden alle POST Werte (wie auch immer) auf Seiten der App zusammengefügt, eventuell mit einem zusätzlichen (geheimen) String gehasht, und dieser Hash als 'requesttoken' mitübermittelt. Serverseitig wird dann das ganze überprüft. Stimmt der Hash nicht mit den übermittelten Werten überein, gibt es eine Fehlermeldung.

Das ist praktisch nicht zu umgehen, solange man nicht weiß, wie genau der Hash generiert wird. Schicht im Schacht also. 

Ich wußte, dass das früher oder später kommt. Nachdem alterma per Request-Header Check geblockt wurde, tauchte in einer neuen Version der offiziellen App der Wert 'requesttoken' und 'timestamp' auf, die ich zuvor nie beobachtet hatte. Mir war klar, dass da was im Busch und es nur eine Frage der Zeit ist, bis die Schalter umgelegt werden. Den Header-Block hatte ich nämlich mit alterma umgangen, alterma dann aber trotzdem nicht mehr veröffentlicht, weil ich ein Katz-Und-Maus-Spiel kommen sah...

Letzten Freitag (18.12.2015) hat man dann serverseitig scheinbar die Schalter umgelegt und die Hash Überprüfung aktiviert, nachdem wahrscheinlich die Großzahl der Nutzer die neueste version der offiziellen App installiert hatte.

Statische Abfragen funktionieren solange, wie man genau all die Post Werte, wie sie Wireshark abgefangen hat, für neue Anfragen nutzt. Ändert man aber einen Wert, muss man Wireshark neu bemühen um alle Post Werte und den passenden Hash zu bekommen.

Das soweit für heute von mir. Vielleicht findet jemand anderes noch etwas heraus...

LG,

Stefan

[alterma]

Habe noch ein paar Tests gemacht. Ich bin mir nun definitiv sicher, dass:

1.) Die Abfrage per MD5 Hash (oder einer vergleichbaren Prüfsumme) abgesichert wurde
2.) Zur Zeit 'deviceids', 'measurementfroms' und 'measurementcounts' nicht Teil der Prüfsummenberechnung sind

Das ist nicht zu knacken, solange man nicht an die App selbst herangeht um herauszufinden, wie genau die Prüfsumme berechnet wird. Ich denke, dass da auch noch ein unbekannter String eine Rolle spielt, denn einfach alle Werte aneinanderreihen und dann 'hashen': das wäre zu einfach und zu leicht zu brutforcen.

Also: iOS Apps zu reversen ist so gut wie unmöglich, so viel ich weiß. Wie das bei Android aussieht, weiß ich nicht. Vielleicht kennt sich da jemand mit aus hier ...

LG,

Stefan

P.S.: Wenn jemand einen Weg weiß, dann wäre eine Private Nachricht eventuell besser, als das hier zu posten...

[derBroBro]

Hallo,

ich habe mir die Sache heute Nacht angesehen und kann nun auch den Token generieren. Da ich allerdings leider erst danach die AGBs der Mobile Alerts App gelesen habe kann ich die Lösung leider nicht öffentlich nennen. Ich kann jedoch jedem empfehlen die AGBs mal zu lesen. Das ich echt unterhaltsam bzw. verstörend (Bspw. § 10.3).

Bisher habe ich die Daten in ein anderes System geschoben, welches saubere Graphen erstellt und man sich auch lange Zeitfenster ansehen kann. Da nun jedoch zum zweiten mal die API umgebaut bzw. so modifiziert wurde das man man Sie nicht 1:1 nutzen kann (bzw. dies nicht gewünscht ist) überlege ich gerade mögliche alternativen.

Wie es scheint, kann man in Gateway einen (eigenen) Proxy einstellen, auf welchen Daten auch die Daten gepostet werden. In ersten Tests hat dies auch gut geklappt. Der Server ist in NodeJS geschrieben und kann die meisten Daten lesen (Temperatur / Feuchte (MA10200 / MA10100 )).

Nach meinem Verständnis wäre dies auch rechtlich OK. Letztendlich würde im schlimmsten Fall die Garantie des Gateways verfallen.

Was haltet Ihr davon?

Gruß Malte

[costa2]

Hallo Malte.

Ich habe mir nun mal node.js unter Windows installiert um zu sehen wie das überhaupt grundsätzlich funktioniert, da ich noch gar keine Erfahrung damit habe.
Nun wäre es interessant wie solch ein Serverscript aussehen müsste.
Weiterhin habe ich erfahren, dass mein Server bei "Domainfactory" ebenfalls node.js ünterstützt.
Somit könnte ich die Ausgabe des Gateways auch dorthin umleiten.

Was die AGB der APP betrifft, wir wollen ja ein eigenes Tool entwickeln, also dürfte es keine Probleme geben.

Volker

[derBroBro]

Hallo Volker,

ich werde sehen, dass ich das Projekt die Tage auf GitHub lade und hier den Link poste.

Da mir im Protokoll noch nicht alle Parameter klar sind, wäre es dann super wenn wir zusammen versuchen, alle Sensorwerte nutzbar zu machen. Bspw. ergibt sich aktuell nur bei der Temperatur nur ein Wertbereich von 0.0°C bis 25,3°C. Was davor und danach kommt konnte ich noch nicht nachvollziehen. Ähnlich sieht es mit der Auslösung der Sensortypen aus. Erkennbar ist war was Temperatur und Feuchte ist, jedoch noch nicht um was für einen Sensor es sich handelt.
Das wird hoffentlich mit mehr Sensortypen besser.

Gruß Malte

[josburg]

Hallo, ich bin auch sehr an einer Lösung interessiert. Gerne kann ich beim Klären von Parametern versuchen zu unterstützen... Ich habe Zugriff auf Thermometer, Thermometer mit Luftfeuchtigkeitsmesser und Regensensor. Viele Grüße Jens


Gesendet von iPhone mit Tapatalk

[josburg]

Bspw. ergibt sich aktuell nur bei der Temperatur nur ein Wertbereich von 0.0°C bis 25,3°C.

Hallo Malte,

welche Probleme hast Du konkret bei dem Temperatur-Wertebereichen?
Bei mir wurden im FHEM einmal keine Minus-Temperaturen angezeigt, das lag an einer falschen Definition in FHEM.

Grüße
Jens

[derBroBro]

Hallo,

soweit ich es aktuell sehe wird der Temperatur Wert in einem Byte gespeichert und dann um eine Kommastelle verschoben. Sprich 0 -> 0.0 °C und 255 (max) -> 25.5°C. Ich gehe davor aus, da der Wert davor angibt ob hierbei etwas modifiziert wird (+/- X). Aufgrund der Zeit hatte ich keine Möglichkeit mal einen niedrigeren Wert zu erzeugen (Gefrierfach, was auch immer).

Das Projekt findet ihr in einer ersten Version hier: https://github.com/derBroBro/private-ma-server

Aus meiner Sicht sind die nächsten Punkte:
- Weiteres untersuchen des Protokolls
- Reduzierung auf einen Wert pro Sensor (Typ)
- Erstellen erste Schnittstelle für Datenspeicherung (Ich nutze thingspeak.com was haltet ihr für Sinnvoll?)

Gruß Malte

[josburg]

Hallo Malte,

bist Du schon weiter gekommen?

Viele Grüße
Jens

[derBroBro]

Hallo Jens,

ja. Temperaturdaten im positiven Bereich sollen nun gehen. Leider konnte ich es im negativen Bereich noch keine Tests durchführen da mit im Gefrierfach die Batterien Probleme machen. Ggf. habe ich jedoch Glück und wir bekommen hier im Süden bald minus Temperaturen.
Weiterhin habe ich die Anwendung so erweitert, dass ein Mittelwert ausgegeben wird und dieser entweder in das Dateisystem oder nach thingspeak.com exportiert werden kann. Die FS Ausgabe (JSON) enthält aktuell auch alle debug Daten.

Da ich damit für meine Zwecke fast alles habe wäre die Frage wie es denn die FHEM braucht? Wie stellt man hier die Daten am besten bereit?

Gruß Malte

[josburg]

Hallo Jens,

ja. Temperaturdaten im positiven Bereich sollen nun gehen. Leider konnte ich es im negativen Bereich noch keine Tests durchführen da mit im Gefrierfach die Batterien Probleme machen. Ggf. habe ich jedoch Glück und wir bekommen hier im Süden bald minus Temperaturen.
Weiterhin habe ich die Anwendung so erweitert, dass ein Mittelwert ausgegeben wird und dieser entweder in das Dateisystem oder nach thingspeak.com exportiert werden kann. Die FS Ausgabe (JSON) enthält aktuell auch alle debug Daten.

Da ich damit für meine Zwecke fast alles habe wäre die Frage wie es denn die FHEM braucht? Wie stellt man hier die Daten am besten bereit?

Gruß Malte

Hallo Malte,

vielen Dank für Deine Mühe.
In FHEM haben es die meisten User per HTTPMod - Modul eingebunden.
Also die Daten per HTTP-Request auf dem Cloud-Server der Mobile Alerts Anbieter abrufen.
Die zuletzt funktinierende URL war: http://23.97.212.128:8080/api/v1/dashboard jedoch ausschließlich per HTTP post und nicht get, daher funktioniert es per Eingabe im Browser generell nicht.

Meine Definition des Temperatur-Sensors in FHEM sieht wie folgt aus:

Code Auswählen Erweitern


define SENSOR_HUETTE HTTPMOD http://sensorcloud.cloudapp.net/api/v1/dashboard 600
attr SENSOR_HUETTE userattr event-on-change-reading icon reading01Name reading01Regex reading02Name reading02Regex requestData requestHeader1 stateFormat


attr SENSOR_HUETTE requestData devicetoken=MEIN-DEVICE_TOKEN-EINGEBEN&vendorid=MEINE-VENDOR_ID-EINGEBEN&version=1.17&build=41&executable=eu.mobile_alerts.mobilealerts&bundle=eu.mobile_alerts.mobilealerts&lang=de&timezoneoffset=120&timeampm=false&usecelsius=true&usemm=true&deviceids=MEINE-DEVICE_ID-EINGEBEN,]

attr SENSOR_HUETTE icon temp_outside

attr SENSOR_HUETTE reading01Name TEMP

attr SENSOR_HUETTE reading01Regex "t1": ([\-\d\.]+)

attr SENSOR_HUETTE reading02Name FEUCHTIGKEIT

attr SENSOR_HUETTE reading02Regex "h": (\d?\d.\d)

attr SENSOR_HUETTE requestHeader1 Content-Type: application/x-www-form-urlencoded

attr SENSOR_HUETTE room Temperatur und Luftfeuchtigkeit,all

attr SENSOR_HUETTE stateFormat {sprintf("%.1f Grad, Feuchtigkeit %.1f %", ReadingsVal($name,"TEMP",0), ReadingsVal($name,"FEUCHTIGKEIT",0))}



Vielleicht helfen diese Informationen weiter?

Viele Grüße
Jens

[josburg]

Hallo,

nachdem die Mobile Alerts Daten seit Dezember nicht mehr per HTTPMod abgefragt werden können, habe ich heute eine Bewertung zur Mobile Alerts App abgegeben.
Evtl. liest diese doch einer und die Hersteller überlegen sich doch nochmal ihre Strategie.
Ich fände es klasse, wenn die Hersteller nochmals in sich gehen und das System wieder für andere Anwendungen (z.B. FHEM) öffnen.

Evtl. möchte der ein oder andere einen ähnlichen Versuch vagen?

Diese Bewertung habe ich abgegeben:

Zunächst das positive: Die Sensoren sowie deren Einrichtung ist gut.
Die App ist alles andere als gut. Keine Grafiken, keine Auswertungen, bei den meisten keine Exportmöglichkeit.
Wem nicht nur die Daten von den Mobile Alerts Sensoren interessieren, sondern an "Heimautomation" denkt, ist m.M. nach seit Dezember mit diesem Systeme in einer Sackgasse. Seit Dezember 2015 kann nicht mehr durch andere Anwendungen (z.B. dem Heimautomationsserver "FHEM") auf die Daten der Sensoren zugegriffen werden. Wer möchte schon je Anbieter von Sensoren in unterschiedliche Apps wechseln?
Wenn sich das nicht wieder ändert ist dieses proprietäre System für mich demnächst gestorben. Hoffentlich kauft es mir noch jemand ab, wenn ich auf andere Sensoren umgestellt habe
An die Hersteller: vielleicht überdenken Sie Ihre Strategie und besuchen mit einer positiven Informationen das FHEM Forum...?
Das wäre klasse, die Sensoren sind an sich wirklich klasse.