Armin Egginger zeigte ein Projekt, an dem er seit Monaten arbeitet: das direkte Auslesen und Vergleichen von FileMaker-Dateien auf binärer Ebene – ohne den Umweg über XML.

Der Anlass: ein Fehler im Release

Der Auslöser war ein klassisches Praxisproblem. Beim Kunden war ein Release eingespielt worden, danach stimmte etwas nicht. Die Frage lautete: Wie findet man schnell heraus, was sich zwischen dem alten und dem neuen Stand geändert hat?

Armin zog das aktuelle Release heraus und verglich es mit einem alten Release aus 2025 (Version 21.6.5) aus der Produktivumgebung. Den Weg über XML hielt er dafür für ungeeignet: “Wenn ich das Ganze über XML mache, dauert mir das zu lang.” Bei großen, über Jahre gewachsenen Lösungen wird der Export zäh und die entstehenden Dateien so groß, dass sie sich kaum noch handhaben lassen – vergleichen kann man sie dann bestenfalls im Streaming, aber nicht mehr vollständig.

Was das Tool leistet

Der Vergleich läuft inzwischen vollständig auf Basis der Binärebene und deckt Felder, Scripte, Wertelisten und weitere Objekttypen ab; lediglich die MBS-Bestandteile fehlen noch. Als Ausgabe entstehen JSON-Dateien und eine HTML-Darstellung, die pro Objektbereich zeigt, was nur in A, was nur in B und was in beiden Ständen enthalten ist.

In der Detailtiefe geht Armin dabei deutlich über das lange vermisste FMDiff hinaus, an dessen Stelle er antreten möchte:

Der Vergleich geht viel tiefer als FMDiff. Das neue Tool kann auf Layout-Objektebene die Position des betroffenen Objekts zeigen – wo FMDiff nur feststellen konnte, das Layout wurde verändert.

Bewusst weggelassen hat er die reinen Formatierungsinformationen, die für die Fehlersuche keine Rolle spielen und die Ausgabe nur aufblähen würden. Erarbeitet hat er sich das über Monate mit eigenen Testfällen – inklusive der Erkenntnis, dass sich Bitlängen zwischen Versionen verändern können, worauf die Analyse eigens reagieren muss.

Perspektivisch soll daraus ein Dienst werden, den man mit zwei Dateien beschickt und der das Ergebnis als JSON zurückliefert – ähnlich wie es FMDiff seinerzeit anbot, nur schneller. Auch das Erstellen von Klonen per Zeitplan ist damit möglich, was bei großen Lösungen erheblich Zeit spart.

Was das Tool ausdrücklich nicht kann und nicht können soll, ist das Zurückschreiben – dafür gibt es das FM Upgrade Tool.

Die ethische Grenze

Ein durchaus spannender Teil der Präsentation drehte sich um die Frage, was ein solches Werkzeug nicht tun darf. Armin hat die Grenzen in einem Guideline-Dokument innerhalb seines Recovery-Toolkits als Regelwerk hinterlegt: keine Passwörter auslesen, keine Passwörter zurückschreiben, keine Kontonamen, keine sicherheitsrelevanten Lizenzberechnungen.

Der Grund ist naheliegend: Wer das Schema einer fremden Lösung auslesen kann, kommt auch an das Skript, in dem steht, wie eine Lizenz generiert wird, und kann sie nachbauen. Als selbst betroffener Anbieter kennt Armin diese Perspektive aus erster Hand.

Genau daran hängt derzeit die Veröffentlichung:

Es läuft bei mir lokal, ich kann alles machen, ich kann alles reparieren. Aber ich kann es nicht rausgeben, weil ich nicht weiß, wie ich es ethisch prüfen kann.

Die Kernfrage lautet: Wie stellt man fest, ob jemand die vorliegende .fmp12-Datei überhaupt auslesen darf? Dass es in einer Datei ein Konto mit Vollzugriff gibt, sagt nichts darüber aus, ob der Nutzer dieses Konto ist – und das Passwort ist verschlüsselt und wird aus Sicherheits-Gründen ohnehin nicht ausgelesen. Ein erster Ansatz für den Dateivergleich: Beide Dateien müssen eine gewisse Mindestanzahl an Übereinstimmungen aufweisen, sonst wird der Vorgang verworfen. So lässt sich zumindest verhindern, dass wahllos eine fremde Datenbanklösung durchleuchtet wird.

Warum überhaupt ein neues Tool?

Für Armin stößt die Verarbeitung von FileMaker-Strukturdaten im XML-Format – trotz seiner langjährigen Expertise auf diesem Gebiet – inzwischen an die Grenzen der Praktikabilität. Andere Formate seien dafür längst besser geeignet. Er schätzt, dass ein Save as XML als JSON ausgegeben nur ein Drittel bis ein Viertel des Platzes benötigen würde – ein Argument, das auch bei AI-gestützten Workflows unmittelbar durchschlägt. XML schleppt hier unnötig viel Ballast mit sich. Dies wurde aus der Runde mit weiteren Argumenten gestützt. Adam Augustin wies auf modernere Ansätze hin, die deutlich kürzer sind als klassische UUIDs, weil sie ohne Bindestriche auskommen und den vollen alphanumerischen Zeichenvorrat nutzen statt nur der Hexadezimalzeichen – Basis 36 statt Basis 16 skaliert um ein Vielfaches besser.

Der Zugriff auf FileMaker-Strukturen hatte hier zunächst die Vergleichbarkeit von Änderungen als Anlass. Spätestens mit der Anforderung, die Struktur auch für agentischen Zugriff verfügbar zu machen, gibt es weitere gute Argumente, die verfügbaren Schnittstellen von FileMaker für heutige Bedürfnisse zu modernisieren. Armins Beobachtung: Es existieren auf Herstellerseite bereits Schnittstellen, um Strukturen zu erstellen und zu ändern – nur eben unvollständig. OData deckt die Schema-Ebene mit Tabellen, Feldern und Relationen ab; was fehlt, ist die Script- und Prozessebene.

Fazit

Armins Ansatz, die FileMaker Datei direkt auf Binär-Ebene auszulesen eröffnet interessante Perspektiven für unterschiedliche Abläufe und Anforderungen. Der größte Vorteil ist die datensparsame und schnelle Ausleitung relevanter Daten. Das Problem bleibt der Schutz gegen unberechtigten Zugriff, den ein solches Tool nicht allein auf technischer Ebene abbilden kann.

Weitere Infos:

FileMaker Recovery Toolkit
https://www.fm-stammtisch.de/themen/2026-07-08-FileMaker-Recovery-Toolkit/

FMDiff – Werkzeug von Winfried Huslik zum Auslesen des FileMaker-Binärformats, historischer Ausgangspunkt der Binär-Extraktion
http://fmdiff.com/

CUID – kürzere Alternative zur klassischen UUID, ohne Bindestriche und mit vollem alphanumerischem Zeichenvorrat
https://www.uuid.lol/cuid

Encrypted Patch File – Claris-Leitfaden zur verschlüsselten Patch-Datei im App Upgrade Tool
https://help.claris.com/markdown/en/app-upgrade-tool-guide/encrypted-patch-file.md