Präambel: Dieser Thread richtet sich an die Erfahrenen User hier, bitte nach Möglichkeit nicht OT werden bzw. Newbie-Fragen stellen - vielen Dank dafür im Voraus!
Hallo zusammen,
folgende, nach meinem Kenntnisstand "revolutionäre" Entdeckung wurde heute in einem anderen Forum gemacht:
-User A hat eine PS3 mit Brick, einen E3 und leider kein valides NOR-Backup --> Backup korrupt, nach bisheriger Kenntnis kann die PS3 nicht mehr gerettet werden
-User B hat(te) eine PS3, baugleiches Modell, die ersten 11 Stellen der Seriennummer identisch zu User A, die letzten 6 stellen weichen ab
-User A spielt aus Verzweiflung das NOR-Backup von User B auf --> PS3 bootet und funktioniert bis auf das LAN und W-LAN. In der Firmware ist die MAC-Adresse nicht eingetragen (Einschränkung kann evtl. noch per Homebrew gelöst werden)
Meine bitte wäre, dieses Phänomen hier gegenzuprüfen und hoffentlich bestätigen zu können. Hierzu würde ich gerne einige Seriennummern sammeln sofern ihr ein Backup der entsp. Konsole erstellen könnt oder ggf. bereits verfügbar habt. Vielleicht haben wir Glück und bekommen die Möglichkeit, eine ähnliche Konstellation nachzubilden. Wenn das Experiment ein Erfolg wäre, würde das unsere bisherigen Annahmen bzgl. der spezifischen Verschlüsselung komplett auf den Kopf stellen. Im Prinzip sollte dann jede Konsole zu retten sein, selbst wenn kein NOR-Backup vorhanden ist.
Ich könnte Backups für folgende Modelle beisteuern:
v4 CECH-H
03-27434672-2xxxxxx
v6 CECH-L
03-27438172-5xxxxxx
08-27438172-1xxxxxx
v7 2004B
02-27453973-1xxxxxx
Habe zwar noch 2 weitere Backups auf der Platte, allerdings sind die Konsolen nicht mehr in meinem Zugriffsbereich und ich kann deswegen die Seriennummer nicht ablesen. Weckt euren Pioniergeist, es würde der ganzen Szene zu gute kommen ^^ Ich nehme an, dass die ersten 10 Stellen der Seriennummer ausschlaggebend sind!
Danke für eure Aufmerksamkeit und Mithilfe!
P.S.Eure Angaben machen nur dann Sinn, wenn die Backups zweifelsfrei der jeweiligen Seriennummer zugeordnet werden können. 50 Backups auf der Platte haben und glauben, dieses müsste jenes gewesen sein ist kontraproduktiv, Schaden dem Versuch und sind absolut unerwünscht.
v CECH-2004A
03-27453072-6060598
03-27453072-6243687
02-27453023-1829636
02-27453023-1726171
cechj04
02-27436773-0564412
cechl04
03-27438172-4547208
und ich selbst bräuchte ein backup für eine CECH-2004A - 03-27453072-6286812
Bin erst morgen Abend wieder zuhause, aber könnte dann einige Backups von mehreren CECHL besteuern.
Das wäre ja mal richtig cool. Obwohl ich mir das nicht wirklich vorstellen kann. Aber Hoffnung habe ich natürlich.
Hast du mal einen Link zu dem Forum?
Den Link gibt es, wenn mir Takeshi das freigeben würde. Ich will aber zunächst nicht zu viel Wind um etwas machen, was sich hinterher als Fake / Zufall oder sonstwas rausstellen würde.
Links zu anderen Foren sind hier doch immer erlaubt!
So,
ich habe folgendes zu bieten :)
CECH-2004A
03-27453027-6617195
CECH-L04
03-27438172-5194340
03-27438172-5190028
Mensch, Fanavity. Wenn du die Konsolen noch hast kannst du es ja schon alleine testen, die beiden CECH-L sind ja mit 13 stellen identisch :o 8)
Jop, allerdings ist die eine L04 quasi defekt. Mit der teste ich erstmal rum. Das ist die aus meinem Thread ;)
Ich nehme mal das Backup der "heilen" CECHL-04 und flashe das da.. Berichte dann morgen nach der Arbeit mal :)!
Das wäre sehr interessant. Falls das nicht klappt, gibt es schon eine weitere Idee bzw. noch ein Puzzlestein:
Auf dem Mainboard der PS3 ist ein Strichcode aufgedruckt, darunter steht nochmals eine Zahlenkombination. Wenn man den Flashdump extrahiert und in der cISD nachsieht, ist dort eine Zahlenkombination aus 8 Stellen der SN und eben dem Motherboard-Strichcode aufgeführt. Vielleicht gilt auch "nur" der MB-Strichcode oder eine Kombination aus SN + Strichcode, damit der Flashdump untereinander kompatibel ist...
Ich fühle es im Urin, die sind das was auf der Spur ;D
(http://www.abload.de/img/unbenannt-13xe2h.png)
Rot eingerahmt = Der erste 8er-Block der Seriennummer
Gelb unterstrichen = Der Strichcode auf dem Mainboard
Erst mal eine kleine Einführung in die Serials der PS3. Ich glaube du solltest einfach mal ein bisschen mehr auf der Page lesen, dann wär das für dich weniger sensationell :D
Zitat von: DoggyDog am 08. Januar 2013, 19:19:45
-User B hat(te) eine PS3, baugleiches Modell, die ersten 11 Stellen der Seriennummer identisch zu User A, die letzten 6 stellen weichen ab
Was das Normalste der Welt ist, denn die ersten 10 Stellen sind im Prinzip nur eine Modellnummer in lang. Die ersten beiden Stellen (00, 02, 03, 08) sind der Hersteller, von jedem gibt es maximal eine dazugehörige 8-stellige Ziffernfolge, die danach kommt. Die ist dann bei allen Konsolen dieses Modells von diesem Hersteller gleich. Die letzten 7 Stellen sind die Seriennummer und die gehen vermutlich über jede Zahl fortlaufend durch.
Seriennummern (allein) zu sammeln wäre demnach sinnlos, ich kann dir schon spontan ein paar der v6 auflisten:
03-27438172-5226154-CECHL04
03-27438172-5226155-CECHL04
03-27438172-5226156-CECHL04
03-27438172-5226157-CECHL04
Naja und so weiter. Das dürften alles gültige Serials sein.
Dumps hab ich zu
- v5-MTK
- v7-MTK und v7-FOX
- v8-MTK und v8-FOX
- v9-FOX
Hab auch zu allen die Serial, allerdings nur die direkte Serial ohne den Modellnummern-Code, den ich aber jederzeit dazustricken könnte.
Die Serial könnte auch nur deshalb im NOR stehen, damit Sony die über das Netzwerk auslesen kann. Die Xb360 sagt dir auch ihre Serial im Menü, bringt dir aber zum "Hacken" wenig.
(Post mal überarbeitet)
Habs geprüft, steht beides drin, sowohl der "Modellnummern-Code", als auch die Serial des Mainboards. Die eigentliche Serial der Konsole steht nicht drin.
Jetzt wäre es ja nur noch zu testen diese Daten zu ändern und in die Konsole zu schreiben. Gibt es eine Möglichkeit einen entpackten NOR-Dump wieder zu packen? Hab da noch nichts gesehen.
Wenn man die Bytes im NOR-Flash tauscht, so dass die nicht mehr vertauscht sind (also die swap-Datei, in der die Bytes nicht mehr "swapped" sind, total verwirrend), findet man die Serial der Konsole, also das, was in der cISD steht, auch direkt in der Datei, unverschlüsselt bei 0x03F090. Das heißt, die Daten lassen sich ändern, ohne den NOR neu packen zu müssen.
Das lässt mir jetzt doch keine Ruhe, ich probier das jetzt mit einer v7 aus. Wobei das schon SEHR stumpf wäre, selbst für Sony, wenn das so einfach ginge. Und es wäre lächerlich, wenn die Hackerszene das noch nicht herausgefunden hätte.
Edit: Vorweg, kein Erfolg.
Habe eine v7 mit der Serial 03-27453072-56xxxxx-CECH-2004A mit 3.72 drauf. Hab einen Dump von einer v7 mit der Serial 03-27453072-56xxxxx-CECH-2004A und der Firmware 3.60 rein geflasht. Dafür habe ich den Dump genommen, wie er ist, dann die Zeile mit der Serial getauscht und dann den kompletten Teil von 0x03F000 bis 0x03F0BF getaucht. Den Dump hab ich jeweils gepatcht, dass die PS3 eine 3.55 will. In jedem Fall blieb die Konsole an, war aber tot. Das wunderte mich, ich dachte da müsste ein YLOD kommen. Aber welche Daten da drin stehen, hat die PS3 nicht interessiert. Ich vermute jedoch, die unterschiedliche Firmware ist ein Problem, trotz des Patches. Der ändert ja nur, was die PS3 will, nicht, was die eigentliche Info der PS3 sagt (Vermutung).
also angeblich wurde nichts an den flash dateien geändert, sondern nur das backup einer ähnlichen serial geflasht. ich hab selber nachgefragt ob was verändert wurde, und will dies auch selber ausprobieren.
@Takeshi
hast du das backup mit den 3.55 downgrade patches vorher bearbeitet? angeblich sei dies auch wichtig, oder wurde es zumindest gemacht.
wie dem auch sei, ich werde es an einer CECH2504B ausprobieren, bei der der vorbesitzer schon ein falsches backup geflasht hat und mir nicht mehr das original bereitstellen konnte. auch er meinte schon, die ps3 blieb an mit blackscreen, und ohne ylod.
dennoch ist es für mich ein zweischneidiges schwert, denn eigentlich sollte der syscon mit dem cell (und rsx?) sozusagen verheiratet sein. warum muss sonst der barcode serial in sony's werkstätten immer vorher gescannt werden, bevor da was gemacht werden kann?
Syscon, Cell und Image gehören zusammen. Der RSX ist nicht gelockt.
Ich verfolge das hier mal gespannt weiter :)
Ich habe das gestern auch probiert mit einer CECH-2004A mit dieser Seriennummer
03-27453072-6286812
habe das gepatchte Backup (Downgrade) zurückgespielt von dieser PS3
03-27453072-6243687
Bild blieb schwarz - PS3 blieb aber an. Kein Yold. Leider ist mein Clip defekt so das ich im Moment nicht weiter testen kann.
Zitat von: mitsimatsimoto am 09. Januar 2013, 09:57:01
also angeblich wurde nichts an den flash dateien geändert, sondern nur das backup einer ähnlichen serial geflasht.
Das war die Aussagem ich weiß. Hat aber eben nicht funktioniert, daher habe ich das mit Ändern der Daten probiert.
Ja, ich habe ALLE Dumps immer vorher gepatcht.
Zitat von: mitsimatsimoto am 09. Januar 2013, 09:57:01
dennoch ist es für mich ein zweischneidiges schwert, denn eigentlich sollte der syscon mit dem cell (und rsx?) sozusagen verheiratet sein. warum muss sonst der barcode serial in sony's werkstätten immer vorher gescannt werden, bevor da was gemacht werden kann?
Weil jede Konsole unter irgendeiner ID im System geführt werden muss, damit die verschiedene Schritte einer Konsole zuordnen können. Die Serial bietet sich da geradezu an. Du kannst da auch eine PS3 mit nicht passender Serial einschicken, ist egal. Aber eine PS3 komplett ohne geht nicht, da weigern die sich.
Ich glaube ehrlich gesagt nicht wirklich dran, da das wie gesagt echt zu stumpf wär, zumal die Daten ja sogar im Rohformat (!) im Flash stehen.
@Takeshi:
Das mit der Seriennummern hätte ich mir anlesen können, richtig!
Mir ist es auch eher darum gegangen, herauszufinden warum ein Dump von Konsole A bei Konsole B läuft. Irgendwo muss es ja paralellen geben, die wollte ich suchen. Dafür bieten sich Seriennummern etc. geradezu an. Das man den Dump nicht durch umschreiben der cISD überall zum laufen bekommt war mir schon klar, so einfach ist es dann doch nicht. Ich wollte eher darauf hinaus, das man damit zumindest Teile irgendwelcher Seriennummern herausfinden kann, auch wenn die Konsole nicht mehr vorhanden ist. Damit können wir ggf. noch mehr Dumps für Experimente einsetzen ;)
Was du mit deinen beiden v7-Dumps versuchen könntest:
Flashe den getauschten/falschen Dump, aber ohne die Serial oder eine andere Nummer per Hexeditor zu ändern. Lediglich den Downgrade-Patch ausführen, sonst wurde im anderen Forum ja auch nichts verändert. Das wäre dann quasi eine 1:1 Nachstellung der Gegebenheiten aus dem anderen Forum.
OK, hast du ja bereits erfolglos versucht. Dennoch werte ich es als teilerfolg, dass die Konsole zumindest anbleibt und kein YLOD aufzeigt. Für mich ein Hinweis, dass zumindest etwas anderst läuft als "üblich"...
Vielleicht gibt es ja grundsätzlich nur eine bestimmte (geringe) Anzahl verschiedene "Verschlüsselungscodes" auf den Konsolen einer Baureihe. So dass jede 10. / 50. oder jede 100. Konsole mit dem gleichen Schlüssel versehen wurde. Jetzt könnte man einfach Blind viele Dumps durchflashen und auf einen Glückstreffer hoffen. Vielleicht kann man aber anhand anderer Daten eingrenzen, welche Dumps untereinander kompatibel sind. Wenn das stimmt, das eine Konsole mit einem fremden Dump wieder lauffähig wurde, muss es meiner Meinung nach ein System dahinter geben.
Vielleicht sind wir mit den Serials auch auf dem Holzweg und es gibt andere, nicht gleich ersichtliche paralellen z. B. im Syscon?
Wie sieht es denn nun mit dem Link aus?
Hat sich erledigt;-)
die sache ist doch die, der user meinte, dass usb und so weiter nach dem flashen des fremden backups ging und er den fsm starten konnte soviel ich rausgelesen hab. aber am ende ist es doch nur ein dummes märchen
So, ich habe mir den anderen Thread nochmals durchgelesen. Was mir noch aufgefallen ist (hatte ich beim letzten durchlesen als nicht so wichtig erachtet): Der defekte und die "Spenderkonsole" hatten nicht nur eine ähnliche Seriennummer sondern auch den gleichen Datecode. Liegt beim Datecode vielleicht das Geheimnis bzw. könnte dieser auch relevant für die Verschlüsselung des Flashspeichers sein :???
Zitat von: DoggyDog am 09. Januar 2013, 12:48:37
Mir ist es auch eher darum gegangen, herauszufinden warum ein Dump von Konsole A bei Konsole B läuft.
Die Frage ist für mich weniger "warum", sondern eher "ob".
WENN da irgendwas geht, dann lässt sich das ganz bestimmt über die Serials eingrenzen, denn so gut wie alles lässt sich darüber gruppieren, weil alle Serials und sicher auch die Verschlüsselungscodes fortlaufend sind.
Was ich bisher immer dachte, ist ja, dass die Prozessor-ID im Flash und Syscon steht und es dann keine einzige Konsole gibt, in der ein fremder Dump passt. Allerdings gibt es bei den Laufwerksplatinen ja auch welche, mit denen das Update geht, aber nichts von Festplatte startet. Hatte sowas noch nie, aber schon mehrmals gelesen.
Zitat von: DoggyDog am 09. Januar 2013, 18:24:44
Liegt beim Datecode vielleicht das Geheimnis bzw. könnte dieser auch relevant für die Verschlüsselung des Flashspeichers sein :???
Ein Modell wird meistens nur mit einem bis drei Datecodes ausgeliefert, daher ist es unwahrscheinlich, dass das noch sonderlich eine Rolle spielt. Eher muss die Serial und damit die Produktion nah beieinander liegen, was einfach mit sich bringt, dass der Datecode gleich ist (aber in wenigen Fällen auch nicht). Bei mir waren die jedenfalls unterschiedlich, 9B und 9D.
Schick mir bitte mal den Link per PM, denn so kann ich schlecht entscheiden, ob es hier in der Topic stehen darf.
Zitat von: mitsimatsimoto am 09. Januar 2013, 17:16:08
die sache ist doch die, der user meinte, dass usb und so weiter nach dem flashen des fremden backups ging und er den fsm starten konnte soviel ich rausgelesen hab. aber am ende ist es doch nur ein dummes märchen
Genau das ist es.
Zitat von: fanavity am 08. Januar 2013, 21:24:40
03-27453027-6617195
Gibts ja nicht, ich hab einen Dump, der liegt nicht mal um 5 daneben! Hast du die Konsole zur Hand, oder nur den Dump? Denn ich hab nur den Dump, aber alle möglichen Daten zur Konsole. Das wäre der ultimative Test. Wenn es dann nicht geht, ist es Quäse.
Zitat von: Takeshi am 09. Januar 2013, 18:52:40
Gibts ja nicht, ich hab einen Dump, der liegt nicht mal um 5 daneben! Hast du die Konsole zur Hand, oder nur den Dump? Denn ich hab nur den Dump, aber alle möglichen Daten zur Konsole. Das wäre der ultimative Test. Wenn es dann nicht geht, ist es Quäse.
Das wäre ja wirklich DER Test. Besser geht es ja kaum
Dann kann ich mir das raussuchen meiner Backups ja erstmal sparen
Hoffentlich hat einer von beiden noch die zugehörige Konsole, sonst scheitert der ultimative Test daran :o :-X
Zitat von: Takeshi am 09. Januar 2013, 18:52:40
Zitat von: fanavity am 08. Januar 2013, 21:24:40
03-27453027-6617195
Gibts ja nicht, ich hab einen Dump, der liegt nicht mal um 5 daneben! Hast du die Konsole zur Hand, oder nur den Dump? Denn ich hab nur den Dump, aber alle möglichen Daten zur Konsole. Das wäre der ultimative Test. Wenn es dann nicht geht, ist es Quäse.
Tach,
also eins vorweg! Ich habe die Konsole noch, aber ob der Test starten kann oder nicht hängt ganz allein von dir ab Takeshi :)
Das ist die CECH-2004a welche ich morgen nachmittag an dich senden werden zwecks des erneuten reballs ;)! Dann könntest du, sofern du lust und Zeit hast gleich noch dein Backup bei Ihr testen!
Ja saubere Sache, dann hab ich auch gleich noch die Konsole bei mir. Noch mehr Motivation die Konsole wieder zum Laufen zu bekommen.
Ich hab die Konsole nicht mehr, deshalb fragte ich.
@KKA: Guck trotzdem mal, ob du ein Backup einer "03-...-66xxxxx-CECH-2004A" oder nahe dran hast, weil die Konsole gerade zerlegt hier liegt.
So ich habe einen minierfolg mit meiner fast toten CECH-L04
Habe folgende Konsolen hier:
CECH-L04
03-27438172-5194340
03-27438172-5190028
Die Konsole 03-27438172-5190028 ist die defekte. Auf diese habe ich nun das ungepatchte Backup der gefasht. Nun bleibt die Konsole auch ohne FlashFun Modus an, zeigt aber nach wie vor kein Bild! Aber die Konsole geht nichts mehr aus! Ich bin diesbezüglich echt ratlos!
Man könnte mal schauen, ob USB angesprochen wird. Evtl. kommt man ja in den FSM?
Er zeigt mir keine USB und oder HDD aktivität an! Genauso wie mit der Original FW. Habe so langsam die Vermutung das das Ding einfach im Arsch ist!?
Dann ist es entweder ein Mythos oder es gibt ein anderes Merkmal, welches die Kompatibilität der Dumps hergestellt hat. Das mit den "ähnlichen" Seriennummern können nwir wohl dann ad acta legen.
Naja, ich weiß ja nicht ob die Konsole überhaupt richtig funzt?!.. Vielleicht liegt es ja nicht an der FW sondern an der Konsole?!
Ne von den ersten Slims habe ich kaum was
Nur ein Backup
CECH-2004B 03-xx...-56xx...
Am meisten CECHL04 und dann noch J, K, M, 2104 und 2504
Zitat von: fanavity am 09. Januar 2013, 20:18:39
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 (http://www.ps3-tools.de/thread.php?threadid=51991&threadview=0&hilight=&hilightuser=0&page=1)
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.
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.
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 :D
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.
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 :???
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.
@Takeshi: Mit einem "ganz falschen" Dump hatte ich seither einen YLOD bekommen.
Ja, das war auch bisher so meine Info, aber ich hatte mit einem falschen Dump noch nie einen YLOD.
Wenn du ein FAT-Backup auf eine Slim schiebst, gibt es sicher ein YLOD - selbst getestet 8)
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.
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 :P
[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
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.
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 :'(
Was meint Ihr zu folgenden Aussagen:
Zitat
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?
Zitatich 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?
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 :D
Schon das gebrochene Deutsch lässt einen nur den Kopf schütteln und den Tab schließen :D
Der ultimative Test mit dem Dump einer PS3, die nur um 3 in der Serial daneben liegt, hat sich erledigt, weil der Dump aus genau dieser Konsole ist. DoggyDog hat sich bei der Angabe der Serial vertippt.
Ich verstehe nur Bahnhof :???
Boa fuck, ich hau euch ständig durcheinander. Dein Glück, deshalb hat deine Konsole auch eine reballte GPU ;D
Hab eine Konsole von fanavity hier, die defekt ist. Ich hatte einen Dump gefunden, der nur um 3 daneben liegt, weshalb es der ultimative Test gewesen wäre, den Dump in der Konsole zu testen. Nur hat fanavity sich vertippt, der Dump ist von seiner Konsole, weshalb der natürlich laufen wird.
Zitat von: Takeshi am 16. Januar 2013, 18:20:06
...... Nur hat fanavity sich vertippt, der Dump ist von seiner Konsole, weshalb der natürlich laufen wird.
Das tut mir leid! :/ Sorry dafür!
Ist ja nicht schlimm, dadurch hätten wir jetzt auch keinen "passenden" Dump gehabt.
Das ist eh Blödsinn, die haben sich da gut verarschen lassen. Es hat bei keinem funktioniert und die ganze konsolenspizifischen Dateien sind bei dem defekten Dump und dem angeblich funktionierenden unterschiedlich (da unterschiedlich verschlüsselt), deshalb kann das kaum sein.