Dump defekt ? !?!?!

Grobistar · 07. Februar 2015, 15:44:16

Hallo Leute,

wollte gestern meine Ps3 via E3 Flasher downgraden / PS3 Slim 2004A Dyn 001, downgradebar bis 2.70 Originalsoftware 4.66) Habe mir den Original Flash ausgelesen, mit Norinspector geprüft und für OK befunden (bei 5 Dumps)! Ich
habe den Dump gepatched mit Nor Patcher V1 und wieder in den Nor geschrieben. Leider schaltet sich die Konsole nach ca. 5 Sek. aus und die rote LED fängt an zu blinken. Nach langer Suche bei Google und im Forum,
bin ich auf den Dump Checker gestossen, der mir 3 Fehler angezeigt hat : metldr Statistic (00407) asecure_loader (00408) und Ros0 Hash (00902) bei allen Dumps ! ! !

Zu sagen ist noch, das die Konsole im Fun Modus an bleibt Tristate gegen Masse !

Hat jemand vielleicht die Möglichkeit meinen Dump anzuschauen, bzw. zu fixen, wenns möglich ist ! Habe gelesen das man es via Hex Editor mit einem anderen Dump machen kann, habe aber leider selber noch keine Erfahrung damit gemacht !

Für hilfe oder Ratschläge wäre ich sehr dankbar !

Ich hoffe die Angaben reichen aus !

Takeshi · 07. Februar 2015, 21:54:18

Das Problem ist, metldr ist defekt, das kann man nicht ersetzen.
Sund die Dumps denn alle gleich? Vergleich die mal über eine Prüfsumme.

Grobistar · 07. Februar 2015, 21:56:36

Ja die Dumps sind soweit alle gleich....Muss die HDD vorher zwingends am Pc formatriert werden, wenn der Dump gepatched ist ?

Takeshi · 07. Februar 2015, 22:16:52

Wer erzählt denn, dass die am PC formatiert werden muss? So ein Quatsch. Die PS3 formatiert die schon selbst. Aber das ist hierfür sowieso egal.

Grobistar · 07. Februar 2015, 22:20:05

Hmm..also habe ich wohl keine chance mehr ?

Takeshi · 07. Februar 2015, 22:38:31

Leider nein, zumindest ist die Wahrscheinlichkeit vernichtend gering. Lad den Dump aber mal hoch und schick mir den Link per PM. Oder schick ihn mur per Mail, dann gebe ich dur meine Adresse.

Takeshi · 08. Februar 2015, 00:26:51

Also ganz ehrlich, für mich deutet nichts darauf hin, dass der Dump defekt ist.

Ein Fehler an den Adressleitungen kann es nicht gewesen sein, denn dann wären die Daten am falschen Ort und damit völlig zerschossen, da würde jedes programm sofort herummeckern und das Entpacken des Dumps wäre nicht möglich.

Bleiben Fehler an den Datenleitungen. Das würde dazu führen, dass mindestens ein Bit für längere Zeit immer 0 oder 1 ist. Leider lässt sich das in der metldr-Datei nicht wirklich feststellen, da die Daten darin ja unbekannt sind und Nullen und Einsen an jeder Stelle möglich sind. Einzig der Anfang ist überprüfbar. Der beginnt bei dir mit 0x00000E85 und das ist korrekt. Wenn nun der Fehler während des Lesens des metldr aufgetreten wäre, wäre es sehr wahrscheinlich, dass sich das durch die ganze Datei bis dahinter durchzieht. Danach ist der Dump jedoch erst mal "leer", er enthält längere Zeit 0x00. Wenn also ein Datenbit defekt wäre, müsste es zu einer binären Null geworden sein. Nun kommt erst mal nichts, aber nach trotzdem weniger als 5 % kommt auch noch 0xFF, was mit dem Fehler aber nicht möglich gewesen wäre. Bleibt somit nur noch übrig, dass der Fehler in der Datei auftrat und vor dem Ende verschwunden ist. Unwahrscheinlich, aber natürlich nicht unmöglich.

Jetzt suche ich gerade nach einem Programm, das Daten binär und nicht in HEX darstellt, um solche Muster zu erkennen. Allerdings scheint das Angebot sehr mager zu sein und ich rede mich gerade darüber auf, dass jemand in einem Forum danach fragt und die Leute nichts besseres zu tun haben, als seine Frage zu ignorieren und ihm stattdessen zu erklären, dass seine Frage doof ist und er einen HEX-Editor bräuchte. Was für Trolle in manchen Foren herumrennen ...
Habe die Suche erst mal aufgegeben, die Datei mit dem HEX-Editor weiter betrachtet und nach 0x0 und 0xF gesucht, und zwar so, dass alle 16 Bit abgedeckt werden. Ich konnte bei ca. 0 %, 25 %, 50 %, 75 % und 100 % der Datei 0x0 und hxF finden, wodurch an diesen Stellen alle Datenleitungen beide Zustände annehmen konnten. Damit ist es unglaublich unwahrscheinlich, dass die Datei wirklich defekt ist.

ros0 könnte man wirklich überprüfen, nur bräuchte ich dafür einen Flash-Dump, der die Firmware 4.60 enthält. Hab ich nicht.

So, was nun? Fakt ist, deine PS3 startet nicht mehr, das lässt sich nicht wegreden. Mein Vorschlag wäre, du flashst den gepatchten Dump in den Flash, liest ihn erneut wieder aus und vergleichst dann die ausgelesenen Daten mit denen, die du in den Flash hineinschreiben wolltest. Vermutlich sind da Unterschiede. Dann wurde er einfach nur falsch in den Flash geschrieben, daher der Ausfall der Konsole.

Kannst du mir noch einen Link zu dem Programm schicken, mit dem du den Dump überprüft hast? Ich finde damit nämlich verschiedene Programme.

Grobistar · 08. Februar 2015, 12:20:02

So danke für deine Mühe. Ich habe dir eine PN geschrieben, wo der link zum Ps3 Dump Checker ist. Hatte vorher immer mit Norinspector geprüft und dieser zeigt mir auch kein Fehler an. Mit dem Nor Inspector habe ich schon einige Ps3 geprüft und danach gepachted. Zum Fehler, scheint es mir ein kurzer Ylod zu sein (Rot Standby, grün, kurz gelb, Rot blinkend) Vielleicht habe ich auch beim Kühler abheben den Grafikchip mit "angehoben" , vielleicht sollte ich mal ein Reflow versuchen. Koischerweise belibt die Ps3 bei Tristate gegen masse ja an und das heißt doch normalerweise kein Hardware defekt sondern nur Systemfehler oder ?

Takeshi · 08. Februar 2015, 13:02:31

Das Programm ist ja witzig. Am Anfang zeigt es einem einen Text an, dass der Programmierer ja keinerlei Haftung übernimmt. Der Kasten hat die Buttons Ja/Nein/Abbrechen und egal was ich wähle, es kam immer "du kannst wohl nicht lesen". Irgendwann ging es dann mit "Ja". Na ja, wie dem auch sei.

Der Fehler mit metldr ist unkritisch, da nur statistisch. Das Programm prüft, wie häufig jede Bitkombination vorkommt. Da es sich um verschlüsselte Daten handelt, dürften keine Muster erkennbar sein, die statistische Verteilung sollte daher gleichmäßig sein. Das heißt bei 256 verschiedenen Möglichkeiten für ein Byte würde jede Kombination zu 0,39 % auftauchen. Der Programmierer hat eine willkürliche Grenze von 0,5 % festgelegt, die nicht überschritten werden darf, doch 0,51 % enthalten 0x00 und damit zu viel. Das ist aber egal.

Dann meckert das Programm herum, dass zwischen 0x0F0D0 und 0x2F000 nur 0x00 stehen dürfte, nur steht da auch was anderes drin. Das an sich stört nicht, da dort eh keine Daten sind, die genutzt werden. Es ist nur seltsam, dass da trotzdem etwas steht, was entweder daran liegt, dass der Dump dort fehlerhaft gelesen wurde und dann vermutlich auch an anderen Stellen, oder der Programmierer weiß schlicht nichts von den Daten, die dort aber gewollt stehen.

Ros0 ist egal, da sich darin die eigentliche Firmware befindet, die sowieso überschrieben wird und zudem austauschbar ist.

Alles in allem sind die Fehler also unkritisch. Allerdings deuten zumindest die letzten beiden darauf hin, dass wo anders unentdeckte Fehler sind. Das ist aber nur Spekulation. Ich habe dann noch andere Dateien überprüft, die teilweise auch fehlerhaft sein sollten, aber trotzdem funktioniert haben. Kann sein, dass die anderen Dumps tatsächlich fehlerhaft sind, aber funktioniert haben die trotzdem. Deshalb würde ich daraus jetzt nicht schließen, dass dein Dump so defekt ist, dass du die Konsole wegschmeißen kannst. Also gilt es nun die Konsole mit dem Dump wieder zum Laufen zu bringen. Du solltest also das versuchen, was ich im vorherigen Post beschrieben habe.