Unbekanntes Dateiformat einlesen

[ryLIX]

Ja bin immer optimistisch
Folgendes habe ich nun geschafft:

Code:

02010C00030000  --- Start Header?
00071300030100  --- Trennung Dateiname/SGID_CodierIndex
00101600030200  --- Trennung SGID CI/ SGID_Hardwarenummer
00101000030300  --- Trennung Hardwarenummer/SWNummer
00100E00030400   --- Trennung SWNummer/Speicherorg
00611200030500  --- Trennung Speicherorg/Anlieferungszustand
00141300030600   --- Trennung Anlieferungszustand/Codierdatenblock
00041700030700   --- Trennung Codierdatenblock/Herstellerdatenblock
00041700030800   --- Trennung Herstellerdatenblock/ReserviertDatenblock
00040C00030900   --- Trennung Reserviertdatenblock/Unbelegt1
006F0C00030A00   --- Trennung Unbelegt1/Unbelegt2
00140C00030B00   --- Trennung Unbelegt2/Kennung_K
003A0C00030C00   --- Trennung Kennung_K/Kennung_D
000F0C00030D00   --- Trennung Kennung_D/Kennung_X
000F0E00030E00   --- Trennung Kennung_X/Kennung_All
00321400030F00   --- Trennung Kennung_All/Parazuweisung_PSW2
004A1400031000   --- Trennung Parazuweisung_PSW2/Parazuweisung_PSW1
003E1300031100   --- Trennung Parazuweisung_PSW1/Parazuweisung_Dir
00181300031200   --- Trennung Parazuweisung_Dir/Parazuweisung_FSW

001E0000FFFF   --- Ende Header

Nun muss ich nur noch wissen wie das zu interpretieren ist. Dann hätte ich den Header entschlüsselt.
Denn das gefundene ist bei allen (20 Dateien kontrolliert) gleich.

Tante edit:
Ich hab noch was gefunden weiß nur noch nicht was ich damit Anfangen muss

Code:

02 01 0C 0003 0000
 |  |  |   |    |_ ID Im Header (0000 in diesem Fall)
 |  |  |   |_ Einleiten der neuen Zeile bzw Trennzeichen zwischen den Zeilen
 |  |  |_ Name (In diesem Falle DATEINAME)
 |  |_ Datenformat (S in diesem Fall)
 |_ Datenname (NAME in diesem Fall)

Und nochmal Edit:
Hab nun den Sinn der ID gefunden.
Man findet über die Hex ID z.b. 0500 den Anfang der zu der ID gehörenden Daten.
0500 = Auslieferungszustand.
Nun muss ich noch sehen wie diese Daten gespeichert sind.
Ich denke das lässt sich dann mit NAME Datenformat und Datenname finden.

[ryLIX]

Code:

02
010C00
03 Start Header

0000  --- Dateiname 00071300
03
0100  --- SGID_CodierIndex 00101600
03
0200  --- SGID_Hardwarenummer 00101000
03
0300  --- SGID_SWNummer 00100E00
03
0400  --- Speicherorg 00611200
03
0500  --- Anlieferungszustand 00141300
03
0600  --- Codierdatenblock 00041700
03
0700  --- Herstellerdatenblock 00041700
03
0800  --- ReserviertDatenblock 00040C00
03
0900  --- Unbelegt1 006F0C00
03
0A00  --- Unbelegt2 00140C00
03
0B00  --- Kennung_K 003A0C00
03
0C00  --- Kennung_D 000F0C00
03
0D00  --- Kennung_X 000F0E00
03
0E00  --- Kennung_All 00321400
03
0F00  --- Parazuweisung_PSW2 004A1400
03
1000  --- Parazuweisung_PSW1 003E1300
03
1100  --- Parazuweisung_Dir 00181300
03
1200  --- Parazuweisung_FSW 001E0000

FFFF  Ende Header

Das is was ich bisher habe.
Ich bin mir aber nicht sicher ob ich da richtig liege

[nicodex]

Zitat von ryLIX:

Das is was ich bisher habe.
Ich bin mir aber nicht sicher ob ich da richtig liege

Bist du schon weiter? Oder anders gefragt, lohnt es sich noch, wenn jemand/ich einen Blick darauf wirft?

[nahpets]

Hallo,

das was Du im letzten Post stehen hast, sieht aber schon recht plausibel aus.
Dateiname hat die Nr. 00 und dann geht es aufsteigend nummeriert weiter bis Nr. 12, gefolgt vom Ende des Headers mit FFFF.

Damit bin ich nicht so ganz einverstanden, kann aber sein, dass ich mich heftig täusche:

Code:

02010C00030000  --- Start Header? 
00071300030100  --- Trennung Dateiname/SGID_CodierIndex 
00101600030200  --- Trennung SGID CI/ SGID_Hardwarenummer 
00101000030300  --- Trennung Hardwarenummer/SWNummer 
00100E00030400   --- Trennung SWNummer/Speicherorg 
00611200030500  --- Trennung Speicherorg/Anlieferungszustand 
00141300030600   --- Trennung Anlieferungszustand/Codierdatenblock 
00041700030700   --- Trennung Codierdatenblock/Herstellerdatenblock 
00041700030800   --- Trennung Herstellerdatenblock/ReserviertDatenblock 
00040C00030900   --- Trennung Reserviertdatenblock/Unbelegt1 
006F0C00030A00   --- Trennung Unbelegt1/Unbelegt2 
00140C00030B00   --- Trennung Unbelegt2/Kennung_K 
003A0C00030C00   --- Trennung Kennung_K/Kennung_D 
000F0C00030D00   --- Trennung Kennung_D/Kennung_X 
000F0E00030E00   --- Trennung Kennung_X/Kennung_All 
00321400030F00   --- Trennung Kennung_All/Parazuweisung_PSW2 
004A1400031000   --- Trennung Parazuweisung_PSW2/Parazuweisung_PSW1 
003E1300031100   --- Trennung Parazuweisung_PSW1/Parazuweisung_Dir 
00181300031200   --- Trennung Parazuweisung_Dir/Parazuweisung_FSW 
001E0000FFFF   --- Ende Header

Nehmen wir mal denhier:

Code:

00071300030100  --- Trennung Dateiname/SGID_CodierIndex

Wie wäre es mit

Code:

0100  --- Trennung Dateiname/SGID_CodierIndex
0010160003

Also hinter der 03 beginnt eine Spalte mit der laufenden Nummer, gefolgt von 00 und dann folgen noch Angaben zum Typ, zur Länge?
Würde die laufende Nummer der Spalten doch eher als ihren Anfang interpretieren und nicht quasi mitten drin. Zumal, wenn Du die Nr. als Anfang interpretierst, bekommst Du bis zu nächsten Nummer immer alle die Zeichenfolgen zu der Spalte zusammen, die auch in der Textdatei stehen. Und wenn Du die Nr. zusammen mit der folgende 00 betrachtest und die beiden Werte vertauschst, also 00+Nr., dann hast Du die gleiche Aufzählung, wie in der Textdatei.
Eventuell musst Du Deine Betrachtungsweise (von Teilen der Dateien) mal von einzelnen Bytes auf Wörter umstellen, dann scheint z. B. die Nummerierung der Spalten "offensichtlicher".

Habe jetzt zugegebenermaßen nicht die Zeit, um mich intensiver damit zu beschäftigen, werde aber heute und morgen ab und an nochmal vorbeischauen

[nicodex]

Wenn man die Daten etwas sortiert, dann wird es einfacher:

Code:

// header
07,00,01,00,01,00,01,01,01,63,65,01,00,02,02,01,0C,00

// definition 0
03,0000         // 03,<id>
'DATEINAME',00  // <name>
55,0002,04      // ?,sizeof(<data_format>),04
'S',00          // <data_format>
55,0005,05      // ?,sizeof(<data_names>),05
'NAME',00       // <data_names>
07,0013         // ?,?

//...

// definition 19
03,0012
'PARZUWEISUNG_FSW',00
07,0013,04
'{L}LWW{B}(B){B}{B}',00
16,0038,05
'BLOCKNR,WORTADR,BYTEADR,FSW,INDEX,MASKE,EINHEIT,INDIVID',00
1E,0000

FF,FF,08,00,00
'GM5.C01',00
5B,03,01,00,01,00,00,03,0A,04,00
'BYTE',00
//...

Damit kann man, trotz unbekannter Werte bereits die Definitionen lesen. Der Rest dürfte dann schwerer werden - mehr als 10min hatte ich leider auch nicht.

[ryLIX]

@nicodex
ja soweit hatte ich das gestern auch noch auseinander getüftelt.
Nur bin ich mir noch nicht sicher wie der Zusammenhang der Bytes mit den Schlüsselwörtern ist.

Code:

03 0000[ID] 'DATEINAME' 00 (55/U) 02 00 04 'S' 00 (55/U) 05 00 05 'NAME' 00 07 13 00

Die Werte in Klammern stehen als U im Text ich behaupte mal das es der Bindestrich ist.

Nur weiß ich nicht wozu die die anderen Werte gut sind.
Im Beispiel also 02 00 04 oder 05 00 05.

Sehe ich das richtig das 00 eine Leerzeile repräsentiert?

Find ich gut das ihr beiden mich hier etwas unterstüzt
Da es das erstemal ist das ich sowas mache und nicht genau weiß was ich mache
Ich werd weiterhin meine beobachtungen hier posten.

[nicodex]

Zitat von ryLIX:

Nur weiß ich nicht wozu die die anderen Werte gut sind.
Im Beispiel also 02 00 04 oder 05 00 05.

Wie ich oben schon geschrieben habe:

02 00 04 -> 0002 (litte-endian Word), 04 (Byte) -> Länge von data_format ("S") inklusive der abschließenden 00 (#0), Unbekannt (immer 04 für data_format)

05 00 05 -> 0005 (litte-endian Word), 05 (Byte) -> Länge von data_names ("NAME") inklusive der abschließenden 00 (#0), Unbekannt (immer 05 für data_names)

[nahpets]

Hallo,

die 00 interpretiere ich auf zwei Weisen:

Ende eines Strings (nullterminierte Zeichenfolgen) oder Teil eines zweibytigen Wertes.
Zugegebener Maßen habe ich noch keinen "Griff" gefunden, der auch nur eine dieser Annahmen definitiv bestätigt.

Deiner "Bindestrichtheorie" möchte ich widersprechen, die Bindestriche sind im Text der Optik wegen und nicht auf den Inhalt der Dateien zurückzuführen. Sonst müssten überall wo im Text Bindestriche sind auch in der Datei U's stehen. Habe nicht den Eindruck, dass die Textdatei den vollständigen Header widerspiegelt, sondern nur die Informationen, die der Programmierer mit ziemlicher Sicherheit entschlüsselt hat. Und das sind die lesbaren Zeichenfolgen.
Unklar ist mir, welchen Zusammenhang die Bytes zwischen den Zeichenfolgen mit dem Inhalt der Dateien hinter dem Header haben.

Nico's Erklärung klingt durchaus plausibel.

[nicodex]

Das Problem sind die vielen Interpretationsmöglichkeiten, die man erst durch möglichst viele Daten und sinnvolle "Muster" konkretisieren kann.

02 00 04 .. könnte zum Beispiel auch folgendes bedeuten: Länge des "Wertes" = 2, Typ des "Wertes" = 0 ( = String), Bedeutung des "Wertes" = 04 ( = Parametertypliste einer Definition), .. "Wert".

Um die Möglichkeiten einzuschränken, hilft nur die Auswertung aller zur Verfügung stehenden Informationen: Anzeigen/Ausgaben von offiziellen und inoffiziellen Anwendungen und Zurückentwicklung selbiger (und wenn es "nur" dazu dient, um festzustellen wie viele Bytes unter welchen Bedingungen gelesen werden - allein diese Information ist sehr hilfreich). Viele dieser Informationsquellen stehen den Leuten im Forum nicht zur Verfügung. Anhand von zwei Dateien ist keine Vollständige Analyse zu erwarten.

[ryLIX]

Also leider kann ich nur mit der inoffiziellen Software was machen da die offizielle sich die Daten zu einem mir unbekannten Zeitpunkt holt.

Was mir noch aufgefallen ist ist folgendes:
Das Konvertierungsprogramm macht einen CRC Check. Wenn man nun ein Zeichen hinzufügt bzw löscht kommt der CRC Fehler.
Wenn aber nur zwei Zeichen vertauscht geht es ohne Probleme.

Ich weiß leider nicht wie ich das Programm noch etwas mehr ausnutzen kann.
Asambler hab ich garkeine Ahnung von und mit Debugging hab ich auch nicht die große Erfahrung.

Edit:
Ich hab mir gerade mal eine der Schlüsselwort Dateien geladen.

Auch dort ist der Header nach dem selben Prinzip aufgebaut.
Enthält aber weniger Informationen weil der Inhalt der Datei nicht so komplex ist
Ich hab die Datei mal angehängt.