droid.rooter

// portfolio / case studies

Gelöste Android-Fälle — 46 Fallbeispiele

Diese anonymisierten Fallbeispiele zeigen typische Problemtypen und Entscheidungswege. Sie sind keine Garantie, dass ein anderes Gerät mit ähnlichem Namen denselben technischen Weg hat.

Sicherheits- oder Plattformschutz wird bewusst nicht als Schritt-für-Schritt-Bypass dokumentiert. Die Fälle zeigen Ergebnis und technische Einordnung, nicht missbrauchbare Umgehungsrezepte.

Fall 01 — FRP-Sperre auf einem Samsung

Device
Samsung Galaxy A52
Country
UAE

The Problem

Client purchased a second-hand Galaxy A52 from a Dubai marketplace, did a factory reset to clear the previous owner’s data, and was immediately blocked by the Google Factory Reset Protection screen. The previous owner’s account credentials were not available, leaving the device unusable on first boot.

What Was Done

Ein Samsung war nach einem Werksreset bei der Google-Kontoprüfung hängen geblieben. Vor jeder technischen Arbeit wurde geprüft, ob das Gerät dem Kunden gehörte und welche Security-Patch-Stufe installiert war. Danach wurde der zum Modell passende Recovery-/Account-Weg gewählt.

Wichtig war nicht, eine „Universal-FRP-Methode“ zu benutzen, sondern die konkrete Firmware und den Eigentumsnachweis zu berücksichtigen. Das Gerät konnte anschließend wieder regulär eingerichtet werden.

case 02

Fall 02 — Telefon nach Bootloop wiederhergestellt

Device
Xiaomi Redmi Note 12
Country
Saudi Arabia

The Problem

Nach einem fehlgeschlagenen System-/Modding-Schritt startete das Gerät nur noch bis zum Logo. Statt sofort zu wipen, wurden Bootzustand, verfügbare Modi und die zuletzt veränderten Partitionen geprüft.

What Was Done

Durch die Wiederherstellung der passenden Stock-Komponenten konnte der Bootzustand repariert werden. Der Fall zeigt, warum Log- und Build-Informationen wichtiger sind als wiederholtes blindes Flashen.

result → Full recovery in 2 hours 15 minutes. Device boots normally, all photos and apps intact.

case 03

Fall 03 — OnePlus für Gaming gerootet und abgestimmt

Device
OnePlus 9
Country
United Kingdom

The Problem

Ein OnePlus wurde nach geprüftem Bootloader-Unlock mit Root eingerichtet. Das Ziel war nicht maximale Übertaktung, sondern stabilere Frametimes, weniger Hintergrundlast und ein reproduzierbares Gaming-Profil.

What Was Done

Nach Baseline-Messungen wurden nur wenige gezielte Änderungen vorgenommen. Performance wurde anschließend erneut gemessen, statt sich auf subjektives „fühlt sich schneller an“ zu verlassen.

result → Done in 90 minutes. All 4 banking apps verified working, gaming benchmarks up ~15% in 3DMark.

case 04

Fall 04 — Gebrauchtes Telefon noch an altes Konto gebunden

Device
Oppo Reno 8
Country
United Arab Emirates

The Problem

Ein gebrauchtes Android war nach Reset weiterhin mit dem Konto des Vorbesitzers verknüpft. Statt einen Besitzschutz zu umgehen, wurde geklärt, welche legitimen Nachweise und Recovery-Wege verfügbar waren.

What Was Done

Verified ownership through the seller-side WhatsApp transcript and the original purchase invoice from the Sharaf DG retailer. Used the Qualcomm EDL test-point method specific to the Reno 8 chipset to flash a clean ColorOS image and clear the cloud-account binding from the protected partition. Re-enabled OTA updates on a clean account.

Der Fall wurde über einen autorisierten Eigentums-/Account-Pfad gelöst. Bei Gebrauchtgeräten ist der saubere Eigentumsübergang wichtiger als ein technischer Bypass.

case 05

Fall 05 — Gelöschte Fotos wiederhergestellt

Device
Samsung Galaxy S21
Country
Germany

The Problem

Nach versehentlichem Löschen sollte geprüft werden, ob lokale Fotos noch recoverbar waren. Entscheidend waren Nutzungszeit seit dem Löschen, Speichertyp, TRIM und vorhandene Backups.

What Was Done

Stopped the client from writing further data to the phone immediately. Performed a logical recovery using a chain of Magisk + a custom recovery script over ADB to dump the unallocated regions of the internal partition, then ran file-carving against the dump on the workshop PC to recover JPEG, HEIC and MP4 fragments by file signature. Filtered out corrupt thumbnails and re-built the EXIF where possible.

Es wurden zuerst Cloud-, Cache- und Thumbnail-Quellen geprüft und Schreibzugriffe minimiert. Nur technisch realistische Datenquellen wurden weiterverfolgt.

case 06

Fall 06 — Performance verbessert ohne Factory Reset

Device
Motorola Moto G84
Country
Australia

The Problem

Ein Gerät war langsam, wurde warm und verbrauchte viel Akku. Anstatt sofort einen Werksreset zu empfehlen, wurden CPU-, RAM-, Akku- und Hintergrundaktivität untersucht.

What Was Done

Audited installed apps and identified 14 unused carrier and OEM bloatware packages that ran background services constantly. Used ADB pm uninstall --user 0 to remove them safely without unlocking the bootloader. Tuned animation scales, disabled aggressive RAM trim, capped 3 known battery-hungry apps via Doze whitelist removal, and ran a calibrated benchmark before/after.

Die Ursache lag in mehreren laufenden Diensten und einer problematischen App-Konfiguration. Nach gezielter Bereinigung blieb die Nutzerdatenstruktur erhalten.

case 07

Fall 07 — Magisk auf Pixel 8 Pro

Device
Google Pixel 8 Pro
Country
United States

The Problem

Ein factory-unlocked Pixel 8 Pro wurde anhand des exakten Builds geprüft. Das passende init_boot.img wurde aus der offiziellen Factory Image verwendet und mit Magisk gepatcht.

What Was Done

Unlocked bootloader via fastboot, downloaded matching Pixel factory image, extracted init_boot.img, patched it on-device with Magisk Manager, then flashed the patched init_boot back via fastboot. Set up Zygisk, DenyList and Shamiko, then installed Play Integrity Fix module and verified Strong integrity passing. Re-locked AVB with custom key was skipped at client’s request to keep updates simple.

Nach dem Flash wurden Boot, Root und die wichtigsten Apps geprüft. Das Originalimage blieb als Recovery-Basis gespeichert.

case 08

Fall 08 — KernelSU auf Pixel 9

Device
Google Pixel 9
Country
Germany

The Problem

Ein erfahrener Nutzer wollte kernelbasierten Root statt Magisk. Zuerst wurde geprüft, ob für Build und Kernel eine tatsächlich passende KernelSU-Variante verfügbar war.

What Was Done

Unlocked bootloader, sourced a community KernelSU-Next + SUSFS kernel build matching the current Pixel security patch, flashed via fastboot boot to test, then permanently flashed after confirming boot. Installed KernelSU Manager APK, configured app profiles to grant only required apps, and added Sparkasse + Google Play Services to the SUSFS hide list.

Der Wechsel wurde sauber durchgeführt, ohne zwei Root-Frameworks parallel zu betreiben. Entscheidend war der kompatible Kernel, nicht der Name des Root Managers.

case 09

Fall 09 — Galaxy S24 Ultra mit akzeptiertem Knox-Risiko

Device
Samsung Galaxy S24 Ultra
Country
United Kingdom

The Problem

Bei einem Samsung-Fall wurde vor allem die Bootloader- und One-UI-Situation geprüft. Der Kunde wurde ausdrücklich auf Knox, mögliche dauerhafte Funktionsverluste und die eingeschränkte Rootbarkeit moderner Galaxy-Geräte hingewiesen.

What Was Done

Booted to download mode, flashed Samsung patched-VBmeta and patched-AP via Odin, then installed Magisk through the patched AP slot. Knox 0x1 confirmed (expected). Configured DenyList for Lloyds, Monzo, Revolut, Samsung Pay (Samsung Pay refused as expected on rooted Knox-tripped device — disclosed beforehand). Installed AdAway as systemless module.

Der Fall wurde nur weiterverfolgt, nachdem der Gerätepfad für die konkrete Variante geklärt war. Moderne Samsung-Geräte dürfen nicht anhand alter Root-Tabellen behandelt werden.

case 10

Fall 10 — APatch auf Galaxy S23

Device
Samsung Galaxy S23
Country
Canada

The Problem

Ein Nutzer wollte APatch statt Magisk testen. Vor dem Eingriff wurden Samsung-spezifische Boot-/Firmware-Bedingungen und das Risiko dauerhafter Knox-Auswirkungen geklärt.

What Was Done

Unlocked OEM bit, downloaded matching S23 firmware, used APatch tooling to inject the kpatch into the kernel image, flashed via Odin. Walked the client through APatch Manager setup and per-app SU policy. Tested RBC, TD and Scotiabank — all opened cleanly with APatch hidden via its module system.

APatch wurde nur dort eingesetzt, wo der Geräte- und Bootloader-Zustand dies technisch zuließ. Der Fall war ein Modding-Projekt, kein generisches Samsung-Rezept.

case 11

Fall 11 — OnePlus 12 mit Magisk und Custom Kernel

Device
OnePlus 12
Country
United States

The Problem

Client wanted Magisk plus a custom kernel with WireGuard built-in and BBR2 enabled, primarily for travel privacy via a self-hosted WireGuard endpoint on a US VPS.

What Was Done

Ein OnePlus 12 wurde zuerst sauber gerootet. Erst nachdem Stock-Root stabil lief, wurde ein gerätespezifischer Custom Kernel hinzugefügt.

Das Setup blieb bewusst modular: Root zuerst, Stabilität prüfen, dann Kernel. Dadurch ließ sich bei Problemen klar erkennen, welche Änderung verantwortlich war.

case 12

Fall 12 — Xiaomi 14 und Mi-Unlock-Warteprozess

Device
Xiaomi 14
Country
Germany

The Problem

Bei einem Xiaomi 14 war nicht der Fastboot-Teil das Problem, sondern die serverseitige HyperOS-Unlock-Policy. Das Konto erfüllte zunächst nicht alle Voraussetzungen.

What Was Done

Created a fresh Mi Account on the device, bound it correctly with EU region, started the 168-hour timer immediately, then scheduled a callback for after the timer. On the second session, completed the unlock, flashed Xiaomi.eu HyperOS 2 build, installed Magisk, configured DenyList + Tricky Store for Sparkasse, DKB and N26.

Statt ein angebliches „7-Tage-Bypass-Tool“ zu verwenden, wurde auf den offiziellen Berechtigungszustand gewartet. Erst nach erfolgreichem Unlock ging es mit Root weiter.

case 13

Fall 13 — KernelSU auf POCO F6

Device
POCO F6
Country
United Kingdom

The Problem

Nach erfolgreichem Xiaomi-Unlock sollte KernelSU statt Magisk eingesetzt werden. Entscheidend war ein passender Kernel-/Build-Pfad für das konkrete POCO F6.

What Was Done

Unlocked bootloader (account had no prior unlocks, completed in standard waiting period), flashed KernelSU-bundled kernel built for HyperOS 2 base, installed KernelSU Manager. Configured app profiles so only Termux and AdAway have SU access. Added banking and Google Play to the umount-from-namespace list.

Root wurde erst eingerichtet, nachdem Stock-Firmware und Rückweg gesichert waren. Performance-Module kamen erst nach Stabilitätsprüfung hinzu.

case 14

Fall 14 — Nothing Phone 2a gerootet

Device
Nothing Phone 2a
Country
Canada

The Problem

Bei einem Nothing Phone 2a wurde der reguläre Fastboot-Unlock geprüft und der passende Boot-Workflow verwendet.

What Was Done

Das Beispiel zeigt, dass relativ offene Geräte trotzdem buildgenau behandelt werden müssen. Rooting bleibt ein Firmware-Prozess, kein markenweites Einheitsrezept.

result → Both apps verified, AFWall+ active. 80 minutes total.

case 15

Fall 15 — ROG Phone 8 Pro für Gaming gerootet

Device
Asus ROG Phone 8 Pro
Country
Saudi Arabia

The Problem

Das Ziel war tiefere Performance-Kontrolle auf einem Gaming-Gerät. Vor jedem Tuning wurden Temperatur- und FPS-Baselines erstellt.

What Was Done

Used Asus’s official unlock APK (still available in 2026 for ROG line), unlocked bootloader, patched ROG-specific boot.img with Magisk preserving Asus-signed components. Installed a community gaming kernel (BBR, schedutil tuned). Verified X Mode and AirTriggers still active. DenyList for Al Rajhi, STC Pay, urpay.

Es wurden keine pauschalen Thermal-Disabler installiert. Änderungen blieben konservativ, da maximale Peaks weniger wichtig waren als stabile Performance über längere Sessions.

case 16

Fall 16 — Importiertes Realme GT Neo 6 geprüft

Device
Realme GT Neo 6
Country
United Arab Emirates

The Problem

Ein importiertes Realme sollte geöffnet und gerootet werden. Zuerst wurden Region, Firmware und aktuelle Deep-Test-/Unlock-Verfügbarkeit geprüft.

What Was Done

Walked the client through reflashing the Realme UI Asia firmware via QPST flash mode, re-applied for in-depth test approval which this time accepted the device, completed the 24-hour required test period, then performed bootloader unlock. Installed Magisk + Tricky Store. Verified Emirates NBD, ADCB and FAB apps.

Da Realme/OPPO-Richtlinien sehr modell- und regionsabhängig sind, wurde keine nicht belegte Freischaltung versprochen. Der Fall wurde an die tatsächliche Eligibility gebunden.

case 17

Fall 17 — Pixel 6a vor Verkauf zu Stock zurückgeführt

Device
Google Pixel 6a
Country
United States

The Problem

Ein gerootetes Pixel 6a sollte für den Verkauf wieder auf Stock gesetzt werden. Factory Image, geänderte Partitionen und Bootloader-Zustand wurden geprüft.

What Was Done

Nach vollständiger Rückkehr auf passende Stock-Firmware wurde erst dann über Relock entschieden. Relock auf modifizierter Firmware wurde bewusst vermieden.

result → Device passes Verified Boot, sells as factory-fresh. 45 minutes.

case 18

Fall 18 — Motorola Edge 50 mit Unlock-Einschränkung

Device
Motorola Edge 50 Pro
Country
United Kingdom

The Problem

Ein Motorola Edge 50 zeigte eine eingeschränkte Unlock-Situation. Statt davon auszugehen, dass jedes Motorola vom Herstellerportal akzeptiert wird, wurde die Variante geprüft.

What Was Done

Der Fall machte deutlich, dass Retail- und Carrier-Modelle unterschiedlich behandelt werden. Wo der Hersteller keine Freigabe erteilt, wird kein erfundener Ersatzweg verkauft.

result → Unlock + Magisk + 2 banks verified. 95 minutes including the API workaround.

case 19

Fall 19 — Root-Eignung eines Vivo X100 bewertet

Device
Vivo X100
Country
United Arab Emirates

The Problem

Ein Nutzer wollte ein Vivo X100 rooten. Die technische Prüfung zeigte, dass ein allgemeiner offizieller Bootloader-Unlock für dieses Modell nicht verfügbar war.

What Was Done

Disclosed upfront that no software-only unlock exists for X100 in 2026. Verified via fastboot dump that the bootloader is fully locked with no oem unlock support. Offered a refund of the diagnosis fee (already free) and recommended the client either accept stock OS, or sell and switch to a Pixel / Xiaomi / OnePlus.

Statt einen riskanten Exploit zu empfehlen, wurde erklärt, welche Ziele ohne Root erreichbar sind und welche Servicepfade für Firmware oder Performance realistisch bleiben.

case 20

Fall 20 — Banking-Apps Monate nach Root plötzlich blockiert

Device
Galaxy S22
Country
Canada

The Problem

Ein lange funktionierendes Root-Setup verlor plötzlich Kompatibilität mit Banking-Apps. Ursache war keine neue lokale Änderung, sondern geänderte App-/Integrity-Prüfung.

What Was Done

Identified that the client’s Play Integrity Fix module was 2 versions behind (a Google rotation in late April 2026 invalidated the older fingerprint set). Updated PIF to the latest signed release from the original developer’s GitHub, refreshed the fingerprint via the included tool, rebooted. Verified Strong integrity, then tested both banking apps live.

Der Stack wurde überprüft und veraltete Komponenten entfernt. Der Fall zeigt, warum Banking-Kompatibilität nie als dauerhaft garantiert werden sollte.

case 21

Fall 21 — Sparkasse pushTAN und Integrity-Prüfung

Device
Xiaomi 13T
Country
Germany

The Problem

Ein gerootetes Gerät sollte weiterhin mit einer deutschen Banking-/TAN-App genutzt werden. Der konkrete App-Build und die Root-Signale wurden separat geprüft.

What Was Done

Es wurde bewusst keine allgemeine Aussage „Sparkasse funktioniert mit Modul X“ gemacht. Bank-Apps sind versions- und serverabhängig.

result → pushTAN activated, full banking functionality restored. 50 minutes.

case 22

Fall 22 — Google Wallet auf gerootetem Pixel

Device
Pixel 7 Pro
Country
United States

The Problem

Ein Pixel bestand bestimmte Integrity-Checks, Google Wallet lehnte das Gerät aber trotzdem ab. Die Ursache lag in zusätzlichen Signalen jenseits eines einzelnen Test-Tools.

What Was Done

Confirmed PIF was up to date, ensured DenyList covered Google Wallet (com.google.android.apps.walletnfcrel), Google Play Services and Google Play Store. Cleared Google Wallet data, signed back in, re-added Chase Visa from scratch. Walked the client through verifying the small charge SMS code.

Der Fall wurde als App-Kompatibilitätsproblem behandelt, nicht als Beweis, dass der Root falsch installiert war.

case 23

Fall 23 — WhatsApp-Übertragung von iPhone auf Samsung

Device
Samsung Galaxy A54
Country
United Kingdom

The Problem

Beim Wechsel von iOS auf Samsung sollte ein bestehendes WhatsApp-Archiv möglichst vollständig übernommen werden.

What Was Done

Statt Datenbanken manuell zu manipulieren, wurde der offizielle bzw. unterstützte Transferweg verwendet und anschließend geprüft, welche Medien und Chats tatsächlich übernommen wurden.

result → Full chat history including media restored. 60 minutes.

case 24

Fall 24 — Snapchat-Probleme nach Gerätehistorie

Device
OnePlus 11
Country
United States

The Problem

Snapchat verweigerte auf einem Gerät bestimmte Funktionen, obwohl Root entfernt worden war. Statt eine Anti-Abuse-Sperre zu umgehen, wurde die Gerätehistorie und App-Situation analysiert.

What Was Done

Cleared Snapchat data and the system-side device-id stores, cleaned residual Magisk references from the system identifier props, regenerated a fresh Android ID and Widevine ID via the appropriate Magisk modules, reinstalled Snapchat from a fresh Aurora Store login.

Der Fokus lag auf legitimer Wiederherstellung, sauberer Stock-Software und App-Support. Sicherheits- oder Plattform-Bans wurden nicht technisch umgangen.

case 25

Fall 25 — Pokémon GO auf gerootetem Gerät

Device
Pixel 8
Country
Canada

The Problem

Ein Nutzer wollte Pokémon GO auf einem gerooteten Gerät nutzen. Die Anforderungen berührten Root-Erkennung und Anti-Cheat.

What Was Done

Switched the device from Magisk to KernelSU-Next + SUSFS, installed Tricky Store + a fresh Pokémon-friendly fingerprint, and configured SUSFS to umount the namespace from the Niantic process. Tested launch over Wi-Fi and 5G.

Es wurde keine Anleitung zum Umgehen von Anti-Cheat-Schutz entwickelt. Stattdessen wurden die trade-offs zwischen Root und einem sauberen Gaming-Gerät erklärt.

case 26

Fall 26 — Instagram stürzt ständig ab

Device
Samsung Galaxy A14
Country
Saudi Arabia

The Problem

Client’s Instagram crashed on launch every time after a recent update. Reinstalling did not help. WhatsApp and other apps fine.

What Was Done

Instagram schloss sich auf einem Android immer wieder. Logs und App-/Systemzustand zeigten, dass kein Rooting nötig war.

Cache, App-Version und Systemkomponenten wurden geprüft. Der Fall wurde als normales Performance-/App-Problem gelöst.

case 27

Fall 27 — Starker Battery Drain auf Galaxy S22+

Device
Galaxy S22+
Country
United States

The Problem

Ein Galaxy S22+ verlor im Standby ungewöhnlich schnell Akku. Battery Stats, Wakelocks und Funkverhalten wurden untersucht.

What Was Done

Die Ursache lag in Hintergrundaktivität und nicht in einem pauschal „schlechten Akku“. Softwareänderungen wurden vor einem Hardwaretausch geprüft.

result → Battery back to ~28 hours mixed use. 50 minutes.

case 28

Fall 28 — Redmi Note 11 zeigt keinerlei Lebenszeichen

Device
Xiaomi Redmi Note 11
Country
United Arab Emirates

The Problem

Ein Redmi Note 11 reagierte nicht mehr auf normalen Boot oder Recovery. Es wurde geprüft, ob Fastboot, EDL/BootROM oder Lade-/Hardwareindikatoren erreichbar waren.

What Was Done

Da Hard-Brick-Diagnose Hardware und Software trennen muss, wurden keine Datenrettungs- oder Flash-Erfolge versprochen, bevor der tatsächliche Low-Level-Zustand klar war.

result → Device boots normally, battery healthy after recharge. 90 minutes.

case 29

Fall 29 — WLAN trennt sich ständig

Device
OnePlus Nord 3
Country
United Kingdom

The Problem

Client’s Nord 3 disconnected from home WiFi every 30–60 seconds and reconnected. Other devices on the same network were fine.

What Was Done

Ein Android verlor regelmäßig die Wi‑Fi-Verbindung. Statt sofort Firmware zu flashen, wurden Router, DHCP, Power Management, VPN und Systemlogs geprüft.

Der Fehler konnte eingegrenzt werden, ohne das komplette Gerät neu aufzusetzen.

case 30

Fall 30 — Kamera zeigt nur schwarzen Bildschirm

Device
Pixel 7a
Country
Germany

The Problem

Client’s Pixel 7a camera app showed a black viewfinder after a system update. Third-party camera apps had the same issue.

What Was Done

Eine Kamera-App zeigte ein schwarzes Bild. Logs halfen zu unterscheiden, ob App, HAL, Berechtigungen, Sensorservice oder Hardware beteiligt waren.

Erst nach dieser Eingrenzung wurden Softwarekomponenten repariert. Ein Custom ROM oder Root war nicht die erste Maßnahme.

case 31

Fall 31 — Extremes Thermal Throttling auf POCO

Device
POCO F5 Pro
Country
Saudi Arabia

The Problem

Ein POCO verlor nach wenigen Minuten Gaming deutlich Leistung. Frequenzen und Temperaturen bestätigten aggressives Throttling.

What Was Done

With the device already rooted, installed a community thermal config that loosens the early-throttling table while keeping the safety ceilings intact. Tuned Adreno frequency steps and disabled an aggressive RAM trim that was triggering CPU spikes.

Statt die Schutzmechanismen komplett abzuschalten, wurde ein konservativeres Profil verwendet und die Dauerleistung gemessen.

case 32

Fall 32 — Kindersicherung auf Galaxy A34

Device
Samsung Galaxy A34 (child)
Country
United States

The Problem

Für ein Kind sollte ein Galaxy A34 mit klaren App-, Zeit- und Standortregeln eingerichtet werden.

What Was Done

Set up Google Family Link as the primary supervision layer, then layered Bark for content monitoring of texts and supported social apps. Configured per-app time limits in Family Link, blocked browser categories at the DNS layer via NextDNS profile pushed to the device, enabled Find My Device location sharing to the parent’s account.

Die Lösung setzte auf transparente Familienfunktionen und sinnvolle Alerts statt auf möglichst versteckte Überwachung.

case 33

Fall 33 — Qustodio für zwei Kinder eingerichtet

Device
Galaxy A24 + Pixel 6a
Country
United Kingdom

The Problem

Zwei Familiengeräte brauchten unterschiedliche Alters- und Zeitregeln. Profile, Ausnahmen und Benachrichtigungen wurden getrennt konfiguriert.

What Was Done

Installed Qustodio on both devices, granted Device Administrator and Accessibility permissions correctly (this is the step most parents miss), set up per-child profiles in the Qustodio web dashboard, calibrated screen-time schedules and category filters to age-appropriate levels. Tested the uninstall-resistance on both devices.

Das Ergebnis war ein übersichtliches Dashboard statt einer Flut irrelevanter Meldungen.

case 34

Fall 34 — Family-Link-Grenzen geprüft

Device
Galaxy A14 (child)
Country
Canada

The Problem

Eltern wollten wissen, welche Funktionen Family Link tatsächlich kontrollieren kann und welche nicht.

What Was Done

Pulled Family Link audit logs, identified the workaround method (a known guest-account exploit on older Family Link builds). Force-updated Family Link, removed the guest accounts, blocked guest-mode at the device-policy level, and added secondary supervision via Bark for chat content. Disclosed all changes to the teenager as the parent insisted on transparency.

Statt ein stärkeres Monitoring-Tool automatisch zu verkaufen, wurden die vorhandenen Family-Link-Funktionen zuerst ausgeschöpft.

case 35

Fall 35 — mSpy auf Familiengerät bewertet

Device
Samsung Galaxy A55
Country
United Arab Emirates

The Problem

Ein Elternteil erwog eine tiefere Monitoring-App. Eigentum, Alter, Transparenz und lokale Rechtslage wurden vor der technischen Einrichtung besprochen.

What Was Done

Installed mSpy with the device physically present (mSpy requires manual install on Android), granted required Accessibility and Notification-listener permissions, configured the dashboard, set up the messaging modules, and verified data flowing into the parent dashboard.

Wo tiefere Überwachung nicht verhältnismäßig oder rechtlich unklar war, wurde eine transparentere Alternative empfohlen.

case 36

Fall 36 — LineageOS auf älterem Pixel

Device
Pixel 4a 5G
Country
Germany

The Problem

Ein älteres Pixel sollte nach Ende des OEM-Supports weiter sinnvoll genutzt werden.

What Was Done

Unlocked bootloader (already retail-unlocked), flashed LineageOS recovery, sideloaded LineageOS 22 build for redfin codename, then sideloaded the MicroG variant overlay and the F-Droid privileged extension. Configured Aurora Store for Play Store apps, set up Banking apps via Aurora.

Es wurde ein aktueller, gepflegter ROM-Build gewählt und der Rückweg auf Stock dokumentiert.

case 37

Fall 37 — GrapheneOS auf Pixel 8a

Device
Pixel 8a
Country
Canada

The Problem

Ein Nutzer wollte maximale Alltagssicherheit und Datenschutz, aber keinen Root-Zugriff.

What Was Done

Used the official GrapheneOS web installer over Chrome, unlocked bootloader, flashed GrapheneOS, re-locked bootloader. Installed Sandboxed Google Play, configured Vanadium browser, set up RBC and Wealthsimple — both worked first try with Sandboxed Play. Walked the client through GrapheneOS’s scoped storage and per-permission profiles.

GrapheneOS wurde als separates Sicherheitsmodell behandelt. Root wurde bewusst nicht zusätzlich installiert.

case 38

Fall 38 — Original-IMEI nach falschem Flash wiederhergestellt

Device
Xiaomi POCO X3 Pro
Country
Saudi Arabia

The Problem

Nach einem fehlerhaften Flash waren Modem-/EFS-Daten beschädigt. Ziel war die Wiederherstellung der ursprünglichen Geräteidentität.

What Was Done

Backed up the existing partitions, wrote the correct IMEI numbers from the device’s rear-cover sticker into the EFS/NV partition using the appropriate Qualcomm tool, then re-flashed the matching MEA-region modem firmware. Verified both IMEI numbers in the dialer and tested data on STC.

Es wurden nur ursprüngliche, legitime Identifikatoren wiederhergestellt. Kein Klonen oder Erfinden fremder IMEIs.

case 39

Fall 39 — Dual-Boot-Projekt auf OnePlus 9R bewertet

Device
OnePlus 9R
Country
United States

The Problem

Ein fortgeschrittener Nutzer wollte mehrere Systeme auf einem OnePlus 9R betreiben.

What Was Done

Partitionierung, A/B-Slots, Recovery-Risiken und Datenverlust wurden geprüft. Das Projekt wurde als experimentell und nicht als Standarddienst behandelt.

result → Dual-boot stable, both systems functional. 110 minutes including training.

case 40

Fall 40 — Anfrage zur Knox-Umgehung für Garantie abgelehnt

Device
Samsung Galaxy S20
Country
United Kingdom

The Problem

Ein Nutzer wollte einen modifizierten Samsung-Zustand so verschleiern, dass Garantieprüfungen getäuscht werden.

What Was Done

Declined the work and explained why: tampering with Knox to deceive a manufacturer warranty is fraud under UK consumer-protection law and against our policy. Offered an alternative — a third-party screen replacement quote and a check on whether the Knox-tripped state actually affects screen warranty (in this case, no, the hardware was within statutory rights regardless).

Die Anfrage wurde abgelehnt. Stattdessen wurden legitime Optionen wie Stock-Reflash und transparente Service-Kommunikation erklärt.

case 41

Fall 41 — Verschlüsselte Backups ohne Cloud übertragen

Device
Galaxy S23 Ultra
Country
Germany

The Problem

Ein Nutzer wollte lokale, verschlüsselte Backups zwischen Geräten übertragen, ohne sie zu einem Cloudanbieter hochzuladen.

What Was Done

Set up an air-gapped local transfer over USB-C OTG cable. Used Signal’s native device-to-device transfer for chats, exported the Aegis vault encrypted file, copied the KeePassXC database directly, and used WhatsApp’s local backup file plus chat-export for selected conversations. Verified each app on the new device.

Die Lösung nutzte lokale Verschlüsselung und direkten Dateitransfer. Der Fokus lag auf nachvollziehbarer Schlüsselverwaltung.

case 42

Fall 42 — Tasker-Fahrprofil

Device
Google Pixel 8
Country
United States

The Problem

Ein Fahrprofil sollte bei Bluetooth-Verbindung mit dem Auto automatisch Navigation, DND und Medien starten.

What Was Done

Built a Tasker profile triggered on the car head-unit’s Bluetooth MAC address. Stack: enable DND with calls-only exception for spouse, set brightness to 80%, launch Google Maps with a saved-route intent, resume the last Spotify playlist via Media Control, enable auto-reply to WhatsApp using AutoNotification ("driving — call you back at <ETA>"). Reverse profile fires on Bluetooth disconnect. Battery audit showed +0.4% per hour of use.

Der Workflow wurde eventbasiert gebaut, damit kein unnötiges Polling den Akku belastet.

case 43

Fall 43 — Autorisiertes Auto-Clock-In mit MacroDroid

Device
Samsung Galaxy A54
Country
United Kingdom

The Problem

Ein Field-Worker-Workflow sollte bei Ankunft an einem bekannten Arbeitsort eine freigegebene Anwesenheitsaktion auslösen.

What Was Done

Configured MacroDroid (chosen over Tasker for the simpler UI the client preferred). Geofence around the hospital site with a 50-metre radius. Trigger fires only between 06:00–22:00 to avoid false starts during personal visits. Stack: HTTP POST to the Trust webhook with auth token stored in MacroDroid variables, Telegram bot message via the Telegram-Bot plugin, switch ringer to vibrate. Departure trigger reverses and clocks out.

Die Automatisierung war transparent und autorisiert. Es wurde keine versteckte Mitarbeiterüberwachung gebaut.

case 44

Fall 44 — Telefon als Home-Assistant-Sensor

Device
OnePlus 12
Country
Germany

The Problem

Ein Android sollte Standort, Akku und bestimmte Gerätezustände an Home Assistant liefern.

What Was Done

Installed Home Assistant Companion app, registered the device, exposed all 32 available sensors. Configured HA-side automations: morning step-out-of-bed (detected via accelerometer + screen-on after 06:00) → bedroom lights warm 20%, kettle on. Phone reaching home Wi-Fi → presence binary sensor flips, away-mode disabled. Battery <20% in living room → TV pauses via the Sony Bravia integration. Two-way: HA can ring the phone to find it, push prioritised notifications, and trigger DND remotely.

Es wurden nur benötigte Sensoren freigegeben und die Datenwege dokumentiert.

case 45

Fall 45 — NFC-Modi für Büro, Schlafen und Auto

Device
Samsung Galaxy S23
Country
United Arab Emirates

The Problem

Mehrere NFC-Tags sollten verschiedene Profile aktivieren.

What Was Done

Sourced 5 NTAG215 stickers (2 spares), wrote each with NFC Tools to fire a Tasker task by ID. Built three Tasker profiles: bedside = DND on, alarm armed for next workday, brightness 0%, blue-light filter on; desk = focus mode (Slack + Gmail + Things only), bridge to Mac via KDE Connect, Pomodoro timer started; car dock = full driving stack as in the Pixel 8 case but adapted for Galaxy S23. Each profile reversible with a second tap on the same tag.

Das Setup ersetzte wiederholte manuelle Schritte und blieb für den Nutzer leicht editierbar.

case 46

Fall 46 — Telegram-Bot mit Termux und Tasker

Device
Google Pixel 7a
Country
Canada

The Problem

Power-user client wanted a daily 09:00 Telegram message from their phone to a private channel containing battery health stats, today’s calendar agenda, weather summary, and a list of any unread Signal threads — all generated on-device, no third-party servers.

What Was Done

Installed Termux + Termux:Tasker bridge. Wrote a small bash script that reads battery-stats from /sys via Termux:API, fetches weather from Open-Meteo (no API key), pulls the day’s calendar via Termux:API’s termux-calendar, and queries Signal-CLI for unread thread counts. Tasker profile: Time = 09:00 daily → run the script → POST the formatted markdown to the Telegram bot via curl. Logs kept on-device only. Battery cost ~0.2%/day.

Ein Gerät sollte lokale Daten erfassen und kontrolliert an einen Telegram-Bot senden.

API-Token, Script und Trigger wurden lokal dokumentiert. Es wurden keine Zugangsdaten in öffentlichen Dateien gespeichert.

Dein Fall sieht ähnlich aus?

Schick Modell, Build und den aktuellen Zustand. Ein ähnlicher Fall ist nur ein Ausgangspunkt — nicht automatisch dieselbe Lösung.

Kontakt — /de/kontakt Leistungen — /de/dienstleistungen