ich weiss ja nicht , aber ne Fat sollte man sowieso aufmachen , reinigen und WLP tauschen
und solage es keine möglichkeit gibt bei NAND Konsolen ein backup zu machen , benutze ich bei diesen die alte Methode mit Hardwareflasher ,obwohl das ja lange dauert
klar es hat bei dir w mal funktioniert , kann aber auch anders laufen und dann isses ohne Backup schwierig bis unmöglich noch was zu retten
[release] PS3Xploit by bguerville, esc0rtd3w und W
-
- [OFW]
- Fatman
-
-
Das stimmt natürlich.
Aber wenn man keine andere Möglichkeit hat. -
denke ich wird das ziemlich lange dauern,
Das Problem ist da einfach nur die Größe des Dumps. So wie ich das verstanden hab wird der NOR/NAND halt erst ausgelesen - also in den RAM geladen - und dann als ganzes erst auf USB gespeichert. Das ist mit dem 16 mb NOR Dump kein Problem. Der NAND Dump hat jedoch 256 mb und da reicht einfach der Arbeitsspeicher nicht um es so zu machen. Da müssen die sich noch etwas anderes überlegen.
-
Okay danke erst einmal für die Infos.Das heißt dann Risiko oder jemand finden der meine PS3 NAND downgraded mit entsprechenden Hardware Flasher.Habe schon mal geschaut ob das jemand bei mir in der Nähe anbietet,aber nichts wirklich gefunden.
Falls jemand in der Nähe Ruhrgebiet Bochum weiß kann mir gerne eine private Nachricht schicken.
Wäre natürlich vom Vorteil wenn ich die Konsole persönlich vorbeibringen und dann wieder abholen könnte,deswegen die Frage. -
Musst selber entscheiden ob du ein risiko eingehen willst.
Wie gesagt es ist eigentlich bei jeder Modifikation der Soft/Hardware ein Brick risiko vorhanden.
-
wenn man mit Hardwareflasher Arbeitet und den Dump gründlich prüft ist das risiko wohl um vieles geringer das was brickt wie ohne Backup
wie ich schon geschrieben habe ich würde das risiko nicht eingehen wenn ich kein Backup von der Konsole habekomme nicht aus dem Ruhrgebiet , hab aber nen HW flasher für NAND`S
-
So viel ich weiß kann man mit dem Hardware Flasher auch einen Brick wieder reparieren .Funktioniert das nur wenn man einen Backup vom NAND/NOR hat oder auch ohne ? Kann mir gut vorstellen das nicht jeder ein Backup bzw. der Backup vielleicht auch nicht astrein ist da er vorher nicht anständig mit HEX Editor geprüft wurde.
-
funktioniert halt nur mit Backup , deshalb rate ich bei NAND Konsolen ja auch von dieser Methode ab da man noch kein Backup damit machen kann , wenn man ne Konsole jailbreakt sollte man schon ein Backup davon haben,egal ob NOR oder NAND da sonst bei nem Brick die Konsole unbrauchbar werden kann
-
Soweit ich weiß gibt es für beides etwas, aber der Code ist Schrott (auch in dem jetzigen NOR-Dumper).
Man kann mit einer NAND-PS3 doch auch noch ein Stück warten...
-
Der NAND Dump hat jedoch 256 mb und da reicht einfach der Arbeitsspeicher nicht um es so zu machen. Da müssen die sich noch etwas anderes überlegen.
Müsste doch möglich sein nur die hälfte zu lesen und auf usb zu speichern.
Wenn man den exploit dann nochmal startet ne abfrage machen, ob schon der erste teil auf der sd ist und dann die andere häfte auslesen.klingt zu einfach, hätten die bestimmt shcon gemacht, wenn es gehen würde ...
-
Wie gesagt,... Code = Schrott, sonst müsste man nicht den kompletten NAND in den RAM 'cachen'...
-
Quatsch... RAM verarbeitet (schreibt/liest) Daten schneller und effizienter, außerdem ist es leichter durch die Sicherheitsmechanismen zu kommen. Beurteile nichts, das du nicht selbst geschrieben hast...
Nicht umsonst setzen große Konzerne Ramdisks ein um große Datenmengen zu verarbeiten (Big Data). Könnte dir jetzt genug Beispiele nennen...
So stolz du auch auf den FMCB Sourcecode sein kannst (zurecht), umso unsinniger sind solche Aussagen -
Ach... Weil RAM also schneller ist, wird alles darein gecacht, statt nur zum Beispiel einen 4/8KB oder auch mehrere MB Cache zu nutzen und während des Dumpens auf USB zu schreiben?
Der Cache könnte auch 128MB groß sein und er würde wahrscheinlich NIE voll werden (wenn man währenddessen den Anfang des Buffers auf USB schreibt), alleine schon da der NAND langsamer gelesen wird als Flash-Zellen, aber selbst wenn es nicht so wäre braucht USB nicht doppelt so viel Zeit... (was es müsste bei 128MB-Cache).
Es ist leichter durch die Sicherheitsmechanismen zu kommen? Die Aussage/Behauptung solltest du untermauern, denn um die Sicherheitsmechanismen zu umgehen braucht man nicht viel RAM...
Die Konsole würde sonst nicht laufen... um es kurz zu sagen.
Sorry, aber deine Argumentation hinkt einfach aus programmier-technischer Sicht (was nichts mit FMCB zu tun hat) und es gibt mittlerweile genug erfahrene Nutzer hier im Forum, die dir dass bestätigen können...
...und beurteilen kann ich was und wie ich (es) möchte... Ob ich damit richtig liege, zeigen Fakten und die Zukunft.
-
Bevor wir diskutieren, wir wissen beide nicht wie der Exploit im Detail ausschaut und im Detail funktioniert. Eventuell haben wir nur begrenzte Zeit um auf den Flash (NOR/NAND) zuzugreifen? Eventuell lässt sich nur der vollständige Dump als Datei schreiben? Wir wissen es schlicht nicht. Aber einen Code, der der Community hilft als Scheiße/Schrott zu bezeichnen finde ich eben persönlich unter aller Sau. Meiner Meinung nach ist kein Code Schrott, jeder Code könnte eventuell besser sein aber Schrott ist keiner, egal ob er nur ne simple Gleichung löst oder die Firewall der CIA aushebelt
In diesem Sinne: Fröhliches Fest
-
Ich gebe dir Recht beim Zugriff und der Zeit, was nicht sooo ungewöhnlich ist (PS3MCA hat theoretisch ein ähnliches Problem), aber dass liegt dann trotzdem am nicht vollständig ausgereiften Code.
Am Schreibzugriff auf USB, oder zumindest interne HDD sollte es nicht liegen...
Ich bezeichne nicht den Exploit, sondern den Dump-Code und speziell EINEN Teil davon als Schrott und da würden mir die Entwickler selbst Recht geben, da dass teilweise nur Protocode/Prototyping ist und der Code somit eher ein 'Proof of Concept', statt vollständig sind...
Das ist NICHT als Beleidigung gemeint und ich denke jeder Entwickler, oder Programmierer sieht genau, worauf ich es beziehe (nicht gegen dich bezogen).
Ich bin eher einer, der die Szene anspornt! Ich habe schon Threads/Posts geschrieben (weil ich selbst die anspornen wollte, die eben nicht programmieren/entwickeln können), in denen ich sage, dass selbst eine Übersetzung einer Sprachdatei ein Beitrag zur Szene ist und Manche haben dadurch schon Foren gegründet!
Übrigens heißt das Alles, dass der Programmcode im Endeffekt relativ schnell auch dafür angepasst werden kann, solange für eine NAND-Konsole nicht irgendwo andere Dinge benötigt werden (kann ja sein, dass Kernel-Zugriff oder manche SYSCALLs [z.B. in der Payload] an manchen stellen noch fehlen [wie gesagt, 'Prototyping'])!!!
Also dauert das bestimmt keinen Monat (solange nicht etwas speziell für die Konsolen fehlt).
Dir auch noch ein schönes Fest.
-
Dann kam das oben falsch rüber, sorry
Hat natürlich auch viel an den traurigen gegebenheiten zu tun warum es so plötzlich released wurde, wollten ja eigentlich erst einige Wochen warten bevor released wird aber dann gibts wieder so Mongos die sich für 5 Minuten geil fühlen wollen und somit ein Haufen arbeit einfach in den Dreck ziehen
-
bguerville wurde am 8.12. auf psx-place wegen dem NAND Dumper angesprochen.
Zitat von nCadeRegalAre you guys still working on the nand dumper? @bguerville @habib
Die Antwort von bguerville dazu:Zitat von bguervilleNot exactly...
The size of nand makes it a problem.
Each flash memory read is 2Mb max (limited by system) so, for instance,
the nor dumper repeats the read operation 8 times with different
parameters to get 16Mb in total. Originally I was hoping to use a
sys_storage_read loop gadget, unfortunately there are only 4 available
in system code, 1 applicable to the situation but unusable due to one
tiny param hard-coded in it so using a loop is not feasible at this
stage.That would mean repeating the read operation 128 times to dump the full
nand to memory. As one read uses 3 gadgets (consider a gadget as a
portion of system code), that means repeating 3 gadgets in ROP 128 times
which is a pita.
Furthermore it gets even more annoying because of the available RAM.
Obviously it's impossible to dump the whole nand to RAM because there is
less than 256 Mb available to us.. So that would mean having to dump
128Mb then save to file then do the next 128Mb & append to file.Finally there is one last detail.
We have noticed that on NOR, reads bigger than 1Mb can fail on occasion,
it explains that some dumps are full of of 00s as some users reported. I
have therefore changed the read size to 1Mb, for 16 operations on NOR,
that update will be released soon...
If the issue were the same on nand we would be talking about repeating 3
gadgets 256 times to read the entire nand without getting read fails.So obviously you must understand why this has not been done yet. It's possible but totally unpractical to do in ROP.
Depending on our research & findings, a full nand dumper will
eventually be provided, at a later stage, in one form or another.There is an idps dumper available on nand & emmc so in practice the
dumpers are not really essential. The flash writer cannot brick fully
your console & any partial brick can be recovered from by patching
the corrupted ros regions with 3Mb from ofw CoreOS.So wie ich das verstehe würde ein NAND Dumper schon gehen aber es ist in diesem Stadium noch nichts für die Masse.
Der NOR wurde anfangs mit 8 x 2MB ausgelesen und dann auf USB geschrieben. Die 2MB sind vom System limitiert und es gab öfter Probleme, deshalb hat man dann 16 x 1MB gelesen/geschrieben.
Das ist bei 16MB kein Problem, bei 256MB sieht es etwas anders aus. Man hat keine 256MB RAM zur verfügung d.h. man müsste den NAND in 2 Teilen auf USB schrieben und dann (manuel?) zusammenfügen. Die beiden Teile müssten dann ja auch (2x 128x1MB) Fehlerfrei sein um ein brauchbaren NAND Dump zu erhalten.Quelle: http://www.psx-place.com/threa….15500/page-72#post-94614
-
Die Mehrzahl der Konsolen hat ja sowieso einen Nor Speicher.
Warum ist Sony damals eigentlich umgestiegen ? -
Sind billiger, schlicht und ergreifend.
-
@Passy: Da gibt es natürlich VERSCHIEDENE GRÜNDE, nicht nur dass von dir angesprochene!
@'MixeryM@xe': Danke für das Zitat! Ja, dass hast du im Allgemeinen richtig zusammengefasst.Aber um es nochmal zu sagen... Der Code ist teilweise 'Protocode' (also nur Dummy-Funktionen) und der Exploit, oder der Programmcode danach nur 'Proof of Concept/PoC'.
Man kann mit etwas eigenem Programmcode (statt auf die APIs zuzugreifen) einfach z.B. einen 4MB-Cache im RAM haben, der größer als 1-2MB ist! Es ist alles einfach noch 'PoC', der Exploit ist vorhanden und erlaubt dass Starten von eigenem Code, aber die Payloads, Zugriffs-Brücken (zu den Syscalls/Systemaufrufen) und der NOR, sowie NAND-Code sind unausfgereift und das wird mit dem Zitat bestätigt!
Im Endeffekt kommt es wieder auf den noch unausgereiften Programm-Code zurück, der warscheinlich erst in etwa einem viertel bis halben Jahr RICHTIG AUSGEREIFT ist.
Edit: Wenn also jemand seine PS3 modden möchte, sollten Diejenigen am Besten 2-3 Monate warten bis es die ersten relativ guten Programme und verbesserten Programm-Code gibt...
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!