Hörmal, es ging im Ausgangsthread im um Festplattenverschlüsselung in einem konkreten Kontext. Du behauptest, das wäre unsicher und führst als Beispiel was ganz anderes an, das in diesem Kontext nicht funktionieren würde. Dann gehst du noch weiter und fängst mit WLAN-Kram an, der damit noch weniger zu tun hat.
Dann versuchst du die Tatsache, dass du das eigentliche Thema nicht gelesen hast (dass es z.B. bei „Suspend“ um „Suspend to Disk/Hibernate“ ging, war aus dem Thread heraus einwandfrei ersichtlich) so hinzudrehen, dass alle anderen, die’s gelesen und im Kontext geantwortet haben, blöd seien.
Was deinen verlinkten Wiki-Artikel angeht: der gibt’s nicht her, dass jemand eine verschlüsselte Systempartition hernimmt und gezielt ohne Kenntnis des Schlüssels ein bestimmtes Binary auf eine bestimmte Weise ändert, während er das restliche System intakt lässt. Hast du den Artikel möglicherweise selbst gar nicht gelesen, sondern nur das Erstbeste, halbwegs seriös und komplex Aussehende mit dem Stichwort hergenommen?
wanne hat geschrieben: 
07.10.2017 00:40:32
Wenn du den Artikel gelesen hättest wüsstest du warum das Quatsch ist:
Der Angreifer müsste wissen, wo genau das Binary liegt, und wenn man nicht gerade installiert, indem man ‘n Image auf die Platte bügelt, kann ich mir gerade schwer vorstellen, wie der Angreifer weiß
im Vergleich zur Aussage im von dir selbst verlinkten Beitrag:
jakoblell.com hat geschrieben:For implementing the attack, we need to know the exact position of the file we want to modify on the physical hard disk.
Hast du dem Herrn auch schon geschrieben, dass das Quatsch ist?
… so, ich mach mal nicht weiter. Prinzipiell kann man das auch auf andere deiner Statements anwenden, aber das macht nur schlechte Laune und verschwendet Zeit – ich votiere weiterhin für ’ne Möglichkeit, deine Beiträge ignorieren zu können; dieses zwanghafte Profilieren, teils unter Herabsetzung anderer Personen und unter Verdrehung der Tatsachen, ist irgendwie nicht mehr schön.
Ich bleibe außerdem bei der Aussage: wenn man sein System mit dm_crypt verschlüsselt, hat ein Dritter, der das Device im ausgeschalteten Zustand vorfindet, keine Möglichkeit, dieses gezielt zu manipulieren. Denkbar wäre eine Manipulation von /boot, doch auch dieser kann man vorbeugen. Außerdem ist’s, mit Blick auf den Ausgangsthread, äußerst unwahrscheinlich, dass das überhaupt relevant ist: Selbst, wenn jemand den Laptop klaut und die Files unter /boot so manipuliert, dass beim nächsten Boot durch den Inhaber der Passphrase die Schlüssel für die anderen Partitionen abgegriffen werden, und ihn dann zurückgibt (was, wenn man nicht gerade für ganz dubiose Einrichtungen [Kriminelle, Staat, beides] arbeitet, noch viel mehr als äußerst unwahrscheinlich ist), bootet man die Kiste anschließend von ’nem Livesystem und sichert die Daten (wenn man, unvorsichtigerweise, kein Backup hatte), nullt die Platte und fertig.
Nichtsdestotrotz sind die oben verlinkten Sachen interessant, und zeigen auch gleich die äußerst triviale Möglichkeit auf, solche Angriffe zu unterbinden: man schreibt einfach eine zufällig große Datei in das FS, bevor man mit der Installation beginnt, oder benutzt schlicht ’nen Offset, oder macht irgendwas anderes, das es einem Angreifer selbst unter der unrealistischen Annahme, er könnte die Installation des vorgefundenen, erstmal nicht bekannten, Systems ausreichend genau nachstellen, nicht erlaubt, die genaue Position der zu manipulierenden Datei zu erraten. Wäre vielleicht sogar ’nen Feature-Request an die Entwickler des Debian-Installers wert (sofern das nicht schon implementiert ist)?
