PS3 NAND Dump Extractor released!

Juan The MW escribió:
Y quizás crear un CF y meterle por el infectus.

Saludos.

Me gusta
Me gusta

No se si alguien de aqui tiene conocimientos suficientes para descifrar RSA

Pero si somo 50 o 60 no se si consiguiesemos hacerlo con LINUX y utilizar el CELL que seguro que es mas potente que cualquier procesador nuestro

VEnga vamos a empezar

es solo descifrar RSA por fuerza bruta? Tendria k mirarlo pero creo recordar k se hacia buscando dos numeros primos que cumplian una formula... pero no me hagais caso k lo estoy diciendo de memoria.

El caso es que programar algo asi no tiene mucho misterio y hacerlo distribuido (cuestion de sockets) xDDD

Edit: Tambien hay que saber la logitud de la clave pq si son 256 digitos o algo mas complicado son 10^256 combinaciones y si es alfanumerica ya es la lokura.

Y porque no?

Venga yo puedo programar algo de Sockets en Java

Animemonos

Jur...

Bueno, el problema es todavía un poco más complejo, primero porque no conocemos como Sony a implementado exactamente los modelos de Trusted Computing.
El TGC define 7 tipos de claves cada una de ellas con determinada funcionalidad. Existen claves que son migrables (se pueden copiar) y otras que no lo son (son inamovibles)

- Signing keys, pueden ser migrables o no, se emplean para firmar.
- Storage keys, empleadas para cifrar.
- Bind keys, utilizadas sobre todo para el intercambio de claves.
- Legacy keys, son las que utilizan el SO y las aplicaciones, las que grabamos nosotros.
- Authentication keys, son las utilizadas para el transporte de datos.
- Identity keys (AIK), no migrable, importantísimas pues se emplean para firmar las otras claves.
- Endorsment keys (EK), no migrable, utilizadas para descifrar datos de autorización y mensajes relacionados con creación de AIKs.

Más información en la web del TGC e IBM (y en google)
Como he dicho, el TGC diseña el modelo pero la implementación y uso depende del usuario, como poder, puede hasta implementarse una ADK (una clave maestra que podría descifrar todos los mensajes cifrados mediante otras claves). Posibilidades infinitas ...

Pero aún hay más, los permisos de acceso. Eres un ejecutable y estás firmado, dependiendo de quien te firme tienes una tarjeta de visita.

Voy a poner un ejemplo con el famoso Hotel:
En el sótano del hotel hay dos habitaciones, una de ellas no tiene puertas ni ventanas, está blindada y sólo te comunicas con un tipejillo que vive en su interior mediante teléfono. El blindaje es impenetrable y el tipejillo es inmortal e indestructible. El tipejillo posee una serie de claves, puedes pedirlepor teléfono que te verifique una firma, te cifre un mensaje o te lo descifre; pero nunca te dará las claves.
La otra habitación sí tiene puerta pero esta tiene un escaner de retina y un soldado armado en la puerta. El tipejillo de dentro sí te puede dar claves y recibirlas.

Ahora tenemos una bonita pareja de claves filtrada para poder entrar al hotel.

En la recepción del Hotel:
- Buenas soy Juan Jugón, quiero pasar (priviliegios de un juego)
- Pase, tiene acceso al Hall, bar, restaurante y su habitación.
- Buenas soy Maria Brillos la de la limpieza (privilegios de utilidad del SO)
- Pase, pase, limpie por favor la piscina
- Buenas, soy Paco Litri el electricista (privilegios de acceder a la NAND)
- Pase, pase, necesitamos actualización de las habitaciones 102 y 103.
- Buenas soy Home Brew el emulador de neogeo creado por la scene (privilegios de JUEGO)
- Pase, pase...
- Buenas, soy NY, SO-NY el dueño (este sí que puede acceder al keystorage)
- Pase, pase, el Hotel es suyo.

El tal Sony se dirije hacia el sotano. Llega a la habitación con puerta.
- Buenas soy el dueño.
- Pase por el escaner de retina por favor
- ok, contento?
- Sí señor, pase, el Hotel es suyo.

- Hola tipejillo, quiero que me añadas la clave de Miguel MataMata que trae unos nuevos shooters muy divertidos.
- Ok, ya puede pasar Miguel MataMata
- Y quiero también que me revoques la clave de Home Brew, no me ha gustado su emulador de neogeo.
- Ok, revocada, los de seguridad ahora mismo le están echando del Hotel.

Mientras en la puerta de la calle:
- Fuera del Hotel, a la puta calle, y no vuelvas !!!!!!
- buaaaaaaaaaaaa, me han hechado...

Queda claro que Sony puede abrir y cerrar el grifo cuando le de la gana?
Y que con los permisos que nos de sólo podemos hacer lo que ella quiera que hagamos?
Pues así están las cosas...

Un saludo.

naima escribió:Jur...
....

Gracias por las aclaraciones, solo una duda k tengo. La primera habitacion, la k esta blindada y solo tiene telefono, seria donde reside digamos k "la clave maestra de sony" y esa no es posible cambiarla???. pq sino no entiendo eso....

ssssO escribió:No se si alguien de aqui tiene conocimientos suficientes para descifrar RSA

Pero si somo 50 o 60 no se si consiguiesemos hacerlo con LINUX y utilizar el CELL que seguro que es mas potente que cualquier procesador nuestro

VEnga vamos a empezar

quien ha dicho que se use RSA¿¿¿????

Dudo que se use RSA (vamos no es que lo dude, es que ni me lo imagino) es otro mas potente.

De todos modos, desencriptar algo por fuerza bruta.... si tuvieras 1000 (10.000, 100.000 , 1.000.000)ps3 en cluster utilizando (sin capar) el 100% de los cells, te diria.. va probemoslo.... pero como no es el caso, olvidate.

devnul escribió:
quien ha dicho que se use RSA¿¿¿????

Dudo que se use RSA (vamos no es que lo dude, es que ni me lo imagino) es otro mas potente.

De todos modos, desencriptar algo por fuerza bruta.... si tuvieras 1000 (10.000, 100.000 , 1.000.000)ps3 en cluster utilizando (sin capar) el 100% de los cells, te diria.. va probemoslo.... pero como no es el caso, olvidate.

Podríamos hacer un llamamiento para crear una masiva masa e intentarlo .

Saludos.

Hay foros en los que se ha estado investigando los backups del HDD y han encontrado archivos que usan las herramientas de encriptación RSA, por eso se piensa que es RSA, aunque seguro que se usa algo mas.

Creo recordar que ya ne PS2 colaboraron Sony y RSA

Respecto a usar una aplicación distribuida para romper por fuerza bruta el crifrado de la PS3 ya se me ocurrió se discutió y no se llegó a nada. Así que va a ser que no

Un saludo

Lo que yo me pregunto es cómo narices hacemos para que la PS3 se trage el susodicho programa (en el caso de hacerse) el cual haga lo que quiera que sea (en este supuesto caso, nuestro "granito de arena")

Desde Linux puede que tengamos "más libertad" pero a la vez está más capada que yo qué sé, y supongo que la capacidad de procesamiento no será la misma que en GAME-OS, por lo que lo interesante sería conseguirlo en el XMB, cosa que la encuentro más que difícil, pero bueno...

En fin, ganas no faltan, ni mucho menos, pero es que lo veo tan difícil...a la vez de fácil (relativamente, claro está)

Gonzo345 escribió:Lo que yo me pregunto es cómo narices hacemos para que la PS3 se trage el susodicho programa (en el caso de hacerse) el cual haga lo que quiera que sea (en este supuesto caso, nuestro "granito de arena")

Desde Linux puede que tengamos "más libertad" pero a la vez está más capada que yo qué sé, y supongo que la capacidad de procesamiento no será la misma que en GAME-OS, por lo que lo interesante sería conseguirlo en el XMB, cosa que la encuentro más que difícil, pero bueno...

En fin, ganas no faltan, ni mucho menos, pero es que lo veo tan difícil...a la vez de fácil (relativamente, claro está)

hombre, en su dia no se penso de utilizar la play. En el ordenador, se utilizaria un arxivo al k todos tengan acceso(ej. una demo k vaya rulando) aunk, puestos a utilizar los Cells... corregidme si me equivoco, pero en linux solo se tiene acceso a un SPU no???

editado... menudo fallo lo del Cel...

Contestando a Gonzo, para k se iciese el harakiri, tendriamos k meterle mano, y eso no seria posible....
Saludos

DarK_FeniX escribió:
hombre, en su dia no se penso de utilizar la play. En el ordenador, se utilizaria un arxivo al k todos tengan acceso(ej. una demo k vaya rulando) aunk, puestos a utilizar los Cells... corregidme si me equivoco, pero en linux solo se tiene acceso a un Cell no???

Saludos

¿Como que a "un Cell"?

Cells, en nuestras PS3, sólo hay 1, aunque supongo que te referirás a los SPU...

Pero vamos, lo curioso es que Cell está diseñado para la computación distribuida, para trabajar de la mano con otros como él, por lo que podríamos utilizarlo para que se hiciera el harakiri....

Gonzo345 escribió:Lo que yo me pregunto es cómo narices hacemos para que la PS3 se trage el susodicho programa (en el caso de hacerse) el cual haga lo que quiera que sea (en este supuesto caso, nuestro "granito de arena")

Desde Linux puede que tengamos "más libertad" pero a la vez está más capada que yo qué sé, y supongo que la capacidad de procesamiento no será la misma que en GAME-OS, por lo que lo interesante sería conseguirlo en el XMB, cosa que la encuentro más que difícil, pero bueno...

En fin, ganas no faltan, ni mucho menos, pero es que lo veo tan difícil...a la vez de fácil (relativamente, claro está)

El problema no radica tanto en la creación de la aplicación distribuida, y sería perfectamente factible ejecutarla en Linux como entorno natural. Sólo perderíamos un SPE de potencia respecto al XMB. El verdadero problema estriba en que no resulta tan sencillo como crear un aplicación de proceso distribuido. Primero hay que saber qué buscamos y cómo encontrarlo, además de estimar si es viable en un tiempo razonable con los recursos que tuviésemos.

Hace falta mucha más información de la que tenemos para que el proyecto fuera viable. Para empezar ni siquiera conocemos los algoritmos usados en los cifrados ni en las firmas, ni tan siquiera el algoritmo de HASH utilizado para la verificación de la integridad de los paquetes. Esto que pongo es sólo un ejemplo de la cantidad de datos que no tenemos antes de poder formular una hipótesis de resolución de un problema. Tenemos muchas incógnitas y pocas de ellas están despejadas para resolver la ecuación

cnova escribió:Tela marinera del monte del pepino...

Joder, pues vamos apañaos....

Es decir: "no es coger el Cell y decirle...trabaja", sino saber una serie de cosas básicas para decirle lo que tiene que maquinar. Totalmente normal, pero tantos vacíos aún a día de hoy...lo veo difícil....

Jur...

Un par de cosas,
La primera es que releyendo mis post creo que algunas cosas con la buena intención de simplificar no las he explicado bien, sobretodo en el primer post que puede dar a entender que sólo existe una clave no migrable.
Claves hay varias, unas migrables y otras no migrables.
Para resumirlo, existen claves internas y externas. Las internas (no migrables) no pueden ser extraidas y/o copiadas, las externas (migrables) sí. Todas las claves se gestionan mediante software.
Podemos mediante una orden solicitar la creación de una AIK, una vez generada está lista para su uso, pero no se puede extraer. De la misma manera podemos solicitar la creación de una clave de firmado, migrable o no. Si la queremos no migrable se generará y no podremos extraerla, si es migrable o bien la generamos o bien se la suministramos nosotros mismos.
En el ejemplo del hotel, la habitación cerrada es la metáfora de las claves utilizables pero sin posibilidad de transferir ni tocar, la habitación con puerta es el almacen de claves de libre acceso (con los privilegios de sistema adecuados, claro)

Segundo, devnul pregunta que quien dice que se use RSA.
Bien, sí se usa RSA al igual que ECC o DSA, como dije antes unos para unas cosas y otros para otras, y la PS3 hace muchas cosas que requieren cifrado. Por ejemplo el HDD se cifra con AES 256, casi seguro en modo LRW (el modo tengo que confirmarlo con mayor seguridad).

Tercero, alguien, perdón por no acordarme, sugirió que si se filtrase una pareja de claves podríamos abrir los .pkg y los .pub con lo que estaríamos al tanto de futuras modificaciones de las claves.
No, como ya comentó devnul, claves para entrar existen muchas y cada una abre su habitación. En resumen, una clave que nos permitiese cifrar y firmar nuestro propio código ejecutable no abriría otros archivos que estuviesen cifrados con otras claves.

Cuarto, la cosa está dificil, es Sony la que puede abrir y cerrar el grifo. La única opción que se me ocurre, esta no permitiría el homebrew pero sí los backups, es leer los BD y suplir aquellos datos que una grabadora no pueda reproducir mediante una modificación de la Firmware del lector. De todas formas seguiríamos a merced de Sony y con posibilidad de baneos.

Un saludo.

Bueno, lo repito, lo de la aplicación distribuida tiene su hilo. Lo podeis leer, informaros y vereis como es inviable. Sí, yo también me llevé una decepción.

AQUÍ EL HILO
http://www.elotrolado.net/hilo_-Crear-una-app-distribuida-para-romper-por-fuerza-bruta-el-encriptado-de-la-PS3-_866405?highlight=crear+una+app

Un saludo

custom para dentro de poco,pero de momento yo no toco nada hasta que salga un custom o algo de utilidad para arriesgar a tocar la nand por algo que valga la pena xD.

naima escribió:Jur...

Tercero, alguien, perdón por no acordarme, sugirió que si se filtrase una pareja de claves podríamos abrir los .pkg y los .pub con lo que estaríamos al tanto de futuras modificaciones de las claves.
No, como ya comentó devnul, claves para entrar existen muchas y cada una abre su habitación. En resumen, una clave que nos permitiese cifrar y firmar nuestro propio código ejecutable no abriría otros archivos que estuviesen cifrados con otras claves.

Lo que comentaba no es que se filtrara una pareja de claves, es algo parecido, pero no era así, venia al hilo de las tacticas para desencriptar y poder leer los ficheros encriptados de la PS3, me explico:

Se han conseguido extraer los archivos de la NAND, pero por ahora no se pueden leer por dentro por que están encriptados.

Si consiguieramos la(s) clave(s) que hagan legibles esos ficheros (me refería a la clave que los hace legibles) podriamos ver su contenido y podriamos ver cualquier cambio que pudieran hacer inhabilitando y habilitando claves o algoritmos de cifrado/validación, ya que estos cambios vendrian dentro de esos archivos que ya podemos leer.

Lo que esa clave no nos permitiría sería modificar esos ficheros pup, pkg etc... y que se los trague para modificar el contenido del sistema.

Otro tema respecto a lo que comentas del FW del lector BR:
Entre los ficheros de la nand y de los pup hay alguno que parece ser la actualizacion del FW del BR, pero tambien está encriptado, con lo que no podemos analizarlo (hasta que no se encuentre la clave que permita leerlo y no se puede modificar al menos en la NAND hasta que no encontremos la clave con la que se firman los paquetes. .

Lo que no se es si el BR de la PS3 tiene un chip propio que tenga el FW, y si es así ese FW no podría estar encriptado, por que el lector no es capaz de descifrarlo.

Tema HDD:
Estoy empezando a estudiar la particion gameos del HDD, hace 3 dias que he empezado, así que nada por ahora.
¿Como sabes que el cifrado es AES 256? ¿Hay algún foro en el que se haya sacado esto? ¿lo has sacado tu? ¿Donde puedo encontrar mas info?

ps3dev escribió:
Lo que comentaba no es que se filtrara una pareja de claves, es algo parecido, pero no era así, venia al hilo de las tacticas para desencriptar y poder leer los ficheros encriptados de la PS3, me explico:

Se han conseguido extraer los archivos de la NAND, pero por ahora no se pueden leer por dentro por que están encriptados.

Si consiguieramos la(s) clave(s) que hagan legibles esos ficheros (me refería a la clave que los hace legibles) podriamos ver su contenido y podriamos ver cualquier cambio que pudieran hacer inhabilitando y habilitando claves o algoritmos de cifrado/validación, ya que estos cambios vendrian dentro de esos archivos que ya podemos leer.

Lo que esa clave no nos permitiría sería modificar esos ficheros pup, pkg etc... y que se los trague para modificar el contenido del sistema.


Otro tema respecto a lo que comentas del FW del lector BR:
Entre los ficheros de la nand y de los pup hay alguno que parece ser la actualizacion del FW del BR, pero tambien está encriptado, con lo que no podemos analizarlo (hasta que no se encuentre la clave que permita leerlo y no se puede modificar al menos en la NAND hasta que no encontremos la clave con la que se firman los paquetes. .

Lo que no se es si el BR de la PS3 tiene un chip propio que tenga el FW, y si es así ese FW no podría estar encriptado, por que el lector no es capaz de descifrarlo.

Tema HDD:
Estoy empezando a estudiar la particion gameos del HDD, hace 3 dias que he empezado, así que nada por ahora.
¿Como sabes que el cifrado es AES 256? ¿Hay algún foro en el que se haya sacado esto? ¿lo has sacado tu? ¿Donde puedo encontrar mas info?

En cuanto a las NAND y los PUP (actualizaciones de firmware) se ha avanzado en ese aspecto y al menos de las PUP se sabe su estructura básica y ohh, sorpresa, en esas actualizaciones hay apartados para el fw de BD, Wifi, etc. por lo que se deduce del poco contenido no encriptado.

en cuanto a lo del HDD salvo que haya salido algo nuevo, difiero en que sea un AES. Más bien se habla de un formato propietario de Sony, así como que parece ser que usan un sistema de Ficheros parecido o basado en ReiserFS modificado.
En la propia estructura de los ficheros de actualización hay "signatures" de cada sección para comprobar la integridad de la actualización y esa signature es de 160 bits y no es una SHA1, probablemente usan otro algoritmo de 160 bits (sigo investigando en ello) o también es propietario.

Si, tanto de la NAND como de los PUP se han conseguido listar los ficheros que incluyen, estoy intentando encontrar el foro donde estaba el programa que extrae los pup y no lo encuentro ¿alguien lo tiene localizado? Tambien tenia un listado de los archivos y tamaños que tenia cada una de las versiones del FW.

Comentaba que tanto en la NAND como en el PUP tienen los ficheros encriptados y por ahora no se pueden leer, por eso preguntaba si se sabe si el lector tenia un chip con el FW con el que pudieramos trabajar. Se publicó que se habia extraido ese FW, pero no tengo detalles del avance del tema.

Respecto al HDD, por favor dame los links de los sitios de los que saques esa info por que he empezado a estudiar el HDD he visto las signatures y marcas, y toda la info que haya es poca. Gracias

Si no me equivoco, lo publicaron originalmente en ps3news.

http://www.ps3news.com/forums/downloads.php?do=file&id=3921


Espero que te sirva.

Upps, lo he publicado 2 veces, sorry

Perdón no me he explicado bien, lo que no encuentro es el desempaquetador de los .pup

En la doc del cell he leido:

The software team in the STI (Sony Toshiba IBM)
Design Center has implemented several
cryptographic standards for the SPE including
symmetric key algorithms such as AES (Advanced
Encryption Standard) and DES (Digital Encryption
Standard), hash functions such as SHA-1 (Secure
Hash Algorithm), and asymmetric key services
such as RSA (Rivest-Shamir-Adleman), and DSA
(Digital Signature Algorithm).

O sea que el SPE lo tiene todo, y lo puede usar sin problemas, con lo que no tenemos pistas de que encriptacion puede estar usando.

ps3dev escribió:Si, tanto de la NAND como de los PUP se han conseguido listar los ficheros que incluyen, estoy intentando encontrar el foro donde estaba el programa que extrae los pup y no lo encuentro ¿alguien lo tiene localizado? Tambien tenia un listado de los archivos y tamaños que tenia cada una de las versiones del FW.

El hilo sobre el desempaquetado de los PUP.
http://www.eurasia.nu/modules.php?op=modload&name=Forums&file=viewtopic&topic=3621&forum=87

No te empaches.

Jur...

cnova escribió:en cuanto a lo del HDD salvo que haya salido algo nuevo, difiero en que sea un AES. Más bien se habla de un formato propietario de Sony, así como que parece ser que usan un sistema de Ficheros parecido o basado en ReiserFS modificado.

No me refiero al sistema de archivos, si no al sistema de cifrado. Ahora lo explico.

ps3dev escribió:Estoy empezando a estudiar la particion gameos del HDD, hace 3 dias que he empezado, así que nada por ahora.
¿Como sabes que el cifrado es AES 256? ¿Hay algún foro en el que se haya sacado esto? ¿lo has sacado tu? ¿Donde puedo encontrar mas info?

Bien, te explico lo que se del cifrado. El HDD se cifra con un sistema transparente similar al de programas para PC como por ejemplo el PGP Disk Whole Encryption. Como he dicho es un cifrado trasparente de tal forma que los programas que acceden al disco no tienen que saber nada de él, ellos sólo trabajan con el sistema de archivos, que este lo desconozco, es a lo que se refería cnova con lo del ReiserFS, ese es el sistema de archivos.
Bien, que sé del HDD?
El tamaño de sector es de 512 bytes y el tamaño de cluster de 2Kb (4 sectores)
El cifrado se hace sector a sector.
El bloque de cifrado es de 128 bits. Eso elimina muchos algoritmos de cifrado a utilizar.
Teniendo en cuenta la información disponible sobre Cell y Trusted Computing sobre los algoritmos empleados

ps3dev escribió:The software team in the STI (Sony Toshiba IBM)
Design Center has implemented several
cryptographic standards for the SPE including
symmetric key algorithms such as AES (Advanced
Encryption Standard) and DES (Digital Encryption
Standard), hash functions such as SHA-1 (Secure
Hash Algorithm), and asymmetric key services
such as RSA (Rivest-Shamir-Adleman), and DSA
(Digital Signature Algorithm).

valga como ejemplo ...
y algunas suposiciones basadas en la experiencia de implementación de sistemas criptográficos, casi con total seguridad es AES.
En principio sería entonces un AES 128.
Y en qué modo?
El modo de cifrado más empleado en la actualidad para el cifrado trasparente de discos es el LRW. Podemos suponer que es el empleado? sí, podemos, es sólo una suposición pero como dije en otro post a falta de comprobarlo es la mejor suposición. El modo LRW emplea dos claves, una llamada 'fuerte' y otra 'debil'. Así pues tendríamos dos claves AES de 128 bits que no es lo mismo que una sóla clave AES de 256 bits pero se le parece. Cuando decimos AES 256 en modo LRW realmente nos referimos a dos claves de 128 bits, una forma más correcta sería AES 128+128 pero la primera se sobreentiende.

Un saludo.

Naima, también me refería al algoritmo de cifrado AES cuando comentaba que todo indica que es un algoritmo propietario de Sony. Si revisas la estructura del HDD, encuentras con un patrón rítmico cada 183 y pico Megas, cosa que no tiene mucho sentido si el disco entero está cifrado tal y cómo planteas (cosa que también había pensado). En cualquier caso sea o no AES estándar sabemos que sería bastante complicado acceder a la información del disco desde fuera del propio S.O. de la PS3.

También comentar que es perfectamente posible (de hecho se usa bastante) cifrados de disco con AES 256 CBC y essiv en lugar de AES LRW.

En cuanto al AES, es posible modificarlo en entornos cerrados en los que no se necesita compatibilidad ni seguir ningún estándar, y cito:

El propósito de AES es que sea tomado como un estándar, es decir que la
mayoría de aplicaciones puedan comunicarse de manera segura. En la
actualidad ya una gran variedad de aplicaciones soportan AES y esto permite
una mejor comunicación de manera segura, entre las aplicaciones que ya
soportan AES están SSL, IPsec, WinZip, entre otras y en muchas otras se
planea soportarlo próximamente como en la nueva generación de GSM, etc.
Sin embargo es posible dada su construcción implementar AES de una
manera propia, esto con el objeto de tener un algoritmo dedicado a cierta
aplicación y aprovechar su diseño. Por ejemplo en sistemas cerrados que no
necesitan ser compatibles con el exterior pueden modificar AES o cambiar
algunos parámetros y obtener un nuevo algoritmo tan seguro como AES.
Las primeras ideas son muy simples, como FIPS 197 donde se describe AES
determina que tipo de parámetros se deben de usar para la denominación
AES. Por lo tanto el cambio o modificación de alguno de ellos en principio
nos dará una nueva versión de AES, estos cambios debe hacerse de manera
muy cuidadosa para no perder las principales características de seguridad
que tiene AES. Obviamente uno esperaría con estos cambios al menos tener
las mismas características del original AES, o eventualmente alguna mejora.

· La primera idea es modificar la longitud del bloque de cifrado o la
longitud de la clave, la longitud de la clave puede ser reducida por
razones de seguridad hasta 80 bits, por razón de diseño del algoritmo
lo más simple es tomar en lugar de 4 columnas, solo 3, es decir tomar
una longitud de 96 bits.
· También cambiar el número de rondas, sabemos que AES es seguro
con al menos 8 rondas.
· Otra sugerencia simple es cambiar el orden de las aplicaciones hechas
en el proceso AES, es decir el lugar de aplicar la secuencia ByteSub,
ShiftRow, MixColumn, AddRoundKey, cambiarla por ejemplo por
ByteSub, MixColumn, ShiftRow, AddRoundKey. Hasta lo que se, esto
no alteraría de alguna forma la seguridad de AES, solo cambiaría la
salida.
Un estudio más completo lo dieron E. Barkan, y E. Biham [52] al mostrar que
si cambiamos todas las constantes involucradas en el algoritmo AES no
tendremos alteración importante alguna, esto da una gran posibilidad de
elecciones. La razón principal para poder obtener estas modificaciones se
debe a que la función cuadrado es lineal en el campo finito GF(28) .
Para explicar esto con detalle damos las siguientes definiciones:

Def 1: Dos algoritmos y son "Duales" si son isomorfos, es decir,
si existen funciones invertibles , y tales que:
p ara cualquier plaintext y clave , K g K
E E
f g h
P K f E P = E h P .
Particularmente si f,g,h son la función cuadrado entonces podemos mostrar
que los algoritmos E, E2 son duales, es decir son equivalentes,
particularmente 2
2 ( 2) ( ( ))2 K K E P = E P es decir que si usamos AES con los
plaintext (que son elementos de un campo finito) al cuadrado, con la clave K
al cuadrado y aplicamos E2 (definición en detalle posterior), entonces el
resultado sería el mismo al usar el original AES y elevar la salida al cuadrado.
E2 significa cambiar todas las constantes de E, deben de elevarse al
cuadrado como elementos del campo finito GF(28) . Las variables
involucradas en AES son:
1) En ByteSub la matriz y la constante de la aplicación lineal.
©Copyright 2005 80
Para la transformación afín Ax+b la debemos cambiar por
QAQ-1x + b2.
2) En MixColumn el polinomio a ser multiplicado.
En MixColumn el polinomio 03x3+01x2+01x+02 debe ser cambiado
por 05x3+01x2+01x+04 , en el proceso de descifrado el polinomio
0bx3+0dx2+09x+0e se cambian por 0dx3+0bx2+0ex+09 .
3) En el programa de claves, las constantes Rcon.
Las constantes de Rcon(02)i-1 por las constantes (03)i-1 .
4) El polinomio irreducible para construir el campoGF(28) .
El polinomio irreducible puede ser cambiado por alguno de los 30 que
existen y que están listados en los antecedentes matemáticos.
Con los anteriores cambios se pueden lograr en principio 240 diferentes
formas de AES.
Considerando los diferentes polinomios del campoGF(28) y sus diferentes
subcampos podemos tener hasta 1170 representaciones diferentes de AES.
Posteriormente Biryukov, De Cannière, Braeken, y Preneel [79],
generalizaron estos cifradores isomorfos hasta 61200, encontrando algunos
equivalentes a las S-cajas Esta técnica también puede ser aplicada a otros
algoritmos importantes como Camellia, Misty, y Kasumi.
Aunque es buena la idea de usar para un caso especial una diferente manera
de AES, su aplicación más importante se ha dado en el criptoanálisis, se cree
que con el número tan importante de diferentes maneras de reescribir el
algoritmo, quizá en alguna de ellas se pueda derivar un ataque eficiente que
después se traslade al original AES. Otra aplicación es poder evitar ataques
como el análisis de potencial.

Como posiblemente en la cita se pierda parte de la información de las fórmulas si te interesa te puedo pasar el enlace.

Teniendo en cuenta todo el I+D que hay detras de todo esto, dudo (puedo equivocarme) que se use un sistema criptografico ya "conocido". Me inclino mas a pensar que es un S.C propietario de Sony y diseñado especialmente para el cell.

Pensar que de hecho, es lo que se va a vender "industrialmente" (en cuanto a los cells) clusters,blalbabllbalalbaa y tiene bastante logica que sea de ese modo (para ofrecer mayor robustez y menor informacion a posibles ataques)

cnova escribió:Naima, también me refería al algoritmo de cifrado AES cuando comentaba que todo indica que es un algoritmo propietario de Sony. Si revisas la estructura del HDD, encuentras con un patrón rítmico cada 183 y pico Megas, cosa que no tiene mucho sentido si el disco entero está cifrado tal y cómo planteas (cosa que también había pensado). En cualquier caso sea o no AES estándar sabemos que sería bastante complicado acceder a la información del disco desde fuera del propio S.O. de la PS3.

También comentar que es perfectamente posible (de hecho se usa bastante) cifrados de disco con AES 256 CBC y essiv en lugar de AES LRW.

En cuanto al AES, es posible modificarlo en entornos cerrados en los que no se necesita compatibilidad ni seguir ningún estándar, y cito:



Como posiblemente en la cita se pierda parte de la información de las fórmulas si te interesa te puedo pasar el enlace.

Teniendo en cuenta todo el I+D que hay detras de todo esto, dudo (puedo equivocarme) que se use un sistema criptografico ya "conocido". Me inclino mas a pensar que es un S.C propietario de Sony y diseñado especialmente para el cell.

Pensar que de hecho, es lo que se va a vender "industrialmente" (en cuanto a los cells) clusters,blalbabllbalalbaa y tiene bastante logica que sea de ese modo (para ofrecer mayor robustez y menor informacion a posibles ataques)

Jur...

Primero, es facil pensar en algoritmos propietarios. Cuando has dedicado años a esto tienes claro que no. Los algoritmos propietarios 'secretos' no funcionan. Tenemos dos filosofías opuestas que chocan, se entrecuzan y coinciden entre sí: La filosofía militar y la de la comunidad científica.
Desarrollar y mantener un algoritmo en secreto ha sido hasta hace poco la piedra angular de la filosofía militar con respecto a la criptografía. Esta postura tenía sentido en un universo pre-criptografía moderna.
La postura de la comunidad científica (no militar) es completamente inversa, la criptografía moderna no se basa en el secreto del algoritmo si no en el secreto de las claves. Si estamos seguros de que nuestro algoritmo no tiene fallos no existe motivo alguno para que no sea ampliamente conocido puesto que su seguridad no se basa en el algoritmo en sí, está basada en la imposibilidad de obtener la clave que descifre el mensaje. La experiencia histórica va aún más allá, la única forma veraz de comprobar la seguridad de un sistema criptográfico es 'parirlo' al mundo. Es decir, ofrecerlo a todos los millones de humanos que habitamos este planeta, le encontráis algún error?
Es DES un algoritmo seguro? Sí, porque a lo largo de las decenas de años de su vida todos los esfuerzos de la comunidad mundial para encontrar un error en él han sido en vano. Hoy en día DES en su implementación basica no es seguro, pero no porque tenga algún fallo si no sólo porque su longitud de clave es demasiado pequeña para resistir un ataque por fuerza bruta. La variante 3DES sigue siendo segura, más aún que un AES 128, por la sencilla razón de que contra DES se ha probado todo y todo lo ha resisitido incluidos muchos ataques que sí han funcionado contra otros algoritmos.
Hoy en día desarrollar un algoritmo entre un reducido grupo de matemáticos y confiar en su acierto para su seguridad es un gravísimo error puesto que en cualquier parte del mundo puede haber alguien que pueda dar con el método para romperlo.
Me gustaría relatar el ejemplo de los algoritmos de cifrado empleados por el sistema de telefonía GSM. Estos se mantuvieron en secreto hasta que por ingeniería inversa se dedujo su funcionamiento, en menos de un mes Rivest Shamir (uno de los inventores del RSA) logró romperlos. Eso no hubiese pasado con algoritmos publicados puesto que sí, se hubiesen roto pero al saber de su rotura hubiesen podido mejorarlos o directamente enviarlos a la basura y crear otros.
Hoy en día, y hasta los organismos militares y gubernamentales lo saben, es un error muy grave de seguridad emplear algoritmos de cifrado no testados por la comunidad científica mundial.

Segundo, estudios sobre el HDD.
Hace meses me hice con varios volcados del disco de varias PS3 para su estudio. Lo primero que observé es que en el disco duro los sectores se cifran según se escribe en ellos. Esto es, en una PS3 virgen su disco duro sigue conteniendo sectores de ceros tal y como venían de fábrica. Si formateamos el disco duro 'en lento' se cifrarán todos los sectores. El disco duro de la PS3 siempre se cifra de la misma manera en la misma consola. Y es fácil ver como los sectores que antes eran ceros ahora están cifrados y todos de la misma manera, son esa gran cantidad de sectores que se repiten. El tamaño del sector está claro, 512 bytes. El tamaño del cluster se deduce también por los sectores a cero de relleno, son 2Kbytes. Esto es, observamos sectores cifrados por ejemplo 1 ó 2 y a continuación hasta completar 4 sectores los sectores de ceros. En el disco duro virgen los vemos a 0 y en el cifrado vemos los mismos sectores que se repiten que hemos identificado como ceros cifrados.
Que el cifrado se realiza sector a sector es obvio. El tamaño del bloque de cifrado lo descubrimos al encontrar sectores que si bien no son identicos al sector que hemos identificado como ceros cifrados, sus primeros 16 bytes (128 bits) son idénticos. Esto quiere decir dos cosas, la primera que ese sector comienza por al menos 16 ceros, la segunda que el bloque de cifrado es un múltiplo de 128 bits. El resto son conjeturas basadas en la lógica y la experiencia.
Eliminados todos los algoritmos que no coinciden con las longitudes de bloque de cifrado que tenemos y basandonos en los algoritmos empleados comunmente por su seguridad contrastada, los utilizados en los modelos presentados por el TGC, anteriores empleos de agoritmos por parte de Sony, algoritmos empleados por soluciones de cifrado de disco similar y no menos importante estudios sobre la entropía de los sectores cifrados casi con seguridad llego a la concusión de que es AES. Todos los que lo estuvimos estudiando llegamos a la misma conclusión.
No me voy a enrrollar más, tenemos 128 bits de bloque y de clave con mucha seguridad. Lo que queda por saber es el metodo de cifrado, si fuese en CBC por ejemplo tendríamos un AES 128 y con LRW un AES 128+128. Conjeturo el modo LRW por ser el más adecuado y empleado actualmente aunque no tengo certeza de su empleo, es lo único en lo que tengo dudas.

Una última cosa, como bien a dicho cnova, AES es muy configurable pero determinadas configuraciones que no han sido ampliamente probadas podrían presentar una debilidad. Io supongo que los chicos de Sony e IBM no son tontos y no se van a arriesgar, si una implementación concreta ha sido probada y tiene seguridad contrastada por qué arriesgarse con otra?
En resumen, no pensemos que en Sony e IBM son idiotas porque no lo son, fallos cometemos todos sin intención de cometerlos, pero arriesgarse a cometerlos es de ser poco inteligente ... Io sí creo que son inteligentes, y de hecho, por lo que sé hasta ahora del sistema de seguridad de la PS3 han hecho lo mismo que io hubiese hecho.

Un saludo.

Se que no viene mucho al tema de ahora mismo la criptografia, y luego matarme si kereis. Pero se me ha ocurrido una idea, ha salido un parche para transformar los mods de pc a ps3 del unreal 3, si se estudia eso no se podria ver como trasforman los archivos para que los reconozca la ps3???
O intentar crear un especie de mod con errores para ver si se le puede meter mano por ahi???

Enlace a la noticia ps3news aki

PD: No tengo ni idea de criptografia, linux y esas cosas, asike si me matais ke sea rapido please

naima escribió:Jur...

Primero, es facil pensar en algoritmos propietarios. Cuando has dedicado años a esto tienes claro que no. Los algoritmos propietarios 'secretos' no funcionan. Tenemos dos filosofías opuestas que chocan, se entrecuzan y coinciden entre sí: La filosofía militar y la de la comunidad científica.
Desarrollar y mantener un algoritmo en secreto ha sido hasta hace poco la piedra angular de la filosofía militar con respecto a la criptografía. Esta postura tenía sentido en un universo pre-criptografía moderna.
La postura de la comunidad científica (no militar) es completamente inversa, la criptografía moderna no se basa en el secreto del algoritmo si no en el secreto de las claves. Si estamos seguros de que nuestro algoritmo no tiene fallos no existe motivo alguno para que no sea ampliamente conocido puesto que su seguridad no se basa en el algoritmo en sí, está basada en la imposibilidad de obtener la clave que descifre el mensaje. La experiencia histórica va aún más allá, la única forma veraz de comprobar la seguridad de un sistema criptográfico es 'parirlo' al mundo. Es decir, ofrecerlo a todos los millones de humanos que habitamos este planeta, le encontráis algún error?
Es DES un algoritmo seguro? Sí, porque a lo largo de las decenas de años de su vida todos los esfuerzos de la comunidad mundial para encontrar un error en él han sido en vano. Hoy en día DES en su implementación basica no es seguro, pero no porque tenga algún fallo si no sólo porque su longitud de clave es demasiado pequeña para resistir un ataque por fuerza bruta. La variante 3DES sigue siendo segura, más aún que un AES 128, por la sencilla razón de que contra DES se ha probado todo y todo lo ha resisitido incluidos muchos ataques que sí han funcionado contra otros algoritmos.
Hoy en día desarrollar un algoritmo entre un reducido grupo de matemáticos y confiar en su acierto para su seguridad es un gravísimo error puesto que en cualquier parte del mundo puede haber alguien que pueda dar con el método para romperlo.
Me gustaría relatar el ejemplo de los algoritmos de cifrado empleados por el sistema de telefonía GSM. Estos se mantuvieron en secreto hasta que por ingeniería inversa se dedujo su funcionamiento, en menos de un mes Rivest Shamir (uno de los inventores del RSA) logró romperlos. Eso no hubiese pasado con algoritmos publicados puesto que sí, se hubiesen roto pero al saber de su rotura hubiesen podido mejorarlos o directamente enviarlos a la basura y crear otros.
Hoy en día, y hasta los organismos militares y gubernamentales lo saben, es un error muy grave de seguridad emplear algoritmos de cifrado no testados por la comunidad científica mundial.

Segundo, estudios sobre el HDD.
Hace meses me hice con varios volcados del disco de varias PS3 para su estudio. Lo primero que observé es que en el disco duro los sectores se cifran según se escribe en ellos. Esto es, en una PS3 virgen su disco duro sigue conteniendo sectores de ceros tal y como venían de fábrica. Si formateamos el disco duro 'en lento' se cifrarán todos los sectores. El disco duro de la PS3 siempre se cifra de la misma manera en la misma consola. Y es fácil ver como los sectores que antes eran ceros ahora están cifrados y todos de la misma manera, son esa gran cantidad de sectores que se repiten. El tamaño del sector está claro, 512 bytes. El tamaño del cluster se deduce también por los sectores a cero de relleno, son 2Kbytes. Esto es, observamos sectores cifrados por ejemplo 1 ó 2 y a continuación hasta completar 4 sectores los sectores de ceros. En el disco duro virgen los vemos a 0 y en el cifrado vemos los mismos sectores que se repiten que hemos identificado como ceros cifrados.
Que el cifrado se realiza sector a sector es obvio. El tamaño del bloque de cifrado lo descubrimos al encontrar sectores que si bien no son identicos al sector que hemos identificado como ceros cifrados, sus primeros 16 bytes (128 bits) son idénticos. Esto quiere decir dos cosas, la primera que ese sector comienza por al menos 16 ceros, la segunda que el bloque de cifrado es un múltiplo de 128 bits. El resto son conjeturas basadas en la lógica y la experiencia.
Eliminados todos los algoritmos que no coinciden con las longitudes de bloque de cifrado que tenemos y basandonos en los algoritmos empleados comunmente por su seguridad contrastada, los utilizados en los modelos presentados por el TGC, anteriores empleos de agoritmos por parte de Sony, algoritmos empleados por soluciones de cifrado de disco similar y no menos importante estudios sobre la entropía de los sectores cifrados casi con seguridad llego a la concusión de que es AES. Todos los que lo estuvimos estudiando llegamos a la misma conclusión.
No me voy a enrrollar más, tenemos 128 bits de bloque y de clave con mucha seguridad. Lo que queda por saber es el metodo de cifrado, si fuese en CBC por ejemplo tendríamos un AES 128 y con LRW un AES 128+128. Conjeturo el modo LRW por ser el más adecuado y empleado actualmente aunque no tengo certeza de su empleo, es lo único en lo que tengo dudas.

Una última cosa, como bien a dicho cnova, AES es muy configurable pero determinadas configuraciones que no han sido ampliamente probadas podrían presentar una debilidad. Io supongo que los chicos de Sony e IBM no son tontos y no se van a arriesgar, si una implementación concreta ha sido probada y tiene seguridad contrastada por qué arriesgarse con otra?
En resumen, no pensemos que en Sony e IBM son idiotas porque no lo son, fallos cometemos todos sin intención de cometerlos, pero arriesgarse a cometerlos es de ser poco inteligente ... Io sí creo que son inteligentes, y de hecho, por lo que sé hasta ahora del sistema de seguridad de la PS3 han hecho lo mismo que io hubiese hecho.

Un saludo.

@naima y cnova: Moooola leer cosas de gente con tantos conocimientos y experiencia. Habeis resuelto mis dudas y habeis contado las cosas que pretendia investigar en el HDD.

Ahora sabiendo todo esto, ¿como veis la posibilidad de hacer un programa para el linux de la PS3 que nos permita por ejemplo leer por dentro los archivos contenidos dentro de los pup (esos archivos agrupan todo el conocimiento necesario)

Otra idea que me ronda la cabeza es usar el mismo sistema que ha usado IronPeter para encontrar algún acceso al HDD desde linux. En su post explica como ha encontrado el acceso a la rsx, de la misma manera puede investigar un camino no documentado al HDD. ¿sabeis si ya se ha hecho?

Kaicos escribió:Se que no viene mucho al tema de ahora mismo la criptografia, y luego matarme si kereis. Pero se me ha ocurrido una idea, ha salido un parche para transformar los mods de pc a ps3 del unreal 3, si se estudia eso no se podria ver como trasforman los archivos para que los reconozca la ps3???
O intentar crear un especie de mod con errores para ver si se le puede meter mano por ahi???

Enlace a la noticia ps3news aki

PD: No tengo ni idea de criptografia, linux y esas cosas, asike si me matais ke sea rapido please

Jejeje esa es la coña pq si se tranforma de PC a PS3 kiere decir k el programilla firma el archivo no? Aunk pensandolo bien ni lo firmara total no es ejecutable ;_; sera como quien le mete una foto a un juego (ejemplo Burnout paradise)

^^U desde luego escribo cada cosa...

ps3dev escribió:
Ahora sabiendo todo esto, ¿como veis la posibilidad de hacer un programa para el linux de la PS3 que nos permita por ejemplo leer por dentro los archivos contenidos dentro de los pup (esos archivos agrupan todo el conocimiento necesario)

Para leer dentro de los PUP sólo se necesita la utilidad que está publicada, a partir de ahí se regeneran los contenidos de la misma como archivos, y esos archivos se pueden visualizar con cualquier editor hexadecimal. Si lo que quieres es analizar o buscar algo concreto se puede hablar. En cuanto a lo de crear la app en Linux no es problema, lo que habría que definir es qué queremos que haga esa app.

ps3dev escribió:Otra idea que me ronda la cabeza es usar el mismo sistema que ha usado IronPeter para encontrar algún acceso al HDD desde linux. En su post explica como ha encontrado el acceso a la rsx, de la misma manera puede investigar un camino no documentado al HDD. ¿sabeis si ya se ha hecho?

Facilítame el enlace al post original de IronPeter para estudiarlo. En cuanto a si se ha encontrado algo tipo RSX pero para el HDD, creo que no se ha conseguido. Para el hypervisor es fácil controlar esos accesos. Sobre el HDD encriptado al no tener un sistema de ficheros en claro ni una tabla de particiones visible y conocida no podemos ver cómo se ubican las particiones de Linux, pero parece ser que si se buscan por el HDD aparece su estructura a partir de unos offsets determinados y estas particiones ó archivos para el XMB, no están cifradas, por lo que sigo insistiendo en que el cifrado del HDD no se aplica en bloque de forma masiva a todos los sectores del disco, sino que se hace de una forma selectiva que desconocemos, esto no quiere decir que Naima no esté en lo cierto al suponer el tipo de algoritmo de cifrado. Sólo quería exponer que es difícil de saber con los datos que tenemos. Otra cosa que complica el estudio del HDD y de la NAND es la "individualización" que sufren en cada PS3.

Es decir cada disco duro que se "formatea" en la PS3 tiene una estructura única y diferente entre sí (así previenen que alguien que se haya descargado juegos de la Store en su disco pueda llevarse ese disco a otra PS3 y poder jugar con ellos). También está documentado que cada firmware instalado es único en cada PS3. Es decir cuando actualizamos, aparte de comprobar la validez de la actualización se realiza un proceso de cifrado único para nuestra PS3 de esos datos de actualización.

Eso explica por qué con el Infectus únicamente se puede downgradear una versión de fw que previamente hayamos copiado y sólo para nuestra PS3.

Resumiendo, @ps3dev, lo de la app en Linux sin problemas, pero primero dime qué queremos hacer con la app, qué queremos buscar, etc.

Aprovecho el post para mostrar mi acuerdo con @Naima en la exposición que hace sobre los algoritmos de encriptación, es cierto que desde hace un tiempo, se persigue la aproximación científica de que el algoritmo sea conocido en contraposición con la técnica de esconder los detalles de la implementación. De hecho también estoy de acuerdo en que este paradigma se aplicase al software en general, (queda claro que me gusta más el modelo Open Source que el privativo )

Naima escribió:El disco duro de la PS3 siempre se cifra de la misma manera en la misma consola. Y es fácil ver como los sectores que antes eran ceros ahora están cifrados y todos de la misma manera, son esa gran cantidad de sectores que se repiten. El tamaño del sector está claro, 512 bytes. El tamaño del cluster se deduce también por los sectores a cero de relleno, son 2Kbytes. Esto es, observamos sectores cifrados por ejemplo 1 ó 2 y a continuación hasta completar 4 sectores los sectores de ceros. En el disco duro virgen los vemos a 0 y en el cifrado vemos los mismos sectores que se repiten que hemos identificado como ceros cifrados.
Que el cifrado se realiza sector a sector es obvio. El tamaño del bloque de cifrado lo descubrimos al encontrar sectores que si bien no son identicos al sector que hemos identificado como ceros cifrados, sus primeros 16 bytes (128 bits) son idénticos. Esto quiere decir dos cosas, la primera que ese sector comienza por al menos 16 ceros, la segunda que el bloque de cifrado es un múltiplo de 128 bits. El resto son conjeturas basadas en la lógica y la experiencia.

Solo apuntar que los mismos sectores que se repiten cíclicamente no es debido a que sean 0 puesto que para un mismo valor origen no obtienes siempre un mismo valor cifrado. Esto es lo primero que se busca, evitar la linealidad en los datos cifrados, y se consigue en AES en la etapa de substitución de bits. Además es sospechoso que el patrón se repita a partir de un offset determinado y cada x megas haya 64Kb de datos exactos con el mismo valor.

Por qué se está centrando la investigación en cómo está cifrado el disco duro?. Yo creo las siguientes cosas:

- Hay juegos que no se instalan en el disco duro. ¿Está también el BluRay encriptado de la misma manera? No, porque un mismo BluRay funciona en todas las PS3. Si está cifrado, lo estará de una forma conocida para todas las PS3.

- Suponiendo que un BluRay no esté codificado o se pueda conocer su cifrado, sería viable entonces saber cómo funciona los distintos ficheros que componen un juego y hacer otros alternativos que sean capaces de leer desde otro sistema de almacenamiento (un disco duro USB por ejemplo). Esto nos evitaría tener que conocer cómo la PS3 cifra su disco duro interno. Os acordaís de cómo se creaban las ISOs de juegos de PSX en la PSP mediante el juego de Golf? Pues la idea es algo similar a esto.

- El algoritmo de descifrado no puede ser muy complicado, dado que eso es trabajo a realizar a la hora de leerlo, y leer un juego constantemente del disco duro y descifrarlo, para mi, es un costo demasiado grande.

- Lo más importante: estoy hablando dentro de mi gran ignorancia del tema[oki]

Saludos.

Dartanyan escribió:- El algoritmo de descifrado no puede ser muy complicado, dado que eso es trabajo a realizar a la hora de leerlo, y leer un juego constantemente del disco duro y descifrarlo, para mi, es un costo demasiado grande.

- Lo más importante: estoy hablando dentro de mi gran ignorancia del tema[oki]

Saludos.

Te corrijo sobre este punto. Te puedo asegurar que el coste en tiempo de procesamiento del cifrado/descifrado es despreciable. Te lo digo desde la experiencia de participar en el desarrollo e implementación de varias capas de cifrado/descifrado tanto a nivel de bloques en disco duro como de un cifrado adicional para ficheros en base a AES para el cifrado simétrico y RSA para la protección de las claves del cifrado AES. Esto trabajando sobre arquitecturas x86, ni te cuento en qué queda la cosa si además tenemos funciones especializadas y optimizadas para correr en un SPE del que tenemos 7 disponibles en la PS3 bajo su sistema y sin contar con los 2 hilos simultáneos que puede manejar el PPC incluido.

En cuanto al tema de los BlueRays y que sean idénticos entre sí, pero eso no soluciona el cómo replicar su funcionamiento bien sea desde disco duro o desde otro medio blueray. En cuanto al firm del la unidad BD la actualizan via las actualizaciones genéricas de firmware, suponiendo que tengan un fw propio alojado en la unidad, nada impide que en las NAND se almacene algún tipo de verificación de fw de la unidad y que imposibilitase su funcionamiento si no coincide.

Voy ha hacer un par de preguntas para entender un poco más esto.

1: Dos discos originales del mismo juego son identicos?

2 ¿Por qué al leer el juego con otro lector blue-ray, o con el mismo lector de la ps3 pero en linux, no obtenemos los mismos datos que realmente hay grabados en el disco original? ¿esque hay sectores ocultos? ¿esque el lector de ps3 es diferente al reto?

3 ¿Los modbios de la ps2 engañan a algo mas que al stock del lector para decirle que tiene un disco original? ¿Como se distingue un disco original? ¿Como funciona la firma digital de manera que al copiar un fichero no se copie la firma también?

Acepto también links, jeje.

@cnova
Es verdad, los archivos extraidos del pup parecen no estar cifrados, y si lo están no lo están en su totalidad. ¿no ha trabajado nadie con ellos para obetener cosas por ingeniería inversa? ¿hay algo que impida este tipo de 'ataque?

Has demostrado que sabes mas que yo de sistemas de cifrado/descifrado, jejeje, yo puedo aportar en otras cosas técnicas

Así que la posibilidad de que yo diga algo que a ti no se haya ocurrido es muy baja, con lo que te devuelvo la pregunta, no hay alguna forma en que podamos atacarla? aunque sea remota

Habria alguna forma de intentar conseguir la clave de al menos una PS3?

Alguien sabe lo que ha intentado c4eva y como le va?

Link de IronPeter:
http://forums.ps2dev.org/viewtopic.php?t=8364

Otro link de ataque a la criptografía (hablan de ataques por HW y explican algunos):
http://forums.ps2dev.org/viewtopic.php?t=9546

Jur...

cnova escribió:Solo apuntar que los mismos sectores que se repiten cíclicamente no es debido a que sean 0 puesto que para un mismo valor origen no obtienes siempre un mismo valor cifrado. Esto es lo primero que se busca, evitar la linealidad en los datos cifrados, y se consigue en AES en la etapa de substitución de bits. Además es sospechoso que el patrón se repita a partir de un offset determinado y cada x megas haya 64Kb de datos exactos con el mismo valor.

No.
Primero, vuelvo a repetir, los datos se cifran sector a sector.
Esto es: Tomamos un sector de 512 bytes y lo ciframos con la clave.
Tomamos el siguiente sector y lo volvemos a cifrar con la misma clave, para que quede claro, al cifrar un nuevo sector lo hacemos sin tener en cuenta sectores anteriores, inicializamos todo. Esto es lo que significa cifrar sector a sector.
Segundo, en AES y en cualquier otro algoritmo de cifrado, un mensaje M de longitud N cifrado con la clave K siempre resultará en el mismo mensaje cifrado C. Es decir, ciframos mil veces el mismo mensaje con la misma clave y obtenemos el mismo mensaje cifrado.
Conclusión, puesto que la clave de cifrado empleada para cifrar el HDD es siempre la misma en una PS3 única y determinada, y que ciframos sector a sector: Todos los sectores iguales se cifrarán siempre de la misma manera. Si quisiesemos que dos mensajes iguales con la misma clave se difraran de diferente manera deberíamos añadir al cifrado un vector que posteriormente pudiesemos predecir a la hora de descifrar, como por ejemplo los IVs del cifrado wireless WEP. La función del vector es combinarse con la clave para obtener una nueva clave diferente, con esta última ciframos. Si todos los vectores varían en cada cifrado obtendríamos textos cifrados diferentes para un mismo texto en claro porque en realidad los estamos cifrando con claves diferentes. El único problema de este método es que estamos añadiendo caos al sistema, caos que si no podemos reproducir (no podemos obtener los vectores) se nos imposibiliza el descifrado. Los vectores o los generas mediante una función conocida con variables conocidas o los transmites junto con el mensaje.

(nota para cnova: La función ByteSub de AES es una sustitución no lineal. Esta se aplica byte a byte a la matriz de estado mediante una S-box 8x8 invertible. La S-box se obtiene a partir de la composición de dos transformaciones, pero eso es más largo de explicar)

Un saludo.

Cuanta cocaina.....


es broma sabeis un huevo de criptografia. Yo solo di una asignatura de libre configuracion xDDD

no me entero ni papa...jajaja

El trabajo me impide contestar mas durante la semana y espero al fin de semana para hacerlo largo y extenso.

Aparte de eso, creo que la informacion que se esta aportando en este hilo, es lo suficientemente interesante (a todos los niveles) como para que se ponga como "destacado" o como se le llame ahi arriba para que no se pierda.

Hace tiempo (como sabeis) le di vueltas a la idea de conectar "en red" dos PS3.

La idea, es ver si teniendo una de ellas en modo GameOS podemos conectarnos a la otra (en modo linux - server - ) para leer contenido.

Cada ps3 se cifra diferente. Si una ps3 accediera a otra ps3, la cifraria como ella misma y la otra no la podria leer? mmmmmmmmmm.

Y luego.. una paranoia que conteste por MP a modo de broma pero... cuantas PS3 en cluster harian falta para reventar un AES, en un tiempo "factible".

Nunca he sido partidario de la Fuerza Bruta pero.. hoy en el curro, hablando en broma... habeis pensado que potencia de calculo tienen 100 ps3 en cluster?

la cuestión es.... ¿de donde vas a sacar 100 ps3? la verdad seria una burrada y el tiempo se reduciría bastante, la cuestión es que todavía no se provó a conectar en red 2 ps3 con esto requisitos...
no creo que sea tan dificil (bueno solo un amgo con otra ps3) coger las 2 y ponerse unas horas a provar

Conectandolos en red.

Para simplificar (y aunque no es lo mismo) imaginate la idea funcional del P2P (rollo azureus,bittorrent) pero para calculo computacional con la PS3.

Jur...

Una cosa que me gustaría añadir.
Supongamos que tenemos el siguiente mensaje:

Dónde está Pepe, me gustaría hablar con Pepe, estás ahí Pepe?

El mensaje lo enviamos cifrado mediante AES con una determinada clave, el resultado podría ser el siguiente (es sólo un ejemplo)

shT6Ujhsp(7gdgFdw6KJ*gt6TyhdgrFbdhj&gdVF65(=hrvboPa2sn63sHiOy

Nos damos cuenta rápidamente de que la palabra 'Pepe' se ha cifrado de manera diferente en cada aparición, a esto es a lo que se refería cnova. Pero 'Pepe' no es el mensaje, el mensaje es toda la frase.
Qué pasaría si Pepe no nos contesta y volvemos a cifrar y reenviar el mensaje, con la misma clave? El mensaje cifrado que enviemos sería el mismo.

AES en un cifrador muy versatil, se puede configurar de varias maneras e incluso puede funcionar como cifrador por bloques o de flujo, pero para el caso que nos ocupa explicaré muy por encima el cifrado por bloques.
Imaginemos un cifrador por bloques que trabaja con bloques de 128 bits. Tenemos un espacio M que contiene todos los mensajes posibles. La clave será también de 128 bits. Tenemos un espacio K que contiene todas las claves posibles. Y por último un espacio C con todos los mensajes cifrados posibles. Dado un mensaje M(i) y una clave K(i) determinadas aplicamos la función F(mi,ki) que nos devuelve un texto cifrado C(i). La función de cifrado F() es una función biyectiva que a un elemento de M le hace corresponder un único elemento de C dependiendo del valor que tome un elemento de K. Más claro todavía, notese además que he simplificado la notación matemática para que todo el mundo lo entienda.
Tenemos 2^128 mensajes posibles. Elegimos una clave de entre las 2^128 posibles. Dada esa clave determinada, la función de cifrado hará corresponder cada uno de los 2^128 mensajes en claro posibles con uno y sólo uno de los 2^128 mensajes cifrados posibles. No podría ser de otra forma porque si a cada mensaje en claro le correspondiesen supongamos 2 mensajes cifrados nos faltaría espacio, puesto que sólo tendríamos un espacio real de 2^64 mensajes cifrados cuando mensajes en claro tenemos 2^128.
Queda claro?
Bien, ahora tenemos un mensaje muy largo. Como nosotros sólo ciframos 128 bits lo dividimos en bloques de 128 bits. Ciframos el primer bloque, después el segundo ... así hasta que acabemos.
Pero que pasaría si se volviese a repetir un bloque en el mensaje?
Pues que se cifraría de la misma manera y eso no lo podemos permitir. Aquí es donde entran en juego los modos de cifrado por bloques. Modos hay varios, no me voy a extender, pero básicamente lo que hacen es hacer depender el cifrado de un bloque del resto del mensaje. Así por ejemplo podemos combinar el resultado del bloque anterior con la clave para obtener una nueva clave con la que cifrar el bloque actual y el bloque actual dependería de la clave y del contenido del bloque anterior.
Supongamos que tenemos un mensaje cuya longitud son 8 bloques:
a, b, c, d, e, f, g, h
y otro mensaje cuyos bloques son:
a, b, c, t, m, f, c, w
Al cifrar los dos mensajes los 3 primeros bloques (a, b, c) serían idénticos pero el resto del mensaje variaría totalmente. En el segundo mensaje el bloque f se cifraría diferente al primero porque su bloque anterior es m (y no e) que este a su vez tenía antes un bloque t (y no d) ... De la misma forma, el segundo bloque c sería diferente del primero.
Queda claro? (vosotros preguntad)

Bien, hemos terminado. Empezamos a cifrar otro mensaje de longitud la que sea, pongamos n. Todo vuelve a empezar, partimos de la clave que suministramos y del primer bloque del nuevo mensaje. Por eso, si repetimos mensaje y clave el resultado es el mismo. A no ser que añadiesemos al sistema un vector de inicialización para cada mensaje cifrado (lo que expliqué en el post anterior), para que nos entendamos, que añadiesemos un contador, cronómetro o número extraido de una serie cada vez que nos piden cifrar un mensaje. Dicho vector lo mezclamos con la clave, con lo cual realmente aunque suministremos la misma clave y el mismo mensaje el mensaje no se cifraría con la misma clave inicial. El problema es que para descifrar deberíamos 'adivinar' que vector se empleó para ese mensaje en concreto, además de conocer la clave. El ejemplo de sistema de cifrado que emplea vectores de inicialización lo puse antes, el cifrado WEP empleado en redes wireless.

Tema PS3.
PS3 no emplea vectores en el cifrado del HDD. Se cifra sector (512 bytes) a sector. Esto es, el mensaje a cifrar es siempre un sector. Queremos cifrar otro sector? bien, pues volvemos a empezar, es decir, mensaje nuevo. Por lo tanto TODOS los sectores iguales se cifran de la misma manera.
Los sectores que se repitan pueden ser muchos, cualquiera que sea identico a otro se repetirá, el más común será el sector vacio (todo ceros). Este como expliqué antes es fácil de identificar porque se ubican en la misma posición en la que antes teníamos sectores de ceros. Quiero recordar que el disco duro viene de fábrica completamente a cero y Sony hace un formato rápido de estos cuando los instala. Sólo se cifran los sectores que se escriben en ese proceso y el resto (la gran mayoría) quedan a 0 sin cifrar. Si reformateamos el disco duro mediante un formateo 'lento' se cifran todos los sectores. Volvemos a leer el contenido del disco y donde antes teníamos sectores vacios ahora en la misma posición tenemos sectores idénticos entre sí pero cifrados. Esos sectores cifrados de esa única forma son ceros. Repito, hay más sectores que se repiten?
Sí, pero de los únicos que puedo conocer su texto en claro son los de ceros.

Espero que haya aclarado las dudas de todos y de cnova en particular.

Un saludo.

Madre del amor hermoso....me mantengo expectante, comento lo justo, pero es que leo cada cosa, que me quedo vamos...flipando es poco.

Es conmovedor ver como hay gente que entiende tanto de criptografía. Estudié un poquito de ella hace poco y la verdad es que no me atrae en absoluto, aunque es interesante.

Gracias por expliaciones como esa, aunque siendo como soy, un hombre de letras que se metió en ciencias...me lo tendré que leer unas cuantas veces, que con tanta "fórmula" (habrá una o por ahí xDDDDDDDDDD) y demás, me emociono y me pierdo .

¡Saludos!

pues 2^512 combinaciones de bits es una animalada ^^U solo se podria atacar de manera distribuida.... aun asi....

Cada PS3 cifra con una clave diferente no? Pues se tendria k sacar la clave de la PS3 de un desarrollador y a partir de ahi k saque informacion

naima escribió:Jur...

Tema PS3.
PS3 no emplea vectores en el cifrado del HDD. Se cifra sector (512 bytes) a sector. Esto es, el mensaje a cifrar es siempre un sector. Queremos cifrar otro sector? bien, pues volvemos a empezar, es decir, mensaje nuevo. Por lo tanto TODOS los sectores iguales se cifran de la misma manera.
Los sectores que se repitan pueden ser muchos, cualquiera que sea identico a otro se repetirá, el más común será el sector vacio (todo ceros). Este como expliqué antes es fácil de identificar porque se ubican en la misma posición en la que antes teníamos sectores de ceros. Quiero recordar que el disco duro viene de fábrica completamente a cero y Sony hace un formato rápido de estos cuando los instala. Sólo se cifran los sectores que se escriben en ese proceso y el resto (la gran mayoría) quedan a 0 sin cifrar. Si reformateamos el disco duro mediante un formateo 'lento' se cifran todos los sectores. Volvemos a leer el contenido del disco y donde antes teníamos sectores vacios ahora en la misma posición tenemos sectores idénticos entre sí pero cifrados. Esos sectores cifrados de esa única forma son ceros. Repito, hay más sectores que se repiten?
Sí, pero de los únicos que puedo conocer su texto en claro son los de ceros.

Espero que haya aclarado las dudas de todos y de cnova en particular.

Un saludo.

@Naima tienes toda la razón, no se pude escribir una respuesta de este tipo a toda prisa como hice. Me encanta la "dialéctica" que llevamos. El error que cometí es que tú hablas de LRW y yo he estado usando siempre CBC y ESSIV (lo de los vectores) para evitar precisamente ataques suponiendo que alguien tuviera acceso al contenido en claro del disco y luego pudiera compararlo con el contenido cifrado.

ps3dev escribió:Has demostrado que sabes mas que yo de sistemas de cifrado/descifrado, jejeje, yo puedo aportar en otras cosas técnicas

Así que la posibilidad de que yo diga algo que a ti no se haya ocurrido es muy baja, con lo que te devuelvo la pregunta, no hay alguna forma en que podamos atacarla? aunque sea remota

Realmente no he demostrado nada, sólo soy un eoliano de a pie que aporta parte de los conocimientos que tengo sobre criptografía, y concretamente porque me toca trabajar con ellos, hay cocos muy buenos ahí fuera. Agradecer también a Naima sus aportes (aparte me divierto mucho).
También te digo que si leo aquí y posteo de vez en cuando es porque cualquier idea aunque sea descabellada en principio es buena, es imposible que a alguien se le ocurra todo aunque conozca algo del tema. Otra cosa es que cuando se postea se piense sobre ello y se vea la viabilidad del mismo.

devnull escribió:La idea, es ver si teniendo una de ellas en modo GameOS podemos conectarnos a la otra (en modo linux - server - ) para leer contenido.

Una de las primeras cosas que se comprobó es que el GameOS no deja ningún puerto abierto por TCP/UDP. Claro que esto se puede seguir comprobando en cualquier fw que vaya saliendo.

Respecto de lo de cálculo distribuido para romper AES olvidadlo, no conseguiremos nada por ese camino (no es viable en un tiempo razonable).

cnova escribió:Respecto de lo de cálculo distribuido para romper AES olvidadlo, no conseguiremos nada por ese camino (no es viable en un tiempo razonable).

Habia pensado por ejemplo que pudieramos hacer:

Guardar un dump del HDD.

Copiar una foto desde el XMB ¿con lo que se quedaríaguardada en la particion gameos, no?

Guardar un nuevo dump del HDD.

Encontrar las diferencias entre los dump.

Con lo que tendriamos el archivo sin cifrar (llamemoslo archivo_foto) y el archivo cifrado (llamemoslo (archivo_foto_c).

Hacer un programa que cifre archivo_foto usando el metodo AES y aplicando secuencialmente claves, hasta conseguir que el resultado sea igual que archivo_foto_c

Esto nos permitiría verificar que estamos en lo cierto y sería un paso fundamental para poder leer el HDD, lo que abriría una puerta enorme a la investigacion y experimentacion.

Incluso haciendolo de forma distribuida ¿sería imposible? Todos hemos leido las maravillas de la potencia del calculo del cell, a lo mejor la podemos usar en su contra.