9/11 Pentagon

Narrenschiffer schrieb:Der Zeitstempel der CDFS interessiert mich nicht, mich interessiert der Erstellungs-Zeitstempel der Datei.

menno - natürlich geht's um den Zeitstempel der Datei - der ist aber im CDFS-Format ! Und wie das Format bzgl. des Timestamps einer Datei aussieht, habe ich schon gepostet.

Wenn du die ISO gemountet hast müsstest du überprüfen, wie der ISO-Treiber deines Linux den im CDFS-Format gespeicherten Zeitstempel des Files interpretiert ! Also genau dasselbe was ich nach dem Download auf einem Windows System gemacht habe. Ich habe dazu nix gemountet, da WinRAR über die Win-Api's auch die ISO lesen kann.

Du brauchst auch nicht den File im Hexviewer ansehen sondern müsstest eruieren WO im CDFS-Format die Verwaltungsinformation über die Datei und da insbesondere jene Struktur die den Timestamp enthält, zu finden ist. Also nicht die ISO mounten sondern die gesamte ISO (als file) analysieren ! Das ist aber etwas aufwändig, wenn man das Format nicht aus dem ff kennt.

Dann wüßtest du bzw. ich (unabh. vom BS/bzw. ISO-Treiber) was original dort steht.

Nochmal weil dir das scheinbar nicht ganz klar ist: In einem Windows-System, welches auf US/Zeitzone eingestellt ist, wird 13.9.2001 23:45 als Zeitstempel der Datei geliefert. Das ist genau das, das in den anderen Quellen steht, welche sich *afaik alle auf US-Locations beziehen, wo ja auch der Schreibvorgang des Files im ISO-Format stattfand.

Insofern ist es schon etwas "kühn" von dir zu behaupten, das was bei deinem System, wenn du die ISO mountest als Zeitstempel steht, repräsentiere "wirklicher" jenen Zeitpunkt, der in der Timestamp-Struktur zum File geschrieben wurde.

Ich hab' mit Linux nicht so oft zu tun und habe auf die Schnelle nicht gefunden, wie irgendwelche ISO-Treiber die Timestamp Struktur interpretieren/auswerten und wie/ob die Systemvariable bzw. /etc/localtime dabei mit "verwurstet" wird.

Ändert sich was bei der Ausgabe von "stat ..." - so wie bei windoofs - wenn du die timezone auf US (also UTC-5) setzt ?

@QNH

QNH schrieb:Also Plausibel ist es wenn man die Vd (auch Vne bei anderen Flugzeugen genannt) erreicht und auseinander fällt. So wie es auch war bei der EgyptAir 990.

als Mitleser der letzten k.a. 20 Seiten bin ich nun langsam an nem Punkt wo ich finde das du einfach ignorierst was dir die Leute sagen.... Die beiden Fälle sind einfach nicht vergleichbar. Bei EgyptAir 990 war NICHT das Tempo schuld am auseinanderbrechen sondern das ruckartige Abfangen der Maschine. Wiki schreibt dazu: Um 01:50:06 Uhr kam Kapitän Mahmoud El Habashy zurück ins Cockpit, als die Maschine bereits die maximale Fluggeschwindigkeit von 0,86 Mach überschritten hatte und mit negativem Lastvielfachem mit etwa 99 Prozent der Schallgeschwindigkeit zu Boden raste.[10][14] El Habashy versuchte das Flugzeug abzufangen, indem er an dem Steuerknüppel zog, allerdings gelang es ihm nicht. Auch mit den Triebwerken ließ sich der Sturzflug nicht beenden, da sie abgeschaltet waren.[14] Erst mit den Flügelklappen schaffte es El Habashy, die Geschwindigkeit zu reduzieren und den Sturzflug nach 40 Sekunden[13] auf einer Höhe von 5.000 Metern[6] abzufangen.

Also ist das Flugzeug bereits längere Zeit deutlich über der empfohlenen max Geschwindigkeit geflogen und nicht sofort bei erreichen dieser zerbrochen...

In meinen Augen sind die beiden Fälle nicht vergleichbar bzw kannst du nicht sagen das EgyptAir 990 wegen der Geschwindigkeit auseinandergebrochen ist

Narrenschiffer schrieb:Ah ja, jetzt hast du es auch herausgefunden. Windows-Systeme passen bei der Ausgabe den Wert an.

Auch UNIX Systeme berechnen bei der Ausgabe den Wert - sonst stünden bei der Ausgabe sieben für Unbedarfte eher  kryptische Werte statt eines lesbaren Datums ! Such einfach mal, ob du Unterlagen findest, WIE das bei deinem Linux erfolgt - hab' ich für Windows doch auch gemacht ;)

Nochmal - SO ist der Timestamp im CDFS-Format gespeichert:

cortano schrieb:Offs Size Description
0 1 Number of years since 1900.
1 1 Month of the year from 1 to 12.
2 1 Day of the month from 1 to 31.
3 1 Hour of the day from 0 to 23.
4 1 Minute of the hour from 0 to 59.
5 1 Second of the minute from 0 to 59.
6 1 Offset from GMT in 15 minute intervals from -48 (West) to +52 (East).

http://wiki.osdev.org/ISO_9660 (Archiv-Version vom 23.11.2017)

Wenn du mit 2 Windows mit identen Zeitzoneneinstellung ein ISO erzeugst und dann wieder ausliest wird der timestamp von Files ja richtig wiedergegeben - müsste man noch etwas experimentieren um auch ohne HEX-Analyse der timestamp-struktur rauszukriegen was da genau bei schreiben/lesen auf unterschiedlichen Systemen passiert bzw. ob man das als Bug oder Feature betrachten kann ;)

@cortano

Also hier am Mac (UNIX) bekomme ich, wenn ich so wie du die ISO entpacke, folgende Zeitinfo für die FDR-Datei:

Erstellt: 14. September 2001 um 08:45

Ich habe also einen völlig anderen Wert als Windows-Systeme. Ich habe den CDFS-Wert +4 Stunden. Windows hat den CDFS-Wert -5 Stunden.

Zur Analyse halte ich den gemounteten Zustand (nicht gespeichert) für den geeignetsten. Im gespeicherten Zustand wird in verschiedene Richtungen verändert.

Vielleicht werfe ich noch meinen Linux-Laptop an, dort müsste ich ein cdrinfo haben, das Daten aus der ISO auslesen kann.

wie kommst du darauf ?

Narrenschiffer schrieb:Zur Analyse halte ich den gemounteten Zustand (nicht gespeichert) für den geeignetsten. Im gespeicherten Zustand wird in verschiedene Richtungen verändert.

Das mounten eines FS interpretiert ja schon mal die Verwaltungsinfo des jeweiligen FS's ! Entweder Unterlagen die erklären wie die CDFS-Struktur des Timestamps geschrieben/gelesen wird - wobei da ja auch Bugs vorhanden sein können - oder mit einigen Systemen herumexperimentieren was beim schreiben/lesen bzw. spielen mit der timezone alles so systemübergreifend passieren kann ...

Wie geschrieben ich habe nur probiert Schreiben/Lesen auf Win mit identer timezone produziert nachvollziehbare Resultate. Das Ändern der timezone resultiert in Angaben, wie spät es lokal, der gesetzten zone gemäß gewesen wäre, als der timestamp geschrieben wurde. So kriege ich unter Win ja ebenso die 4:45 wenn ich UTC setze sowie beliebige andere Werte je nach gesetzter timezone ...

cortano schrieb:wie kommst du darauf ?

Weil dann die Daten so vorhanden sind, wie sie vom Zielsystem ausgelesen werden, wenn sie gespeichert sind. Die Daten sind ja nur im RAM und nicht physisch gespeichert.

Ich habe jetzt auf meinem Linux-Rechner die ISO gemountet, und die FDR-Datei spuckt folgende Info aus:


Erstellt: 14. September 2001 um 08:45 CEST


Zum ersten Mal habe ich eine Zeitzonenanzeige mit. Nach EST (Washington) wäre dies:


Erstellt: 14. September 2001 um 02:45 EST

Narrenschiffer schrieb:Weil dann die Daten so vorhanden sind, wie sie vom Zielsystem ausgelesen werden, wenn sie gespeichert sind. Die Daten sind ja nur im RAM und nicht physisch gespeichert.

jetzt verstehe ich nur Bahnhof. Das Speichermedium ist doch wirklich völlig egal. Ist dir der Zweck und die Funktionsweise eines Filesystems so halbwegs klar ? Das ist quasi der "Aktenordner mit Inhaltsverzeichnis und Meta-Informationen" für die einzelnen Dokumente (dateien/files).

Das mounten verwendet dieses "Inhaltsverzeichnis nebst Metainformationen" um den Zugriff auf die Dokumente zu organisieren/ermöglichen. Wo das ganze physisch "beheimatet" ist, ist auf dieser Ebene völlig egal. Strukturell ähnlich dem OSI-Modell bei der Netzkommunikation, wo für den Presentation-Layer auch schnuppe ist, wie der physical-Layer implementiert ist.

QNH schrieb:Also Plausibel ist es wenn man die Vd (auch Vne bei anderen Flugzeugen genannt) erreicht und auseinander fällt.

Vd und Vne sind aber 2 völlig unterschiedliche Geschwindigkeiten mal wieder. Wenn ein Flugzeug bei Vd einfach auseinanderbrechen würde wäre es gar nicht zugelassen worden. Siehe die 20% Sicherheitsmargin. Macht es dich nicht stutzig das dir Leute etwas von Geschwindigkeiten erzählen von denen sie offensichtlich keine Ahnung haben? Fing ja schon mit den 600kn beim Egypt Air Flug an.

Bei Egypt Air lagen ganz andere Lastvielfache vor. Auch das ignorierst du. Und auch das es im Sturzflug ja nicht auseinander gebrochen ist.

cortano schrieb:jetzt verstehe ich nur Bahnhof. Das Speichermedium ist doch wirklich völlig egal

Nein, ist es nicht.

1. Wenn du mountest, liegen die Metadaten im originalen CDFS vor.
2. Wenn du speicherst, werden die Metadaten ins Ziel-Dateisystem übertragen.

Bei 1: da kommt es darauf an, was der Betriebssystem wie aus CDFS lesen kann.
Bei 2 kommt es darauf an, welche Metadaten das Ziel-Dateisystem wie übernehmen kann.

Bei mir sind auf UNIX die Zeitdaten sehr wohl unterschiedlich, ob ich mounte oder speichere (siehe oben).
Linux kann im gemounteten Zustand sogar die Zeitzone bestimmen.

Wenn nun bei unterschiedlichen Systemen in unterschiedlichen Speicherformen eine Datei Zeitdaten ausliest (mehrere Stunden unterschied), so ist für mich die Windows-Anzeige kein Indiz, dass die FDR-Daten vor dem offiziellen Erhaltszeitpunkt geschrieben wurden, sondern dass Windows mit dem Zeitstempel anders umgeht als andere Systeme, die allesamt einen späteren Zeitpunkt angeben.

QNH schrieb:Nochmals, wie weit wollen wir noch die Margin vergrössern? Bis es passt?

Die Limits waren sicher überschritten aber das bedeuted doch nicht das das Flugzeug beim Limit auseinander fällt. Das sind Limits bis zu denen der Betrieb sichergestellt werden muss. Für alles darüber hinaus übernimmt niemand mehr Verantwortung aber das bedeuted nicht das es unmöglich ist.

QNH schrieb:Wenn Du eine Groundspeed angibst, dann ist das nicht die Geschwindigkeit mit der das Flugzeug durch die Luft fliegt. Ich weiss, viele meiner freunde haben da auch ein Problem es zu verstehen.
Theoretisch kannst Du eine A380 mit 50 Kmh (GS) fliegen. Allerdings müstest Du auch 300 kmh Gegenwind haben :-)

Kann es sein, dass du airspeed und groundspeed verwechselst?
Ich bin sicher kein Experte und habe mir nur Wikipedia dazu durchgelesen.
Wenn es also heißt 300km/h GS, dann bedeutet das, dass das Flugzeug für eine 300km Distanz eine Stunde braucht.

Narrenschiffer schrieb:Nein, ist es nicht.

1.Wenn du mountest, liegen die Metadaten im originalen CDFS vor.
2.Wenn du speicherst, werden die Metadaten ins Ziel-Dateisystem übertragen.

....

*örks wir reden völlig aneinander vorbei und ich gewinne den Eindruck, dass dir nicht so ganz klar ist, wovon ich spreche, bzw. was beim Auslesen der timestamp-Info eines Files im CDFS-Format passiert und wo es dabei zu "Interpretationen" der physikalisch gelesenen Daten kommen MUSS, damit sie user-verständlich angezeigt werden können ;)

Ich rede überhaupt NUR von deinem Fall 1 !

Und dabei ist es egal WO (physikalisch) die Daten liegen.

Von dem Fall, dass ich die Dateien aus dem CDFS in irgendein anderes FS speichere und dann irgendwas analysiere war nie die Rede...

cortano schrieb:Von dem Fall, dass ich die Dateien aus dem CDFS in irgendein anderes FS speichere und dann irgendwas analysiere war nie die Rede

Ok, stimmt, du scheinst die ISO im RAR noch im unentpackten Zustand auszulesen (da habe ich mich verschaut). 

Dann ist die Analyse noch einfacher: Windows interpretiert die Zeitstempel anders als UNIX oder Linux. Windows zeigt den frühesten Zeitpunkt an, Linux einen mittleren, Unix den spätesten.

Nur aus dem Verhalten von Windows-Betriebssystemen lässt sich nicht schlussfolgern, dass die Datei vor dem offiziellen Erhalt des FDR geschrieben wurde und daher nicht echt sein kann, wie in der VT-Welt vermutet wird.

Für mich ist der Fall abgeschlossen. Weder Unix noch Linux lassen erkennen, dass die Datei zu früh geschrieben wurde. Die Windows-Interpretation reicht mir nicht für eine VT.

Nachtrag: ich habe zwar die Strukturinfo für den Timestamp in der CDFS-Verwaltungsstruktur gepostet, was aber in dem Dokument ( http://wiki.osdev.org/ISO_9660 ) nicht eindeutig hervorgeht, ist die genaue Semantik wie eine lokale Uhrzeit darin abgelegt wird bzw. werden soll:

Insbesondere ob die ersten 6 Felder immer die Zeitangabe in GMT enthalten und der Offset in Feld 7 die Abweichung bzgl. der lokalen Timezone, oder ob in den ersten Feldern die lokale Zeit gespeichert werden soll und der Offset nur als Info über die Timezone zu verstehen ist.

Narrenschiffer schrieb:Dann ist die Analyse noch einfacher: Windows interpretiert die Zeitstempel anders als UNIX oder Linux. Windows zeigt den frühesten Zeitpunkt an, Linux einen mittleren, Unix den spätesten.

also das ist jetzt wieder völliger Quatsch - sorry !

Narrenschiffer schrieb:Nur aus dem Verhalten von Windows-Betriebssystemen lässt sich nicht schlussfolgern, dass die Datei vor dem offiziellen Erhalt des FDR geschrieben wurde und daher nicht echt sein kann, wie in der VT-Welt vermutet wird.

Für mich ist der Fall abgeschlossen. Weder Unix noch Linux lassen erkennen, dass die Datei zu früh geschrieben wurde. Die Windows-Interpretation reicht mir nicht für eine VT.

OK - eigentlich hast du also gar nicht verstanden, was überhaupt zu klären wäre :D

Debunker auf den Fidschis können sich auch mit Win. glücklich schätzen, denn nach deren "Analyse" a'la deiner Methode wäre der File noch viel später erstellt worden, als du wegen deiner 2er unterschiedlicher Ausgaben auf Linux/Unix herumratest ;)

cortano schrieb:eigentlich hast du also gar nicht verstanden, was überhaupt zu klären wäre

Microsoft dann auch nicht. Beachte den letzten Satz.

File Times and CDFS

The date and time stamps of files that are located on or originate from media using Compact Disc File System (CDFS) are adjusted for the local time zone. ISO 9660 states that CDFS is to display the date information correctly for the local time zone. This is done so that dates for files on CDFS are displayed the same as those on Universal Disk Format (UDF). UDF is the newer standard for distribution media. If your code depends on the unmodified date information for a file that resides on or originates from media using CDFS, it may not function correctly.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx

McMurdo schrieb:Die Limits waren sicher überschritten aber das bedeuted doch nicht das das Flugzeug beim Limit auseinander fällt. Das sind Limits bis zu denen der Betrieb sichergestellt werden muss. Für alles darüber hinaus übernimmt niemand mehr Verantwortung aber das bedeuted nicht das es unmöglich ist.

Dass heisst wenn eine Maschine vor überschreiten der Vd Margin auseinander bricht, kann man den Hersteller verklagen?. Also könnte man Boieng verklagen weil die 990 vor der Margin auseinander brach?

Groucho schrieb:    QNH schrieb:
   Wenn Du eine Groundspeed angibst, dann ist das nicht die Geschwindigkeit mit der das Flugzeug durch die Luft fliegt. Ich weiss, viele meiner freunde haben da auch ein Problem es zu verstehen.
   Theoretisch kannst Du eine A380 mit 50 Kmh (GS) fliegen. Allerdings müstest Du auch 300 kmh Gegenwind haben :-)

Kann es sein, dass du airspeed und groundspeed verwechselst?
Ich bin sicher kein Experte und habe mir nur Wikipedia dazu durchgelesen.
Wenn es also heißt 300km/h GS, dann bedeutet das, dass das Flugzeug für eine 300km Distanz eine Stunde braucht.

Du hast recht, Du bist da sicher nicht Experte.
Lies bitte nochmal was ich schrieb.

Wenn Du eine Groundspeed angibst, dann ist das nicht die Geschwindigkeit mit der das Flugzeug durch die Luft fliegt.

Und hier jetzt die stat-Ausgabe des gemounteten Files unter Linux:

stat American\ 77.fdr Datei: 'American 77.fdr' Größe: 25165994 Blöcke: 49153 EA Block: 2048 Normale Datei Gerät: 700h/1792d Inode: 1795 Verknüpfungen: 1 Zugriff: (0400/-r--------) Uid: ( 1000/ ego) Gid: ( 1000/ ego) Zugriff : 2001-09-14 08:45:38.000000000 +0200 Modifiziert: 2001-09-14 08:45:38.000000000 +0200 Geändert : 2001-09-14 08:45:38.000000000 +0200

cortano schrieb:also das ist jetzt wieder völliger Quatsch - sorry !

muss das etwas relativieren - also der erste Satz ist ja noch richtig. Nur um zu verstehen WIE Unix/Linux das was da pyhsikalisch gespeichert ist in ein lesbares Datum umrechnet, bräuchte man entsprechend verbindliche Infos über die Funktionsweise deren ISO-Treiber/Zugriffsroutinen.

Sollte die zum download verfügbare ISO seitens NTSB auf einem Windows System mit korrekter Datums/Zeit- & Zeitzonen Einstellung erzeugt worden sein - was ich nicht verifizieren kann/konnte - dann "stimmt" nach meinen Versuchen auch der Timestamp mit 13.9.2001 23:45 welcher dann die korrekte lokale Zeit (UTC - 5std) zum Schreibzeitpunkt der Daten in Washington darstellt.

Wodurch die 2 unterschiedlichen zeitlichen Verschiebungen bei Linux/UNIX basieren müsste man eben technisch erst mal ermitteln, wozu ein etwas tieferes Verständnis wie genau die CDFS Timestamp-Daten auf verschiedenen Systemen geschrieben/gelesen werden nötig ist.

Da der FDR um ca. 4:00 morgens am 14.9 lt. mehreren Quellen gefunden worden sein soll und man sich im PDF der NTSB durchlesen kann, was alles gemacht wurde um überhaupt mal die Daten zu gewinnen, dürfte jeder "plausible" Schreibzeitpunkt der aufbereiteten .fdr Datei nur wenige Zeit später unter die Rubrik Debunkerlatein fallen :D