Eigene ETS Produktdatenbanken erzeugen

[jolt]

Tja was soll ich sagen, die Sicherheit liegt wohl in der Komplexität des Ganzen und nicht unbedingt im Sicherheitskonzept

Für Projektdateien gibt es übrigens einen Mechanismus bei dem alles korrekt implementiert ist. Hier können Hersteller ihren Public Key über neue knx_master.xml Files auf den Kundenrechner bringen. Sogar einen Weg einen geleakten Key zu revoken gibt es. Es stellt sich allerdings die Frage welchen Sinn das bei Projektdateien macht. Weil die wird man immer beim Kunden speichern müssen. Also muss dort auch ein Private Key vorhanden sein...

So richtig fixen kann man das Problem eigentlich nicht wenn man den Import von alten ProductDBs nicht abschaltet. Könnten sie eigentlich machen, denn normalerweise müsste jede DB ja wegen der Zertifizierung bei denen vorliegen. Die müssten dann alle konvertiert, signiert und immer _alle_ mitgeliefert werden.

Naja nicht unser Problem, zumal ich glaube, dass die auch nicht Fort Knox bauen wollen, sondern primär einen stabilen Betrieb sicherstellen wollen. Ob dafür natürlich der ultra komplexe Technologie Stack die richtige Entscheidung war...

[tuxedo]

Naja nicht unser Problem, zumal ich glaube, dass die auch nicht Fort Knox bauen wollen, sondern primär einen stabilen Betrieb sicherstellen wollen. Ob dafür natürlich der ultra komplexe Technologie Stack die richtige Entscheidung war...

Die hätten ja vermutlich nur das konvertieren der alten VD-Files in .knxprod-Files nicht implementieren müssen. Damit wäre die Signierung der Produktdatenbanken innerhalb der ETS nicht notwendig gewesen (oder hab ich etwas übersehen?).

[tuxedo]

Ist jetzt auf Github:

https://github.com/KNX-on-Arduino/SignKnxProd

Hab die Anleitung dazu als readme dazu gepackt und noch ins englische übersetzt, plus das ganze noch um eine Warnung bzgl. der eventuellen Lizenzverletzung KNX/ETS versehen.

[jolt]

Der Import von alten Projekten wird dann komplizierter, da du dann nicht mehr die Devices importieren kannst, sondern erst auf eine neue (hoffentlich) vorhandene ProductDB matchen musst. Wenn der User also nicht für alle seine Produkte passende DB's hat, bekommt er seine alten Projekte nicht importiert.

Security geht leider oft (immer?) zu Lasten des Users. Ich werde dank des Dongels z.B. nie auf ETS5 updaten. Aber das soll hier nicht unser Thema sein

[jolt]

Super, vielen Dank! Ich bastel gerade an einem XML -> ProductDB Builder. Ein Python Script um die ganzen Einträge zu verstehen und halbwegs automatisch zu erzeugen. Könnt ihr dann als Vorlage für eine Integration in Konfig Apps nehmen. Ich würde das Repository forken und das Tool dort einchecken. Pull Request sobald es nutzbar ist. Passt?

[tuxedo]

Ich würde das Repository forken und das Tool dort einchecken. Pull Request sobald es nutzbar ist. Passt?

Jepp.

[l0wside]

Ich bitte um Verständnis, dass ich mich in Anbetracht der zweifelhaften rechtlichen Lage nicht zum Signieren der XML-Dateien äußern werde.

Dafür gibt es einige weitere Erkenntnisse zur Struktur der XML-Dateien. Sinnvoll ist es sicher, eine bestehende zu nehmen und anzupassen. Erkenntnisse sind potenziell etwas unstrukturiert.
Die Konnex hat einen Gutteil übrigens selbst aufgeschrieben: http://www.knx.org/fileadmin/support...escription.pdf - Projekt- und Produkt-Dateien unterscheiden sich jetzt nicht soooo tiefgreifend.

• (Fast) jedes Element hat eine Id. Wenn ein anderes Element darauf verweist, heißt das zugehörige Tag (meistens) RefId.
• Am Ende jeder Datei stehen in einem Abschnitt <Languages> die Übersetzungen, die per RefId darauf verweisen, wo sie hingehören.
• Im Hauptverzeichnis stehen nur knx-master.xml, die .signature und ein Unterverzeichnis, dessen Namen (M-xxxx) sich aus der Manufacturer ID ableitet.
• In knx-master.xml stehen die Manufacturer IDs, einmal dezimal (wie hier), einmal in Hex mit Präfix M-, z.B. M-0139 = 313 = Feel s.r.l
• Die Manufacturer Ref Id (M-xxxx) ist das Präfix für alle internen IDs.
• In Hardware.xml sind drei wichtige Elemente:
  • Die Namen von Hardware und Produkt (das sind aus Sicht der ETS wohl zwei verschiedene Dinge)
  • Die IDs von Hardware und Produkt. Die Hardware heißt M-xxxx_H-yyyy, das Produkt dann daraus abgeleitet M-xxxx_H-yyyy_P-zzzz
  • Die ID der Applikation (einen Namen scheint sie nicht zu haben) im Format M-xxx_Hyyyy_Azzzz, begleitet von einer Hardware2Program Id im Format M-xxx_Hyyyy_HPzzzz

Die diversen IDs-Elemente (xxxx, yyyy, zzzz) dürften zumindest teilweise dem entsprechen, was man über Device Info aus den Geräten auslesen kann (bzw. daraus ablesen kann.

• In Catalog.xml wird das Gerät nochmals gelistet, dabei wird auf Product Id und Hardware2Program Id referenziert.
• Der Name der eigentlichen Beschreibungsdatei leitet sich aus der ID der Applikation (s.o.) ab und ist schlicht die Applikations-ID gefolgt von ".xml".
• Die Beschreibungsdatei startet mit der Deklaration der Speicherbereiche. Diese heißen ..._AS-xxxx, wobei xxxx die Startadresse in Hex ist.

...to be continued

[tuxedo]

Ich bitte um Verständnis, dass ich mich in Anbetracht der zweifelhaften rechtlichen Lage nicht zum Signieren der XML-Dateien äußern werde

Wenn du's genau nimmst, müsstest du auch zu allem XML spezifischen, das nicht in der verlinkten Schema-Definition enthalten ist ebenfalls schweigen. Weil alles andere wäre ja eine Art von Reverse-Engineering was laut Lizenzbestimmungen untersagt ist. Auch darfst du streng genommen nicht anfangen die .knxprod anfangen zu entpacken und reinschauen --> Ebenfalls reverse engineering.

[coliflower]

Weil alles andere wäre ja eine Art von Reverse-Engineering was laut Lizenzbestimmungen untersagt ist. Auch darfst du streng genommen nicht anfangen die .knxprod anfangen zu entpacken und reinschauen --> Ebenfalls reverse engineering.

Nur eine Frage am Rande ...
Wenn ich keine ETS habe und somit keinen Lizenzbedingungen zugestimmt habe, darf ich dann auch nicht mit Dateien "spielen" ?

[tuxedo]

Nur eine Frage am Rande ...
Wenn ich keine ETS habe und somit keinen Lizenzbedingungen zugestimmt habe, darf ich dann auch nicht mit Dateien "spielen" ?

Hmm, das geht natürlich. Aber argumentierte mal im Streitfall dass du kein ETS hast.

[l0wside]

§202a StGB:
"Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert sind, ..."

Das ist bei XML-Daten im Klartext ersichtlich nicht der Fall. Bei einer undokumentierten API auch eher nicht, aber darüber kann man schon streiten.

Und dann gibt es noch das Urheberrecht, §69f UrhG lautet:
"(1) Der Rechtsinhaber kann [...] verlangen, daß alle rechtswidrig hergestellten [...] Vervielfältigungsstücke vernichtet werden. [...] (2) Absatz 1 ist entsprechend auf Mittel anzuwenden, die allein dazu bestimmt sind, die unerlaubte Beseitigung oder Umgehung technischer Programmschutzmechanismen zu erleichtern."

Das ist m.E. recht klar einschlägig. Der Hash ist ein technischer Programmschutzmechanismus.

Da ist ausreichend Raum für viel Ärger: §97 UrhG (Schadenersatz) und §108 UrhG (Strafrahmen bis 1 Jahr, gewerbsmäßig bis 3 Jahre).

Kann alles falsch sein, IANAL. Aber die Konnex hat im Zweifelsfall mehr Geld für Anwälte.

Max

[jolt]

Leute, don't panic. Ich habe in meinem Leben schon D-Boxen, Router, WLAN Treiber etc gehackt, reverse engineered, gesnifft oder sonst was damit gemacht. Bisher waren die Hersteller zwar nicht begeistert, aber beleidigt war auch keiner. War natürlich auch immer für einen guten Zweck (in der Regel um Linux darauf laufen zu lassen oder es unter Linux laufen zu lassen). Der Hersteller hatte hinterher also einen Mehrwert.

So sehe ich das hier auch. Es geht nicht darum die Software illegal ohne Lizenz zu nutzen / verteilen, sondern darum mehr User in die ETS zu bekommen bzw. eine heterogene Tool Landschaft zu vermeiden. Beides sollte doch auch im Interesse der Konnex sein. Die können sich auch ausrechnen das der Shitstorm der entsteht wenn die gegen ein paar versprengte DIY Jünger ins Feld ziehen nicht sonderlich positiv auf ihr Image wirken wird.

Die selfbus / freebus Jungs verteilen sonst seit langer Zeit ProductDB's bei denen sie sich auch das Passwort vorher "besorgt" haben. Sagt auch keiner was dagegen.

Nicht falsch verstehen, mir liegen Copyright und EULAs sehr am Herzen, ich will hier keinesfalls zum blauäugigen Ignorieren aller Bedenken aufrufen. Ich denke wir haben hier ausreichend Zeit in die Analyse der Optionen gesteckt und verfolgen einen Weg der so sauber wie möglich ist. Wenn die Konnex wirklich ein Problem damit hat, dann soll sie sich einfach melden und wir löschen das Zeug einfach wieder.

Wenn Sie schlau sind dann bieten Sie uns aber eine Möglichkeit auch DIY Geräte zertifizieren zu lassen. Irgend eine abgespeckte Hobby Zertifizierung, die auch gerne ein paar Euros kosten darf. Das wäre wirklich die Königslösung

[tuxedo]

§202a StGB:
"Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert sind, ..."

Das ist bei XML-Daten im Klartext ersichtlich nicht der Fall. Bei einer undokumentierten API auch eher nicht, aber darüber kann man schon streiten.

Wenn es denn XML im Klartext wäre. "Offiziell" ist es eine Datei mit Endung ".knxprod" für die es keinen "freien Editor gibt". Dass die Konnex eine Schema-Definition preis gibt und verrät dass das nur eine ZIP ist und intern XML Dateien stecken ist nochmal was anderes. Und man kann das auch als "besonderen Schutz" auslegen (leider sind die wenigsten Richter IT-Affin).
Ist für mein befinden weder weiß noch schwarz, aber immerhin grau.

"(1) Der Rechtsinhaber kann [...] verlangen, daß alle rechtswidrig hergestellten [...] Vervielfältigungsstücke vernichtet werden. [...]

Das wäre der Fall wenn man die ETS "hackt" und so dass sie jeder ohne gekaufte Lizenz nutzen kann. Aber es geht um Dateien die aller voraussicht nicht die Konnex erstellt hat (weiß da jemand mehr?) sondern die Hersteller selbst (mit dem Tool der Konnex).

Der Hash ist ein technischer Programmschutzmechanismus.

Aber der "hash" wird nicht "umgangen" und auch nicht "vervielfältigt".

Zum Rest von Jolt: FullACK.

[coliflower]

Hey Leute, wenn man die Arbeit aus wissenschaftlicher Sicht betrachtet, dann sollte es nicht verboten sein (ein System auf Zuverlässigkeit prüfen) sonst wären die ganzen Profis und Unis ständig in Häfn, weil diese andauernd irgendwelche Systeme auseinander nehmen und schauen was geht ….

Wenn es jemandem zu heiß ist dann soll der die Finger davon lassen ...

[StefanSweden]

Ein Teil der Arbeit ist schon erledigt, die Arbeiten mit dem XML Format und dem exportieren sind aber noch nicht fertig. Irgendwie kommen wir da nie zu, Hilfe ist willkommen
https://github.com/selfbus/development-tools-incubation

Das alte VD Format ist ein Kampf und bisher sind wir noch an die Grenzen der BCU1 gebunden, ca. 240 Byte inklusive aller GA Tabellen.