Was verhindert speziell, dass OTAs auf modifizierten /Systemen übernommen werden, und warum kann es nicht abgeschaltet werden?

Ich hatte einen ständigen Albtraum, OTAs auf keinem meiner (gerooteten) Geräte nutzen zu können. Sie booten in TWRP, beschweren sich über den Build-Fingerabdruck und werden nicht installiert, also muss ich auf eine vollständige ZIP-Datei warten und meine Systeme manuell flashen.

Was hindert die OTAs daran, über eine modifizierte /system-Partition zu installieren, und warum kann sie nicht besiegt oder deaktiviert werden?

Wenn es nicht besiegt/deaktiviert werden kann, warum kann mein modifiziertes /system nicht über seinen Build-Fingerabdruck lügen, um diese Validierung dazu zu bringen, die Installation der OTAs zuzulassen?

Antworten (2)

OTA-Dateien funktionieren, indem sie Dateien patchen, anstatt sie durch eine vollständige Kopie der neuen Version der Datei zu ersetzen. Das bedeutet, dass überprüft werden muss, ob die vorhandenen Dateien genau wie erwartet sind, oder der Patch-Prozess funktioniert nicht (oder könnte dazu führen, dass die Datei beschädigt wird). Wenn Sie den Fingerabdruck fälschen und die Anwendung des OTA erzwingen, erhalten Sie möglicherweise ein Gerät, das nicht booten kann, weil einige Dateien beschädigt sind.

Android 5.0 (glaube ich) wechselte von der Überprüfung nur der gepatchten Dateien zur Überprüfung der Partition als Ganzes, sodass jede Änderung (auch an einer Datei, die nicht gepatcht wird) dazu führt, dass dies fehlschlägt.

Haben Sie eine Idee, warum dies nicht entfernt oder besiegt werden kann?
Oh, ich verstehe - Sie sagen, dass die Inhalte der OTAs jetzt auf dem unveränderten System basieren, hmm. In diesem Fall bin ich nur verwirrt darüber, was auf einem / System, das gerootet und dann „vollständig entrootet“ wurde, so „anders“ sein könnte.
Hallo, Sie glauben also, OTAs führen jetzt dmverity-ähnliche Überprüfungen durch?
@moonbutt74, es scheint so . Ich denke, das liegt daran, dass das Entfernen von Alien-Dateien /systemwährend des Unrootings nicht funktioniert, um ein Systemupdate zu täuschen, da die Anordnung von Bits in einem Block vor dem Rooting und nach dem Unrooting sicherlich unterschiedlich wäre.

Zusätzlich zur Antwort von @bmdixon

  1. OEMs wie Samsung haben einen Knox-Zähler, der ausgelöst wird, sobald Sie rooten oder die Bestandswiederherstellung durch benutzerdefinierte ersetzen. Früher gab es Abhilfemaßnahmen, aber ab Note 4, die Knox auslöst, „brennt“ diese Information in die Hardware. Die einzige Möglichkeit, den Knox-Status wiederherzustellen, besteht darin, diesen Chip auf dem Motherboard zu ändern !! (Mir ist nicht bekannt, wie dies erreicht wird, aber es ist als E-Mail-Antwort von Samsung aktenkundig). Ich erwarte, dass OTA dies zuerst überprüft

  2. OEMs wie Huawei (mein aktuelles Gerät ist Honor 6) ermöglichen es Ihnen, den Bootloader zu entsperren und ihn durch eine Garantie abzudecken, die OTA-Updates ermöglicht, wenn gerootet, aber die Bestandswiederherstellung intakt ist. Das Ersetzen der Wiederherstellung schlägt OTA fehl

  3. Ich vermute, dass Fluggesellschaften, die ihre Kunden "einsperren", auch ihre eigenen Mittel zur Überprüfung einsetzen werden, bevor sie OTA zulassen (wahrscheinlich ist dies ein Grund, warum es unterschiedliche Verzögerungen bei der Einführung von OTA durch Fluggesellschaften gibt).

Es ist also möglicherweise keine einfache Lösung, den Wiederherstellungstrick OTA zu haben ... zu viele Tricks zum Erlernen und proprietäre, was NICHT der Zweck von TWRP ist