Zum Hauptinhalt springen
  1. Beiträge/

iBeacon per Reverse Engineering: wenn die Hersteller-App versagt

·235 Wörter·2 min
Peter Schmidt
Autor
Peter Schmidt
Inhaltsverzeichnis

Die Beacons für mein NearGuide-Projekt sind eingetroffen - und mit ihnen die erste Hürde.

Die Hürde: ein Format, das die App verschweigt
#

Schnell stellt sich heraus: Die mitgelieferte App des Beacon-Anbieters funktioniert ziemlich übel. Vor allem ist in der Bedienoberfläche überhaupt nicht zu erkennen, wie man aus dem universellen Bluetooth-Beacon tatsächlich ein Apple-konformes iBeacon konfiguriert.

Genau das ist aber entscheidend. Apples Bluetooth-Stack reagiert nur dann sparsam - also ohne den Akku leerzusaugen - auf Beacons, wenn diese exakt dem iBeacon-Format entsprechen. Für eine App, die im Hintergrund und über Stunden zuverlässig auf Orte reagieren soll, ist das keine Kür, sondern Voraussetzung.

Claude Code wird zum Reverse-Engineering-Werkzeug
#

Hier kommt Claude Code ins Spiel. Mit einer winzigen, selbstgebauten App, etwas Mitschneiden des Bluetooth-Funkverkehrs am iPhone und einigen gezielten Eingaben in die Konfigurationssoftware des Herstellers war das Format verstanden - und eine erste Fassung einer eigenen Provisionierungs-Software umgesetzt.

Das Bemerkenswerte daran: Ich musste kein einziges Stück Programmcode anfassen. Meine Aufgabe bestand allein darin, die alte Hersteller-Software zu bedienen, während Claude Code mitlas und die richtigen Schlüsse zog. Den Rest hat es innerhalb einer einzigen Nachmittags-Session erledigt.

Ein Gedanke zum Schluss
#

Ich frage mich ernsthaft, ob ich mein Auto mit diesen Reverse-Engineering-Fähigkeiten noch lange behalte. Der Schlüssel funktioniert ja auch über Funk.

In Teil 3 nehmen die nativen Apps für iOS und Android Gestalt an - und mit ihnen der Sprung von Opus 4.7 auf 4.8.