Analisi Dump... Anomalie riscontrate

[Vale]

SAlve ragazzi, allora ho fatto ben 4 dump della mia NOR su slim 2004B;
sto seguendo la meravigliosa guida di Zeruel per l'analisi e la validazione manuale dei dump.

Tutto bene fino al passo degli "Altri Byte da Verificare":
Come da guida dovrei trovare questi valori:

Altri byte da verificare:
Controllate anche i seguenti byte, come sempre devono corrispondere a questa lista (offset - nome - byte corretti):
800 - asecure_loader - 00 00 00 01 00 00 00 01 00 00 00 00 00 02 E8 00
2F000 - eEID - 00 00 00 06 00 00 1D D0 00 00 00 00 00 00 00 00
3F000 - cISD - 00 00 00 03 00 00 02 70 00 00 00 00 00 00 00 00
3F800 - cCSD - 00 00 00 01 00 00 08 00 00 00 00 00 00 00 00 00
EC0000 - cvtrm - 00 00 00 00 FF FD FF FF FF FF FF FF FF FF FF FF (oppure 53 43 45 49 FF FF FF FF FF FF FF FF FF FF FF FF)
F20000 - CELL_EXTNOR_AREA - 43 45 4C 4C 5F 45 58 54 4E 4F 52 5F 41 52 45 41


Invece io non mi trovo; infatti i miei valori sono:

800 - 00 00 00 01 00 00 00 01 00 00 00 00 00 02 E8 00 - OK COINCIDE
2F000 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - come vedete NON COINCIDE
3F000 - FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF - anche questo NON COINCIDE
3F800 - FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF - anche questo NON COINCIDE
EC0000 - 53 43 45 49 FF FF FF FF FF FF FF FF FF FF FF FF - OK COINCIDE
F20000 - 43 45 4C 4C 5F 45 58 54 4E 4F 52 5F 41 52 45 41 - OK COINCIDE.

Che devo fare????

[zeruel85]

A parte che EC0000 è giusto.

Se estrai la NOR con Flowrebuilder i file sono corretti? Soprattutto eEID e cISD.

Inviato dal mio GT-I8150 utilizzando Tapatalk

[Vale]

A parte che EC0000 è giusto.

Se estrai la NOR con Flowrebuilder i file sono corretti? Soprattutto eEID e cISD.

Inviato dal mio GT-I8150 utilizzando Tapatalk

grazie Zeruel per avermi prontamente risposto:
scusami ma non ho capito la domanda...

ho estratto la NOR con Flowrebuilder e mi ha creato la cartella Dump1.ext e all'interno ci sono i file (che nella guida dici di controllare)

Li ho controllati ed è tutto ok.

Inoltre, ho proseguito con la guida e fatto gli altri controlli e coincide tutto (tranne che per qualche stringa nei Ros0 e Ros1)

[TheLinuxMafia]

Scarica flow rebuilder ed utilizzarlo per estrarre la nor e controlla se le dimensioni dei file sono corrette.
Ops abbiamo postato insieme !

La console era stata già modificata ? Considera che quei valori vengono sovrascritti dalle patch.

Inviato dal mio HTC One utilizzando Tapatalk

[Vale]

e quali dovrebbe essere le dimensioni corrette??

ho fatto 4 dump e sono tutti e 4 grandi 16.384 KB

Aggiungo, se può essere utile, che sto partendo da OFW 4.55

Anche il controllo su OFFSET 0x2F077 sul quale dovrei avere 09, a me risulta 00 (l'intera riga relativa a 2F000 è tutta 00 00 .. .. 00).

Che è successo???

[Vale]

Scarica flow rebuilder ed utilizzarlo per estrarre la nor e controlla se le dimensioni dei file sono corrette.
Ops abbiamo postato insieme !

La console era stata già modificata ? Considera che quei valori vengono sovrascritti dalle patch.

Inviato dal mio HTC One utilizzando Tapatalk

No la console non è stata mai modificata...

si, ' ho già estratto la NOR con FlowRebuilder; le dimnesioni 16.384 KB sono corrette???

Anche il controllo su OFFSET 0x2F077 sul quale dovrei avere 09, a me risulta 00 (l'intera riga relativa a 2F000 è tutta 00 00 .. .. 00).

Help Me

nella saldatura del teensy sulla motherboard ho usatome come punto di massa GND un punto diverso da quello vicino a VCC

quello sopra al punto RY/BY:

[Vale]

Non sono in condizioni di poter flshare CFW vero??

Aggiungo, se può essere di ulteriore analisi, che la NOR è una Spansion.

[Vale]

Aggiornamento:
ho perfezionato alcune saldature.
Dump effettuato: TUTTO OK, tranne per alcuni valori in Ros0 e Ros1.

Può andare così????

[The Pusher]

Scusa, te lo dico per esperienza; non farti seghe mentali (o almeno non troppe). Utilizza Nor Inspector e vedi se i check sono tutti su OK
I ros a me al 99% delle volte li da cannati (con il tool di swizzy e rogero).

[Vale]

Scusa, te lo dico per esperienza; non farti seghe mentali (o almeno non troppe). Utilizza Nor Inspector e vedi se i check sono tutti su OK
I ros a me al 99% delle volte li da cannati (con il tool di swizzy e rogero).

Si grazie Pusher, ho flashato già la nor... ora sono fermo al punto di installar eil CFw: non è che potresti rispondermi all'altro thread: [url]http://www.consoleopen.com/forum/hack-ps3-ps3-slim/18081-appunti-dubbi-sulla-guida-di-tommino81-dw-su-nor.html[/url] .... grazie.

Sto con la ps3 in mano....

[Vale]

Dw completato.... grazie a tutti ragazzi.

[Razorbacktrack]

La mia risposta la trovi qui visto che hai aperto 12 thread diversi : [url]http://www.consoleopen.com/forum/showthread.php?p=232896[/url]

Inviato dal mio HTC One S utilizzando Tapatalk

[zeruel85]

Piccolo appunto: se avesse flashato partendo col dump iniziale, avrebbe brickato. Giusto perché poi la gente non venga a piangere nel forum...

Ros e rvk OK, non sono (quasi) mai un problema. Ma i dati univoci, se sono cannati, diventa un soprammobile. Nel suo caso eEID e cISD erano cannati.

Inviato dal mio GT-I8150 utilizzando Tapatalk

[The Pusher]

Zeru, scusa , vorrei fare una riflessione costruttiva (alla quale sono SICURO sarai contento di partecipare); i downgrade come ben sai ho cominciato ad offrirli anche io ai clienti da qualche tempo a questa parte; su 74 dump 72 hanno i ROS segnalati come cannati; NORinspector da comunque tutto OK.
Il tuo discorso e' giustissimo, ma penso che i dubbi della gente (che erano anche i miei all'inizio) a riguardo dei ROS riscontrati come non validi, siano legittimi (non nei tuoi confronti o del tuo tutorial PERFETTO sulla validazione dei dump), ma sulla veridicita' dei dati all'interno di un dump che identifica i ROS

[zeruel85]

La questione è semplice: fottetevene dei Ros e dei revokation. Tanto vanno patchati. Sono dati contrassegnati "per firmware type", cioè, variano al variare del firmware installato. I vari tool automatizzati scazzano semplicemente perchè è arduo hash-checkare tutti i Ros e rvk, a seconda della tipologia di console e del firmware (anzi, DEI firmware presenti, in quanto come sappiamo la NOR/NANDs tengono in memoria gli ultimi due update effettuati, così anche la Xbox 360 che ha due CF e due CG se non vado errato).

Non è questione di tutorial perfetto o perfettibile, è chiaro che se butti il dump all'interno del tool automatizzato e i magic headers sono cannati, tiri giù i santi dal paradiso. Ma ti faccio un esempio, aprendo un dump con HxD. Guardo il magic headers, e noto che il famigerato FACEOFF DEADBEEF è presente, MA, è traslato di un offset a sinistra. Che significa? Posso dare una interpretazione logica e razionale ad una cosa del genere? Certo, ma solo se lo guardo in faccia, e cioè uso un Hex Editor per vedere come è "costruito" il mio dump che ho effettuato. Se è traslato, significa che ho cannato un collegamento dell'Address da 00 a 07, quindi vado nella mia installazione e ricontrollo solamente 8 connessioni, anziché 50.

Altro esempio: noto che il magic headers non è FACEOFF DEADBEEF, ma ha un byte in meno, ad esempio EABD9FE DDACBDEE, significa che ho invertito una Data line, e vado a controllare i collegamenti Data, solo e soltanto quelli.

Chiaro che se lavori con un programmatore esterno te ne fotti di questi ragionamenti, però in ogni caso, se hai imperfezioni nei dump (e non mi riferisco ai Ros e rvk!), puoi comunque risalire alla causa dello "scazzo del dump".

Tutto questo per dirti, come ti avevo anche detto al telefono qualche settimana fa, che l'hash check sui Ros e sui revokation te ne puoi bellamente fregare. Però non te ne puoi disinteressare se ciò che il dump ti rileva come cannato, riguarda dati UNIVOCI (per-console data) della tua console, cioè dati criptati con chiavi che non conosci e non conoscerai probabilmente mai. Per farti un esempio che sicuramente capirai al volo: keyvault e fcrt. Se li canni al dump iniziale, poi che fai?

Tutto qui.

Per quanto riguarda il mio tutorial. Ciò che mi premeva quando l'ho stilato (e comunque non esistevano ancora tool affidabili al 100% all'epoca), era far ragionare la gente. Capisco altresì che si perda molto tempo a validare un dump a mano, e non ho minimamente la pretesa che la mia guida sia vista e letta come un dogma, anzi, ben vengano i tool automatizzati che ti semplificano l'esistenza. Ma molti utenti, non so se l'hai notato, usano questi tool e a volte capitano molti che aprono un thread per falsi positivi, cioè per dump ritenuti BAD dai software, ma che in realtà di BAD non hanno proprio nulla. In conclusione: ho cercato di stendere il tutorial in modo tale che la gente cominciasse a toccare con mano com'è costruito un dump, "smontarlo" con l'Hex Editor e guardarci dentro, per prendere coscienza su ciò che stanno facendo e invogliarli a non impigrirsi con nozioni preconfezionate.

Vi lascio con una tabella in cui potete rendervi conto della suddivisione degli offset all'interno di un dump NOR o NAND unita che sia. Penso sia una dimostrazione alquanto lampante di come sia IMPOSSIBILE flashare un dump di una console in un'altra console (seppur della stessa revisione/SKU o quel che l'è), come in molti tentavano di fare mesi fa, o che comunque continuavano a chiedermi se fosse possibile farlo o no.

[url]http://www.psdevwiki.com/ps3/Flash[/url]