Datum Error: DUMP verhindern

Auf jedem Gerät kann es zu Fehlern kommen, bei denen das Datum falsch angegeben wird, so etwa vor 1 Monat bei macOS oder aktuell bei Fedora. In diesem Artikel will ich aber auf keinen Fall von dem eigentlichen Fehler reden, sondern viel mehr, wie ein DUMP verhindert werden kann, denn dies kann auch zu weitaus gravierenderen Problemen führen, als nur zu einem so "kleinen" Fehler. Im folgenden Experiment werde ich versuchen, das Auslesen von Daten aus dem RAM zu verhindern. Als "Opfer" werde ich in diesem Fall ein Videoprogramm und ein Bildschirmaufnahme Programm nutzen.

Aufbau des Experiments:

  • Die beiden Programme führen normale Arbeiten (abspielen und aufnehmen) durch
  • Der RAM wurde mit einem RAM Test gleichzeitig getestet so, dass der RAM voll ausgelastet war
  • Ich griff mit einem Skript in die Prozesse ein

Das erste Skript, erstellt und kopiert ununterbrochen temporäre Dateien die dann immer wieder im RAM gespeichert werden, ein zweites Skript führt die Dateien aus und belastet so zusätzlich noch die CPU. Das dritte und letzte Skript, probiert ununterbrochen eine plist Datei einzuschleusen, welche falsche Daten (Datum) enthält.

Zum Experiment:

Beim Start des Experiment waren 15 von den 16 GB von meinem RAM besetzt und meine CPU zu 40 % ausgelastet.

Dann startete ich das Skript und startetet gleichzeitig ein PHP Upload und das betreffende PHP Skript muss am Schluss die Plist Datei auslesen.  Das Skript erstellte gleichzeitig neue Kopien von sich, damit ich die Effektivität der Überlastung prüfen konnte, liess ich das andere Skript die Dateien ständig verschieben. Da ich zum erstellen von neuen Skripten folgendes genutzt habe:

 

>rem Saved in D:\Temp\file.bat @echo off @echo hier ist der genaugleichecode> file2.bat @echo 123>> test.txt //Nach dem Speichern des neuen Skripts, habe ich es aussgeschnitten und in den RAM verlegt.

Nach 300 Durchgängen (die Anzahl Skripte die laufen steigt exponentiell) war nur noch 1 MB RAM verfügbar, weshalb die "low RAM Space" Warnung angezeigt wurde. Das System startete nun den Löschvorgang von Daten und da das dafür zuständige System unterhalb des OS ist, konnte es nicht wissen wofür die betreffende Daten  verwendet werden und prompt löschte die Firmware Daten, die durch den PHP Upload erstellt wurden, die sorgte dafür, dass diese Daten inkomplett waren und somit unbrauchbar. Gleichzeitig versuchte ein anderes Skript die Plist Datei reinzuholen und da zahlte sich die hohe CPU Auslastung aus, denn das Anti-Viren Programm reagierte nicht mehr richtig, die unteren Ebenen löschten Daten, um die neue Datei reinzuschreiben (zu diesem Zeitpunkt waren weniger als 0.5 MB RAM verfügbar) und so kam es, dass die Datei in den RAM eingeschrieben wurde. Zum Glück nur in den "öffentlichen" Bereich des RAM`s, allerdings wurde die Datei von den anderen Programmen gelesen. Durch die grosse Auslastung konnte unteranderem Firefox nicht mehr überprüfen, ob ich das richtige Passwort eingegeben habe, denn das ROOT Passwort konnte nicht aus dem NVRAM gelesen werden und aufgrund von einer kleinen Lücke im Code, kommt/kam es dazu, dass das Passwort nicht existiert und das Betriebssystem versucht das Passwort in den RAM zu schreiben, dabei kommt es zu dem angezeigten RAM-Error. Möglicherweise könnte man eine solche Überschreibung auch zum Hacken verwenden, man könnte ja mit Brute Force immer wieder versuchen auf den gleichen Block eine Datei zu legen, allerdings denke ich, dass diese genau so lange wie die vorher im Block gespeicherten Daten sein sollte, da dies ansonsten auffallen würde. Um das was beim Auslesen schiefgegangen ist, etwas einfach zu erklären hier kurz ein Beispiel:

 

Monat 13 ist außerhalb der Grenzen, diese lustige Fehlermeldung erschien erstmals im Dezember 2017 auf dem Geräteprotokoll und der Konsole vieler MacOS-Geräte. Der Fehler wurde von vielen verschiedenen Anwendungen gemeldet, aber meistens von Anwendungen von Drittanbietern, deshalb denke ich, dass es einen Fehler bei der Kommunikation des Kernels und dieser Anwendungen gab!

 

So dachten diese Anwendungen, dass der Dezember, Monat 13 wäre. Herausgestellt hat sich dabei, dass der Date Timestamp nicht richtig geschrieben wurde. (Falls du mehr dazu erfahren willst, dann besuche diese Webseite). Der Fehler traf gerade bei hoher Auslastung mehrere Male pro Sekunde auf. Lustigerweise trat dieser Fehler auch während dem Experiment auf (allerdings nicht in der macOS Version, sondern bei Fedora), dies wird neben der sehr hohen Auslastung von den Kernel Save Prozessen auch auf die hohe Physische Auslastung zurückzuführen sein. Denn beim schreiben muss immer wieder Spannung aufgebaut werden und wenn das viel mehr gemacht wird, besteht die Gefahr, dass ein Teil elektrisiert bleibt und so dazu "gerechnet" wird. In diesem Fall waren es aber wahrscheinlich viele Zeichen, denn die Zahl 13, besteht im Hexadezimalsystem und im Dezimalsystem aus viel mehr Zeichen als die Zahl 12! Dies hat unteranderem auch zu der beschädigten hochgeladenen Datei geführt. Schlussendlich wurde die betreffende falsche Datei erkannt und hat keinen Schaden hinterlassen, dafür blieb sie aber beschädigt drauf.

Was kann ich tun, wenn ich denke, dass mein Server ein Problem mit dem RAM hat?

  • RAM TEST DURCHFÜHREN
  • RAM-Purge (Säuberung)
  • Wenn es zu einer fehlerhaften "elektriesierung" kommt, kann es sehr viel Sinn machen, eine sehr grosse sinnlose Datei zu speichern, zu kopieren und zu verschieben. Die Datei sollte soweit wie möglich in die Nähe deiner RAM Grösse kommen, denn so sollten die Blocks überschrieben werden. Funktioniert dies nicht, kann es Sinn machen, die RAM-Bausteine (nur wenn Gerät ausgeschaltet) zu entfernen und nach c.a 1 Minute wieder einzusetzen.

Fazit:

Am Schluss stürzte der Server ab und beim Neustart wurde der RAM gelöscht, auch die Teile, die ich in dem nicht flüchtigen Teil eingeschleust habe.

 

PS: Du kannst auch mit einem Memory-Test den gesamten RAM füllen, denn dieser speichert eine Datei dort ab, um zu Überprüfen wie viel Speicherplatz auf deinen RAM-Blöcken sind.

Click the button



KONTAKT

Bitte den Code eingeben:

Hinweis: Bitte die mit * gekennzeichneten Felder ausfüllen.


ADCELL

Hey! Thats me!

Severin Kämpfer Bremgarten bei Bern

16 years old trekkie.

Persönliche Webseite:

https://www.severin-kaempfer.ch

Unterstütze KKTVCAM mit 1 CHF! Bezahle mit Bitcoin!



Made with ♥ in Bern (Switzerland)!

KKTVCAM ÜBERNIMMT KEINE HAFTUNG FÜR ALLE ANGABEN AUF DIESER SEITE.