Thunderbird – Ausführen beliebigen Programmcodes

Thunderbird About infos 52.5.0
Alle Thunderbird Versionen vor 52.5.0 sind von einer Remote-Code-Execution (RCE) Schwachstelle und anderen Sicherheitslücken betroffen, die als schwerwiegend eingestuft wurden.

Alarmstatus

Fedorabenutzern stehen derzeit (Stand: 28.11. 14:19 Uhr) KEINE Updates zur Verfügung.

Wie uns Jan Horak von RedHat mitteilt, befindet sich Thunderbird 52.5.0 derzeit im Bau. Testversionen werden daher vermutlich heute noch für Fedora bereitstehen.

Update

Seit 14:55 Uhr stehen die Updates für Fedora zum Download in Koji bereit.

Die frischen RPMs könnt Ihr dann für Eure jeweilige Fedoraversion hier finden :

Fedora 25 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005614
Fedora 26 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005616
Fedora 27 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005615
Fedora 28 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005618

CERT Warnung zu Thunderbird

Die Warnung des Bund-CERT finden Sie hier : https://www.cert-bund.de/advisoryshort/CB-K17-2035

Thunderbirds Mitteilung

Mozilla stuft die Sache schon etwas genauer ein und dafür, das es bereits am 23. November 2017 gemeldet wurde, haben unsere Distributionen echt langsam gearbeitet, alle, auch Suse .

Wer sich ein Bild machen will, hier die nötigen Infos:

Impact: critical
Products: Thunderbird
Fixed in Thunderbird 52.5

„In general, these flaws cannot be exploited through email in the Thunderbird product because scripting is disabled when reading mail, but are potentially risks in browser or browser-like contexts.“

CVE-2017-7828: Use-after-free of PressShell while restyling layout

„A use-after-free vulnerability can occur when flushing and resizing layout because the PressShell object has been freed while still in use. This results in a potentially exploitable crash during these operations.“

CVE-2017-7830: Cross-origin URL information leak through Resource Timing API

„The Resource Timing API incorrectly revealed navigations in cross-origin iframes. This is a same-origin policy violation and could allow for data theft of URLs loaded by users.“

CVE-2017-7826: Memory safety bugs fixed in Firefox 57, Firefox ESR 52.5, and Thunderbird 52.5

„Mozilla developers and community members reported memory safety bugs present in Firefox 56, Firefox ESR 52.4, and Thunderbird 52.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort that some of these could be exploited to run arbitrary code.“

Glückwünsche

Wie unsere Quellen berichten, stellt OpenSUSE bereits eine gepatchte Version für SUSE Linux Enterprise 12 sowie OpenSUSE Leap 42.2 und 42.3 bereit.

Glückwünsche an SUSE, Ihr wart die ersten 🙂

 

gleiche RPMs aus verschiedenen Quellen

Ein bisschen speziell ist unser heutiger Fall von Systemupgrade. Wir haben mehrere Repositories/Quellen von RPM Paketen für ein Paket, wollen aber das System per DNF upgraden und ein Paket aus einem bestimmten Repo benutzen.

Das Problem

Wir haben Fedora 25 als OS mit dem Default PHP von Fedora und zwei anderen PHP Versionen von Remi, einem französischen Repository für Serversoftware. Ein Serverupgrade kann man leicht mit

dnf –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

durchführen. Damit alle zusätzlichen Rpms von Drittrepos auch mitkommen beim Update, muß das jeweilige Repo global aktiviert sein, oder man gibt es in der Zeile mit an :

dnf –enablerepo=remi –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

Wenn man das in unserer Ausgangssituation tut, bekommt man einen Quellwechsel ins Spiel, denn man nicht unbedingt haben will. Remi hat nämlich eine neuere Version von PHP als das Fedorarepo.

Der Unterschied

Das hat natürlich einen Grund, Remi hat sich genau dem gewidmet, neigt aber dazu ohne umfangreiche Testrepos zuarbeiten. Fedora dagegen hat eine Communitytestumgebung, auf der Tester die Pakete bewerten müssen, bevor Sie ins Stablerepo gepusht werden.

Fedora hat also ggf. die stabiler laufenden Pakete, weil überhaupt jemand mal testhalber so ein Paket installiert hat. Auf einer Serverumgebung wollen wir natürlich genau dies haben, außerdem könnten die Remi Pakete anders kompiliert sein, und daher unerwartete Nebenwirkungen haben, was strikt zu vermeiden ist.

Quellrepowechsel verhindern

Gibt man jetzt das Upgradekommando ein und hat alle Quellrepos aktiviert, sieht Dnf das „neuere“ PHP Paket bei Remi und wechselt die Quelle, genauso, also wenn man das Testrepository aktiviert und dort ein neueres Paket vorhanden ist.

Daher muß man das Remirepo deaktivieren und erstmal normal upgraden. Nach dem Reboot kann man dann einfach dnf update benutzen um die Pakete zu aktualisieren, die im Remirepo vorhanden sind.

Überraschung

Bei unserem Beispiel F25 zu F26 und PHP kommt es zu einem Versionssprung von PHP 7 auf PHP 7.1 . Damit haben wir jetzt ggf. zweimal 7.1. drauf, einmal von Fedora und einmal von Remi, wo man doch eigentlich 7.0 und 7.1. haben wollte.

Also lösen wir das auf, indem wir 7.1 von Remi entfernen und 7.0 aufspielen:

dnf –enablerepo=remi update php56* php72*
dnf –enablerepo=remi erase php71*
dnf –enablerepo=remi install -y php70-php-process php70-php-cli php70-runtime php70-php-imap php70-php-common php70 php70-php-pdo php70-php-mbstring php70-php-json php70-php-pear php70-php-gd php70-php-mcrypt php70-php-mysqlnd php70-php-xml

Glückwunsch. Sie haben jetzt vier PHP Versionen auf Ihrem Server 😀

Mit FedUP, dem eigentlichen Upgradetool, hätte man das so nicht geschafft, da wäre das PHP dann auch von Remi gekommen.

Redhat-Webseite des Session-Replaying bezichtigt

Da haben es Forscher der Princeton Universität mal genauer genommen und eine Menge bekannter Webseiten auf sogenanntes Session-Replaying untersucht. Dummerweise sind davon nicht nur hierzulande eher unbekannte Webseiten zu finden, sondern auch Teamviewer, wordpress.com, wp.com, conrad.de, comodo.com, Skype & Microsoft und Redhat .

Was ist Session-Replaying ?

Session-Replaying bezeichnet Trackingtechniken in Javascript, die alle Tastatureingaben, alle Mausbewegungen usw. aufzeichnen und zur Auswertung an einen Drittanbieter übermittelt. Natürlich ohne vorher zu fragen, ob die das dürfen. Mit den Daten kann man als Webseitenbetreiber auswerten lassen, wo die eigenen Seiten besonders gut oder besonders schlecht sind. Soweit, so „naja“. Jetzt zeichnen die Scripte aber auch Fehleingaben auf, also z.B. alles was in der Zwischenablage ist und per Copy&Paste unabsichtlich kopiert wird, bspw. auch Passwörter.

Was damit für Schindluder getrieben werden kann, kann sich jeder selbst ausmalen, dem das Copy&Paste schon einmal seine Dienste versagt hat. Das geht nämlich leider schneller, als einem Lieb ist.

Für Redhat kommt der Dienst von clicktale.net ins Spiel. Dieser wurde von Princeton mit dem Vermerk : „evidence of session recording“ versehen.

Gegenmaßnahmen

Wenn es nach dem jüngsten FireFox Update auf 57 gegangen wäre: Keine.

Glücklicherweise hat Giorgio Maone sein Plugin NoScript auf die neue Firefox Api angepaßt. Damit kann man die Tracking-Domains sperren, bzw. erst gar nicht aktivieren. Also, alle die an Giorgio gezweifelt haben, sollten vor Ihm auf die Knie fallen und um Entschuldigung bitten. Der Mann und sein Plugin können Euch jeden Tag den Arsch retten! Das Teil ist für den Datenschutz der Goldstandard. Wundert mich eigentlich, daß die Bundesdatenschutzbeauftragte das nicht für jeden Behörden PC vorschreibt. Das wäre ja mal was 🙂

Die Liste

Wer sich die Liste ansehen will, die ist hier erhältlich:

https://webtransparency.cs.princeton.edu/no_boundaries/session_replay_sites.html

Ihr werdet noch mehr prominente Namen finden z.B. addidas.com , dominos.com ( Ex-Joeys ) , symantec.com, mongodb.com, cpanel.net, magento.com, bitdefender.com, acrobat.com, worldoftanks.com und wenig verwundernd kaspersky.ru .

Alle Apacheprozesse gleichzeitig stracen

Der Apache Webserver kommt ja mit mehreren Methoden daher, wie er effektiv möglichst viele Anfragen gleichzeitig beantworten kann. Die alte Prefork-Methode, die nicht mit HTTP2 kompatibel ist, startet dazu einen Prozess mit wenigen Kindern und splittet neue Prozesse ab, sobald eine Anfrage reinkommt.

Ein einfaches strace -f -p [pidvonerstemhttpd] reicht völlig aus um alle Zugriffe auf den Apachen zu tracen.

Das Event-Modell

Im Eventmodell , das für HTTP2 nötig ist, klappt das nicht mehr ganz so leicht. Hier müssen tatsächlich alle laufenden Prozesse gleichzeitig getraced werden, was in dem Beispiel hier:

├─httpd─┬─httpd(apache)
│ └─4*[httpd(apache)───63*[{httpd}]]

schon sehr,sehr viel Tipparbeit wäre ( > 240 pids) . Natürlich kann man das vereinfachen, indem man ein paar kleine Shellanweisungen nutzt:

strace -f -p `pidof httpd | sed -e "s/ /,/g"`

pidof als Befehl gibt uns leerzeichensepariert alle Prozessids zurück, die zum Httpd gehören. Leider kann strace die so nicht verarbeiten, also müssen wir die Ausgabe in kommasepariert umwandeln, dies macht der SED – Befehl. Die Backticks führen die Befehlsanweisung vor dem Aufruf von strace aus, so daß das Ergebnis direkt als Argument benutzt werden kann.

Linux – mysqldump sieht Leerzeichen als leeren Datenbanknamen an

Erinnert Ihr Euch noch an diesen Beitrag : Solution – mysqldump – No database selected when selecting the database aus dem Jahr 2016 ?

MariaDB & mysqldump

Damals stolperte ich über einen Fehler im Kommandozeilenparsing von Mysqldump.

Wie sich herausgestellt hat, konnte der Betreuer Michael Scholm bei Redhat die Ursache für das Problem entdecken. Kommt Ihr nie drauf: Das  war Schuld ! Oh ?! Ihr habt es nicht gesehen, hier nochmal  . Vielleicht mit der Lupe, da: > <. Ein Space.  Hier … zwischen dem „usr/bin/mysqldump“ und dem „–addlocks“ ist ein “ “ zuviel drin:

/usr/bin/mysqldump  --add-locks -e --force -R ....

Da es keine Option ist, wird es tatsächlich als valider Versuch, einen Datenbanknamen anzugeben gewertet.IMHO, ein Parser-Logik-Bug. Redhat sieht das anders: „not a bug“. Da jetzt raus ist, was es verursacht, kann man es ja leicht beheben.

etwas Kontext

Die Parser für Linux sind, sagen wir mal, ein bisschen eigen und deren Interpretation auch. Als Trenner zweier Argumente einer Kommandozeile gilt ein freistehendes Leerzeichen. Die Bash-Shell entfernt doppelte Leerzeichen und setzte ein Leerzeichen an die Stelle. So ein Leerzeichen zu viel ist schnell getippt und würde zu vielen „Dicke Finger-Syndrom“-Problemen führen, weil ..

… Ja, weil der Parser ohne diesen Trick, zwei Leerzeichen in Folge so übersetzen :

ls -la  foo => ls -la "" foo

Weil „Leerzeichen“ sind Trenner, also steht da oben eigentlich: „ls{Trenner}-la{Trenner}{Trenner}foo .

Wenn man aber zwischen den Trennern nichts hat, dann kommt ein leeres Argument raus. Was ein leeres Argument bedeutet, zeigt sich hier im Beispiel:

[marius ~]$ ls -la "" foo
ls: Zugriff auf '' nicht möglich: No such file or directory
ls: Zugriff auf 'foo' nicht möglich: No such file or directory

Wie man sehen kann versucht ls tatsächlich auf aka. „“ zuzugreifen. Wie das gehen soll ? Gar nicht. Ist ein Logikbug im Kontext von ls . Es wiederspricht der Natur eines ls , etwas aufzulisten, das es nicht gibt. Ergo müßte das Argument ignoriert werden. Jeder Mensch würde das so machen. Computerprogramme sind in der Beziehung blöde. Deswegen gibt es die Bash, die das Doppel-Leerzeichen wegnormaliziert und so vorhersehbare Fehler vermeidet, weil ..

Fehler vermeiden

wie man im obigen ls Beispiel gesehen hat, kann man es ja explizit angeben, wenn man muß => „“ oder “

MariaDB zieht sich jetzt auf den Standpunkt zurück, daß mysqldump sich ja nur wie ls verhalten würde. Tut es natürlich nicht, weil mysqldump komplett failed, wo ls einfach weitermacht und einen Fehler ausgibt.  Naja, Nobodys perfect.

Update

… oh, Redhat hat die Meinung geändert und einen Featurerequest bei MariaDB für einen besseren Parser erstellt. \o/ Das gibt einen dicken Daumen rauf! Mal sehen wies bei MariaDB ausgeht.

Wolfsburg – städtisches Bullshit-Bingo

Oh man, ich habe ja selten Spaß wenn Post von Xing kommt, aber den hier möchte ich Euch nicht vorenthalten :

Die Stadt Wolfsburg hat mal so richtig tief ins Klo gegriffen 🙂 C.C. früher Leitung des Coworking Space „Schiller 40“ und vielen bekannt vom Webmontag in Braunschweig und Wolfsburg, hat einen neuen Titel bekommen

Urban Digital Development Officer

Liebe Stadt Wolfsburg,

Ihr seid nicht die US Navy und auch keine sonstige US Einrichtung, Stadt oder Behörde. Benehmt Euch auch mal so! Der Titel ist Bullshit. C.C. tut mir jetzt schon leid. Der wird todsicher deswegen gemobbt werden, wenn nicht von Euch, von mir garantiert ;D

Linux – Autostandby per Gui einstellen

Im externen Beitrag Autostandby für Festplatten im Blog kopfkrieg.org wurde gezeigt, wie man per UDEV Regeln seinen Festplatten unter Linux mitteilt, wann Sie sich automatisch abschalten sollen.

Autostandby – GUI statt UDEV Konsole

Nun ist das nicht grade der intuitivste Weg, das seinen Festplatten mitzuteilen, daher hier ein einfacherer Weg über die Gui vom Laufwerkstool:

Zunächst einmal wählt man Links die Festplatte aus und über das Menü oben rechts die Laufwerkseinstellungen (E).

Wie man auf dem obigen Bild schon sehen kann, war die Platte schon im Sleep ( zzZ Symbol neben dem Laufwerk ).

Gnome-Disks Gui to adjust auto sleep timers per diskDanach stellt man einfach die gewünschte Zeit ein, nach der die Platte einschlafen soll und drückt „OK“ , Fertig.

Wer dies auf einem Server tun möchte, könnte sich einfach seine Linux X11 Session nach Hause exportieren und so auch in den Genuss der GUI kommen 😉

Original bei KopfKrieg: https://kopfkrieg.org/2017/11/19/autostandby-fuer-festplatten/

Linux – Warnung Firefox 57 im Update

Fedora hat Firefox 57 ins Stable Repository gepusht. Damit schalten Sie allerdings auch alle Securityrelevanten Addons ab, da diese mit dem neuen Plugin-System nicht mehr kompatibel sind. Themes ergeht es genau so.

Wer also auf seine Sicherheit beim Browsen nicht verzichten will, ist in der schizophrenen Situation, daß er auf FF 56 downgraden muß. FF 56 läßt sich aber nicht direkt installieren, man muß tatsächlich erst FF55 und dann als Update FF 56 installieren.

Anstatt einen Firefox II Zweig rauszubringen, werden alle Benutzer vom FireFox mit automatischem Tracking, Flash, Javascriptdrivebys usw. beglückt und Ihr könnt Euch drauf verlassen, daß einen 0-Day für das neue System gibt, weil das ja auch so laaaaaaaaaannnnge getestet wurde 🙁 Cool geht anders!

 

Linux – DNS-DeTracking mit nscd

Das Problem

Wenn man alle seine DNS Anfragen über einen einzigen Anbieter abwickelt, kann der leicht herausbekommen, wofür man sich interessiert, da er ja jede Domain kennt, mit der man „reden“ will.

Wenn man von einem DNS Anbieter, sei es die Deutsche Telekom oder Google, nicht vollumfänglich getrackt werden will, kann man nur seinen eigenen DNS-Cache betreiben, oder laufend den DNS Anbieter wechseln ? Oder gibt es da vielleicht noch eine dritte Möglichkeit ?

Methode 1:

Jeder kann sich einen DNS Cache auf dem eigenen PC installieren. Der Nachteil ist, es ist nicht besonders effizient und bei einigen DSL-Anbietern kann man auch nicht selbst die DNS Auflösung machen. In letzterem Fall solltet Ihr Euch auf jeden Fall einen Tunnel in die freie Welt aufbauen, z.b. per VPN. Einen eigenen Server der dafür ausreicht kann man sich schon für 6,50 € im Monat mieten. Ihr braucht  dann noch sowas : UDP Traffic per SSH tunneln, Die Vorratsdatenspeicherung umgehen oder VDS: Schnell ein VPN aufsetzen . Es geht zwar nicht um die Vermeidung der VDS, aber das Prinzip ist das gleiche. Aber wenn Ihr sowieso schon einen eigenen Server habt, laßt den das DNS Cache übernehmen.

Wieso ist das nicht effektiv ?

Ein DNS Cache macht nur dann Sinn, wenn viele Klienten in einem Netzwerk das Cache benutzen, denn der eigentliche Sinn ist, daß nicht jeder Rechner die Root-DNS kontaktiert, sondern das man möglichst viele Anfragen lokal selbst beantworten kann, weil man bereits einmal danach gefragt hat. Das geht zum einen schneller, zum anderen spart es Traffic ein. Das man seinen Fußabdruck dabei kleiner hält, fällt praktischerweise nebenbei ab. Je mehr einen DNS Cache benutzen, desto mehr gehen auch die eigenen Anfragen in der Masse unter.

Methode 2:

Ein Script, daß laufend die /etc/resolv.conf  neu und die DNS Servernamen in der Reihenfolge zufällig hinein schreibt, ist mit ein bisschen Bash-Foo machbar. Dauer ca. 15 Minuten.

Methode 3:

Schauen wir uns mal die /etc/resolv.conf an, finden wir dort:

; generated by /usr/sbin/dhclient-script
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Wenn man nichts weiter auf seinem Rechner installiert hat, wird in genau dieser Reihenfolge ein DNS nach dem Anderen abgefragt, wenn der vorherige DNS nicht rechtzeitig antwortet.

Das Verhalten kann man aber ändern:

options rotate
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Jetzt würde ein entsprechend gut programmierter Resolver, das ist der Programmteil, der die DNS Auflösung macht, zufällig aussuchen, welchen der DNS er benutzt. Trägt man hier also viele öffentliche DNS Server in dieser Liste ein, verteilt man alle DNS Anfragen auf diese Server, was jedem einzelnen logischerweise die Möglichkeit nimmt, ein umfangreiches Profil zu erstellen.

Dummerweise juckt diese Anweisung kaum einen Resolver. Das geht sogar soweit, daß der erste in der Liste mal einfach überlesen wird 🙂 Also muß eine Lösung her, die diese Anweisung respektiert: NSCD

dnf install nscd
systemctl start nscd
systemctl enable nscd

Ab jetzt werden DNS Abfragen über den NameserverCacheDämonen abgewickelt, und der fragt zufällig die DNS in der Liste an. Da es sich auch um einen Cache handelt, fragt er im Laufe der Zeit ( TTL eines Eintrags ) nur einmal die Rootserver an ( Kleiner Fußabdruck ) .

Damit wäre das Trackingproblem erledigt, wenn Ihr viele DNS Server zur Verfügung habt.

Einen eigenen DNS Cache auf dem PC zu betreiben, ist nicht weiter wild, man müßte nur den named installieren und starten. Da aber bei DNS Abfragen einiges unterwegs schief gehen kann, ist eine starke DNS Infrastruktur wie bei Google durchaus ein starker Partner.

Welche Methode für Euch die richtige ist, müßt Ihr wissen.

Linux – Datarecovery mit QPhotoRec

Wer kennt das nicht ? Eine Datei aus Versehen gelöscht und wie kommt man an die jetzt wieder ran ? Da kommt QPhotoRec ins Spiel.

Bevor wir uns aber dem Recoverytool zuwenden, müssen wir erst mal klarstellen, was beim Löschen von Dateien passiert.

Festplatten haben physikalische Sektoren fester Länge, welche die Elektronik der Festplatte mit Hilfe des Schreiblesekopfes einzeln ansprechen kann. Das alleine hilft aber beim Speichern von Daten nicht. Erst das Dateisystem(Filesystem) erzeugt eine logische Struktur in diesen Datenblöcken, so daß man Dateien mit Daten überhaupt erst anlegen und verwalten kann.

Dazu speichert sich das Filesystem eine Liste mit bereits belegten Speicherblöcken und ein Baumdiagramm der Dateistruktur, was z.B. eine verlinkte Liste von Namen sein kann, zu denen noch der erste Block der Datenblöcke vermerkt ist. Ohne weiter ins Detail zu gehen, speichert so ein Filesystem noch eine ganze Menge an anderen Daten, z.b. Zugriffsrechte, Erstellungsdatum, Länge usw. .

Im Prinzip besteht ein Directoryeintrag aka Filename nur aus einer Referenz auf einen Datenblock und eine Referenz auf einen Block mit Metainformationen wie Name, Datum usw.  . Wenn man jetzt in dem „Directory“ in dem sich die Datei „befindet“ die Referenzen zu diesen beiden Blöcken löscht, und die Blöcke des Datenteils der Datei aus der Liste der belegten Blöcke löscht, ist die Datei „weg“, aber die Daten sind noch auf der Platte gespeichert. Das Filesystem weiß bloß nichts mehr darüber. Der Inhalt der ehemaligen Datei ist aber noch da, bis die Datenblöcke neu beschrieben werden.

Das Linuxproblem

Und da kommt uns jetzt Linux in den Weg, denn ein Linuxsystem schreibt laufend neue Informationen auf mindestens die Systemfestplatte, so daß es i.d.R. nicht lange dauert, bis so ein freier Datenblock mit neuen Infos überschrieben wird.

D.b. wir müssen schnell sein und wir müssen weise handeln.

Als ersten zieht man mal den Strom vom PC ab!

WAAASSSSS !?!?!?!

„Das kannst Du nie im Leben ernst meinen!“

Ich fürchte doch, kommt aber drauf an, wo man was gelöscht hat 🙂 Auf der Systemplatte werden laufend Dateien geschrieben. D.b. das es je nach freiem Platz, schnell geht, bis die ehemaligen Dateiblöcke überschrieben sind.

Bei modernen Installationen sind /home/ und einige andere Mountpoints nicht auf der Systempartition, sondern auf einer eigenen Partition. Wenn man in /home/ was gelöscht hat, dann braucht Ihr den Rechner natürlich nicht gleich vom Strom trennen! Hier könnt Ihr den Teil mit Abschalten und von Livedisk booten überspringen und gleich zum Recovery übergehen.

Wenn man aber etwas wichtiges auf der Systemplatte/partition gelöscht hat, muß man schnell sein. Ein verschärfendes Problem ist, daß beim Runterfahren eines Computers auch Daten geschrieben werden, z.b. merken sich diverse Programme wo sie waren, als Sie beendet waren. z.B. FireFox 🙂 Wäre das nicht fatal, wenn man beim Runterfahren um Daten zu retten, genau diese Daten mit eigentlich nutzlosen Infos übernageln würde ?! Zusätzlich wird der Inhalt des Filesystemramcaches auf die Platte gesynct, was VIEL Schreiben beinhalten kann. Um das nicht stattfinden zu lassen, bleibt leider nur der harte Reboot.

ACHTUNG: Sie machen das auf eigene Gefahr, DENN weil genau z.b. das Syncen des Filesystemcaches aus dem Ram auf die Platte nicht stattfindet UND Schreibzugriffe im laufenden Betrieb unterbrochen werden, KANN (und WIRD) das Filesystem weiter beschädigt. Dies KANN zu einem Datenverlust führen.  Journalingfilesysteme gibt es nicht umsonst, benutzt die, die haben genau dagegen wirksame Mechanismen!

Der harte Reset

Damit beim Booten die Datenblöcke nicht überschrieben werden, weil z.b. Tempdateien erzeugt werden, MUß man von einer LiveDisk starten, idealerweise mit der aktuellen Rettungscd, wo QPhotoRec schon drauf ist.

Da QPhotoRec ROOT Rechte braucht, müßt Ihr wissen wie Ihr dort dann ROOT werdet und QPhotoRec aus der Root-Bashshell startet!

Das Recovery

Ihr startet also QPhotoRec als Root und seht das :

Photorec

Schritt 1:

Mit der Selectbox das Medium auswählen, daß man „retten“ will. Oben ist das /dev/sdd mit einem USB Stick.

Schritt 2 :

Die Partition aussuchen in der man was gelöscht hat, ODER gleich die ganze Platte durchsuchen lassen. Liegt bei Euch. Alles durchsuchen zu lassen dauert eine ganze Weile länger, fördert i.d.R. aber auch mehr zu Tage.

Schritt 3 :

Das Speichermedium für die geretteten Daten auswählen , im Beispiel oben /media/recovery .

LOGISCHERWEISE rettet man seine Daten NICHT auf das Medium von dem Sie stammen, weil man dabei natürlich die freien Datenblöcke übernagelt! Also IMMER auf eine andere Partition/Platte/USB-Stick/Cloud-Speicher retten.

Schritt 4 :

„SEARCH“ drücken und Kaffee trinkengehen.

Wenn man fertig ist, sieht das so aus :

Ergebnis von Photorec

Wenn man jetzt QPhotoRec beendet, kann man in dem Speicherort nachsehen was man bekommen hat.

Es wird nicht nur die eine Datei dabei sein und, todsicher wird die nicht den gleichen Namen haben wie früher. Akzeptierts einfach, der Name ist für immer verloren 🙂 Ihr könnt Euch nur an dem Dateitype (z.b. der Endung) und der Größe orientieren. Da immer mal wieder was auf einer Platte gelöscht wird, besteht auch immer die Möglichkeit was zu finden, was man nicht gesucht hat. Das Recoverytool kann das natürlich nicht wissen, es sucht nur nach zusammenhängenden Dateiblöcken.

Da QPhotoRec nur ein einfaches Programm ist, ist der Beitrag hier zu Ende.

Kleiner Hinweis: USB Sticks sind aufgrund der Hardware nicht die besten Beispielmedium zum Retten, aber bevor ich das erklärt habe, ist Ostern 🙂 Wer es trotzdem wissen will, liest es hier nach : Mit LUKS einen USB Stick verschlüsseln

Und bevor Ihr ein Problem habt, daß es beim Retten nur noch schlimmer macht, setzt einfach Backups ein 😉