Über uns

Wer hinter LegacyMind steht

Zwei Gründer aus Ingolstadt, eine selbst entwickelte Engine, kein Investor.

01/Unternehmen

Eine GmbH, zwei Gründer

Handelsregister
HRB 12510
Amtsgericht Ingolstadt
USt-IdNr.
DE458254926
Rechtsform
LegacyMind GmbH
Gegründet September 2025
Sitz
Falkenstr. 10, 85049 Ingolstadt
Geschäftsführung
Marco Plannet
Finanzierung
Selbst finanziert
Kein Investor an Bord

Prüfbar: Die Registernummer lässt sich im Registerportal der Länder nachschlagen, die USt-IdNr. im MwSt-Informationsaustauschsystem der EU. Beides steht auch im Impressum.

02/Gründer

Ben baut die Engine, Marco die Partnerschaften

Ben Plannet, Co-Founder und CTO von LegacyMind

Co-Founder und CTO

Ben Plannet

Zehn Jahre IT-Sicherheit, erst Pentests von Android-Apps, heute die Software, die in vernetzten Geräten steckt.

Er hat die Engine gebaut, die eine Firmware auseinandernimmt: Dateisystem entpacken, jede Komponente und Version bestimmen, Schwachstellen zuordnen, Rückportierungen der Distributionen berücksichtigen, Kernel-Treffer filtern. Und die Ebene unter der Paketliste: Passwort-Hashes in der Konto-Datenbank, offen liegende Schlüssel, Zertifikate unter der BSI-Empfehlung, fehlende Schutzmechanismen in den Binaries.

Jede Demo macht Ben selbst.

Ben auf LinkedIn
Marco Plannet, Co-Founder von LegacyMind

Co-Founder und Geschäftsführer

Marco Plannet

Knapp 30 Jahre in internationalen IT-Landschaften, ursprünglich Infrastruktur, Security und Informationssicherheit.

Bei LegacyMind macht er die Partnerschaften und führt die Gespräche mit Geschäftsführung, Herstellern und Betreibern: was ein Befund aus der Firmware für den Betrieb heißt, und was als Nächstes zu tun ist.

Marco auf LinkedIn

03/Ursprung

Wie das angefangen hat

Am Anfang standen Gespräche, lange bevor es ein Produkt gab. Wir haben Interviews mit führenden Leuten aus der Industrie geführt, um zu verstehen, wo es in der IT-Sicherheit wirklich hakt. Und immer wieder kam dieselbe Frage zurück: Habt ihr euch schon mal Embedded-Geräte angeschaut?

Als die fünfte Person unabhängig von allen anderen dieselbe Frage stellte, war die Entscheidung gefallen. Wir haben die Software gebaut. Die erste Version setzte auf ein etabliertes Open-Source-Framework auf. Heute sind die Stufen, die Bewertung und die CVE-Korrelation unser eigener Code. Was dieser Satz konkret heißt, steht in der nächsten Marke: alle 18 Stufen, in der Reihenfolge, in der sie laufen.

04/Engine

18 Stufen, fünf Ebenen, eine Reihenfolge

Jede Stufe ist eine eigene Datei mit einer Liste der Stufen, auf die sie wartet. Aus diesen Listen ergibt sich die Reihenfolge des Laufs, vier Stufen einer Ebene gleichzeitig. Die Spur zeigt, was gelesen wird und in welcher Ebene, nicht was gefunden wird.

phoenix/18 Stufen/5 Ebenen/0/18 passiert
  • extract
  • parse
  • detect
  • match
  1. E0Extraktion0/1 Stufe
    • extract-image

      Entpackt das Image, liefert Wurzelverzeichnisse und nicht erkannte Blöcke

  2. E1Paketdatenbanken, Binaries, Geheimnisse0/14 Stufen

    Alle 14 hängen nur an extract-image. Vier laufen gleichzeitig.

    • parse-dpkg

      /var/lib/dpkg/status, Debian-Familie

      wartet auf extract-image

    • parse-opkg

      /usr/lib/opkg/status, OpenWrt

      wartet auf extract-image

    • parse-apk

      /lib/apk/db/installed, Alpine

      wartet auf extract-image

    • parse-rpm

      /var/lib/rpm/rpmdb.sqlite, RHEL-Familie

      wartet auf extract-image

    • parse-wince

      PE-Dateien mit VS_VERSIONINFO, Windows CE

      wartet auf extract-image

    • parse-flat-binary

      Images ohne Dateisystem, was die Bytes selbst sagen

      wartet auf extract-image

    • parse-elf-identity

      ELF-Header, Interpreter und SONAME je Binärdatei, auch ohne Paketdatenbank

      wartet auf extract-image

    • parse-binary-strings

      Versionsmuster in Binaries, mit Byte-Offset als Beleg

      wartet auf extract-image

    • parse-binary-hardening

      RELRO, NX, PIE, Stack-Canary, FORTIFY je ELF (checksec)

      wartet auf extract-image

    • parse-weak-functions

      Unsichere libc-Funktionen je ELF (readelf)

      wartet auf extract-image

    • detect-credentials

      /etc/shadow und /etc/passwd, Hash-Verfahren je Konto

      wartet auf extract-image

    • detect-crypto-keys

      Private Schlüssel, geparst statt gegrept

      wartet auf extract-image

    • detect-certificates

      X.509-Zertifikate, CA-Bundles zählen als Inventar

      wartet auf extract-image

    • detect-language-packages

      PyPI, npm und Maven aus den installierten Manifesten

      wartet auf extract-image

  3. E2Kernel0/1 Stufe
    • parse-kernel-meta

      Kernel-Version und Module aus /lib/modules, nach den Paketdatenbanken

      wartet auf extract-image · parse-opkg · parse-dpkg · parse-apk

  4. E3Kernel-Konfiguration0/1 Stufe
    • parse-kconfig

      /boot/config-<ver>, sonst extract-ikconfig aus vmlinux oder bzImage

      wartet auf extract-image · parse-kernel-meta

  5. E4Zuordnung0/1 Stufe
    • match-cves

      16 Quellen parallel, KEV und EUVD als Anreicherung, Fusion je CVE

      wartet auf parse-dpkg · parse-opkg · parse-apk · parse-rpm · parse-binary-strings · parse-kernel-meta · detect-language-packages · parse-wince · parse-flat-binary · parse-kconfig

Eine Ebene ist der längste Pfad zurück zu extract-image. Sie folgt aus der Zeile wartet auf jeder Stufe, nicht aus einer Zeichnung. Mit der Maus auf einer Stufe leuchten die Stufen auf, auf die sie wartet.

05/Grundsätze

Woran wir uns halten

  1. 01

    Jedes Ergebnis ist nachrechenbar

    Jedes Ergebnis muss ein Auditor nachrechnen können. Als Signal für aktive Ausnutzung gelten zwei behördlich geführte Kataloge: der KEV-Katalog der CISA und die EUVD der ENISA. Beide sind öffentlich. Die CSAF-Meldungen der Hersteller zählen als Quelle für die Zuordnung, nicht als Ausnutzungssignal.

    Prüfbar: Im Bericht steht zu jeder Zuordnung die Quelle.

  2. 02

    Ihre Firmware bleibt bei uns

    Die Analyse-Infrastruktur läuft ausschließlich in der EU. Firmware wird nicht an externe Analyse-Dienste weitergegeben. Nach der Analyse wird sie gelöscht.

    Prüfbar: Die Datenschutzerklärung nennt den Verarbeitungsort.

  3. 03

    Eine Lücke ist ein Befund

    Wenn die Analyse etwas nicht lesen kann, steht das im Ergebnis, mit der Grundgesamtheit: wie viele Wurzelverzeichnisse geprüft wurden, welche Prüfungen ohne Eingabe blieben. Lieber eine benannte Lücke als ein grüner Haken ohne Beleg.

    Prüfbar: Der technische Bericht hat dafür einen eigenen Abschnitt: Abdeckung, Grenzen und Erklärung zum Prüfumfang.

  4. 04

    Keine Compliance-Prozentzahl

    Der Bericht zählt Feststellungen, er benotet nicht. Zu jedem Punkt aus CRA Anhang I und § 30 BSIG steht, ob es einen Befund gibt, ob geprüft wurde und nichts gefunden, oder warum nicht geprüft wurde.

    Prüfbar: Ein Prozentwert müsste teilweise belegte Kontrollen gewichten. Jede Gewichtung wäre ein Urteil, das die Evidenz nicht trägt.

  5. 05

    Verschlüsselt bleibt verschlüsselt

    Ein herstellerseitig verschlüsseltes Image wird nicht entschlüsselt. Dann steht im Bericht, dass es nicht gelesen wurde, und warum.

    Prüfbar: Ein Image, das die Extraktion nicht öffnet, erscheint im Bericht als nicht gelesen, nie als sauber.

  6. 06

    Wir messen uns an fremden Daten

    Die Engine wird gegen den Debian Security Tracker abgeglichen, nicht gegen unsere eigene Erwartung. Was dort steht und bei uns fehlt, ist ein Fehler bei uns.

    Prüfbar: Debian, Ubuntu, Red Hat und Alpine sind vier der sechzehn Quellen, die match-cves liest.

06/Kontakt

Testen Sie es an Ihrer eigenen Firmware

Schicken Sie uns eine Firmware-Datei aus Ihrem Bestand. Ben zeigt Ihnen im Gespräch, was die 18 Stufen darin lesen, und was nicht.

Kontakt aufnehmenoder direkt an info@legacymind.de