Warnhinweis beim Systemstart entfernen

Hallo Zusammen,
ich habe da mal eine Frage. Ich habe folgende Installation: Install /e/ on a Samsung Galaxy S5 Neo - “s5neolte” auf einem SM-G903F durchgeführt.
Die Installation hat ohne Probleme funktioniert. Es scheint auch alles Andere funktioniert ohne Probleme. Ich bekomme jetzt aber bei jedem Start folgende Warnmeldung:
Android-System
Es liegt ein internes Problem mit deinem Gerät vor. Bitte wende dich diesbezüglich an den Hersteller.

Es wäre super wenn Jemand eine Lösung hat. Vielen Dank

Hi, beim selben Telefon dieselbe Meldung. Einfach wegwischen…

Hallo. Danke für die Antwort. Ich gehe auch davon aus das es sich um eine reine Info Meldung handelt. Es wäre trotzdem schön wenn man diese Meldung eliminieren könnte.

1 Like

bei manchen Geräten sind die Methoden zum flashen der Hinweise bekannt (Motos). Wenn es was für Dich ist, könntest Du schauen ob die Methoden für neuere Samsungs sich auf die älteren anwenden lassen, bzw generell bei XDA suchst was sich machen lässt.

Ich habe das Selbe beim Samsung A3 (2016).
Natürlich lässt es sich wegwischen, aber so eine Meldung kommt ja nicht umsonst.
Es muss ja im Code eine Stelle geben, die diese Meldung auslöst.
Somit dürfte irgendetwas nicht funktionieren.
Hat sich der Entwickler schon mal mit dem Thema befasst?

ja, siehe u.a. hier https://doc.e.foundation/faq#does-e-allow-for-the-bootloader-to-be-locked-on-phones-that-support-verified-boot - hängt vom Gerät ab ob das Tooling bekannt ist um den Relock zu machen.

Die beste community Referenzliste die ich kenne ist https://hub.libranet.de/wiki/and-priv-sec/wiki/verified-boot , eine gute Erklärung zu AVB im PostmarketOS Wiki

Eine Aufzählung wessen man sich aussetzt ohne verifizierter Bootkette ist https://android.stackexchange.com/questions/36830/whats-the-security-implication-of-having-an-unlocked-boot-loader

Als Nutzer musst Du abwägen ob das Szenarien sind die ein Problem sind, minimal solltest Du Dich um Verschlüsselung der userdata Partition kümmern, das gibt Dir im Verlustfall ein wenig Zeit um Passwörter zu rotieren von Accounts die auf dem Gerät waren.

Dein A3 2016 ist dort aufgeführt, das s5neolte nicht, aber eng verwandte andere Geräte.

1 Like

Also ist ein entsperrter Bootloader die Ursache der Meldung?
Innerhalb der System-UI habe ich keine Möglichkeit das zu ändern.
Das System habe ich mittels TWRP installiert was auch aktuell als Recovery aktiv ist.

ja, ein entsperrter Bootloader macht das und ist zunächst ein berechtigter Hinweis. Eine verifizierte Bootkette wirst Du nach dem flashen zunächst nicht kriegen, es sei denn Du baust alles selbst. Gehst Du zurück zur Stockrom hast Du wieder eine Kette und der Warnhinweis verschwindet.

Sieht das Gerät keine Updates mehr würde ich aber eher die Schwäche beim Bootloader akzeptieren als Softwarelücken zur Laufzeit. Kernellücken wirst Du eh nicht ersetzt kriegen wenn das Gerät vom Hersteller nicht mehr unterstützt wird.

1 Like

Vorrausgesetzt man ist also aufgeklärter Nutzer eines ungelockten bootloaders, hat sich mittels Verschlüsselung ein stückweit Zeit erkauft - wie flasht man sich den Warnhinweis schön? das weiss ich nur bei Motorolas einer bestimmten Generation und habe noch keine Erfahrung mit Samsung-Geräten, aber das immer Hilfreiche XDA skizziert das Vorgehen das man prüfen kann:

param.bin* / up_param.bin in den offiziellen Images finden, modifizieren, zurückspielen (odin/heimdall). Die jpgs die man ersetzen möchte sind Warning_L.jpg / Warning_SVB.jpg in dem param.bin Beispiel (ist ein einfaches entpackbares und wieder erstelltes tar archiv / tarball).

1 Like

An “Kosmetik” hab ich kein Interesse.
Warum liefert ein “offiziellen” e-Build diesen Fehler?

für das “Warum” musst Du auf Lesetour gehen. Im Grunde ist an den Samsung images ja nichts “offiziell” im Herstellersinne.

Der nicht kosmetische Weg setzt ein Gerät vorraus das sich relocken lässt (“Android Verified Boot 2 - fähig”): die Pixels können es, weshalb jene Geräte von Calyx/Graphene unterstützt werden. Das FP3 auch, aber mit einer Einschränkung (kritische Partitionen können ohne unlock via EDL geflasht werden, was eine Schwäche ist).

Allerdings, statt dem “grünen” Bootscreen kommt dann trotzdem der “gelben” Warnhinweis, weil nicht-Hersteller-Keys zum signieren der Partitionsinhalte verwendet wurden - ist deswegen aber nicht weniger sicher. Mindestens in dem Fall wäre die Kosmetik eines eigenen Bootlogos berechtigt :slight_smile: hier der Ablauf: Boot Flow  |  Android Open Source Project

Eine ganz gute Erklärung zum unlock/relock Thema ausserhalb der Android developer doku ist A discussion about bootloader locking/unlocking... AKA I want to relock my bootloader, should I? : LineageOS

2 Likes

Offiziell ist hier wohl nichts auch nur von einem einzigen Hersteller.
Hier, oder bin ich hier völlig falsch(?), werden alternative Betriebssysteme angeboten, oder irre ich da?

Zitat aus verlinktem Artikel:
Authorized operating systems are usually signed by the manufacturer of the phone with a private encryption key to which only they have access, and this signature is checked before the operating system is allowed to load.”

Hmm, dann sollte ich also lieber von all diesen Projekten die Finger lassen.
Machts gut e…

hängt vom Gerät ab ob Du die Finger davon lassen musst: ist AVB2 implementiert kannst Du bzw das Projekt eigene Keys hinterlegen und die Bootpartitionen damit signieren. Calyx/Graphene unterstützen dann aber auch nur Geräte die das Implementiert haben und noch Updates für die firmware blobs erhalten - die Pixels. Das würde deinem Anspruch gerecht werden. Auch /e/ könnte das Vorgehen auf jenen Geräten unterstützen, das ist nur (noch) nicht der Projektfokus

1 Like

Nach dem, was ich in dem von dir dankenswerterweise verlinkten Artikel lesen konnte, ist das eine vom Softwarehersteller implementierte Abfrage.
Soweit so gut.
Warum geht kein Autor (ja, alles Hobby und so weiter) daran und implementiert in die Custom Rom ala Lineage OS und seine Forks vergleichbares?

Stattdessen wird man im besten Fall (!) von einer Warnmeldung aufgeschreckt, im schlimmsten Fall passiert gar nichts!

Pixel fällt raus, da nur (seitens G**gle, und damit auch Graphene) eine arg begrenzte Updatezeit des OS.