Eigene ETS Produktdatenbanken erzeugen

[l0wside]

Hallo jolt,

mit dem von dir angesprochenen "Flamewar" war wohl die Diskussion zwischen Tuxedo und mir vor einiger Zeit gemeint.
Ich wäre mehr als froh, mein bisheriges Config Tool in die Tonne zu treten und die ETS verwenden zu können. Insofern bin ich an deinen Erkenntnissen hochinteressiert (und die Grundlage für die o.g. Diskussion entfiele gleich mit). Allerdings wüsste auch ich gerne, ob man die Erkenntnisse guten Gewissens verwenden kann - auf nähere Bekanntschaft mit §202a StGB lege ich keinen Wert, deswegen wäre die Info, woher der Private Key kommt, schon interessant.

EDIT: habe erst nach der Antwort deine Extraktionsmethode gesehen. Damit entfällt das für mich leider

Wenn du KNX-Stack schreiben willst: ich bin damit schon fertig (und habe versucht, mich an den Standard zu halten). Schicke mir mal eine Mail, dann bekommst du die Zugangsdaten.

Zur KNXPROD:

Ich habe mir jetzt (ziemlich willkürlich) die .knxprod des MDT-Logikmoduls hergenommen.

In der hardware.xml steht ja nicht viel drin, das enthält wohl generische Produktbeschreibung, einen Verweis auf die XML-Datei mit dem eigentlichen Inhalt und Verweise auf andere Sprachversionen.
Die eigentliche Beschreibungsdatei hat in etwa folgende Struktur:

KNX
  ManufacturerData
    Manufacturer
      ApplicationPrograms
        ApplicationProgram
          Static
          Dynamic
      Languages

Die interessanten Daten sind in Static und Dynamic. Alle Daten sind über IDs verknüpft, die ein bisschen nach GUID aussehen (aber keine sind).
Static sieht so aus:

Code - hier sind Speicherstellen definiert, z.T. mit Inhalt.
  AbsoluteSegment
  AbsoluteSegment
  ...
ParameterTypes - hier können Wertearten definiert werden, z.B. ein Int von 0 bis 255 oder eine Aufzählung
Parameters
  Parameter
  Parameter
  ...
ParameterRefs - hier wird jedem Parameter zusätzlich noch eine Ref-Id zugewiesen. Zweck ist mir unklar.
ComObjectTable
  ComObject
  ComObject
  ...
AddressTable
AssociationTable

• Die Parameter gibt es in zwei Geschmacksrichtungen - mit und ohne Memory-Eintrag. Letztere werden wohl auch ins Gerät geschrieben, erstere werden nur ETS-intern verwendet. Hat jemand eine Ahnung, wie man hier Properties statt der vermaledeiten Memory-Einträge verwenden kann?
  EDIT2: habe bei Gira was gefunden, sieht dann so aus:
  

  	<Parameter Id="M-0008_A-A012-12-34D5-O000A_P-2730" Name="Allg_Hardwaretype" ParameterType="M-0008_A-A012-12-34D5-O000A_PT-Type.5FHardware" Text="Hardwaretype" Access="None" Value="1">
  	  <Property ObjectIndex="0" PropertyId="78" Offset="0" BitOffset="0" />
  	</Parameter>

• Die ComObjects sind relativ einfach; ins Gerät geschrieben wird am Ende vermutlich nur die Nummer ("Number")
• Zu Address Table und Association Table kann ich nur auf die BCU2-Doku von Martin Kögler verweisen. Letztendlich ist die Address Table eine Liste von GAs (je 16 bit), die Association Table verknüpft dann diese Adressen mit den ComObjects über deren "Number".
  Wenn ich mich recht erinnere, gibt es in der ETS ein Verfahren, um die beiden Tabellen an verschiedene Speicherstellen schreiben zu können (d.h. die Adresse im EEPROM ist nicht fix). Im von mir betrachteten Gerät allerdings sieht es aus, als ob die Adressen fix wären.

Es folgt Dynamic. Hier scheint beschrieben zu werden, wie in der ETS abhängig von einzelnen Werten andere Werte sichtabr sind oder auch nicht.
Struktur von Dynamic:

Channel
  ParameterBlock
    ParameterRefRef
    ParameterRefRef
    ...
    choose
      when
    ComObjectRefRef

Daraus bin ich nicht so recht schlau geworden, vermutlich wäre eine simplere Applikation einfacher gewesen. choose/when sind wohl If-Abfragen. Die IDs und vor allem das Hin und Her zwischen ID und Ref-ID machen das Leben nicht unbedingt leichter.
Für eine erste eigene .knxprod könnte man auf den Dynamic-Teil aber vielleicht auch einfach verzichten.

Max

[jolt]

Hallo Max,

der Key kommt direkt aus der ETS, wie man den extrahiert habe ich ein paar Posts weiter vorne beschrieben.

Legal seitig dürfte das kein Problem sein, solange der Key immer ausgelesen wird und nicht in unseren Tools bereits enthalten ist.

Ich schicke den Source Code des Tools gleich noch an tuxedo, dann kann er ihn in das Github Repository einchecken. Wäre super wenn jemand mal probieren könnte welche Sektionen wirklich alles enthalten sein müssen, damit die ETS die DB akzeptiert. Evtl kann man das ja noch mal deutlich entschlacken und dann sukzessive ergänzen sobald wir die Tools und das Wissen um die anderen Parameter ergänzt haben.

Grüße,
Florian

[tuxedo]

Legal seitig dürfte das kein Problem sein, solange der Key immer ausgelesen wird und nicht in unseren Tools bereits enthalten ist.

Damit bist du immer noch mindestens in der Grauzone: Wozu eine Software, die ohne Key - welchen man nicht "legal" erhält - schlicht nicht zu gebrauchen ist. Die Anwendung der Software wäre mit der illegalen Beschaffung des Keys verbunden, womit die Nutzung der Software dann ebenfalls "illegal" wäre (achtung, laienvermutung).

Ich schau mir den Source aber gerne mal an.

[l0wside]

Hallo Florian,

coole Sache jedenfalls, ich werde versuchen, eine Produktdatenbank für meine Temperatur-/Feuchtesensoren zu erstellen. Allerdings kann ich die hinterher sicher nicht veröffentlichen

Max

[jolt]

Naja, ich darf den Key ja legal auslesen, nur halt nicht an andere weiter geben. BTW Rev Engineering Passagen in EULAs etc sind ohnehin nicht gültig, siehe Wikipedia.

[tuxedo]

Hab mich vor Jahren schon mit EULA und ReverseEngineering beschäftigt.

Per Se ungültig ist das nicht. Es gibt da Ausnahmefälle.

Aus Wikipedia:

Zudem sind solche Lizenzklauseln in vielen Ländern generell ungültig, da den Nutzern einer Sache gesetzlich das Recht zusteht, zur Überprüfung der Anwendungssicherheit (siehe auch Trojanisches Pferd) oder zur Fehlerbehebung ein von ihnen erworbenes Softwareprodukt einem Reverse Engineering zu unterziehen. Das reine Untersuchen von Dingen, die einem selbst gehören, darf man gegebenenfalls der Freiheit der Forschung zuordnen, so dass ebenfalls entsprechende Lizenzklauseln nicht greifen.

"in vielen Ländern" heisst nicht "in allen Ländern" und auch nicht "in Deutschland".
Ich selbst darf das "für mich" machen, weswegen es l0wside für sich auch mal probieren wird. Aber Aufgrund dieser Erkenntnisse eine Software ins Leben rufen die andere auch nutzen können und die nur das eine zum Ziel hat, ist nach wie vor fragwürdig.

Mehr als den Source dafür veröffentlichen würde ich erstmal nicht wollen. Binaries/Executables darf sich dann jeder selbst anfertigen.

[jolt]

Korrekt, wir sprechen hier über DIY. Ich habe keine Ambitionen Gira oder MDT zu werden ;-)

[l0wside]

Lassen sich Produktdatenbanken mit "Unregistered" und ohne Key eigentlich auch einlesen? Und wenn ich ein Projekt mit einem so generierten Produkt speichere und exportiere, ist dann der Key noch da, oder ist der verschwunden?
Ich suche eben nach einem brauchbaren Umweg.

Ansonsten bin ich mir mit Tuxedo einig - das ist eine ziemlich dunkle Grauzone. Leider.

Max

[jolt]

Nein, es lassen sich nur signierte Product DB's einlesen. Ich habe noch ein bisschen weiter geforscht und es ergeben sich folgende Optionen:

1. Key auslesen und selbst signieren (wie beschrieben)
2. Wir nutzen das ETS3 VD Format, hier gibt es keine Signaturen, nur ein Zip Passwort. Das müsste man allerdings genauso aus der ETS auslesen. Oder Brute Forcen.
3. Wir nutzen die ETS Libraries um die Files zu signieren.

Variante 3 bedeutet wir schreiben ein kleines C# Program dass die ETS DLL aufruft und die Signierung anstösst. Der Code dazu ist nur ein 3 Zeiler sieht so aus:

var myType = typeof(ConverterEngine).Assembly.GetType("Knx.Ets.Converter.ConverterEngine.ConverterEngine");
var mi = myType.GetMethod("SignOutputFiles", BindingFlags.Static | BindingFlags.NonPublic);
mi.Invoke(null, new object[] { args[0] });

Ich finde diese Variante bisher am besten. Ist zwar kein dokumentiertes API aber irgendwie kann ich auch nichts illegales daran erkennen. Was denkt ihr?

Grüße,
Florian

[tuxedo]

Variante 3 gefällt mir auch am besten. Ist sicher etwas "weißer" als der bisherige Weg, aber ob er schon "strahlend weiß" ist wage ich noch zu bezweifeln. Zumindest ein Grauschleier liegt noch darüber.
Grund:

EULAs sind nicht per-se ungültig. Bin mir bei der ETS gerade nicht sicher ob ich da vor der Verwendung/dem Kauf auf eine EULA hingewiesen wurde und was darin so alles stand (müsste man mal recherchieren).

Evtl. problematische Abschnitte aus dem ETS Lizenzvertrag (http://www.knx.org/knx-de/software/b...en/index.php):

(0) Unter der Voraussetzung, dass der Lizenznehmer die jeweilige Lizenzgebühr entrichtet hat, räumt KNX Association dem Lizenznehmer ein nicht ausschließliches und nicht übertragbares Recht zur Nutzung der ETS-Software oder der Hersteller-Tool-Software gemäß den nachfolgenden allgemeinen und wesentlichen Bedingungen sowie für die in der Softwaredokumentation dargelegten Zwecke und Anwendungen ein.

Sofern der Punkt hier rechtens ist, wäre es einem nicht gestattet die ETS für etwas anderes zu nutzen als Gedacht. Signieren würde hier wohl darunter fallen.

Der Lizenznehmer ist nicht berechtigt, den Quelltext der Software oder irgendeinen Teil der Software zurück zu entwickeln (reverse engineering) oder sonst wie zu rekonstruieren oder weitere Kopien von der Software und/oder der Softwaredokumentation oder von Teilen der Software und/oder der Softwaredokumentation anzufertigen.

Wenn man's hier genau nimmt, betrifft das nur den Source-Code. Der Vorgeschlagene 3. Weg betrifft aber den Einsatz einer undokumentierten API die auch nicht sonderlich gesichert ist. Mit Tools wie Dependency-Walker und Co (die jedem C/C++ Entwickler von Haus aus zur Verfügung stehen) kann man ohne jeden Aufwand von DLLs die Schnittstellen lesen. Das wäre wohl kein Source-Code-Reverse-Engineeren, und schon gar nicht das umgehen von Sicherheitsmechanismen, aber API lesen wie es jeder Entwickler Tag täglich macht.

des Weiteren ist es ihm nicht gestattet, abgeleitete Werke (Derivate), die komplett oder in Teilen auf der Software basieren, zu kopieren, abzuändern, anzupassen, zu verschmelzen, zu übertragen oder zu erstellen.

Abgeleitete Werke erstellen... Nun. Das 3-Zeilen-Signiertool wäre ein abgeleitetes Werk, denn es macht sich die Funktion der ETS zu nutze. Wäre zwar nur ein kleines abgeleitetes Werk, aber es wäre eines.

Sowohl die Software als auch die Softwaredokumentation stellen Geschäftsgeheimnisse von KNX Association und/oder ihrer Lizenzgeber dar und/oder sind nach dem Urheberrecht und sonstigen Rechten geschützt; das Eigentum an der Software und der Softwaredokumentation verbleibt weiterhin bei KNX Association und/oder ihren Lizenzgebern. KNX Association und/oder ihre Lizenzgeber sind die Inhaber sämtlicher Rechtsansprüche, Urheberrechte und jeglicher sonstigen Eigentumsrechte auf bzw. an jedem SOFTWAREPAKET; jegliche Teile und Kopien des Softwarepakets verbleiben im Eigentum von KNX Association und/oder ihrer Lizenzgeber.


Mit Ausnahme der in diesem Lizenzvertrag eingeräumten Lizenzrechte erwirbt der Lizenznehmer keinerlei Rechtsanwartschaft, Recht oder Anrecht auf das bzw. an dem SOFTWAREPAKET.

Der Abschnitt ist ziemlich verzwickt. Ich bin mir nicht sicher ob man das tatsächlich so weit einschränken kann. Unter Strich besagt der Absatz: Du darfst die ETS nur Nutzen, aber sonst hast du keinerlei Rechte daran (nicht einmal das Besitzrecht der Softwareinstallation der ETS?).



Wenn man die ETS4 zu irgend einer Zeit runterladen und installieren konnte ohne vorher den Lizenzvertrag abnicken zu müssen, wäre der Lizenzvertrag hinfällig. Aber ich glaube (weiß es aber nicht) das das nicht der Fall war/ist.

[l0wside]

Lassen sich Produktdatenbanken mit "Unregistered" und ohne Key eigentlich auch einlesen?

Ich antworte mir mal selbst: nein, geht nicht. Der Key bleibt auch in der .knxproj erhalten, wenn man ihn verändert, weigert sich die ETS, das Ergebnis einzulesen

@Alex: selbst wenn deine Schlussfolgerung, dass man mit der EULA kollidiert, falsch sein sollte - Ärger mit der Konnex ist trotzdem programmiert. Ob nun zivil- oder strafrechtlicher Ärger, nervig und teuer wird´s in jedem Fall.
Fazit für mich: ich werd´s mal testen, aber das Ergebnis nicht veröffentlichen. Für DIY-Zwecke reicht das ja.

Gruß,

Max

[tuxedo]

Na in den Lizenzbedingungen steht auch dass man die Lizenz nicht verkaufen darf. Und man darf es trotzdem. Die wissen das, übertragen dir auch die Lizenz von A nach B, aber ändern tun die die Lizenzbedingungen dennoch nicht. -> Abschreckung... Aber es gibt genug Punkte die sicherlich rechtlich wasserdicht sind, weswegen Weg Nr. 3 noch nicht das gelbe vom Ei ist. Binaries eines solchen Tools würde ich nach wie vor nicht veröffentlichten wollen.

[jolt]

So dachte ich mir das auch. Das Signieren der Files kann ja dann jeder selbst machen. Vielleicht gibt es ja zukünftig einen Weg wie man offiziell DIY Geräte in die ETS bekommt. Die Hoffnung stirbt ja bekanntlich zuletzt

[jolt]

So, habe das Tool noch ein bisschen ergänzt, sodass jetzt jeder der Bedarf hat damit Testen kann:

1. Code in eine Datei kopieren und auf der Platte speichern (z.B. als knxsign.cs)
2. Pfad zum csc.exe (C# Compiler) finden. Da die ETS auf C# basiert, ist der Compiler bereits installiert. Typischerweise in C:\Windows\Microsoft.NET\Framework\v4.0.30319, je nach Framework/Windows Version ist der Pfad anders oder Version eine andere. Zur Not also nach csc.exe suchen
3. Program compilieren: <pfad>\csc.exe knxsign.cs
4. knxsign starten: knxsign.exe <pfad zur ETS Installation> <Pfad in dem sich die zu signierenden Files befinden>

Viele Grüße,
Florian

using System;
using System.Reflection;

class Program
{
    static void Main(string[] args)
    {
        if (args.Length != 2)
        {
            Console.WriteLine("Syntax: <path to ETS installation> <path to files to be signed>");
            return;
        }

        string dllLocation = System.IO.Path.Combine(args[0], "Knx.Ets.Converter.ConverterEngine.dll");

        if (!System.IO.File.Exists(dllLocation))
        {
            Console.WriteLine("Can't load Knx.Ets.Converter.ConverterEngine.dll at location: " + dllLocation);
            return;
        }

        string signDir = args[1];

        if (!System.IO.Directory.Exists(signDir))
        {
            Console.WriteLine("Directory to be signed doesn't exist! Location: " + signDir);
            return;
        }

        var asm = Assembly.LoadFrom(dllLocation);
        var type = asm.GetType("Knx.Ets.Converter.ConverterEngine.ConverterEngine");
        var mi = type.GetMethod("SignOutputFiles", BindingFlags.Static | BindingFlags.NonPublic);
        mi.Invoke(null, new object[] { signDir });
    }
}

[tuxedo]

;-) Schon lustig dass die ETS alles notwendige mitbringt:

* C#-Compiler
* die passende DLL zum signieren

Da geben die sich solche Mühe mit der Lizensierung (Dongle, ...), und dann gibt's keinerlei Sicherheitsmechanismen die das selbst-signieren von eigenen .knxprod-Files verhindern....

Das fahrlässigste ist aber dass der private-key zum signieren in der ETS enthalten ist. Und wenn ich mich nicht irre haben sie sich damit in eine Sackgasse manövriert:

Die können den Schlüssel ja nicht einfach abweisen um solche privaten Basteleien in Zukunft zu verhindern. Sonst können hunderte (oder tausende?) bereits existierende Produktdatenbanken nicht mehr verwendet werden. Diese müssten alle neu signiert werden. Und nochmal den private-key mitliefern... Man macht ja nicht den gleichen Fehler zwei mal. Und alle Produktdatenbanken zum überprüfen und umsignieren nach Brüssel schicken ist auch Käse...

Kurzum: Das Kind liegt im Brunnen. Erst mit einer neuen ETS "könnte" man wohl sagen: "Alte Datenbanken werden nicht mehr unterstützt, der Hersteller muss neue liefern".

[update]
Hab das Tool mal ausprobiert. Hat keine 5min gedauert bis die erste Signatur rausgefallen ist. Tolle Sache.