01374c426e
Implementiert eigenen MobileBackup2-Restore-Trick zur Supervision-Übernahme von aktivierten iOS-Geräten ohne Factory-Reset. Foundation für DiGA-Phase-G Lock-Layer-Stack (non-removable Apps, non-removable Profiles, OnDemand-VPN- Toggle-Lock) auf Consumer-iPhones. Verifiziert end-to-end auf: - iPhone Air (iPhone18,4, iOS 26.5): TL→ReBreak re-supervise ✅ - Olfa iPhone 14 Pro (iPhone15,3, iOS 26.4.2): TL→ReBreak re-supervise ✅ Key empirische Findings: 1. Find-My-iPhone MUSS off sein (ErrorCode 211 sonst) → Stolen Device Protection (SDP) zwingt FMI an seit iOS 17.3+ 2. SupervisorHostCertificates DARF NICHT in CloudConfigurationDetails sein für fresh-supervise auf activated unsupervised devices (sonst partial-apply) 3. MCInstall.SetCloudConfiguration firet 14002 auf allen activated devices → MobileBackup2-Restore-Trick ist der einzige Weg 4. TL's extracted-embed-bytes != TL's wire-output (Runtime-Mutation) → Verbatim-Kopieren reicht nicht Reverse-Engineering basiert komplett auf: - Apple's public protocol docs (devicemanagement, mobilebackup2 schemas) - libimobiledevice (open-source reference impl) - TL public-distributed binary (interop-RE, legal per US-DMCA-1201 + EU-2009/24) Structure: cmd/supervise/ — main CLI (check, cloud-config, supervise, cert-info, unsupervise) cmd/dump-artifacts/ — diagnostic helper (no device needed) cmd/usbmux-proxy/ — MITM-proxy for TL-traffic-capture (debug) cmd/tl-patcher/ — patches TL's hard-coded usbmuxd path (debug) internal/dlmessage/ — DLMessage wire-protocol (4-byte BE length + plist) internal/mobilebackup2/— mobilebackup2-service impl (BaseVersionExchange, Hello, Restore, ServeFiles + TL-extracted templates) internal/cloudconfig/ — CloudConfigurationDetails.plist builder (cert-less, 25 keys matching TL's runtime-output) internal/cert/ — auto-gen + persist supervisor-cert in ~/.rebreak-supervise/ internal/mcinstall/ — MCInstall.GetCloudConfiguration für state-checks internal/device/ — go-ios DeviceEntry wrapper internal/afclock/ — AFC sync-lock auf /com.apple.itunes.lock_sync internal/notification_proxy/ — PostNotification (syncWillStart/etc) internal/preflight/ — FMI/Activation/OS-version pre-checks internal/supervise/ — End-to-end Flow-Orchestrierung (MobileBackup2 default, MCInstall via REBREAK_FORCE_MCINSTALL=1) Pending für volle Productization (Phase G): - Fresh-supervise direkt-empirisch auf truly-unsupervised iPhone testen (heute Nacht nur durch Inferenz aus TL-Verhalten gestützt) - Auto-MDM-enroll-Step nach Supervise (ConfigurationURL oder cfgutil-style) - DiGA-Onboarding-Flow + Lyra-Coach für FMI/SDP-Disable - Multi-Device-Validation (Modelle, iOS-Versionen) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ReBreak MDM — Projektübersicht
Was ist das
MDM steht für Mobile Device Management. Dieses Projekt setzt einen selbst-gehosteten MDM-Server (NanoMDM) auf, der ein iPhone dauerhaft unter Supervision halten kann — mit dem Ziel, dass der Nutzer (Chahine) eine Spiel-Blockade nicht ohne Aufwand umgehen kann.
Das Szenario: Chahine enrolled sein iPhone freiwillig in das MDM-Profil (self-binding). Das Profil kann er nicht selbst entfernen, weil dafür ein Admin-PIN oder die Zustimmung eines Trustees nötig ist. Die Trustees sind Olfa und Ina Wittek.
Kein Enterprise-MDM. Kein Firmenzweck. Kein App-Store-Management. Ausschließlich: Entfernung des MDM-Profils blockieren.
Warum getrennter VPS
Der MDM-Server läuft auf einem separaten Hetzner-VPS (rebreak-mdm, 178.105.101.137), getrennt von rebreak-server (49.13.55.22, Nuxt-App). Gründe:
- Kein Crossover-Risiko: ein Deploy-Fehler auf dem App-Server betrifft nicht den MDM-Server
- Unabhängige Uptime: MDM muss laufen auch wenn die App deployed wird
- Klarere Verantwortung: MDM-Server hat keine App-Logik, nur nanomdm + postgres + nginx
Architektur
[Chahines iPhone]
|
|-- NEFilter (ReBreak iOS App, anderer Scope)
| Blockiert Gambling-Domains via Network Extension
|
|-- MDM-Profil (dieser Server)
Verhindert Entfernung der App ohne Admin-Zustimmung
|
v
[mdm.rebreak.org] (178.105.101.137)
|
+-- nginx (443 SSL) --> nanomdm (127.0.0.1:9000)
|
v
postgres (127.0.0.1:5432)
DB: nanomdm, User: nanomdm
Apple-Push-Zertifikat-Flow:
[Server: push.csr] --> [identity.apple.com] --> [push.pem download]
|
[scp push.pem to server]
|
[nanomdm benutzt push.pem
um Apple APNS zu erreichen
= MDM-Befehle ans Gerät]
Trust-Modell
- Chahine: Gerät-Owner, enrolled sich selbst. Hat keinen MDM-Admin-Zugriff (Sinn der Sache).
- Olfa: Co-Admin. Hat Zugriff zu MDM-Credentials (in
/opt/nanomdm/auf dem Server). - Ina Wittek (
ina.wittek@gmx.de): Trustee. Bekommt per Email einen Notfall-Schlüssel, mit dem sie das MDM-Profil entfernen kann falls Chahine z.B. das Gerät für dringende Arbeit braucht und weder er noch Olfa erreichbar sind.
Factory-Reset = nuclear option. Zerstört alle Daten. Sollte nur als letztes Mittel genutzt werden.
Status
- Phase A ✅ Server-Bootstrap
- Phase B ✅ TLS-Zertifikat
- Phase C ✅ NanoMDM container + nginx
- Phase D ✅ Apple Push CSR generiert — Benutzeraktion ausstehend
- Phase E ⏳ Email an Ina (blocked: Apple-cert + Resend-key fehlen)
- Phase F ⏳ Device-Enrollment (factory-reset + USB-Supervision + Profil-Installation)
Details in PHASES.md.
Quick Links
- SSH:
ssh rebreak-mdm(178.105.101.137) - NanoMDM: https://mdm.rebreak.org
- Apple Push Portal: https://identity.apple.com/pushcert/
- Resend (Email-Service): https://resend.com
- NanoMDM Docs: https://github.com/micromdm/nanomdm