Gira X1 unter der Lupe

Als Softwareentwickler gucke ich mir gerne an, wie professionelle Hard- und Software aufgebaut ist und zusammenspielt. Im Falle des Gira X1 interessiert mich, was dort eigentlich für ein Betriebssystem läuft, welche Prozesse laufen, wie ein Firmware-Update stattfindet, welche Ports geöffnet sind, wie Logikbausteine hinzugefügt werden usw. Glücklicherweise gibt es alle Firmware-Dateien von Gira einfach so als Download. Es sind keine Passwörter o.ä. nötig, um die Datei zu entpacken. Also bekommt man das “komplette Linux” als Download. Inklusiver aller Scripts und Binaries. Sollte also ziemlich einfach werden, einen tieferen Einblick zu bekommen. Starten wir doch gemeinsam. Der Blog-Beitrag könnte etwas länger werden (und wurde immer mal wieder angepasst) - also in Ruhe lesen und nachvollziehen.

Was ist der Gira X1?

Wenn man sich das Gerät genau anschaut, sieht es aus wie der Gira S1. So weit, so unspektakulär. Viel interessanter wird es, wenn man sich die Geräte der ise GmbH anschaut. Also zum Beispiel “Smart Connect KNX”, “KNX e-charge”, “KNX Sonos”, “KNX Hue” und so weiter. Dir wird auffallen, dass all diese Geräte exakt gleich aussehen. Man halt also einmal die Hardware entwickelt und rollt auf der Basis unterschiedliche Software aus. Eigentlich ein starkes Konzept. Ich gehe also stark davon aus, dass die Hard- und Software komplett von der ise Individuelle Software und Elektronik GmbH aus Oldenburg entwickelt wurde. Lädt man sich die Firmware-Updates von deren Produkten herunter, so ist alles 1:1 identisch aufgebaut. Gleiche Ordnerstruktur, gleiche Dateinamen, gleiche Scripts.

Ein bisschen verrückt ist allerdings, dass man im Firmware-Paket vom “ISE Smart Connect KNX” auch einen Gira-Ordner findet. Ist das Produkt eventuell komplett identisch zum Gira S1? Aber wir kommen vom Thema ab. Jetzt geht es erstmal um den Gira X1.

Gira-Geräte im Netzwerk finden

Wenn man im GPA (Gira Projekt Assistent) auf “Geräte suchen” klickt, dann werden alle Gira-Komponenten im Netzwerk gefunden und aufgelistet. Das gleich macht ja auch die App für Smartphones und Tablets. Aber wie funktioniert das? Dafür nutzt Gira das SSDP (Simple Service Discovery Protocol). Dabei werden Multicast Messages an die Adresse 239.255.255.250 gesendet. SSDP nutzt dabei Port 1900.

Da musste ich mich selbst erstmal einlesen. Mit mDNS, DNS-SD, APIPA, Zeroconf und so weiter findet man zig verschiedene Mechanismen, welche teilweise aufeinander aufbauen oder ähnlich funktionieren. Ich habe mir den Request einfach mal mit Wireshark angeschaut:

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 3
ST: urn:gira-de:device:Device:1
USER-AGENT: Gira Protocol/2.0 UPnP/1.1 Gira SSDP Client/2.0

Danach wird diese URL aufgerufen: http://x.x.x.x:8080/discovery/ssdp. Die Antwort sieht wie folgt aus:

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0" configId="1">
    <specVersion>
        <major>1</major>
        <minor>1</minor>
    </specVersion>
    <device>
        <deviceType>urn:gira-de:device:Device:1</deviceType>
        <friendlyName>Gira X1 (172.16.0.211 00:0a:b3:37:88:fb)</friendlyName>
        <manufacturer>Gira Giersiepen GmbH &amp; Co. KG</manufacturer>
        <manufacturerURL>http://www.gira.de</manufacturerURL>
        <modelDescription>Gira X1 (IP Module 05 - Extension Module KNX 2) 2.7.585.0</modelDescription>
        <modelName>Gira X1</modelName>
        <modelNumber>GIGSRVKX02</modelNumber>
        <modelURL>http://172.16.0.211:8080/DeviceDescription.xml</modelURL>
        <serialNumber>GIGSRVKX023788FB,2.7.585.0</serialNumber>
        <UDN>uuid:909c0c57-a0b5-d548-82e8-f915368a04c4</UDN>
        <presentationURL>http://172.16.0.211</presentationURL>
        <webaccessURL></webaccessURL>
        <capabilities>DeviceStack,Logic,Timer,Scenes,Visu</capabilities>
    </device>
</root>

Danach holt der GPA diese Datei ab: http://x.x.x.x:8080/DeviceDescription.xml (siehe modelURL im SSDP XML response)

Inhalt:

<?xml version="1.0" encoding="UTF-8" ?>
<GipsDevice version="1.1">
    <Ip DnsServer="172.16.0.1" SecondaryDnsServer="0.0.0.0" DefaultGateway="172.16.0.1" DHCP="true" SubnetMask="255.255.0.0" Address="172.16.0.211"/>
    <Ethernet MacAddress="00:0a:b3:37:88:fb"/>
    <Description>
        <Manufacturer Name="Gira Giersiepen GmbH &amp; Co. KG" Value="GI"/>
        <Model Description="Gira X1 (IP Module 05 / Extension Module KNX 2)" Name="Gira X1" Value="GSRVKX02"/>
        <HwRev Value="10"/>
        <SerialNumber Value="GIGSRVKX023788FB"/>
        <FirmwareVersion Value="2.7.585.0"/>
        <SecureConnection Value="true"/>
    </Description>
    <HealthState>
        <Property Name="10" Value="true"/>
        <Property Name="Maintenance" Value="true"/>
        <Property Name="SD" Value="false"/>
        <Property Name="RTC" Value="true"/>
    </HealthState>
    <HealthStateOfMonitoredApplications>
        <Application Id="10" Name="knxstack.sh" Alive="true"/>
        <Application Id="17" Name="iscwebservice" Alive="true"/>
    </HealthStateOfMonitoredApplications>
    <AdditionalInformation>
        <Knx Serialnumber_1="0008158105CF" Serialnumber_2="000000000000" Serialnumber_3="000000000000" Serialnumber_4="000000000000"/>
    </AdditionalInformation>
</GipsDevice>

Interessant ist hier die Info HwRev (was ja wohl für Hardware-Revision stehen wird). Dort ist der Wert 10 hinterlegt. Also gab es schon 1 bis 9?

Hardware

• SoC: NXP MC IMX6 U 7 C VM 08 A C (ARM Cortex A9, 800 MHz, i.MX 6 series 32-bit DualLite)
  • MC: Mass Production
  • U: DualLite
  • 7: Industrial
  • C: Industrial: -40 to +105°C
  • VM: Package - MAPBGA 21 x 21 0.8mm
  • 08: Frequency - 800 MHz
  • A: Fusing - Default settings
  • C: Silicon revision (3N81E = 1.3)
• RAM: 2x 4 Gb NT 5C C 256M16 E R - EK (DDR3L-1866 13-13-13) = 1 GB
• Flash: SanDisk iNAND 7250 SDINBDG4-8G (8 GB)
• SD-Kartenslot (aktuell von der Applikation nicht genutzt, aber angeschlossen und konfiguriert!)
• SMSC LAN9303 IC als Managed LAN Switch

»Gira X1 Hardware Front«

»Gira X1 Hardware Back«

»Gira X1 Hardware Bottom«

Software

Über die Software kann man sehr viel herausfinden, wenn man sich einfach das Firmware-Update von der offiziellen Seite als ZIP-Datei herunterlädt und entpackt. Zum Zeitpunkt dieses Blogbeitrags ist die Version 2.7.585 vom 28.09.2021 aktuell.

Als Linux kommt Linux-IMX zum Einsatz (von NXP). Hier gibt es alle Informationen auf der Seite des Herstellers.

In der Datei Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/www/web/opensources.json werden alle verwendeten Open-Source Projekte dokumentiert:

• Linux Kernel 3.17.0 (vom 29.01.2015)
• Mono
• nginx - Web-Server (1.15.7 vom 27.11.2018)
• simplewebserver - Web-Server (3.1.1 vom 21.10.2020)
• dropbear - SSH-Server (2018.76 vom 27.02.2018)
• openvpn - VPN-Server (2.4.6 vom 19.04.2018)
• avahi (0.7)
• dbus (1.12.16)
• busybox (1.29.3)
• i2c-tools (4.1)
• sqlite (3280000)

Webserver

Der X1 stellt mehrere Webserver bereit. Die meisten Zugriffe laufen über nginx, welcher die Anfrage entweder selbst beantwortet, oder an einen anderen Prozess mit proxy_pass weiterleitet.

• Über Port 80 kann die normale X1-Seite aufgerufen werden. Die WWW-Daten liegen unter Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/www/web und werden von nginx ausgeliefert.
• Unter /webservice können verschiedene Geräte-Infos und Konfigurationen abgefragt werden. Siehe “Interner Webserver (iscwebservice)” weiter unten.
• Weiterhin läuft der Gira IoT Endpunkt unter HTTPS (Port 443) https://x.x.x.x/api/v2/. Siehe “Gira-IoT-Webserver” weiter unten.

Interner Webserver (iscwebservice)

Die API-Requests werden von Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/opt/gira/bin/iscwebservice entgegen genommen, welcher als Dienst unter Port 1080 läuft.

nginx leitet diese an den internen “isc” Endpunkt weiter. Siehe nginx config:

Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/etc/nginx/nginx.conf

# Webservice
location /webservice {
    rewrite /webservice(.*) /api$1  break;
    proxy_pass         http://127.0.0.1:1080;
    proxy_http_version 1.1;
    proxy_redirect     off;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Es findet also ein Rewrite auf /api und Port 1080 statt. Dieser Port ist allerdings nur von localhost nutzbar (siehe iptables weiter unten). Dieser “interne” Webserver nimmt auch die Firmware-Updates entgegen. Siehe “Firmware-Update” weiter unten:

# firmware upload
location /webservice/upload/v2 {
    rewrite    /webservice/upload/v2 /api/upload break;
    proxy_pass http://127.0.0.1:1080;

    client_body_temp_path      /opt/userdata/nginx;
    client_body_in_file_only   on;
    client_body_buffer_size    1M;
    client_max_body_size       100M;

    proxy_pass_request_headers on;
    proxy_set_header           X-File-Name $request_body_file;
    proxy_set_body             off;
    proxy_redirect             off;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Hier ein Beispiel-Request (POST)

{
    "command": "getDeviceInfo",
    "data": {
        "forceLong": true
    },
    "keepAlive": true
}

Beispiel-Response:

{
    "data": {
        "User": "Administrator",
        "DebugMode": "INACTIVE",
        "Time": "2022-03-09T15:07:54",
        "StartupTime": "2022-01-31T19:39:50",
        "SdCardPresent": false,
        "SdCardUsage": 0,
        "SdCardSize": 0,
        "Hostname": "GSRVKX02-000ab33788fb",
        "CurrentFirmwareVersion": "2.7.585.0",
        "MacAddress": "00:0a:b3:37:88:fb",
        "Dhcp": true,
        "IpAddress": "172.16.0.211",
        "SubnetMask": "255.255.0.0",
        "DefaultGateway": "172.16.0.1",
        "NameServer": "172.16.0.1",
        "Ntp": true,
        "NtpServerAddress": "0.europe.pool.ntp.org",
        "NtpInterval": 10,
        "KnxSerialNumber": "0008158105CF",
        "KIM-FriendlyName": "Gira X1",
        "AppName": "",
        "EtsDownload": false,
        "DeviceName": "Gira X1",
        "DeviceId": "GSRVKX02",
        "CurrentSystem": "System A",
        "SerialNumber": "GIGSRVKX023788FB",
        "TimeZoneID": "133",
        "SyslogSeverity": 6,
        "KIM-LicenceInfo": "",
        "KnxBusVoltage": true,
        "ProgrammingMode": false,
        "MaintenanceRequired": false,
        "UserManagement": true
    }
}

Daneben gibt es noch viele weitere “Commands”, welche zum Beispiel die “Erweiterte Protokollierung” aktivieren (entspricht syslogSeverity 6 - “Info”):

{
    "command": "setSyslogSeverity",
    "data": {
        "syslogSeverity": 6
    },
    "keepAlive": true
}

und deaktivieren (entspricht syslogSeverity 4 - “Warning”):

{
    "command": "setSyslogSeverity",
    "data": {
        "syslogSeverity": 4
    },
    "keepAlive": true
}

über den Webserver auf Port 4433 (siehe unten) kann man das Log-Level noch auf 7 stellen - was für “Debug” steht.

Weiterhin werden folgende Commands unterstützt:

• getDeviceInfo - Geräte-Informationen (siehe oben)
• getFirmwareStatus - Firmware-Status
• setSyslogSeverity - Erweiterte Protokollierung aktivieren / deaktivieren (siehe oben)
• getLogicEnginePage - Erweiterungen / Logikbausteine und Logikblätter
• getLogfile - Log-Dateien herunterladen
• setProgrammingMode - Programmiermodus aktivieren / deaktivieren
• reboot - Gerät neustarten
• getPasswordSalt // doAuthenticateSession - Login

Über weitere Commands kann der Dienst noch:

• die IP-Konfiguration verändern
• den NTP-Server konfigurieren
• den X1 auf Werkseinstellungen zurücksetzen
• …

Gira-IoT-Webserver

Die API-Requests werden von Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/opt/gira/bin/restserver entgegen genommen, welcher als Dienst unter Port 5522 läuft.

nginx leitet diese an den internen “iot” Endpunkt weiter. Siehe nginx config:

Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/etc/nginx/server443/nginx_restapi.conf

location /api {
    proxy_pass http://127.0.0.1:5522;
}

Da dies ein Dienst ist, welcher offiziell von Dritten genutzt werden soll, gibt es dazu eine ausführliche PDF-Dokumentation unter Gira IoT. Daher führe ich das hier nicht weiter aus.

Noch ein Webserver?

Auf Port 4433 läuft ebenfalls ein Webserver, welcher über HTTPS verschiedene Infos bereitstellt. Also noch ein Webserver. Langsam wird es viel. Authentication z.B. mit “Administrator” & dem vergebenen Passwort bei ein Einrichtung.

• https://x.x.x.x:4433/discovery/presentation - Service-Seite mit einigen Einstellungen
• https://x.x.x.x:4433/discovery/presentation/completely - die gleiche Service-Seite mit mehr Infos zum Gerät
• https://x.x.x.x:4433/discovery/download - Liefert (bei mir) nur “Download failed” auf einer HTML-Seite
• https://x.x.x.x:4433/discovery/log - Auflistung aller Log-Dateien und Download-Möglichkeit
• https://x.x.x.x:4433/discovery/systemlog - SysLog darstellen
• https://x.x.x.x:4433/discovery/logic - Status der Logik-Engine
• https://x.x.x.x:4433/discovery/download/logfiles - GDS-Logfiles laden (als ZIP-Datei)

Woher ich die Infos habe? Aus dieser Datei: Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/opt/gira/etc/devicestack/devicestack.info

SSH-Zugriff

Als SSH-Server wird dropbear verwendet. Der Dienst wird nur gestartet, wenn die Datei /opt/userdata/.ssh-enabled existiert. Siehe Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/etc/init.d/S50dropbear. Diese Datei kann mit Hilfe der Funktion enable_ssh in der Datei Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/opt/gira/share/devicestack/ipmodule-functions angelegt werden. Das ist eine Sammlung von Funktionen, welche in anderen Scripts geladen wird.

KNX

Der KNX-Stack wird in einem separaten Prozess gestartet. Siehe Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/opt/gira/bin/knxstack.

Die Konfiguration ist hier zu finden: Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/opt/gira/etc/knxstack/knxstack.conf

Firmware-Update

Das Firmware-Update findet in diesen Verzeichnissen statt

• /opt/fwu/
• /opt/fwu/system_offline
• /opt/fwu/system_current

Es wird in ein A-System und ein B-System unterschieden, zwischen welchen gewechselt wird. Welches System aktiv ist, steht in /opt/extparam/booted_system. Außerdem kann das aktuell aktive System auch herausgefunden werden, wenn man die Geräte-Informationen abfragt (siehe “Interner Webserver”). Bei mir steht dies aktuell auf System A.

Nachdem die Firmware-Datei über den Webservice hochgeladen wurde, wird das Gira-X1-2.7.585-Firmware-2096/opt/fwu/pre-script ausgeführt. Dieses Bash-Script mach folgendes:

1. Verzeichnis /opt/fwu/system_offline wird erstellt
2. Es wird geschaut, welches System gerade aktiv ist
3. Falls das jeweils andere System gerade gemountet ist, findet ein unmount statt
4. Es wird ein Filesystem erstellt (mke2fs)
5. Das System wird gemountet
6. Der Inhalt der Firmware ZIP-Datei wird nach /opt/fwu/system_offline entpackt
7. Die drei tar-Dateien rfs_regular_(directories|symlinks|devices).tar aus dem Firmware-Update werden nacheinander entpackt

Dann folgt das Gira-X1-2.7.585-Firmware-2096/opt/fwu/post-script, welches ein wenig aufräumt:

1. Es werden Dateiberechtigungen gesetzt
2. Es werden ca-certificates installiert
3. Es wird (falls vorhanden) der Bootloader getauscht
4. Unmount von /opt/fwu/system_offline
5. Es werden Berechtigungen für den logic-User (siehe unten) angepasst

Wo könnte man hier eingreifen?

• Der Prozess sieht vor, dass man eine extra_packages_directories.tar mitliefern kann, welche weitere Dateien enthält. Diese werden automatisch entpackt und nach dem Update gelöscht.

Jetzt könnte man meinen, man erhöht einfach die Versionsnummer, tauscht ein paar Dateien aus und packt alles wieder zusammen. Das klappt leider nicht, weil das Firmware-Paket signiert ist. Scheinbar läuft das nach genau dem gleichen Schema ab, wie die Signatur der Logikbausteine. Warum sollte man auch verschiedene Prozesse dafür entwickeln? In der Datei Gira-X1-2.7.585-Firmware-2096/FirmwareDescription.xml findet man im XML die Signatur (SignatureValue wurde gekürzt):

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
        <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
        <Reference URI="">
            <Transforms>
                <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
            <DigestValue>O7JlezOKwTCCo2NIWUa/mQANJzbisbC3rLKbHPQh8yQ=</DigestValue>
        </Reference>
    </SignedInfo>
    <SignatureValue>PeirWmKetv...</SignatureValue>
</Signature>

Siehe auch

• mkfs.ext3
• XmlDsigEnvelopedSignatureTransform

SD-Karte

Die SD-Karte wird bereits vom X1 automatisch unter /opt/card gemountet. Auch im Device-Status (siehe oben unter “Webserver”) wird ausgegeben, ob eine SD-Karte gefunden wurde, oder nicht. Genau das gleiche sehen wir bei der Geräte-Suche. Auch dort wird aufgeführt, ob eine SD-Karte eingelegt ist (siehe oben unter “Gira-Geräte im Netzwerk finden”).

Also ist im Prinzip alles für die Nutzung vorbereitet worden. Es gibt nur noch keine praktische Anwendung dafür. Schade!

Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/etc/udev/scripts/sdcard.sh

Ports und Firewall

Iptables-Definition aus Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/etc/iptables/isc.rules

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT 
-A INPUT -p tcp --dport http -j ACCEPT
-A INPUT -p tcp --dport ssh -j ACCEPT
-A INPUT -p tcp --dport 8153 -j ACCEPT
-A INPUT -p tcp --dport 4432 -j ACCEPT
-A INPUT -s 127.0.0.1 -p tcp --dport 65155 -j ACCEPT
-A INPUT -p tcp --dport 65155 -j REJECT
-A INPUT -s 127.0.0.1 -p tcp --dport 1080 -j ACCEPT
-A INPUT -p tcp --dport 1080 -j REJECT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
COMMIT

• Port 80: HTTP-Webserver, welcher die Diganose-Seite bereitstellt (nginx)
• Port 1080: HTTP-Webserver, welcher u.a. den Firmware-Update Prozess startet (iscwebservice)
• Port 4433: HTTP-Webserver, Service-Enpunkt
• Port 5522: HTTP-Webserver, REST-API (Gira IoT)
• Port 8080: HTTP-Webserver, Device-Discovery (SSDP)
• Port 3671: IP KNX-Stack

Benutzer

In der Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/etc/passwd werden alle Benutzer beschrieben, welche das System kennt:

root:x:0:0:root:/opt/userdata:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/false
bin:x:2:2:bin:/bin:/bin/false
sys:x:3:3:sys:/dev:/bin/false
sync:x:4:100:sync:/bin:/bin/sync
mail:x:8:8:mail:/var/spool/mail:/bin/false
www-data:x:33:33:www-data:/var/www:/bin/false
operator:x:37:37:Operator:/var:/bin/false
nobody:x:65534:65534:nobody:/home:/bin/false
logic:x:500:500:Logic engine user:/:/bin/sh
avahi:x:1000:1000::/:/bin/false
dbus:x:1001:1001:DBus messagebus user:/var/run/dbus:/bin/false

Ein Shadow-Template für die Benutzer findet man unter Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/opt/gira/etc/devicestack/shadow.template. Dort ist logischerweise auch das root-Passwort (gehasht) zu finden:

root:LCvWLl406P61Q:10933:0:99999:7:::

Da hier kein Algorithmus angegeben ist, wird wahrscheinlich DES (Data Encryption Standard) bzw. crypt für das Hashing verwendet. Als Salt werden dabei die ersten beiden Zeichen genutzt - also LC.

Zusätzlich gibt es noch die Datei Gira-X1-2.7.585-Firmware-2096/opt/fwu/system_offline/opt/gira/etc/devicestack/shadow.template.root

root:BEoWX8rRkH/Jc:10933:0:99999:7:::

Wenn man den Hash bei Google sucht, findet man heraus, dass das Passwort in dieser Datei “root” ist. Das kann man auch leicht mit einem der Befehle prüfen (Salt ist BE):

openssl passwd -crypt -salt BE root
mkpasswd -m des -S BE -s <<< root

Jetzt ist die Frage, welche Datei wann genutzt oder geladen wird. Leider (bzw. zum Glück) wird die Datei shadow.template.root nur in der Funktion reset_passwd() des SSH-Servers init.d verwendet. Welche aber nie ausgeführt wird. Da steht sogar als Kommentar drüber, dass das Passwort auf root gesetzt wird. Also müsste man herausfinden, was LCvWLl406P61Q für ein Passwort ist. Brute Force? Dann würde man allerdings ein Sicherheitsfeature aktiv umgehen. Und das möchte ich nicht versuchen (und schon gar nicht veröffentlichen). Generell wäre das aber möglich, da das Passwort ja “nur” 8 Zeichen haben kann. Nur Klein- und Großbuchstaben wären also schon 53.459.728.531.456 mögliche Kombinationen. Das dauert mehrere Tage im schlimmsten Fall. Je nach Hardware. AWS lässt grüßen.

Der einfachste Weg wäre also, in der Datei einfach einen neuen Hash zu hinterlegen und das Image neu zu flashen. Wie man Passwörter für die Datei generiert, habe ich ja auf zwei unterschiedlichen Wegen bereits gezeigt.

Prozesse

Über die Diagnose des X1 kann man einiges über die internen Prozesse erfahren. Dafür einfach über den integrierten Webserver als Administrator anmelden. Unter “Diagnose” wird dann alles wichtige aufgelistet. Hier die Ausgabe von meinem System:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root               991512    136312    804000  14% /
devtmpfs                418304         0    418304   0% /dev
proc                         0         0         0   0% /proc
sysfs                        0         0         0   0% /sys
devpts                       0         0         0   0% /dev/pts
tmpfs                    10240        16     10224   0% /var/tmp
tmpfs                    10240       172     10068   2% /var/log
tmpfs                    10240       132     10108   1% /var/run
/dev/mmcblk0p1           10871       176     10081   2% /opt/extparam
/dev/mmcblk0p4         5422340    118672   5024896   2% /opt/userdata

Mem: 488968K used, 544444K free, 324K shrd, 153560K buff, 207780K cached
CPU:   0% usr   4% sys   0% nic  95% idle   0% io   0% irq   0% sirq
Load average: 0.01 0.03 0.05 1/210 914
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  914   430 root     R     2508   0%   5% top -b -n 1
  430     1 root     S     195m  19%   0% /opt/gira/bin/devicestack
  603   499 root     S     192m  19%   0% /opt/gira/bin/knxstack -f /opt/gira/etc/knxstack/knxstack.conf -s 0008158105CF
  502   430 root     S     143m  14%   0% /opt/gira/bin/iscwebservice -p 1080 -c /opt/gira/etc/iscwebservice/iscwebservice.conf
  508   430 root     S     108m  11%   0% /opt/gira/bin/restserver
  504   430 root     S    93708   9%   0% /opt/gira/bin/presencesimulation
  509   430 root     S    91660   9%   0% /opt/gira/bin/usage-statistics-client
  511   430 root     S    81652   8%   0% /opt/gira/bin/sonosapp
  501   430 logic    S    81104   8%   0% /usr/bin/mono /opt/gira/share/LogicEngine/LogicModule.Engine.Runner.exe
  512   430 root     S    72420   7%   0% /opt/gira/bin/hueapp
  373     1 root     S     7568   1%   0% /usr/sbin/haveged -w 1024 -r 0
  393   391 www-data S     6576   1%   0% nginx: worker process
  391     1 root     S     6296   1%   0% nginx: master process /usr/sbin/nginx
  189     1 root     S     2888   0%   0% /sbin/udevd -d
  380     1 dbus     S     2880   0%   0% dbus-daemon --system
  892   189 root     S     2856   0%   0% /sbin/udevd -d
  893   189 root     S     2856   0%   0% /sbin/udevd -d
    1     0 root     S     2508   0%   0% init
  352     1 root     S     2508   0%   0% udhcpc -x hostname:GSRVKX02-000ab33788fb -b -s /etc/dhcp.script -i eth0
  105     1 root     S     2508   0%   0% /sbin/syslogd -n
  186     1 root     S     2508   0%   0% /sbin/klogd -n
  499   430 root     S     2508   0%   0% {knxstack.sh} /bin/sh /opt/gira/bin/knxstack.sh -f /opt/gira/etc/knxstack/knxstack.conf -s 0008158105CF
  463     1 root     S     2508   0%   0% /sbin/getty -L ttymxc0 115200 vt100
  286     1 root     S     2376   0%   0% /sbin/watchdog -t 15 /dev/watchdog
    7     2 root     SW       0   0%   0% [rcu_sched]
  608     2 root     SW       0   0%   0% [irq/280-knxspi_]
   38     2 root     SW       0   0%   0% [kworker/1:1]
    3     2 root     SW       0   0%   0% [ksoftirqd/0]
   11     2 root     SW       0   0%   0% [ksoftirqd/1]
   85     2 root     SW       0   0%   0% [mmcqd/0]
  217     2 root     SW       0   0%   0% [kjournald]
 6932     2 root     SW       0   0%   0% [kworker/u4:1]
  614     2 root     SW       0   0%   0% [kworker/0:2]
    9     2 root     SW       0   0%   0% [migration/0]
   10     2 root     SW       0   0%   0% [migration/1]
  306     2 root     SW<      0   0%   0% [kworker/1:1H]
    2     0 root     SW       0   0%   0% [kthreadd]
  811     2 root     SW       0   0%   0% [kworker/0:1]
   89     2 root     SW       0   0%   0% [kjournald]
   95     2 root     SW       0   0%   0% [kjournald]
  181     2 root     SW<      0   0%   0% [kworker/0:1H]
    5     2 root     SW<      0   0%   0% [kworker/0:0H]
    8     2 root     SW       0   0%   0% [rcu_bh]
   12     2 root     SW       0   0%   0% [kworker/1:0]
   13     2 root     SW<      0   0%   0% [kworker/1:0H]
   14     2 root     SW<      0   0%   0% [khelper]
   15     2 root     SW       0   0%   0% [kdevtmpfs]
   16     2 root     SW<      0   0%   0% [netns]
   17     2 root     SW<      0   0%   0% [writeback]
   18     2 root     SW<      0   0%   0% [crypto]
   19     2 root     SW<      0   0%   0% [bioset]
   20     2 root     SW<      0   0%   0% [kblockd]
   21     2 root     SW       0   0%   0% [khubd]
   28     2 root     SW       0   0%   0% [kswapd0]
   29     2 root     SW       0   0%   0% [fsnotify_mark]
   39     2 root     SW       0   0%   0% [irq/365-da9063-]
   78     2 root     SW       0   0%   0% [irq/81-imx_ther]
   79     2 root     SW       0   0%   0% [irq/161-2190000]
   80     2 root     SW       0   0%   0% [irq/54-mmc1]
   81     2 root     SW       0   0%   0% [irq/56-mmc0]
   82     2 root     SW<      0   0%   0% [ipv6_addrconf]
   83     2 root     SW<      0   0%   0% [deferwq]
   86     2 root     SW       0   0%   0% [mmcqd/0boot0]
   87     2 root     SW       0   0%   0% [mmcqd/0boot1]
   88     2 root     SW       0   0%   0% [mmcqd/0rpmb]
 7725     2 root     SW       0   0%   0% [kworker/u4:2]

Gerätedetails

Applications
	Command Line: /opt/gira/bin/knxstack.sh
		Status:          OK
		Process ID:      499
		Monitoring Type: IPC
		State:           Heartbeat OK
		Process Memory:
			Virtual:    2.45 MB
			Resident:   1.56 MB
			Shared:     1.49 MB
			Text:       0.66 MB
			Lib:        0.00 MB
			Data:       0.29 MB
			Dirty:      0.00 MB
	Command Line: /opt/gira/bin/iscwebservice
		Status:          OK
		Process ID:      502
		Monitoring Type: IPC
		State:           Heartbeat OK
		Process Memory:
			Virtual:  143.32 MB
			Resident:  24.60 MB
			Shared:    14.72 MB
			Text:       1.84 MB
			Lib:        0.00 MB
			Data:     116.39 MB
			Dirty:      0.00 MB
System
	Time:                 2022-03-09T14+44+47
	Initialized:          yes
	File Path:            /opt/gira/etc/devicestack/device.config
	Emulation:            no
	Module ID:            IM05
	Locked:               no (Project Verification Unlock)
	Configuration locked: no (Server Configuration Change Unlock)
	Updating:             no
	Waiting for reboot:   no
	Pending reboot:       no
	Restart required:     no
Hardware
	Version:              HC00
	Manufacturer:         Gira Giersiepen GmbH & Co. KG (GI)
	Device:               Gira X1 (GSRVKX02) 10
	IP Module:            IP Module 05 (IM05) 10 A0
	Extension Module:     Extension Module KNX 2 (KX02) 10 A0
	Serial Number:        GIGSRVKX023788FB
	Device GUID:          909c0c57-a0b5-d548-82e8-f915368a04c4
	MAC Address(es):      00:0A:B3:37:88:FB
	KNX Serial Number(s): 0008158105CF
	Portal Serial Number: 000ab33788fb
Software
	Version:               SC01
	Boot Strap Version:    1.0
	Boot Loader Version:   1.0
	Boot Script Version:   1.0.0.0
	Current System:        A
		Firmware Version:    2.7.585.0
		System Version:      2.7.585.0
		Application Version  2.7.585.0
		Boot Failure Count:  0
	Fallback System:       B
		Firmware Version:    2.7.585.0
		System Version:      2.7.585.0
		Application Version: 2.7.585.0
		Boot Failure Count:  0
Logging:
	Syslog:              no
	Level:               4
	Target:              :514
	Local:               no
	Console:             no
	Append to File:      yes
	File Name:           /var/log/devicestack
	File Rotation Size:  262144
	File Rotation Count: 4
NTP:
	Enabled:  yes
	Server:   0.europe.pool.ntp.org
	Interval: Every 10 minutes
RTC:
	Enabled:  yes
	Interval: Every 10 minutes
	Device:   /dev/rtc0
Location:
	Time Zone: 133 Europe/Berlin ((UTC+01:00) Europe/Berlin )
	Latitude:  53.15
	Longitude: 8.22
	Sunrise:   2022-03-09T06+57+00
	Sunset:    2022-03-09T18+17+00
General
	Project:              ID4a6f1dfb-704f-4f36-901d-11ef0b7ee09a
	Device Type:          server
	Device Name:          GiraX1
	Friendly Name:        Gira X1
	Device Hint:          NOCS;NOQC;LOAD:MODULES
	Persistence Interval: 10 minutes
Remote
	Root Path:    /opt/gira/share/devicestack/web
	Port:         80
	Web Cache:    0
	Sessions:     100
	Timeout:      600
	API Port:     4432
	API PortCert: 4434
	API Secure:   1
	API MaxConn:  20
	Default Page: /index.html
	Login Page:   /login.html
Runtime
	Application Path:  Applications
	Module Path:       Modules
	Native Runtime:    no
	Mono Runtime:      no
	Scripting Runtime: no
Field
	Simulation:   no
	KNX:          yes
	KNX Hint:     
	KNX RF Hint:  
	KNX Reliable: no
Service
	Configuration URI:  https://localhost:4433/service
	Configuration Mode: SECURE;
Heartbeat
	Enabled:  yes
	Interval: Every 10 seconds
Watchdog
	Enabled:  yes
	Interval: Every 10 seconds
Device
	Device UID:     221951d4d5ac
	Sub-device ID:  
IP Configuration
	DHCP:            yes
	IP Address:      172.16.0.211
	Subnet Mask:     255.255.0.0
	Default Gateway: 172.16.0.1
	DNS Server:      172.16.0.1, 0.0.0.0
Network Configuration
SD Card Event State:         [sceOut]
Network Configuration State: [nceDhcpAddressAcquired]
Time States
	Timer:       no
	Time Server: no
	DST Enabled: no
Common
	Firmware Files Base Dir:  /
	Application Root Path:    /opt/gira/etc/devicestack
	WWW Root Path:            /opt/gira/share/devicestack/web
	Clone Script File:        /opt/gira/bin/clone-system
	App Config File:          /opt/userdata/devicestack/appconfig.xml
	System App Config File:   systemappconfig.xml
	SD Card Device Index:     0
	SD Card Root Path:        
	System Log File:          System.txt
	System Log Path:          /opt/userdata
	Device Stack Config Path: /opt/gira/etc/devicestack
	Device Stack Config File: /opt/userdata/devicestack/devicestackconfig.xml
	User Data Path:           /opt/userdata/devicestack
	Ext Param Path:           /opt/extparam
	New Style Boot Sequence:  true
	Firmware X509 File:       /opt/gira/etc/devicestack/FwImage_PEM.crt
	Config File:              /opt/userdata/devicestack/mtd5.image
	Locked Config File:       /opt/userdata/devicestack/mtd5Locked.image
	Block Config File:        /opt/userdata/devicestack/mtd5.image
	Temp Directory Path:      /opt/userdata/tmp
	netcfg.state File:        /opt/userdata/netcfg.state
	App Supported Features:   Scenes;Timer;Logic;Visu;
GPA
	Project loaded:           yes
	Active project directory: /opt/userdata/gpaproject/0/projects
	Firmware version:         2.7.585.0
	Visu GUID:                5f914fa8-6c88-4129-9917-b1f315538598
	Visu Master:              yes
	Capabilities:             DeviceStack Logic Timer Scenes Visu

Emulation

Jetzt würde ich die Software gerne auf anderer Hardware laufen lassen. Da es sich um einen ARM Cortex A9 handelt, müsste man diesen eigentlich mit QEMU emulieren können. In der Liste findet man unter sabrelite das Freescale i.MX6 Quad SABRE Lite Board (Cortex A9). Das klingt doch vielversprechend, oder?

Hilfreiche Links:

• Embedded Linux for i.MX Applications Processors
• Running ARM programs under linux