Hallo, ich habe hier eine Siemens SPS S7 1200 die ich als defekt erstanden und dann repariert habe. Jetzt würde ich aus Neugier gerne herausfinden was für ein Prozessor da innendrin werkelt. Mit der Bezeichnung auf dem Haupt-IC findet man keine weiteren Informationen, ich gehe darum davon aus dass es ein speziell gefertigter IC ist. Selbst Siemens wird hier aber nicht das Rad komplett neu erfinden, sondern als Prozessor wird dort irgendetwas übliches wie z.B. ein ARM werkeln. Der eigentliche Anwendungscode der von der zugehörigen Programmiersoftware in die laufende Steuerung hochgeladen wird habe ich schonmal abgehört, das scheint aber kein (zumindest mir bekannter) Assembler zu sein sondern eine Art Zwischencode der vom Prozessor interpretiert wird. Ein Firmwareupdate habe ich mir auch schonmal mit einem Hex-Editor angesehen, aber damit komme ich nicht weiter. Wobei ich dort bisher nur nach dem Vorkommen von Zeichenketten und verdächtigen Texten gesucht habe. Im Anhang Fotos der Hauptplatine mit den Bezeichnungen auf den Bauteilen. Gibt es vielleicht Dinge (Anbindung des externen Speichers etc.) woran man verschiedene Prozessortypen erkennen kann?
Firmware wäre wohl der beste Ansatz zum rausfinden, falls die nicht verschlüsselt ist. Ansonsten könnte ich mir schon vorstellen, dass das ne Eigenentwicklung ist, die machen sowas ja schon ne Weile...
Also komplett verschlüsselt wohl nicht, zumindest finden sich einige Strings von Dateipfaden zu den Quelldateien wieder. Vielleicht sind andere Teile aber doch verschlüsselt, es wurde in der Vergangenheit über ein Firmwareupdate ja mal ein hardcodiertes Passwort herausgefunden, vielleicht sind die darum etwas vorsichtiger ;-) Wobei es längere Strings gibt die nach 8 Bytes immer durch ein 0xff getrennt sind, wie auch welche die das nicht aufweisen. Die Ursprungsdatei ist Intel-Hex codiert, die ich erstmal 1:1 in Binär zurückgewandelt habe. Vielleicht sind das nur Artefakte der Wandlung. Ich habe momentan nur keinen Ansatz wie ich in der Firmware nach Kennzeichen suchen kann. Eine Idee die ich hätte, wäre nach öfters vorkommenden Byte-Reihenfolgen zu suchen, um damit auf Dinge wie Funktionsaufrufe schließen zu können. Wenn die Firmware in C++ geschrieben wurde, muss man da doch bestimmte Muster erkennen können.
Vermutlich als ein ASIC von Fujitsu hergestellt. Mich würde aber mal der I/O-Schutz interessieren. Ist der auf einer anderen Platine? Ich meine mich auch zu erinnern, daß Siemens erst diverse Generationen von normalen Prozessoren verwendete und dann auf eine direkte Implementierung als VM in Hardware umstieg.
Abdul K. schrieb: > Vermutlich als ein ASIC von Fujitsu hergestellt. Mich würde aber mal der > I/O-Schutz interessieren. Ist der auf einer anderen Platine? Der I/O Krams ist auf einer anderen Platine, von der kann ich später gerne mal Fotos machen. Die Spannungsversorgung ist auf einer weiteren Platine, da war auch der Defekt (wurde fälschlicherweise an 230V AC statt an 24 V DC angeschlossen). > Ich meine mich auch zu erinnern, daß Siemens erst diverse Generationen > von normalen Prozessoren verwendete und dann auf eine direkte > Implementierung als VM in Hardware umstieg. Das war bei den S7 300 so. Da gab es Varianten welche MC7 (quasi der SPS Assembler) von Hause aus sprechen, Nachbauten gibt es z.B. von Vipa käuflich zu erwerben. Die 1200 ist aber eine komplett neue (Low-Cost)-Steuerung welche kein MC7 kann.
Angehängte Dateien:
-
IO-Vorderseite.jpg
510 KB -
IO-Rueckseite.jpg
460 KB
Im Anhang die Fotos von dem I/O Board. Leider kann man auf denen die Bezeichnungen nicht wirklich erkennen. Ich habe mal einen Musterzähler über das das ca. 1MB große Firmwareupdate laufen lassen. Bei 8 Byte Größe sind dieses die 15 häufigsten: Vorkommen: 381 - Data: e92d0002e10f1000 Vorkommen: 381 - Data: 2d0002e10f1000e3 Vorkommen: 381 - Data: 1080e121f001e8bd Vorkommen: 381 - Data: 80e121f001e8bd00 Vorkommen: 381 - Data: e121f001e8bd0002 Vorkommen: 272 - Data: e5940000e3500000 Vorkommen: 248 - Data: 21f001e8bd0002e5 Vorkommen: 243 - Data: 0000d3a00001dbff Vorkommen: 232 - Data: 184000c1184000c0 Vorkommen: 228 - Data: 0002e10f1000e3c1 Vorkommen: 228 - Data: 02e10f1000e3c110 Vorkommen: 228 - Data: e10f1000e3c11080 Vorkommen: 228 - Data: 0f1000e3c11080e1 Vorkommen: 228 - Data: 1000e3c11080e121 Vorkommen: 228 - Data: 00e3c11080e121f0 Bei 16 Bytes diese: Vorkommen: 228 - Data: e92d0002e10f1000e3c11080e121f001 Vorkommen: 228 - Data: 2d0002e10f1000e3c11080e121f001e8 Vorkommen: 228 - Data: 0002e10f1000e3c11080e121f001e8bd Vorkommen: 228 - Data: 02e10f1000e3c11080e121f001e8bd00 Vorkommen: 228 - Data: e10f1000e3c11080e121f001e8bd0002 Vorkommen: 153 - Data: e92d0002e10f1000e3811080e121f001 Vorkommen: 153 - Data: 2d0002e10f1000e3811080e121f001e8 Vorkommen: 153 - Data: 0002e10f1000e3811080e121f001e8bd Vorkommen: 153 - Data: 02e10f1000e3811080e121f001e8bd00 Vorkommen: 153 - Data: e10f1000e3811080e121f001e8bd0002 Vorkommen: 152 - Data: 0f1000e3811080e121f001e8bd0002e5 Vorkommen: 119 - Data: e5940000e2400001e5840000e5940000 Vorkommen: 119 - Data: 940000e2400001e5840000e5940000e3 Vorkommen: 119 - Data: 0000e2400001e5840000e5940000e350 Vorkommen: 119 - Data: 00e2400001e5840000e5940000e35000 Jetzt müsste man nur noch möglichst viele Compileroutputs von Vergleichsarchitekturen finden.
Nativen ARM Code erkennt man an einer Häufung von 32-Bit Worten der Form Exxxxxxx. Die meisten Codeworte eines Programms sehen so aus, weil E=unconditional. Allerding muss man bei einer solchen Analyse erst einmal rauskriegen, ob big- oder little-endian.
Hallo, am aussichtsreichsten wäre es wohl, den Anfang der Firmware durch alle verfügbaren Disassembler zu jagen, ob was vernünftiges rauskommt; schliesslich fangen alle Programme ähnlich an, z.B. DI JMP... Ist leider sehr mühsam. Thomas W. schrieb: > Ich habe mal einen Musterzähler über das das ca. 1MB große > Firmwareupdate laufen lassen. Ja, Statistiken wären auch eine gute Möglichkeit, aber dazu bräuchte man Vergleichsstatistiken von jedem in Frage kommenden Prozessor, über möglichst viele Projekte gebildet, sonst sagt das nichts aus. Woher nehmen? Schon möglich, dass es irgendwo Profiabteilungen gibt, die sich sowas erarbeitet haben, dann wäre die Analyse auf Knopfdruck möglich. Aber da müsste man wohl bei Spezialisten für Industriespionage und bei Geheimdiensten suchen. Lass mal deine Beziehungen spielen. Gruss Reinhard
A. K. schrieb: > Nativen ARM Code erkennt man an einer Häufung von 32-Bit Worten der Form > Exxxxxxx. Die meisten Codeworte eines Programms sehen so aus, weil > E=unconditional. Allerding muss man bei einer solchen Analyse erst > einmal rauskriegen, ob big- oder little-endian. Dem muss ich mal nachgehen, denn zumindest habe ich viele Werte nach dem Muster. Mein Ansatz war Assembler Konstrukte wie
1 | xor eax, eax |
bei x86 zu finden. Ich habe meine Analyse mal in 2-Byte Mustern über calc.exe laufen lassen. Dort kommt diese Anweisung aber erst an 104. Stelle der häufigsten Muster. Am häufigsten sind hingegen die nops. Wobei ich ein Muster immer (zur Zeit noch) byteweise überprüfe, wenn mal 10 nops hintereinander stehen werden diese 9 mal als Muster gewertet. Das müsste ich nochmal anpassen. Es gibt ja diese Webseite zum disassemblieren http://onlinedisassembler.com Nur muss man da vorher die Platform kennen, eine automatische Erkennung gibt es nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.