Formato PS3 Filesystem

Esto es una pregunta:
¿No se podria crear un grupo de trabajo compartiendo archivos de cualquier tipo para que trabajen mas pc`s aunque esa gente no supiera tanto como vosotros para distribuir el trabajo y avanzar mas en menos tiempo?
Digo archivos para desencriptar o analizar o lo que sea porque yo me presento voluntario ya que me siento un poco inutil mirando sin poder hacer nada

Bueno, aquí está el primer mega de un disco formateado "completo" (no "rapido") en la PS3. Primeras conclusiones:

1) La clave de encriptación es inalterable, única para cada disco (basada en DISK-ID?)

2) El sector 0x000200-0x0003FF parece ser un sector vacío, lleno de 0's antes de la encriptación. El disco recién formateado está lleno de sectores idénticos a este.

3) Los sectores con 0's que aparecen el otras imágenes son debidos a que el GAMEOS no ha escrito en ellos, y conservan los sectores inicializados a 0, tal como los entrega el fabricante del HD.

4) El sector 0x000800 empieza igual que el 0x000000, el sector 0x015000 empieza como el 0x011000


Hermes, pasalo por tu programilla "comparador" de sectores.

Sigo mirando.

Supongo que ya lo sabras, pero por si acaso. El arbol de directorios parece similar al de psp, cuando formateamos una memory stick nos crea este arbol:

|
--MUSIC
|
--PICTURE
|
--VIDEO
|
--PS3
..|
...--UPDATE
..|
...--SAVEDATA (este no lo crea en la memory pero si que lo hace cuando copiamos las partidas guardadas)

Se puede presuponer que en PS3 tambien existira un directorio GAME, pero desde la memory stick, usb... parece tener esto capado. O usar otro directorio. Yo estube ayer haciendo pruebas y no me reconocia nada (probe extensiones PUP y PBP)

Ahora habria que ver si copiando un archivo desde una memory, tambien lo codifica, y si es asi, meter un archivo de X KB, todo a 0, a ver si este tambien pasa por el encriptado

Hermes escribió: Los sectores a 0 pueden ser debido a que no se utilicen o que han tenido el sentido comun de no encriptarlos (pues de hacerlo, ya tendriamos la clave pues como dice savage, parece que los datos esten Xoreados)

No tengo puerto sata II para hacer pruebas, por eso tanto hablar y tan poco probar.

Tambien seria interesante comparar dos juegos comprados de la store, osea el mismo juego pero comprado con diferentes consolas, y pasarlos por el programa de Hermes para comparar las diferencias (osea si te lo bajas ya directamente firmado para cada consola o lo va haciendo al vuelo)

Se me ocurre una probatina, coges 2 hd's de ps3 formateaditos, bajas en uno de ellos una demo y miras a ver exactamente que ha cambiado, coges solo lo que ha cambiado (la demo supuestamente) y lo metes en otro hd de ps3 totalmente distinto y formateado.

Funcionara esa demo?
Si este es el caso, las demos serian "universales" lo que implicaria que la encriptacion que llevan es general a todas las ps3 y no dependen de la identificacion del disco ni del hardware de la consola.

funcionara con un juego comprado de ps3store?
Si este es el caso, pasara lo mismo que con la demo, lo que implicaria que se podrian clonar estos juegos entre distintos discos sin pasar por la ps3store (ojo, no estoy promoviendo la pirateria, solo es curiosidad)


Si alguna de las dos preguntas anteriores es negativa, no tendremos programas "universales" pero sabremos que en esos programas reside algun tipo de clave identificatoria, lo que acotaria muchisimo la busqueda.

Otra prueba...
Si podemos comparar un hd formateado y un hd formateado + demo, podemos extraer la parte de la "demo"

Ahora, cogemos 2 hds de ps3, bajamos la misma demo en ambos, extraemos la parte de la demo de ambos hds...
Son iguales? la clave es la misma, volvemos a la teoria de la "clave universal"

Son distintas? en que son distintas? ahi reside la clave?
Para rematar se podria comparar con un tercer hd y la misma demo bajada. Son distintas las 3 demos en los mismos offsets? en caso afirmativo me jugaria el cuello a que ahi reside la clave (presupongo publica) de encriptacion de los programas de ps3.

Otra prueba mas.
Cogemos y formateamos de nuevo los 2 (o 3 incluso mejor) hds.
bajamos otra demo DISTINTA en los 3 hds
miramos la parte de demo, los offsets que cambian son los mismos?
coinciden los offsets cambiados en algo con los offsets cambiados de la anterior demo que hemos hecho pruebas?

Aun acotaremos mas la busqueda con estas pruebas.

Por supuesto solo son teorias, pero a lo mejor no es tan descabellado

PauSaDRaMaTiCa escribió:
Tambien seria interesante comparar dos juegos comprados de la store, osea el mismo juego pero comprado con diferentes consolas, y pasarlos por el programa de Hermes para comparar las diferencias (osea si te lo bajas ya directamente firmado para cada consola o lo va haciendo al vuelo)

Me parece una buena idea, pero supongo q habria q hacerlos con 2 hds recien formateados

Se agradecen las teorías, pero si no las probais, o no las pensais comprobar, podeis absteneros de darlas. Y no penseis mal, o que lo digo por joder, pero hay algunas tan recargoladas que los autores no se han dado cuenta de en que momento se le han levantado los pies del suelo.

La criptografia no es un juego de niños, no penseis que esto vaya a ser fácil, con con cuatro comparaciones vaya a salir.

Deberemos encontrar que funcion k(a,b) genera la key (MD5/SHA/CRC...) y quien es a (COMÚN en todas las PS3) y quien es b (ID del HD).

Y debemos encontrar que función f(d,k(a,b)) da como resultado lo que hemos visto en los discos. Dicha función será algun algoritmo conocido o no de criptografía.

O sea, si no habeis jugado nunca con explosivos, no encendais la mecha, que luego se hace todo un poco más dificil de seguir (llevamos ya + de 100 mensajes).

Gracias, y siento si he herido a alguien, no lo hago con mala leche, sino en beneficio de todos.

j

Y no es posible que a todo lo que se meta el HD le pasen un xor como hacian en el data.psp de los juegos de PSX para PSP?

Hermes, la cabra siempre tira al monte xD
Estas en la brecha!!
Que bien te veo

j

He borrado el disco, metiendo sectores llenos de ceros, para estar absolutamente seguros. Lo he metido en la PS3 y le he dado un formato rápido. Nada más.

Adjunto fichero con los primeros 100MBytes de mi disco (comprimidos ocupan poquito), así como el volcado hexadecimal de las zonas que no son 0's, y el ID de mi disco.

http://www.apostols.org/savage_100MB_cleaned.zip

En resumen lo que os vais a encontrar:


no lo he comprobado, pero algunas zonas de datos parerecen iguales, a parte de que sigue repitiendose el famoso sector 1 por muchos sitios.

Voy a darle cuatro vueltas al craneo ...

[EDITADO]:

Le he metido una falsa imagen de 10MB, toda ella llenita de ceros, y no la encuentro (accedo al disco po USB, y va lentillo). La imagen se llama fakezero.gif y ocupa 10240000 bytes, con fecha/hora: 2007-04-02 10:53, l ahe metido en el siguiente volcado:

http://www.apostols.org/savage_100MB_fakezero.zip

En cuanto al inicio (primeros 6 megas de disco), esto es lo que ha cambiado:

Como te digo arriba, he comparado los datos del primer fichero que subistes, 512 bytes del offset 0 con los del offset 800h y coinciden.

Como se me ocurrió que los datos en 800h son copia de seguridad de los anteriores datos en 0h, pensé que en tu primer volcado los datos en 800h, tendrian que ser los mismos que se obtendiran en un formateo.

En efecto, los datos en 800h de tu primer fichero, coinciden con los datos en 0h en el fichero formateado.

De ser así, si rellenas el primer sector con 0, al ser copiados en 800h codificados, deberia mostrar todos los datos a 0 o una sucesion de bytes raros

Si miras con atencion en 800h, veras que los datos son distintos: ya no coinciden los primeros 48 bytes como coincidian antes y tampoco son ceros... asi que ha habido un proceso de por medio que ha obtenido datos caoticos al copiar

¿Podrias hacer una cosa? coge los datos de un sector que este codificado en el disco, uno raro y copialo como primer sector y luego formatea, a ver si aparece tal cual en 800h.

En los dos primeros ficheros, se ha dado esa circustancia y en el ultimo no, porque los datos son raros

A ver que es lo que sucede con la modificacion que te digo.

No se lo que es, pero he encontrado una zona con 64Ks de "basura" donde bloques de 512bytes coinciden con el sector 0, y otros con lo que encontramos en la posición 0x1100 y 0x1500. Puede que no siempre codifique de la misma forma, ya has visto con el formateado "completo" .... bueno, voy a ver como encuentro los 10MB de falsa foto que le he metido ...

j

Hechos:


Especulacion *REEDITADA*:

j

Sobre el contenido del sector 0 y la dirección 800h, voy a formatear de nuevo, a ver que hace.

Hermes escribió:Esto nos da una base de trabajo, pues hasta ahora no conociamos el contenido de un sector desencriptado y por tanto, no sabiamos que habia que buscar de utilizar un metodo de fuerza bruta.

de todas formas es tan probable o tan poco probable como que 200h-3ffh sea un sector lleno de ceros una vez encriptado.

3) Savage ha supuesto que el metodo de encriptacion es TEA o XTEA, aunque tambien ha descubierto que si se modifica un byte, varia el resultado de los posteriores a este. Yo no se si el metodo será exactamente asi o no, lo que está claro es que de ser uno de estos metodos, la key debe variar en cada encriptacion, pues de ser la misma, siempre que codifiquemos el mismo paquete de 64bits, deberiamos obtener el mismo paquete codificado y los datos observados no coinciden.

Asi que de ser alguno de estos metodos, la key debe variar en funcion de los datos previos obtenidos y es posible que la "semilla" para poder desencriptar un sector, esté en esos primeros 16 bytes que se repiten tanto. Es posible que esa semilla xoreada con algo, de la clave para desencriptar los siguientes 64 bits/128 bits y que luego el resultado se utilice como nueva key (xoreando de nuevo con ese algo) para obtener otro paquete.

Para cifrar debemos tener en cuenta dos cosas, el algoritmo y el método de cifrado:

Algoritmos clave simétrica, entre parentesis longitud bytes del bloque cifrado:
- des(8), tripledes(24), xtea(16), blowfish(56), rijndael(32), twofish(32)

Descartamos tripledes y blowfish dado que 24 y 56 no son divisores de 512

Metodos:
- ECB: Electronic CodeBook mode. Metodo mas sencillo, cada bloque de cifrado se hace independientemente.
- CBC: Cipher Block Chaining mode. Se hace XOR con el bloque anterior a los datos antes de cifrarlos.
- OFB: Output-Feedback mode. Una cambio (byte) en origen implica solo un cambio en destino (usado para transmisiones, facil recuperación).
- CFB: Cipher-Feedback mode. Stream adaptado a bloques, resultado parecido a CBC pero recupera si faltan datos o se alteran.

Yo descartaría OFB y CFB, son más orientados a transmisiones digitales. Y descrato definitivamente ECB, por que en sectores con bytes repetidos (dentro del propio sector) veríamos repeticiones en el cifrado.

Me quedo con método CBC, por fácil, rápido y conocido.

Creo que esto contesta a varias de tus dudas o preguntas.

1) Me gustaria que me dierais la opinion sobre esos 16 bytes que se suelen repetir: ¿creeis que es algun tipo de cabecera que está encriptada o los debemos considerar como una semilla a partir de la cual se obtiene la key para desencriptar un sector?

Eso me hace pensar que detrás hay una secuencia de 16 bytes desencriptados que existen en todos esos sectores donde el cifrado se repite. Me indica además, que la longitud de bloque de cifrado es de 16bytes o menor y que solo te puede pasar al inicio de sector (como si usasen CBC).

Respecto a usar eso para sacar la clave, no es posible: Aunque tengas datos + equivalentes datos cifrados, no se puede averiguar la clave de forma matemática. El único camino es explorar el total del espacio de claves existente (inabarcable ni con una PS3), deberíamos montar un CrackTEA@Home ...

Una vez petada la clave (16Bytes), deberíamos averiguar que relación tiene con el DISK-ID. Bastante difícil si han usado un MD5SUM (16bytes)

La lógica indica que ha llegado el momento de olvidarse del tema.

Pero, aunque parezca todo imposible, a veces la estupidez humana (lo único infinito) hace que las cosas se hagan más sencillas. No es el primer sistema de este estilo que he abierto gracias a adivinar que pensaba el programador de turno cuando lo escribió.

Mi nariz me dice que esos 16bytes son ceros patateros. Con lo cual solo hace falta implementar TEA.crypt o TEA.decrypt y trabajar con esos 16bytes, no con todo el sector.

La putada adicional es que para cada clave TEA existen 2 claves validas equivalentes, pero que no tienen nada que ver con la original, y si diesemos con una de esas no podríamos encontrar nunca la relación DISK-ID con la key de cifrado.

Bueno, no decaiga el humor, que en cuanto haya un exploit de verdad, volcamos la memoria de las SPU's (256K's cada una), y una de ella se debe encargar de estas cosas.

EDITO:
Última prueba realizada: He metido el primer mega de HaDeSh a mi disco, y la PS3 me ha pedido formatear el disco. Esto indica con bastante seguridad que se usa el DISK-ID como parte de la clave de cifrado, y que si no somos capaces de cambiar el Disk-ID tampoco podemos hacer full-backup para meterlo en otro disco duro.

Sigo el hilo desde hace bastante, pero no quería postear para no estropear el hilo.

Tengo una pregunta: habeis topado con una pared?es lo que me ha parecido entender del ultimo mensaje de savage.

Bueno, en cualquier caso animo campeones que seguro que acaba saliendo algo importante de este hilo

Si, efectivamente es una pared, pero los Yamakasi del parkour no se detienen por una pared

Adjunto imagen recien formateada, después de meter el primer mega de HaDeSh en mi disco y que PS3 dijera que debía formatearlo...

Saludos.

Yo tambien sigo el hilo desde hace tiempo y quisiera preguntar si el at home ese es como el seti at home de la nasa, de ser asi me apunto y mi pc esta para lo que se necite que para eso tengo maquina de sobra

savage escribió:Si, efectivamente es una pared, pero los Yamakasi del parkour no se detienen por una pared

Adjunto imagen recien formateada, después de meter el primer mega de HaDeSh en mi disco y que PS3 dijera que debía formatearlo...

Saludos.

¿Efectivamente esta la clave en el primer MB?
Una pequeña duda, si se consiguiese esa calve ... seria lo que permitiese poder montar los discos? o bueno generar un driver ?

yo tampoco quiero estropear el hilo pero no puedo resistirme a daros animos y gracias por todo lo que estais haciendo, salga o no salga nada en claro

HaDeSh escribió:¿Efectivamente esta la clave en el primer MB?

No, en realidad no. Pero tenemos un bloque (16Bytes) que suponemos provienen de cifrar 16 ceros. Si comprobamos todas las combinaciones de clave posible que van desde 00000000000000000000000000000000 hasta FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, y ademas hemos acertado en el Algoritmo y Modo de Cifrado, pues tendremos una Clave.

La Clave de UN SOLO DISCO, no una clave general.

A partir de ahí puede ser incluso más complicado, pues para generar la clave se ha usado una función y unos datos que desconocemos y uno que suponemos (Disk-ID).

Una pequeña duda, si se consiguiese esa calve ... seria lo que permitiese poder montar los discos? o bueno generar un driver ?

Seria el primer paso para comprender la estructura del disco, y después, una vez comprendida, podríamos hacer algo parecido al hdl_dump, o un driver para acceder desde el PC.

Jojjojjojojo!!! me lo estoy pasando bomba de verdad, leeros asi de esa manera tan Técnica es una delicia

Seguid seguid, y animo, que os estais portando y da gusto veros trabajar asi :D

Mucha suerte con las investigaciones.

Salu2

j

Savage, pero no te ibas de vacaciones? viciosillo...

Hermes escribió:La verdad que he estado pensando en el tema y no creo que ese bloque de 16 bytes provenga de 0

Imaginate un estructura parecida a una FAT o a un Directorio. El sector cero está parcialmente inicializado, y el sector 1 (en 200h) no sido rellenado, por lo tanto puede estar a 0, perfectamente, como los tropecientos sectores de contenido idéntico que aparecen en el disco.

Veamos, en al menos dos ocasiones, has rellenado los sectores con valores 0 y en 800h ha aparecido un sector con datos raros.

creo qe se trata simplemente de una copia de respaldo del sector 0, y que cad a vez que este cambia se deja una copia en esa posición. Pero aunque fuera el resultado de descifrar/recifrar de forma erronea el sector 0 -no creo en eso-, no te aporta nada para sacar la KEY de MI disco, por eso se les llama algoritmos de criptografía dura, luego a eso hay que sacarle la relacion con el DISK-ID.

Saludos.

Buenas gente

-No quiero estropear este post que por lo poco que se de esto parece que sois los unicos que por lo menos os lo estais kurrando.Solo queria animaros y haber si teneis suerte,pues si conseguis algo nos vais a hacer un gran fabor a todos.A lo dicho,Suerte campeones.

j

Si hacen falta voluntarios para procesar informacion o lo que sea mi ordenador esta a vuestra disposicion

Yo también proceso lo que haga falta procesar.

Me apunto, un Dual core 2 edicion 6800 serviria?

Si hay que ayudar se ayuda.

Salu2

yo tb ayudo en lo k sea, animo!!

Bueno al fin pude instalar el linux en mi pc y todo por la mierda de ACPI. Quiero empezar a meterle mano a esto y mirar unas cosillas pero desconozco que editor hexagesimal puedo usar para linux.

Algun consejo??

Jbom escribió:Bueno al fin pude instalar el linux en mi pc y todo por la mierda de ACPI. Quiero empezar a meterle mano a esto y mirar unas cosillas pero desconozco que editor hexagesimal puedo usar para linux.

Algun consejo??

apt-get install ht
"hte" para ejecutar

Leyendo lista de paquetes... Hecho
Creando árbol de dependencias... Hecho
E: No se pudo encontrar el paquete ht


no me encuentra el paquete y no se como buscarlo.

http://www.ps3news.com/forums/playstation-3-dev-chat/ps3-hdd-contents-64646.html

programa para ver las particiones de la ps3 desde linux.

tambien un tal Hackobell afirma montar una imagen .bin en linux hacer un crash al xmb y que la imagen siga montada. lo ha probado con peliculas.

http://www.ps3news.com/forums/playstation-3-chat/ps3-iso-loader-progression-dev-chat-only-63317-11.html

lacion escribió:http://www.ps3news.com/forums/playstation-3-dev-chat/ps3-hdd-contents-64646.html
programa para ver las particiones de la ps3 desde linux.

Lo que dices no es cierto. Lo que este programa muestra es lo mismo que ya se ha comentado en este hilo aproximadamente. Y sí, lo hace desde Linux, pero desde el linux de un PC, enchufando el disco de la PS3 a un adaptador SATA o USB/SATA del PC, tal como venimos haciendolo nosotros.

lacion escribió:tambien un tal Hackobell afirma montar una imagen .bin en linux hacer un crash al xmb y que la imagen siga montada. lo ha probado con peliculas.
http://www.ps3news.com/forums/playstation-3-chat/ps3-iso-loader-progression-dev-chat-only-63317-11.html

Personalmente no me creo nada de lo que dice. Este tio no tiene ni idea de como funciona un sistema operativo y se cree que ha encontrado un error en linux, que le da privilegios en el GAMEOS. Es IMPOSIBLE lo que explica. Linux/PS3 funciona bajo un hypervisor, y lo que "montes" en linux, en absoluto se ve por encima, y mucho menos al volver a GAMEOS, con el linux y su hypervisor fuera de memoria.

Apuesto que a este pájaro le ha pasado una de principiante como una casa. Ha puesto un MPG2 en un disco USB, y lo ha podido reproducir.

Hola, llevo varios dias leiendoos. muy buen trabajo y interesante. poca cosa puedo hacer yo aparte de aprender y ir probando cosillas...

el caso que da la casualidad que dando vueltas me e encontrado este curioso artículo:

http://www.maxconsole.net/?mode=news&newsid=15647 ,

que me parece que apunta algunsa cosas como las que se estan comentando en este hilo (algunas ya savidas) que pueden ser interesantes. animos y adelante

savage escribió:Lo que dices no es cierto. Lo que este programa muestra es lo mismo que ya se ha comentado en este hilo aproximadamente. Y sí, lo hace desde Linux, pero desde el linux de un PC, enchufando el disco de la PS3 a un adaptador SATA o USB/SATA del PC, tal como venimos haciendolo nosotros.

ejem.. cierto nunca he dicho lo contrariop. postee el link para el que lo quisiera bajar y probar.

savage escribió:Personalmente no me creo nada de lo que dice. Este tio no tiene ni idea de como funciona un sistema operativo y se cree que ha encontrado un error en linux, que le da privilegios en el GAMEOS. Es IMPOSIBLE lo que explica. Linux/PS3 funciona bajo un hypervisor, y lo que "montes" en linux, en absoluto se ve por encima, y mucho menos al volver a GAMEOS, con el linux y su hypervisor fuera de memoria.

Apuesto que a este pájaro le ha pasado una de principiante como una casa. Ha puesto un MPG2 en un disco USB, y lo ha podido reproducir.

es posible. solo quedara esperar un poco y ver que pasa a ver si es mentira o no. pero lo que se va hablando hasta ahora tiene sentido.
incluso en una virtualizacio de la memoria de ps3 bajo el xmb como esta a linux ahora se puede acceder a otras cosas. como bien se hacen en los exploits de las Maquinas virtuales de VMware para acceder a servidores seguros hoy en dia.

Me hago eco de una noticia puesta en el hilo del isoloader de paradox y pego aqui lo que interesa para este hilo:

ps3news escribió:PS3 DEV Chat Forum opened; PS3 HDD Contents unveiled!
........ and to kick things off Hansooloo has shared a preliminary PS3 HDD Contents analysis post there!

Si el titular es cierto hay dos posibilidades, han desencriptado el sistema de archivos o han encontrado un agujero para recuperarlo de la consola ya desencriptado.

Edito: he leido un poco mas sobre esto y lo unico que hay son suposiciones (asi que titular un tanto desacertado) copio y pego las conclusiones alli sacadas:
From the analysis performed so far, here are some findings:

1. The HDD is encrypted with a (most probably) Sony proprietary format.
2. If [kLink]Linux[/kLink] is setup on the machine, the HDD will contain the relevant ext2 or ext3 partitions, but it will NOT be visible to a regular OS. This is because, the HDD does NOT have a standard partition table. If one uses WinHex to scan the HDD, then the program will find the ext2/ext3/swap partitions at their respective offsets.
3. A program has been written to scan blocks of 16bytes for where contiguous data is on the HDD. This program has identified major blocks of data on a freshly formatted 60GB HDD.
4. Of major interest is that right around the 380MB marker, we start seeing blocks of 64KB data, and this repeats itself EVERY 183.72MBs. Why does a system need 64KB worth of markers every so often, is a mystery at the moment.
5. Each HDD is "individualized" the moment it is formatted on a particular PS3 unit. An individualized HDD CANNOT be used in another PS3 unit due to (in theory) a unit based signature being written to each HDD.
6. A project is underway to "individualize" 2 same make and model (Seagate Momentus 60GB 2.5" SATA) HDDs and perform a byte level diff to spot differences in the disk layouts.
7. This diff will also be analyzed by the data block scanning program mentioned in Item-3 above.

Permitidme que me explaye con el mensaje de marras, que está dando vueltas por todos los foros y blogs de la scene:

1. The HDD is encrypted with a (most probably) Sony proprietary format.

Cualquiera que haya estudiado una tarde de criptografia (no hace falta más), se dará cuenta que esto que dicen es absurdo. No se crean algoritmos criptograficos seguros cada dia. Los que hay son suficientemente fuertes para que no los rompas, aunque sepas de cual se trata.

2. If Linux is setup on the machine, the HDD will contain the relevant ext2 or ext3 partitions, but it will NOT be visible to a regular OS. This is because, the HDD does NOT have a standard partition table. If one uses WinHex to scan the HDD, then the program will find the ext2/ext3/swap partitions at their respective offsets.

Nada nuevo. Lo primero que leí sobre el tema, era de fecha Enero/2007. Ver enlace: http://forums.ps2dev.org/viewtopic.php?t=7534

3. A program has been written to scan blocks of 16bytes for where contiguous data is on the HDD. This program has identified major blocks of data on a freshly formatted 60GB HDD.

Lo único útil que han hecho, un programa para los que saben usar la shell de unix

4. Of major interest is that right around the 380MB marker, we start seeing blocks of 64KB data, and this repeats itself EVERY 183.72MBs. Why does a system need 64KB worth of markers every so often, is a mystery at the moment.

Bueno, esta te la acepto, misma duda tenemos muchos. Yo he metido 100MB de fichero en el disco, y no he encontrado tanto disco ocupado contiguo (máximo bloques de 64Ks, como dice este) Existe la posibilidad, aunque penalice seriamente al rendimiento del disco, que los datos se guarden "dispersos", y no aparezcan de forma contigua en el disco.

5. Each HDD is "individualized" the moment it is formatted on a particular PS3 unit. An individualized HDD CANNOT be used in another PS3 unit due to (in theory) a unit based signature being written to each HDD.

Falso. DR KANNABIS, de este foro, hizo la prueba de intercambiar dos discos duros, tal como le pedi, y funcionaron, DESMINTIENDO esto que dice el pájaro en este punto. Ver Post: http://www.elotrolado.net/showthread.php?s=&postid=1707319136#post1707319136

Ya me he quedado contento

no se si os servirá de algo, pero si os pasais por el hilo del isoloader, se habla de algo que han dixo en ps3news de que un tio ha conseguido montar una imagen en linux y salirse al xmb sin perder los cambios o algo asi...

KSiNauSia escribió:no se si os servirá de algo, pero si os pasais por el hilo del isoloader, se habla de algo que han dixo en ps3news de que un tio ha conseguido montar una imagen en linux y salirse al xmb sin perder los cambios o algo asi...

Ya vereis que cuando se saque algo fijo que es por parte de algun español,mucha bomba de humo nos venden estos guiris y vosotros pikais...en fin.Animo gente que seguro que podeis con esto,confio mas en vosotros que en el resto.

Edito.Vaya pareado,parezco Mc..jejej

buenas aber si alguien me puede echar ena mano

superloco escribió:buenas aber si alguien me puede echar ena mano

Hey, aquí estamos de nuevo.

Me he pegado una maratoniana sesión de intercambio de ideas y pruebas con Han Sooloo, de ps3news.

Resultados probados:

• Se encripta por sectores (512Bytes)
• No se usa el número de sector como valor de inicialización del metodo de cifrado ni como semilla, ni clave, ni nada. Dos sectores desencriptados identicos, generan dondequiera que los guarde, dos sectores cifrados identicos.
• Cada 188Mb (0xb7b8000) aproximadamente, existe una Tabla de Ocupación, o como queramos llamarla, de 64Ks, que hace referencia a los sectores que la siguen.
• Lo que aparece en el sector 1 son CEROS, un sector vacío, cifrado con nuestro clave/algoritmo/método. Confirmado escribiendo 198MB de ceros, que han generado 198MB del mismo contenido que el sector 1 del disco.
• los 16Bytes que coinciden en el inicio del sector 0, con el 1 son por que en el sector 0 desencriptado, estos bytes están a 0.

Adjunto la diferencia entre un disco vacío (limpiado a 0's y recien formateado) a la izquierda, y el mismo disco después de meterle los 198MB de datos (izquierda), útil para hacerse una idea de como reparte la ocupación de espacio en disco. Usad un editor que no rompa las lineas y que use fuente monoespaced.

savage escribió:Hey, aquí estamos de nuevo.

Me he pegado una maratoniana sesión de intercambio de ideas y pruebas con Han Sooloo, de ps3news.

Conclusion, vais por buen camino?

Ahora almenos sabeis mas cosas del cifrado del HD no?

PD: se me olvido daros animos .

Seguid asi chicos

Salu2

Bueno parece que se adelanta algo. Y yo sin poder poner linux en mi pc.

Ahora se me plantean algunas preguntas

savage escribió:# Se encripta por sectores (512Bytes)

Entonces si ponemos un archivo que ocupe mas de 512bytes mete los datos contiguos o los esparce??

El resto que quedase hasta completar un sector de 512Mb los rellena de 0??

savage escribió:# No se usa el número de sector como valor de inicialización del metodo de cifrado ni como semilla, ni clave, ni nada. Dos sectores desencriptados identicos, generan dondequiera que los guarde, dos sectores cifrados identicos.

Sabemos el algoritmo de cifrado??

savage escribió:# Cada 188Mb (0xb7b8000) aproximadamente, existe una Tabla de Ocupación, o como queramos llamarla, de 64Ks, que hace referencia a los sectores que la siguen.

La Tabla de Ocupacion va cifrada??

Complementando lo que dije ayer noche:

[*] Se encripta por sectores (512Bytes)

O sea, no se encripta a nivel archivo. Cualquier acceso a disco que se hace desde el GameOS, implica criptación y desencriptación de los sectores escritos o leidos.

[*] No se usa el número de sector como valor de inicialización del metodo de cifrado ni como semilla, ni clave, ni nada. Dos sectores desencriptados identicos, generan dondequiera que los guarde, dos sectores cifrados identicos.

No podemos asegurar ni cual es el algoritmo ni cual es el método de cifrado. Mi apuesta es por xTEA (128bits de clave), que cifra en bloques de 64bits, es ultrarápido, fácil, libre, sin royalties y duro. El método: CBC, al menos eso parece, a falta de alguna prueba adicional, usando un IV fijo, aunque desconocido. Mi apuesta en cuanto al IV es: 64 bits a 0.

[*] Cada 188Mb (0xb7b8000) aproximadamente, existe una Tabla de Ocupación, o como queramos llamarla, de 64Ks, que hace referencia a los sectores que la siguen.

Como cualquier otra parte del disco que usa GameOS, estos sectores de las tablas de ocupación están cifrados.

Saludos.

rarebyte escribió:¿No es demasiado rapido xTEA como algoritmo de cifrado?

Esa es una pregunta realizada sin usar mentalidad Hacker. La pregunta sería:

¿ Que es más probable ?

• ¿ Que invierta una fortuna en matemáticos, para que desarrollen un sistema criptográfico ultra-secreto, de dudosa o desconocida resistencia, y que solo usaremos en Sony ?
• ¿ Que use un sistema criptográfico conocido, FUERTE, LENTO y por el cual debo pagar royalties ?
• ¿ Que use un sistema criptográfico conocido, FUERTE, RÁPIDO, PÚBLICO y GRATUITO ?

Respecto a la velocidad, no debería notarse retraso en accesos. Ni con TEA ni con DES, ni con nada de lo que se suele usar.

Puede generar más problemas a la velocidad de acceso a disco el hecho de que esté la información "dispersa" por el disco duro .

Saludos.