Duda importante verificando Dumps

Es porque tienes el dump con los bytes intercambiados... a esto se le suele llamar "byte swapped"
Si lo miras en el hexeditor... cada byte son dos "digitos", y se hace el swap cada 2 bytes si no recuerdo mal... por ejemplo, si haces swap a esta cadena:
1122334455667788
Te quedaria asi:
2211443366558877

Esos programas te hacen el byteswap (el dumpchecker es compatible con las dos formas), pero puedes usar este programita que encontre hace unos dias
https://www.sendspace.com/file/hnvasd

En linea de comandos... ejecutas el programa y le dices la ruta del dump.... y te lo modifica

-------------------------
Lo de las ROS0 y ROS1... no te preocupes... debe ser porque estas usando una version del dumpchecker antigua
Cada una de las ROS contiene datos de los firmwares que se han instalado (el actual, y el anterior)

En las ROS se guardan datos que son del firmware... no tienen demasiada importancia porque son genericos... es decir que si coges la ROS0 de otro dump hecho en otra PS3... lo podrias usar en tu dump (substituyendo una de tus ROS)
Otro ejemplo que demuestra lo poco importante que son estos datos... es que los parches que se aplican a un dump para hacer el downgrade... lo que hacen es escribir las ROS completamente (es como si quedasen corruptas... te las has cepillado)... y una vez que has hecho eso enciendes la PS3 y te deja instalar el firmware 3.55

debes usar tambien el dumpstatistics, ese te analiza de otra manera el dump y si te da bien, el error de ros del dumpchecker no es relevante.
si el statistics te da un error el dump esta mal sacado.

en menos de 10 segundos tienes el dump validado con esos dos programas.

Gracias por vuestros consejos. Pasando el Dumpstatistic me sale 00's: 15,42% (en rojo); FF's: 10.47% y Other: 0.29% (ambos en verde). El programa dice que no hay errores así que las doy por buenas. No lo dije antes pero estas dumps las saco ahora por el REBUG Tools, así que al obtenerlas vía software la probabilidad de que sean "malas" supongo que es casi nula a no ser que tenga fastidiad físicamente la memoría USB donde se escribe el Dump....

Otra pregunta, que igual es una chorrada por desconocimiento mío, pero estos archivos .NORBIN que tengo... ¿se flashearían directamente así para un hipotética resutauración de mi PS3 o debería aplicarles antes el "Byte Swap"...

PLIS-PLAS escribió:debes usar tambien el dumpstatistics, ese te analiza de otra manera el dump y si te da bien, el error de ros del dumpchecker no es relevante.
si el statistics te da un error el dump esta mal sacado.

en menos de 10 segundos tienes el dump validado con esos dos programas.

eso no existe no inventarse las cosas , te puedo dar mas de 100 dump que están bien con esas tool y no lo están , las consolas llevan datos únicos por consola y no hay ninguna app que lo sepa ni lo habrá , esos datos son los que joden la consola los otros no , un dump con los 4 datos vitales en sus posiciones y el resto lleno de 000 vacio es un dump valido para recuperar una consola , llevo haciéndolo muchos años sobre todo en nand por tema de algoritmo y a ser dos memorias independenientes

Pues yo estoy muy seguro de lo que digo y tambien llevo muchos años en esto y probe de todo, en miles de consolas.
Antes de que esas tools se actualizaran y se corrigieran no decia lo mismo, ahora son confiables si se usan bien.

Pues yo te puedo asegurar que has echo pocas asin sin cargarte alguna , yo llevo mucho mas que tu y muchos juntos y jamas me he cargado una consola y mira que sacado dump malos hasta soldando que es como yo siempre lo hago , con teensy , pero lo poco que use el e3 mas de lo mismo y es el que mas fallaba ,. No hace mucho uno de aqui que pedia revisar dump y que esas tool lo daban por bueno estaba mal le faltaba un dato vital y eso no lo save ninguna tool y es un fallo que suele dar muy comun el e3 por culpa del clip y una patilla con falso contacto , por mucho que quitaba y ponia clip le salia muchos iguales pero mal y otros desiguales pero esas tool los daban buenos al final ladrillo. Si se pasa por aqui podra coroborarlo .

Las tool buscan fallos de lineas de datos yyyy que no sigan una regla y cabeceras de otros datos que no son esenciales en posiciones , el problema de muchos dump malos que dan por buenos es la repeticion de cruzado de datos y repititivos.

@LUCKYMAS si no es mucha molestia los vitales como se miran exactamente, supongo que con hxd, hay algun post?

gracias

Pues las que hice de esa manera (con las tools corregidas y actualizadas) ninguna falló.
Como uso e3 éste sí me fallo y arruinó alguna nor por fallo de hardware,aún soldado, hasta te lo he comentado por privado.

He chequeado y corregido manualmente miles de dumps corruptos antes que existieran las viejas tools que conocimos y la verdad es que me alegro que hayan sacado versiones funcionales para hacer el trabajo más simple.

Puedo asegurar empíricamente y con total certeza que con PS3DumpChecker 4.88 y Dumpstatistic fixed(ambos actualizados) los vitales estan chequeados y se asegura la integridad del dump.

Con esto no sugiero que no se revise manualmente con hexa , que toma 5 minutos más, sino que quiero dejar en claro que puedo comprobar que con los dos "ok" de esas tools se obtiene un dump correcto y si hay un error se indica de inmediato inequívocamente.

Lo que le pasa a los novatos es que "CREEN" que ese error que no entienden no les va a afectar para nada y terminan en perma-brick. Por supuesto que hay que saber QUÉ y POR QUÉ se está haciendo por más tools que haya.

Y si es la nor que falla se puede usar la de otra consola y escribir la nor (previamente dumpeada) de la original.

No hay que ver fantasmas donde ya no los hay, todo avanza y se mejora y si es para mejor, también es de machos saber reconocerlo.

Yo he corrido mas que tu en ese aspecto y revisado mas dump de personas quee se han cargado sus ps3 por usar esas tool que los dan buenos y no lo son ya te digo que muchos usuaroos son de aqui y muchos reicidentes hasta han cambiado su metodo facil del clip al cargarse ya dos o mas consolas y se han ido al metodo mas seguro que el clip , soldando , y aun asin soldando suelen salir mal si cambias cables en point por confusion o incluso por usar flux sale mal aunque no te lo creas , es asi , y ami me ha salido de todo incluso tener que flashear con la consola en stamby por no poder flashearla en marcha por que se bloque la nor, que por lo que he leido por aqui hos a passdo a muchos casos asin y han desoldado y soldado mil veces con los mismos resultados y esta todo bien , pero cada consola es un mundo y si la conoces sabes como sacaela .
Dump malos por una mota polvo con cambio de una letra o punto en vital , dump con vitales repititivos y faltando esenciales , dump desiguales cada uno soldando por usar flux , fallo al instalar cfw con error f14 en fat nor soldando por usar flux o tener trisate soldado teensy, luz verde de la muerte por tener trisate soldado o haber metido corrientes estaticas por hay y un largo etc. Todos esos fañlos si lo tetestas antes la salvas.
Pero si no sabeis como va esto y no teneis mucha idea y quereis usarlas podeis pero que sepais que seguran no son , para principiantes sin idea pues para 4 igual le sale rentable. Pero yo siempre aviso y confirmo lo que digo.

Si el problema esta en que las zonas que se llaman "los vitales" estan encriptadas... y cuando hay datos encriptados no se pueden comprobar de forma manual (ni automatica)

Por ejemplo, si tenemos esta cadena (que pertenece a una zona encriptada):
012345678ABCDEF012345678ABCDEF012345678ABCDEF012345678ABCDEF
Y al hacer el dump se copia mal un byte (el que he puesto en negrita como 00) y queda asi:
012345678ABCDEF012345678ABCDEF002345678ABCDEF012345678ABCDEF

Esa cadena con el fallo es imposible de saber si esta bien o mal... porque el 00 podria ser correcto
Si encriptas algo podrian aparecer esos 00... es algo normal porque dentro de una zona encriptada podria aparecer cualquier numero.... y todos podrian ser validos

Los programas que comprueban esto de forma automatica lo unico que comprueban es que la zona sea igual de larga que lo que deberia ser.... pero los datos dentro de ella no se pueden comprobar


-----------------
La unica forma de comprobarlo con fiabilidad 100% es desencriptarlo (usando keys)... si al desencriptarlo el programa te dice que se ha podido desencriptar correctamente... significa que etaba bien
Pero si ese area encriptada tiene un solo byte "mal"... entonces es imposible desencriptarlo... el programa te diria que hay algun problema... eso significa que estaba mal

Es la unica forma.... y ningun programa de los que se usan para verificar dumps hace esto... por eso hay que considerarlos solo "orientativos"
Pero como he dicho... las comprobaciones manuales tambien son orientativas

si correcto pero si apagas y desenchufas usb si soldas claro, vuelves a arrancar y sacar si varían es que hay algo mal soldado suelto o equivocado , otra comprobación que hago manual es en vitales que no haya mas de dos yy seguidos entre medias no al final excepto isd , incluso se me han dado casos en dos consolas que existen tres yyy pero son diferentes , y en el caso que existieran mas o linea de 16 bit completas ese dump esta mal eso es lo que hacen las tool , pero ya sabéis que este mundo de la electrónica cualquier fallo te la cargas incluso sin sacar dump

De forma manual se pueden comrpobar muchas cosas... el problema es que hay miles de cosas que se pueden comprobar de esa forma
Nadie comprueba todo de forma manual porque se tardarian muchisimas horas en hacerlo

He hecho una captura de pantalla para que se entienda mejor lo que estaba explicando de las zonas encriptadas
Es un dump de una NOR... y he cogido una zona al azar (en realidad no se lo que es)


La zona que tengo marcada en oscuro es justo el inicio de una zona encriptada (dentro de ella cualquier byte podria ser valido, es imposible de saber si esta bien o mal)
Digo que esta encriptada porque los bytes varian muchisimo... no siguen ningun patron... es como si fueran bytes "al azar"

Justo delante de la zona marcada... aparecen 0x00 repetido 8 veces... eso es un "padding" (una zona que no se usa, esta ahi para poder alinear la zona encriptada que viene despues)
Ese padding si se podria comprobar de forma manual

Justo delante del padding aparece una cadena corta de bytes al azar... eso podria ser un "hash" (una verificacion de seguridad de la zona encriptada)
Este hash (en el caso de que sea un hash) si se podria comprobar de forma manual... pero habria que usar un programa que lo compruebe... y esto no lo hace nadie

Y justo delante del hash hay una zona que parece una tabla... donde se guardan posiciones, o contadores (con valores, 0x01, 0x30, 0x40)
Eso tambien se podria comprobar de forma manual.... o de forma automatica en el caso de que coincida entre diferentes dumps

-----------
Tambien hay dumps que contienen datos "raros" y los programas no son capaces de identificarlos como validos
Porque son de consolas "raras"... por ejemplo si mandas una PS3 a reparar al servicio tecnico oficial de sony... ellos pueden reconstruir todo el software de la maquina (incluidos keys nuevos, y los vitales) por ejemplo si les mandas un modelo de fat te pueden poner el southbridge de otro modelo de fat distinto
O cualquier otra cosa que quieran modificar... usando componentes o partes del software que no eran de ese modelo de PS3
Asi que esa PS3 tendria algo "raro"... es como si fuera unica o una edicion especial.... y como lo mas probable es que nunca se haya publicado un dump de esa PS3 la gente que hace los programas no consideran que el dump es bueno
Aunque en realidad si es bueno... solo es que esa consola le han hecho algo "raro" de forma oficial... o pertenece a un grupo muy pequeño de consolas que se fabricaron usando partes de otros modelos