Was bewirkt die Option "Überprüfung der Signatur der Zip-Datei" in der benutzerdefinierten Wiederherstellungs-TWRP? Woher weiß ich, ob es bei der Installation überprüft werden sollte?
Beachten Sie, dass Sie es in den TWRP-Einstellungen deaktivieren können.
Toogley
@toogley Wie kann man die "Überprüfung der Zip-Dateisignatur" in den TWRP-Einstellungen deaktivieren?
NilsB
1
@NilsB Sie sollten es in den Einstellungen oben ankreuzen können. Vielleicht verwenden Sie eine alte Version von TWRP?
Ksyrium
Antworten:
8
Grundsätzlich aktiviert das Flag zur Überprüfung der Zip-Dateisignatur das Flashen nur, wenn die Zip-Datei vom Entwickler ordnungsgemäß signiert wurde. Dies ist (fast) die gleiche Methode, mit der Jar-Dateien in Java signiert werden.
Grundsätzlich möchten Sie vor dem Ausführen eines Programms eines Drittanbieters sicherstellen, dass es nicht manipuliert wurde ( Integrität ) und dass es tatsächlich von der Entität erstellt wurde, von der es behauptet, dass es stammt ( Authentizität ). Diese Funktionen werden normalerweise durch ein digitales Signaturschema implementiert, das garantiert, dass nur die Entität, die den Signaturschlüssel besitzt, eine gültige Codesignatur erstellen kann. Der Signaturüberprüfungsprozess überprüft sowohl, ob der Code nicht manipuliert wurde, als auch, dass die Signatur mit dem erwarteten Schlüssel erstellt wurde.
Beachten Sie aus dem oben Gesagten, dass dies (offensichtlich) nicht erkennen kann, ob der Code selbst Malware usw. ist, sondern dass er so ist, wie er war, als er vom Entwickler signiert wurde. Sie müssen dem Entwickler jeder Software vertrauen, die Sie flashen.
Ein Beispiel hierfür ist, dass Sie ein benutzerdefiniertes ROM nicht über eine Bestandswiederherstellung flashen können, da bei der Bestandswiederherstellung nach einer Signatur des Herstellers gesucht wird.
Es kann auch erkennen, ob eine Zip- Datei beschädigt ist, stellt jedoch keine endgültige Überprüfung dar. Sie sollten die MD5-Summe der Datei überprüfen und mit der vom ROM-Entwickler bereitgestellten vergleichen.
„ Woher weiß ich, ob es überprüft werden sollte? “ Dies wird wahrscheinlich variieren, je nachdem, was Sie tun. Ich habe es im Allgemeinen auf dem Standardwert der bestimmten Wiederherstellung belassen, die ich verwende, und ich hatte es noch nie um es auf Zip-Dateien zu überprüfen oder zu deaktivieren. Beachten Sie, dass einige perfekt funktionierende Pakete möglicherweise falsch signiert sind und möglicherweise perfekt installiert werden, wenn Sie die Überprüfung deaktivieren. Umgekehrt kann es sich jedoch um eine beschädigte Datei handeln und das Gerät booten.
Ich lasse es aktiviert, und wenn jemand in einem Thread / der Entwickler sagt, dass die Installation in Ordnung ist, werde ich ein Nandroid- Backup erstellen und versuchen, es mit deaktivierter Signaturüberprüfung zu flashen. (IMMER ein Backup erstellen!)
Hier ist ein Beispiel für den Versuch, ein benutzerdefiniertes ROM auf einer Standard-S4-Wiederherstellung zu installieren:
Update-Paket finden ...
Update-Paket
öffnen ... Update-Paket überprüfen ...
E: Keine Signatur (188 Dateien)
E: Überprüfung fehlgeschlagen
Installation abgebrochen.
Hier ist ein Link zu den technischen Informationen zu GitHub, auf die hier nicht näher eingegangen werden kann.
Soweit ich weiß, erfordert die Überprüfung der Authentizität einer Signatur (im Gegensatz zu nur ihrer Integrität) eine Reihe von Stammzertifikaten, von denen eines das Zertifikat signieren sollte, das die Datei selbst signiert hat - selbstsignierter Code garantiert nur die Integrität, es sei denn Der Benutzer vergleicht den Zertifikatfingerabdruck manuell mit einer vertrauenswürdigen Quelle. Ist in TWRP eine Liste der Stammzertifikate integriert?
Antworten:
Grundsätzlich aktiviert das Flag zur Überprüfung der Zip-Dateisignatur das Flashen nur, wenn die Zip-Datei vom Entwickler ordnungsgemäß signiert wurde. Dies ist (fast) die gleiche Methode, mit der Jar-Dateien in Java signiert werden.
Von hier aus
Beachten Sie aus dem oben Gesagten, dass dies (offensichtlich) nicht erkennen kann, ob der Code selbst Malware usw. ist, sondern dass er so ist, wie er war, als er vom Entwickler signiert wurde. Sie müssen dem Entwickler jeder Software vertrauen, die Sie flashen.
Ein Beispiel hierfür ist, dass Sie ein benutzerdefiniertes ROM nicht über eine Bestandswiederherstellung flashen können, da bei der Bestandswiederherstellung nach einer Signatur des Herstellers gesucht wird.
Es kann auch erkennen, ob eine Zip- Datei beschädigt ist, stellt jedoch keine endgültige Überprüfung dar. Sie sollten die MD5-Summe der Datei überprüfen und mit der vom ROM-Entwickler bereitgestellten vergleichen.
„ Woher weiß ich, ob es überprüft werden sollte? “ Dies wird wahrscheinlich variieren, je nachdem, was Sie tun. Ich habe es im Allgemeinen auf dem Standardwert der bestimmten Wiederherstellung belassen, die ich verwende, und ich hatte es noch nie um es auf Zip-Dateien zu überprüfen oder zu deaktivieren. Beachten Sie, dass einige perfekt funktionierende Pakete möglicherweise falsch signiert sind und möglicherweise perfekt installiert werden, wenn Sie die Überprüfung deaktivieren. Umgekehrt kann es sich jedoch um eine beschädigte Datei handeln und das Gerät booten.
Ich lasse es aktiviert, und wenn jemand in einem Thread / der Entwickler sagt, dass die Installation in Ordnung ist, werde ich ein Nandroid- Backup erstellen und versuchen, es mit deaktivierter Signaturüberprüfung zu flashen. (IMMER ein Backup erstellen!)
Hier ist ein Beispiel für den Versuch, ein benutzerdefiniertes ROM auf einer Standard-S4-Wiederherstellung zu installieren:
Hier ist ein Link zu den technischen Informationen zu GitHub, auf die hier nicht näher eingegangen werden kann.
quelle