Revolutionäre Entdeckung wegen konsolenspezifischer PS3-Verschlüsselung?!

[Takeshi]

Nun bleibt die Konsole auch ohne FlashFun Modus an, zeigt aber nach wie vor kein Bild! Aber die Konsole geht nichts mehr aus!

Genau das hab ich bei mir auch, und da ist die Serial meilenweit auseinander.

Bin gerade in der Topic am lesen, hier mal der Link: klick

Edit: Der Typ mit der gebrickten PS3 hat ja seine Serial gepostet, das ist die 03-27453072-6028021-CECH-2004A. Das Backup, das laufen soll, hab ich heruntergeladen, stammt aus einer 03-27453072-57xxxxx-CECH-2004A, also um ungefähr 0300000 daneben, was ja schon ordentlich ist. Sein originales Backup ist wirklich so im Arsch, da lässt sich auch gar nicht die Modellnummer rauslesen, da steht nur 0xFF drin.

Mich schockt ja auch gerade, dass die sich da ja so sehr mit dem ganzen Downgrade-Kram auskennen, aber sich a) nicht sicher sind, ob das A und B am Ende wirklich für die Festplattengröße steht und b) nicht sicher wissen, dass der erste Teil der Seriennummer bei einem Modell quasi immer gleich ist.

[Takeshi]

Mein erster Clip ist nun im Arsch, der war mit einer Schraubzwinge befestigt und urplötzlich gab der E3-Flasher nur noch den Fehler 10001100 aus. Neuer Clip dran, lief wieder. Aber schon beim Dritten Lese-/Schreibvorgang ging es ohne Schraubzwinge nicht mehr. Man ist das ein Müll.

Habe in die Konsole 03-27453072-569xxxx-CECH-2004A den Dump von esprit (von ps3-tools) aus einer 03-27453072-57xxxxx-CECH-2004A geflasht, wieder kein Bild. Und nun sind die Konsolen nicht so weit von der Seriennummer auseinander, aber kann natürlich trotzdem sein, dass die Serial aus einem anderen "Key-Block" ist. Die Firmware ist übrigens auf beiden 3.60, den fremden Dump hab ich auf 3.55 gepatcht.

Im nächsten Schritt hab ich den originalen Dump verändert. Ab 0x03F000 bis 0x03F0BF stehen individuelle Daten, darunter die Serials. Hab dort die Daten aus einer anderen PS3 geschrieben und die PS3 bootet, es läuft ein Spiel von Disk und ein BD-Film auch. Die Festplatte wurde ebenfalls erkannt. Ich habe fast das Gefühl, die Daten selbst in dem Bereich sind der Konsole total egal. Die sind höchstens ein Indiz für andere relevante Daten im Flash.

Habe von esprit noch mehr Dumps erhalten, aber die probier ich erst morgen durch. Aber ich glaub irgendwie immer weniger dran. Mit der PS3 von fanavity werde ich das aber auf jeden Fall noch ausprobieren, wenn die wieder läuft.

[Takeshi]

Und wieder kein Erfolg. Nach wie vor ist die Testkonsole eine 03-27453072-56xxxxx, rein geflasht hab ich einen Dump einer anderen 56xxxxxx (Mainboard Serial ist minimal drunter) und eine 57xxxxx, beide führen zu einer toten Konsole, die an bleibt.

Ich bin jetzt eher dran die Dumps zu vergleichen und den Aufbau zu verstehen. Dazu nahm ich zwei Dumps des gleichen Modells mit der gleichen Firmware (3.60) zur Hand. Da habe ich nun folgende Erkenntnisse gewonnen:
- Wenn ich den Dump entpacke, unterscheiden sich die Daten im Root-Verzeichnis alle, auch die metldr im Ordner asecure_loader. Die Daten sind also Konsolen-individuell
- In den Ordnern ros0 und ros1 befindet sich die aktuelle Firmware, in dem anderen Ordner die vorherige (wieso auch immer). In einer war 2x die 3.60 drin, in der anderen die 3.60 und im anderen die 3.55. Die einzelnen Dateien der 3.60 sind in beiden Dumps identisch (macht Sinn) und die beiden Ordner, die beide die 3.60 enthalten, sind auch identisch.
- Ab 0x100470 in Dump 2 scheint ros0 zu beginnen (mit 360.000.SCE), denn da kommt ein langer Block mit Inhalt, der sich unterscheidet. Das geht grob bis 0x61C8CF. Da also noch gar nichts ungewöhnlich. In dem ersten Dump steht 355.000 bei 0x5C7A20.
- Jetzt wird es spannend. Bei 0x800470 beginnt ein weiterer langer Block mit "360.000.SCE" und der ist in beiden Dumps identisch! Damit gibt es hier KEINE individuelle Verschlüsselung. Hier ließen sich Daten bei einem Brick damit austauschen, wenn die Konsole auch mit einem 3.55-Patch nicht mehr startet.
- Die Datei bootloader_0 im Root-Verzeichnis finde ich im Dump bei 0xFC0000, auch "unverschlüsselt", 1:1. Die anderen sind auch alle irgendwo 1:1.

Für mich heißt das, es lassen sich alle Daten im Dump tauschen, da sie "unverschlüsselt" sind. Selbst, wenn der Dump fehlerhaft ist und noch ein paar Daten vorhanden sind, könnte sich damit eine PS3 retten lassen, auch wenn kein fremder Dump direkt läuft, solange die individuellen Daten vorhanden sind. Dazu braucht es kein Programm, das die einzelnen Dateien wieder zu einem Dump zusammenschustert, das geht von Hand, wenn auch mit einem gewissen Aufwand. Man muss nur noch herausfinden, wann wo was steht. Der Flow Rebuilder findet es auch irgendwie heraus. Die Dateien wie der bootloader_0 sind vom Flow Rebuilder "entpackt" nach wie vor verschlüsselt. Der Bootloader ist bestimmt bei allen PS3s eines Modells mit einer Firmware immer gleich, wird aber individuell verschlüsselt - wie individuell ist jetzt die Frage. Sollte es irgendjemandem gelingen zwei Konsolen zu finden, bei denen sich der Dump untereinander austauschen lässt, wäre bei diesen Dateien zu suchen, ob da etwas identisch ist. Das müsse dann nämlich der Fall sein, anders kann ich mir nicht vorstellen, dass ein fremder Dump läuft.

Jetzt wäre noch zu untersuchen, wie sich besagte Dateien mit verschiedenen FW-Versionen verändert. Und dann könnte man die mal manuell in einen fremden Dump schieben und gucken, ob er irgendwann läuft und wenn ja, wann.

So, jetzt geh ich mal ins Bett

[DoggyDog]

Mensch Takeshi,
da hast du aber ganze Arbeit geleistet, respekt  Jetzt brauchen wir zwei i.O.-Dumps von Konsolen, deren Dumps untereinander kompatibel sind. Dann könnte man diese genauer unter die Lupe nehmen.

[DoggyDog]

So, heute folgende Konstellation getestet:

Meine Konsole:
Serial: 03-27438172-1xxxxxx-CECHL04
MB-Strichcode: 3HFA0137542A
Made in China MTK 4-117-082-01

Folgende Backups gepatcht und geflasht:

Backup von Sasch:
Serial: 03-27438172-4547208-CECHL04
MB-Strichcode: 400600570763

Backups aus dem anderen Forum:
MB-Strichcode: 400600329656
MB-Strichcode: 400611004966
MB-Strichcode: 400612805123

Ergebnis:
Immer blieb die Konsole nach dem Flash an, HDD und USB wurden nicht angesteuert, Bild wurde nicht ausgegeben. Der Clip und der E3 waren während der Testreihe immer angeschlossen, somit kann auch ein Fehler beim schreiben des NORs nahezu ausgeschlossen werden - was auch dadurch belegt wird, dass nach dem Flashen des richtigen Dumps alles wieder normal gelaufen ist.

Vielleicht ist der Misserfolg darin begründet, dass ich mit meiner MTK-Konsole offensichtlich nur Fremd-Dumps von FOX-Konsolen zum testen hatte. Ich glaube dass der MB-Strichcode bzgl. der evtl. Kompatibilität wichtiger als die Serial ist. Vielleicht findet sich ja noch ein Dump welcher theoretisch besser passen könnte 

[Takeshi]

Also ein Dump von einer MTK in einer FOX oder umgekehrt wird sicher nicht funktionieren. Wenn das geht, würden wohl Dumps von allen Konsolen des Modells laufen. Die Konsolen haben ja sogar einen ganz anderen Aufbau der Serials, da wird erst recht der Key unterschiedlich sein.

Klar, die Serial des Mainboards ist wichtiger, aber die Serial ist ja ebenfalls fortlaufend, wie auch die Konsolen-Serial. Die Serials sind nur untereinander etwas vermischt, die laufen also nicht 100%ig parallel hoch, sondern etwas schwammig. Deshalb lässt sich auch nie 100%ig sagen, welche Laufwerksplatine in eine Konsole gehört, sondern nur, ob es wahrscheinlich ist, oder eben nicht. So ist das hier auch. Wenn also die Serial der Konsole um geradeeinmal 3 daneben liegt, wird die vom Mainboard auch nicht viel weiter auseinander sein. Dabei muss man auch beachten, beim Mainboard gibt es mehr Stellen als bei der Konsolen-Serial. Das heißt, steigt die Serial der Konsole um eins, steigt die des Mainboards nicht immer um eins mit, sondern mehr.

Das Ergebnis, dass die Konsole an bleibt, aber nicht startet, ist ja der ganz normale Misserfolg, das passiert immer mit dem falschen Dump.

[DoggyDog]

@Takeshi: Mit einem "ganz falschen" Dump hatte ich seither einen YLOD bekommen.

[Takeshi]

Ja, das war auch bisher so meine Info, aber ich hatte mit einem falschen Dump noch nie einen YLOD.

[DoggyDog]

Wenn du ein FAT-Backup auf eine Slim schiebst, gibt es sicher ein YLOD - selbst getestet 

[Takeshi]

Ja, das hab ich auch schon gedacht, hab ich aber irgendwie immer gelassen, weil das wirklich total Banane wäre, das kann ja nicht laufen.

[DoggyDog]

Das war einfach ein Versuch, da ich für das Slim-Board eh keinen korrekten Dump hatte. Wollte halt wissen, was passieren wird. Das würde aber wiederum bedeuten, dass zumindest etwas der flaschen Dumps beim gleichen Modell interpretiert wird. Wenngleich dies auch nur zur folge hat, dass die Konsole an bleibt. Software-Flashfun-Mode quasi 

[edit]
Takeshi, du hattest ja auch einen Versuch mit negativem Ergebnis ausgeführt. Kannst du hiervon mal die entsprechenden"Seriennummern" vom Mainboard gegenüberstellen?

@all:
Ich suche nun einen Dump einer CECHL welche diesem MB-Strichcode (siehe Konsole oder cISD) nahekommt:
3HFA0137542A

[Takeshi]

Ich hab sogar mehrere Versuchen mit negativem Ergebnis durchgeführt, hab glaub 3 verschiedene Dumps, die irgendwie in Frage kommen, ausprobiert. Alle brachten das gleiche Ergebnis.

Ich beschäftige mich damit später weiter, eventuell morgen. Bin gerade mit etwas anderem beschäftigt.

[DoggyDog]

Habe mittlerweile zwei MTK-Dumps beschaffen können:
3HF10247772B
3HF10277938A

Die "MB-Nummer" ist zwar nicht ähnlich, habe es aber trotzdem versucht - leider ohne Erfolg - es ist das selbe Ergebnis wie mit den anderen Backups 

[DoggyDog]

Was meint Ihr zu folgenden Aussagen:

hi

also ich hab mich ja nun mit dem thema ps3 Backup beschäftigt um herauszubekommen wie was funktioniert , hab die dateien alle mit einem assemble "übersetzen lassen" und mit einem compiller emuliert damit ich weiss was systemabhängig ist und was nich --> Fazit: Die sernr spielt absolut keine rolle lediglich der datecode ist wichtig aber auch nur wegen dem BD Laufwerk da da die LWPlatinennr mit drinnen steht , was aber auch kein prblem ist da man diese ja nur einzutragen brauch vom BU seiner konsole:-) also alle nummern sin im grossen und ganzen egal , die fragt die konsole nicht ab der rest in de csid sind DUMMYfiles um den speicher zu füllen.

warum brauchst du die platinennummer?

ich hab das BU ohne angeschlossener geräte geflasht also keine hdd kein db kein wlan und BT nichts angeschlossen.

das was entschlüsselt wird ist nur zum einen die Driveboards der BD LW und der HDD da ja die systeme untereinander alle gleich sind vom gleichen DC her.

wie ich geflasht habe:

mein defektes BU komplett mit Dummy Files befüllt ( also NOR gelöscht)

das BU der anderen konsole 3 mal hintereinander eingeflasht im FUN mode und dan 1x das gepatchte

Kosole abgesteckt ->eingesteckt->konsole lief an alles ging nur kein internet

Das hört sich für mich "abenteuerlich" an. Ich denke, der User hat uns einen Bären aufgebunden, oder?

[Takeshi]

Die Aussage hört sich nicht wirklich seriös an, finde ich. Ich bezweifel, dass man den Code einfach so interpretieren (Assembler) kann, er ist ja teilweise verschlüsselt.

Der Satz "das was entschlüsselt wird ist nur zum einen die Driveboards der BD LW und der HDD" macht außerdem keinen Sinn. Wie soll bitte das Laufwerk entschlüsselt werden? Höchstens die Firmware im Laufwerk, aber auch das ist Müll, denn das Laufwerk hat nichts damit zu tun, ob die Konsole startet oder nicht, genau so die HDD.

Wie oft man vorher etwas anderes in den NOR schreibt, ist total egal.

Der erste Eintrag klingt also für mich nicht wirklich glaubwürdig, der zweite ist totaler Schrott.

Ich glaube, wenn Sony-Mitarbeiter in ihrer Freizeit so was lesen, lachen die sich immer kaputt