PS3 NAND Dump Extractor released!

1, 2, 3, 4, 5, 6
Devnul de lo sencillo que lo quieres explicar no me entero de la mayoría.

Poder leer los archivos de la NAND (o sea desencriptarlos y dejarlos como binarios normales) permitirían atacarlos por ingenieria inversa, ahora mismo la encriptacion impide este ataque.

Permitiría aprender como funciona y sobre todo como forzar errores que nos permitan experimentar. En los archivos de la nand (sino me equivoco) está un archivo que actualiza la unidad BR, leer ese archivo nos permitirá conocer su funcionamiento y poder hackear el bus que lo comunica con el resto del sistema lo que permitiría modificar ciertas respuestas del lector, o permitiría que nos pudieramos hacer backups 1:1, lo que acercaría un hd loader.

Otro punto que yo creo que es clave es enender lo que se guarda en el HDD.

POr favor, en las respuestas haced alguna referencia a los terminos reales, como puedan ser firmware, encriptacion, etc... para que tambien lo podamos entender los que sabemos algo del tema, pero no tenemos un conocimiento profundo de la ps3.

Gracias
si si la esplicacion esta bien , pero

si tu metes a tus cuatro colegas en el hotel , como personal , tras pasar todas los tramites administratibos ....

y luego que pasa paco dame una abitacion , ¿cual quieres?
- la 220 , y le dices , paco lo ma segure que la puerta la deje abierta
y tire un tabique . no pasa nada

paco eres un colega
gotama escribió:Devnul de lo sencillo que lo quieres explicar no me entero de la mayoría.

Poder leer los archivos de la NAND (o sea desencriptarlos y dejarlos como binarios normales) permitirían atacarlos por ingenieria inversa, ahora mismo la encriptacion impide este ataque.


Si desencriptases la NAND, vieras el contenido, modificases algunas cosas y quisieras volverlo a encriptar, no podrias (no podrias de forma valida)

Es como la clave publica y la privada. Para desencriptar tienes (consigues) la publica, pero para encriptar, necesitas la privada.
devnul tio eres un hacha, ahora lo he entendido mejor ^^
fijate que toy en la ingenieria tecnica de informatica y hoy he aprendido más que en estos 3 meses xDD
devnul escribió:
Si desencriptases la NAND, vieras el contenido, modificases algunas cosas y quisieras volverlo a encriptar, no podrias (no podrias de forma valida)

Es como la clave publica y la privada. Para desencriptar tienes (consigues) la publica, pero para encriptar, necesitas la privada.


Si, en eso estamos de acuerdo, pero no tiene por que ser necesario modificar los ficheros de la nand, al menos en un principio. Aprendiendo el funcionamiento nos permitiría saber cuales son las comprobaciones que hace donde y como las hace, que tipo de dato espera, etc... Una vez la conozcamos podriamos educarla aunque fuera via HW, o provocar fallos que nos permitieran probar cosas.

El punto mas debil y atacable sería la comunicacion con el lector o el HDD ya que ninguno de los dos es capaz de encriptar o desencriptar datos solo envian/reciben datos y ejecutan comandos.

Según vayamos aprendiendo su comportamineto e intercambio de datos, estaremos mas cerca de poder educarla y quien sabe si incluso encontrar vias de obtener las claves famosas que nos permitieran escribir ficheros en la nand o el HDD. Ya ha sido posible obtener las super seguras claves para copiar BR y HDDVD de video.

Como toda obra humana la ps3 y el cell tienen fallos y "puertas traseras" por fallos de diseño o implementacion, el tema es encontrarlos, dificil, por que está claro que el diseño de seguridad es bastante bueno, sobre todo por que es una arquitectura que todavía es muy desconocida.

Lo que está claro es que tus explicaciones sobre el funcionamiento del sistema y los links a los pdf que has puesto son muy muy buenos para la scene, ya que nos ayuda a entender a nuestro 'enemigo'
este hilo es como un porro...a mas que lees no terminas de entender pq ries,pero ries. [sati]

en fin ya voy pillando el concepto por la explicacion del libro de arabe.
[+risas]

saludos y feliz dia cualquiera...pa mi es un dia de hipocresia pq soy feliz siempre y no lo soy mas por que es 31 diciembre o 1 de enero.

lo dicho

dew
devnul escribió:
...


Muchísimas gracias por las explicaciones, para un "simple mortal" como yo es un lujo poder absorver tanta información interesante y útil.
Un saludo y de nuevo gracias.
Muchísimas gracias a devnul por explicarlo tan bien [sonrisa] .

Pero pienso yo, ¿no sería más fácil hacer una modificación de hardware para engañar al lector o al HDD y saltarse las comprobaciones?. Porque según lo que has explicado, atacarle por un CF parece difícil [sonrisa] .

Saludos y, de nuevo gracias.
gotama escribió:
Si, en eso estamos de acuerdo, pero no tiene por que ser necesario modificar los ficheros de la nand, al menos en un principio. Aprendiendo el funcionamiento nos permitiría saber cuales son las comprobaciones que hace donde y como las hace, que tipo de dato espera, etc... Una vez la conozcamos podriamos educarla aunque fuera via HW, o provocar fallos que nos permitieran probar cosas.

El punto mas debil y atacable sería la comunicacion con el lector o el HDD ya que ninguno de los dos es capaz de encriptar o desencriptar datos solo envian/reciben datos y ejecutan comandos.

Según vayamos aprendiendo su comportamineto e intercambio de datos, estaremos mas cerca de poder educarla y quien sabe si incluso encontrar vias de obtener las claves famosas que nos permitieran escribir ficheros en la nand o el HDD. Ya ha sido posible obtener las super seguras claves para copiar BR y HDDVD de video.

Como toda obra humana la ps3 y el cell tienen fallos y "puertas traseras" por fallos de diseño o implementacion, el tema es encontrarlos, dificil, por que está claro que el diseño de seguridad es bastante bueno, sobre todo por que es una arquitectura que todavía es muy desconocida.

Lo que está claro es que tus explicaciones sobre el funcionamiento del sistema y los links a los pdf que has puesto son muy muy buenos para la scene, ya que nos ayuda a entender a nuestro 'enemigo'


La llave de HD-DVD y BR fue mucho más fácil de encontrar porque se podían leer desde PC, donde puedes usar todo tipo de cosas (por ejemplo, debuggers) y obtenerla de la memoria.

El HDD no me parece que tenga mucha utilidad ya que lo único que hace es proporcionar datos, pero el tratamiento (desencriptación y uso) lo hace la consola.
Alguien lo ha intentado?

Seguramente lo pruebe cuando pueday os digo como ha ido
jajaja dios que bueno lo de devnul, unos ejemplos fantasticos, lo del hotel ha sido mortal xDDD
Sobre este tema, a ver si me podeís aclarar rápidamente las dudas que tengo...

- El cell fué diseñado para la PS3 pero también con ámbito semi-general, o más bien, para utilizarlo en otros dispositivos según tengo yo entendido. Entonces, no se si la doctrina de seguridad reside en algún sitio en particular, o mejor dicho, la programación de la misma si reside en algún sitio. Puesto que no creo ke sea algo intrínseco del cell, o en cambio me equivoco? Entonces, algo así como atacarle por ahi para reprogramar (una odisea....) o poder cambiarle la política de seguridad temporalmente por HW para determinadas cosas y mantener la misma para otras.

o todo esto va en el juego de instrucciones?

la verdad es que estoy más perdido que el na....

Por cierto, gracias por los documentos técnicos, interesantes sin duda...

salu2
BURTON C.BELL escribió:este hilo es como un porro...a mas que lees no terminas de entender pq ries,pero ries. [sati]


[qmparto] [qmparto] [qmparto]

Con eso sí que me he reído yo!!! Muy bueno!!!


Salu2!!!
Nitrok escribió:Sobre este tema, a ver si me podeís aclarar rápidamente las dudas que tengo...

- El cell fué diseñado para la PS3 pero también con ámbito semi-general, o más bien, para utilizarlo en otros dispositivos según tengo yo entendido. Entonces, no se si la doctrina de seguridad reside en algún sitio en particular, o mejor dicho, la programación de la misma si reside en algún sitio. Puesto que no creo ke sea algo intrínseco del cell, o en cambio me equivoco?


Esta en el propio Chip.

Imagen

Como puedes ver, se accede a la información de forma encriptada. Solo dentro del procesador (y solo dentro suyo y no de otro) la desencripta sin utilizar la memoria,hace la operacion, lo vuelve a encriptar y lo saca, por lo que nunca tenemos acceso al contenido (-e-n-c-r-i-p-t-a-d-o) Desencriptado

Esa encriptación no se hace por software, la hace el propio procesador por hardware y utiliza criptografia asimetrica.

http://en.wikipedia.org/wiki/Public-key_cryptography



PD : UFf se ve fatal la imagen. A ver..

Sobre cerrado --> informacion encriptada
Sobre abierto --> informacion desencriptada
Cuadrado Azul --> Memoria
SPE --> Super Pollazo Expres.... (es broma xD SPE es SPE xD)


PD2: Kanna Shimizu es el culpable del cell :) Culpable en el buen sentido de la palabra, ya que es el lumbreras (vease, arquitecto) padre del artefacto :)


(editado) comietí un error, puse "nunca tenemos acceso al contenido encriptado" queria decir, al contenido desencriptado.
ostia pixa vaya paranolla, q alguien me mande un privado cuando se puedan cargar backups por favor
xD
devnul escribió:
Esta en el propio Chip.

Imagen

Como puedes ver, se accede a la información de forma encriptada. Solo dentro del procesador (y solo dentro suyo y no de otro) la desencripta sin utilizar la memoria,hace la operacion, lo vuelve a encriptar y lo saca, por lo que nunca tenemos acceso al contenido (-e-n-c-r-i-p-t-a-d-o) Desencriptado

Esa encriptación no se hace por software, la hace el propio procesador por hardware y utiliza criptografia asimetrica.

http://en.wikipedia.org/wiki/Public-key_cryptography



PD : UFf se ve fatal la imagen. A ver..

Sobre cerrado --> informacion encriptada
Sobre abierto --> informacion desencriptada
Cuadrado Azul --> Memoria
SPE --> Super Pollazo Expres.... (es broma xD SPE es SPE xD)


PD2: Kanna Shimizu es el culpable del cell :) Culpable en el buen sentido de la palabra, ya que es el lumbreras (vease, arquitecto) padre del artefacto :)


(editado) comietí un error, puse "nunca tenemos acceso al contenido encriptado" queria decir, al contenido desencriptado.


Pues creo que voy a decir una tontería pero bueno :-P . ¿Y si se hiciera un chip para el procesador? [mad] [mad] . Seguramente inviable, pero bueno. Parece que está complicada la cosa.

Saludos.
Jajaja; me he reido bastante y creo haber entendido lo que tratas de contar por encima, Devnul. Buen sentido del humor, y gracias por molestarte entreteniendonos-enseñándonos [360º]
edu_3 escribió:ostia pixa vaya paranolla, q alguien me mande un privado cuando se puedan cargar backups por favor
xD

yo te lo digo ke soy de jerez tambien XD
devnul escribió:SPE --> Super Pollazo Expres.... (es broma xD SPE es SPE xD)


Synergistic Processing Element xDDDDDDDDDDDDDDDD

En fin, yo no tengo ni idea de por dónde acabará la cosa, por hardware o software, pero vamos, con la PSP ya se tuvo mucha suerte y me dá a mí que con la PS3 no vamos a tener tanta suerte...
Juan The MW escribió:
Pues creo que voy a decir una tontería pero bueno :-P . ¿Y si se hiciera un chip para el procesador? [mad] [mad] . Seguramente inviable, pero bueno. Parece que está complicada la cosa.

Saludos.


Para ver el contenido de los datos desencriptados? No ayudaria mucho.

Imagina que el codigo de la NAND es el siguiente:

cojo_un_numero(x)
cojo_un_numero(y)
hago_operacion(x,y)
muestro_resultado(z)

y encriptado, es

* K/JNM(JA(=KS(!
* 0BNHMAVSIKIY

B//&AHNSG&((
NMS??=A/"%(1

(* notese que las dos primeras funciones se llaman igual, sin embargo se codifican diferente)

Si colocasemos un/unos chip/s sobre los cells para ver los datos, veriamos (por poner un ejemplo)

4
5
61
61

Sabemos que coje el 4 hace una operacion con el 5 y saca el 61.

Si eres rapido en mates, te daras cuenta que no hay ninguna operacion matematica con estos dos enteros, que de 61. Por lo que no sabemos que operacion ha usado.

Bien, puedes pensar... "en algun momento habra un resultado que si sepa como conseguirlo a partir de 2 enteros....y entonces ya sabre que operacion es..." Bueno, eso es un problemon mas que una solucion. Porque? La culpa la tiene el señor Fermat y Euler.

De todos modos, saberlos interesa mas para temas criptograficos que no para el contenido intrinseco del programa. Porque? Veamos un ejemplo:

(los mas avanzados,reconocereis rapido este sistema)

1. Encontrar dos grandes números primos, p y q (secretos), y calcular el número n (publico) mediante su producto, n=p*q.

2. Encontrar la clave de descifrado constituida por un gran número entero impar, d (secreto), que es primo con el número F(n) (secreto), obtenido mediante F(n)=(p-1)*(q-1). Siendo F(n) la función de Euler.

3. Calcular el entero e (publico) tal que 1 ó e ó F(n), mediante la formula: e*d-1(mod F(n)).

4. Hacer publica la clave de cifrado (e,n).

5. Para cifrar un texto, es necesario previamente codificar el texto en un sistema numérico, bien decimal o bien binario, y dividir en bloques Mi de tamaño j o j-1 de forma que, según sea el alfabeto usado el decimal o el binario cumpla en cada caso: 10^(j-1) < n < 10^j o 2^(j-1) < n < 2^j. Cuando se toma como tamaño j, el descifrado del texto puede no ser único, por tanto esta elección se hace solo cuando la unicidad del descifrado no es importante.

6. Cifrar cada bloque Mi transformándolo en un nuevo bloque de números Ci de acuerdo con la expresión: Ci-Mi^e(mod n).

7. Para descifrar el bloque Ci, se usa la clave privada d según la expresión: Mi-Ci^d(mod n).

Analicemos la base numérica que hace que si M se cifra en C entonces C se descifra en M. Con las claves publica y privada (e,n) y d descritas, dado cualquier mensaje original M representado por un entero entre 0 y n-1 se tiene que, efectivamente, si C-M^e(mod n), entonces C^d-M(mod n).

Si se considera el mensaje descifrado D-C^d(mod n) como C-M^e(mod n), se tiene que D-(M^e+kn)^d(mod n), siendo k algún entero no negativo. Si se desarrolla el binomio, se obtiene que D-M^(e*d)(mod n), pero dado que e*d-1(mod F(n)), se tiene que D-M^[t*(p-1)*(q-1)+1](mod n) para algún entero t no negativo. Como p es primo y p-1-0(mod F(p)), la identidad de Euler-Fermat confirma que M^(p-1)-1(mod p), luego existe algún entero r tal que M^(p-1)=r*p+1 y por tanto M^[t*(p-1)*(q-1)+1]=[(r*p+1)^(t*(q-1))]*M- M(mod p). De la misma forma, se llega a que M^[t*(p-1)*(q-1)+1]-M(mod q). A partir de ambas ecuaciones congruenciales y gracias al corolario de la identidad de Euler-Fermat que afirma que: "Para dos primos distintos cualesquiera p y q y cualquier par de enteros positivos x y u, si x^u-x(mod p) y x^u-x(mod q), entonces x^u-x(mod p*q)", se llega finalmente a la identidad M^[t*(p-1)*(q-1)+1]-M(mod p*q).

Los procesos de cifrado y descifrado pueden ser implementados mediante algunos algoritmos conocidos.

Las dos principales dificultades en la implementación del RSA (facil eh? ;) ) son:

1. Potencias modulares.
2. Búsqueda de números primos.

Para aumentar las dificultades, la seguridad del RSA estriba en que los primos p y q elegidos han de ser muy grandes. Para encontrar los grandes primos p y q se pueden utilizar varios algoritmos, como el de Solovay-Strassen, y el de Lehman y Peralta, que sirven para comprobar la primalidad.

En el caso del RSA puede encontrarse el entero d, primo con F(n)=(p-1)*(q-1), tomando simplemente un número primo mayor que max{p,q}.

Para calcular el entero e tal que e*d*-1(mod F(n)), se puede utiliza el algoritmo euclídeo por ser d primo con F(n).

Por ultimo, las operaciones de cifrado y descifrado requieren el calculo de potencias modulares, lo que se puede llevar a cabo en tiempo polinomial. Exactamente son necesarias 2*(log2 (n)) multiplicaciones modulares, de manera que, por ejemplo, para el calculo de 2^18=(((22) 2) 2) 2 * (22) son necesarias 5 multiplicaciones modulares.


Y todo esto para que ? (modificando un poco el tercio) Pues para lo que sugerian anteriormente con la ingenieria inversa,cosa que desde YA queda totalmente descartada. Porque??? Sigamos avanzando para verlo..


Para analizar la seguridad del sistema, se supone que el criptoanalista tiene una cantidad ilimitada de pares (M,C) de mensajes originales y sus correspondientes criptogramas. Las posibles maneras que tiene de atacar el sistema son las siguientes:

1. Factorizar n.
2. Calcular F(n).
3. Ataque por iteración.
4. Ataque de Blakley y Borosh.

Vamos a analizar estos posibles ataques:

1.- Factorizar n:

De esta forma obtiene el número F(n)=(p-1)*(q-1), y con el la clave privada d, puesto que e es publica y se cumple: e*d-1(mod F(n)).

Al ser n el producto de solo dos números primos, un algoritmo de factorización requiere como máximo 'n pasos, pues uno de los dos factores es necesariamente un primo menor que 'n. Sin embargo, si n fuera el producto de N>2 primos, un algoritmo de factorización necesitaría como máximo n^(1/N) pasos, que es una cota menor que 'n, por lo que se concluye que es adecuada la obtención de n como producto de solo dos números primos.

Con respecto al estudio del problema de la factorización, hay que mencionar al precursor de la moderna factorización, el algoritmo de fracciones continuas de Morrison-Brillhart, ya que es uno de los más rápidos. Sin embargo, los dos algoritmos de factorización que resultan más prácticos para grandes enteros corresponden al de factorización con curvas elípticas de Hendrik Lenstra y al de factorización con filtro cuadrático de Carl Pomerance. Ambos algoritmos convierten el problema de la factorización de un entero n en el problema de encontrar soluciones no triviales ('x <> y(mod n)' y 'x <> -y(mod n)') de la ecuación: x3-y3 (mod n). Si se supone que ni (x+y) ni (x-y) son múltiplos de n enteros, se deduce que el m.c.d.(x+y,n) o bien el m.c.d.(x-y,n) es con seguridad un factor no trivial de n, por lo que se resuelve el problema de la factorización.

Por ejemplo, si n=97343, entonces la ecuación x2-y2 (mod 97343) es fácilmente resoluble por ser los factores de n dos números primos muy cercanos. Como 3122-1(mod 97343) y ni 313 ni 311 son múltiplos de 97343, se concluye que 313 y 311 son los factores de n.

2.- Calcular F(n):

Como se ve a continuación, esta manera es equivalente a la anterior. Si se tiene F(n), dado que p+q=n-F(n)+1 y a partir de la suma se puede calcular (p-q) 2 por coincidir con (p-q) 2-4*n, luego se consigue la factorización mediante las formulas q=[(p+q)-(p-q)]/2 y p=[(p+q)+(p-q)]/2.

3.- Ataque por iteración:

Si un enemigo conoce (n,e,C), entonces puede generar la secuencia: C1-C^e(mod n), ..., Ci-[C(i-1)]^e(mod n), con lo que si existe algún Cj tal que C=Cj se deduce que el mensaje buscado es M=C(j-1) pues [C(j-1)]^e=Cj=C. Ahora bien, en cuanto la igualdad Cj=C se cumple solo para un valor de j demasiado grande, este ataque se vuelve impracticable. Con respecto a esto, Rivest demostró que si los enteros p-1 y q-1 contienen factores primos grandes, la probabilidad de éxito mediante este procedimiento es casi nula para grandes valores de n.

4.- Ataque de Blakley y Borosh:

El sistema RSA, además, tiene una característica muy peculiar, advertida por Blakley y Borosh, y es que no siempre esconde el mensaje. A continuación vemos un ejemplo que lo muestra.

Si e=17, n=35 y los mensajes a cifrar son M1=6 y M2=7, entonces se obtiene que 6^17-6(mod 35) y 7^17-7(mod 35). Una situación más peligrosa para el sistema aparece, por ejemplo, con los valores p=97 q=109 y e=865, ya que el criptosistema resultante no esconde ningún mensaje, pues M^865-M(mod 97*109)

En general, lo ocurrido en el ultimo ejemplo ocurre siempre que e-1 es múltiplo de p-1 y q-1, pues en ese caso M^e-M(mod p*q). Además, se tiene que para cualquier elección de n=p*q siempre existen al menos 9 mensajes M que no se cifran en realidad, ya que verifican la ecuación M^e-M(mod n). De esos 9 mensajes hay tres fijos, que son M perteneciente a {0,1,-1}. Para hacer que el sistema RSA sea resistente contra ataques basados en este hecho, es conveniente elegir como claves privadas números primos de la forma p=2*p'+1, donde p' es un primo impar.

Para la selección de los parámetros del sistema el usuario debe comprobar las siguientes condiciones para intentar evitar los ataques mencionados:

* Los números primos p y q deben tener una diferencia grande (ataque 1).
* Los números primos p y q deben ser del orden de 100 dígitos (ataque 2).
* Los enteros (p-1) y (q-1) deben contener grandes factores primos (ataque 3).
* Los números primos p y q deben elegirse de manera que p=2*p'+1 y q=2*q'+1 con p' y q' números primos impares (ataque 4).

Los primos p y q del RSA deben ser de la forma x=2*x'+1 (siendo x' un número primo impar) tal que x-1 tiene grandes factores primos, con aproximadamente 100 dígitos y de forma que p-q sea grandes.

No obstante, es lógico pensar que a medida que se profundiza en la investigación se añadirán y descubrirán nuevas propiedades de los parámetros que deban verificar para que el sistema resultante se fortalezca.

Uno de los más recientes ataques al RSA fue realizado por Wiener. Llevo a cabo un criptoanalisis en tiempo polinomial de un sistema RSA con claves privadas pequeñas. Para ello, utilizo un algoritmo que representa los números racionales como fracciones continuas finitas.

De todo lo anterior se concluye que para que la seguridad del sistema RSA quede perfectamente salvaguardada es necesario escoger cuidadosamente las claves a utilizar.

Finalmente se presentan algunos resultados que versan sobre la seguridad del sistema.

Un algoritmo que calcule d se puede convertir en un algoritmo probabilístico que factorice n.

Si el RSA se aplica en un entorno en el que el modulo n y los exponentes de cifrado y descifrado d son distribuidos por una agencia de manera que esta proporciona un modulo n común a todos los usuarios, los exponentes de cifrado de cada usuario eA, eB, ... y distribuye entre los usuarios las claves privadas dA, dB, ..., pero en todo caso mantiene para si los números p y q, entonces cualquier usuario puede determinar en tiempo cuadrático determinístico la clave de descifrado secreta de otro usuario.

Si dos usuarios usan el mismo modulo en un sistema RSA y lo saben, entonces cada usuario puede descifrar los criptogramas enviados al otro.

Luego queda claro que esas condiciones no resultan muy propicias para la seguridad de las comunicaciones.

A pesar de las ventajas evidentes de este esquema frente a los sistemas de clave secreta, hay que subrayar que en la actualidad la principal desventaja del RSA estriba en que es mucho más lento que el DES y que los cifrados en flujo. Como cifras ilustrativas, se puede señalar que el DES trabaja a unos 20 megabits por segundo, mientras que el RSA funciona a una velocidad 1000 veces menor, y aunque la investigación para acelerar el proceso es intensa, es de esperar que esta proporción se mantenga, ya que también se realiza para los cifrados simétricos.

El punto más débil del RSA es su velocidad (comparándola con la de otros cifrados, como el cifrado en flujo).


******************************************************
*Y todo esto a donde nos lleva ???? A LA PUÑETERA FIRMA DIGITAL :)*
******************************************************

El desarrollo de las telecomunicaciones en estos últimos años ha creado toda una variedad de nuevas necesidades. Por ejemplo, dado que en la mayoría de las operaciones bancarias es necesario firmar los documentos, con el uso de los ordenadores se requiere un nuevo planteamiento, donde una firma digital sustituye a la firma manual y cumple las mismas propiedades que ésta. Se puede distinguir la firma:

* implícita (contenida dentro del texto) de la explícita (añadida al texto como una marca inseparable).
* privada (legible sólo para quien comparte cierto secreto con el emisor) de la pública (legible para todo el mundo).

La firma digital debe ser:

* única, pudiéndola generar solamente el usuario legítimo.
* no falsificable, el intento de falsificación debe llevar asociada la resolución de un problema numérico intratable.
* fácil de autenticar, pudiendo cualquier receptor establecer su autentidad aún después de mucho tiempo.
* irrevocable, el autor de una firma no puede negar su autoría.
* barata y fácil de generar.

Otra característica que han de tener las firmas digitales es que deben depender tanto del mensaje como del autor. Esto debe ser así porque en otro caso el receptor podría modificar el mensaje y mantener la firma, produciéndose así un fraude (en el ejemplo de la biblioteca, el libro en arabe que esta en un dialecto, lo modificabamos en ese dialecto yluego resulta que no es factible, ya que no hemos usado el lenguaje original)

Si el emisor A envía un mensaje firmado digitalmente al receptor B, este último no sólo debe convencerse de que el mensaje fue firmado por el primero, sino que, además, debe ser capaz de demostrar a un juez que A realmente firmó ese mensaje. Esta noción fue ideada por Diffie y Hellman en 1976. La firma digital y el correo electrónico ofrecen conjuntamente sustanciosas ventajas, una de ellas es hacer posible el correo certificado y la firma electrónica de contratos.

La idea principal de la firma digital es que solamente el emisor la pueda producir y además se pueda demostrar que, efectivamente, es él quien la produce. Representa por tanto, un control más fuerte que la autenticación.

Considérese un sistema de clave pública donde Mk y Ck denotan respectivamente, a los espacios de mensajes originales y cifrados asociados a una clave k.

Un sistema de clave pública ofrece la posibilidad de ser usado para firmas digitales siempre que para k perteneciente a K; Mk=Ck y para m perteneciente a M; Ek(Dk(m))=m.

Denotando la clave escogida por el usuario A como a, se tiene que si el criptosistema es seguro, entonces sólo A puede calcular Da, pero cualquiera puede calcular Ea de forma eficiente.

Considérese un mensaje m perteneciente a Ma y s=Da(m). Cualquier usuario puede calcular Ea(s) y comprobar que coincide con m, pero, sin embargo, sólo A puede deducir el valor de s para el que Ea(s)=m. En este sentido, s puede ser considerado como la firma de A para el mensaje m. Si B muestra el mensaje s y su cifrado Ea(s) a un juez, éste debe de convencerse de que ningún otro m s que A pudo haber firmado ese documento con Ea(s). En otras palabras, los algoritmos de descifrado y de cifrado pueden verse, respectivamente, como un algoritmo de firma digital y su correspondiente algoritmo de verificación.

La actual velocidad de los sistemas de clave pública recomienda su utilización para generar firmas digitales cortas y separadas del texto (firmas explícitas).

Si además de capacidad de firma digital se desea secreto, entonces la firma digital puede ser utilizada conjuntamente con un cifrado de clave pública. Si el usuario A quiere enviar un mensaje secreto firmado a un usuario B, puede usar el algoritmo secreto de firma digital Da y el algoritmo público de verificación Eb, produciendo c=Eb(Da(m)). Si envía este mensaje c al usuario B a través de un canal inseguro, entonces B puede calcular la firma de A mediante s=Db(c) y de ahí recuperar el mensaje claro m=Ea(s). Esto supone que en el caso de que hubiera más de un posible emisor en el encabezado del mensaje debe decir claramente que el mensaje viene de A para que B pueda saber qué algoritmo de verificación debe aplicar. Es más, si B guarda el mensaje s, llegado el momento podrá probar ante un juez que A le envió el mensaje m, tal y como se explicó previamente.

Hay que tener cuidado cuando se afirma que el conocimiento por parte de B del valor de una firma s tal que Ea(s)=m tiene que ser considerada como una demostración de que A firmó m, ya que B podría elegir un valor s aleatorio, calcular m=Ea(s) y luego argumentar que A envió m, aunque no tenga sentido. Las cosas empeoran si la proporción de mensajes con significado es alta, porque en este caso B podría escoger varios valores de s aleatoriamente hasta toparse con uno para el que Ea(s) tenga significado. Por esta razón, es recomendable alguna forma normalizada para las firmas digitales, y que se acepte s como firma del mensaje m sólo si se tiene que m=Ea(s) y que m está en forma normalizada. Desafortunadamente, todavía no está claro cual sería la forma normalizada recomendable para utilizar con el sistema RSA.

Si se utiliza el RSA para conseguir secreto y como firma digital, entonces es preferible que cada ususario use claves distintas para cada uno de los dos propósitos. De esta forma, cada usuario tendría asignada una clave en el directorio público de claves de cifrado y otra distinta en el directorio público de firma digitales. Esta separación es útil para dos propósitos. En primer lugar, ayuda a evitar el problema que surge cuando el módulo del emisor es mayor que el del receptor. En segundo lugar dado que el RSA es débil frente a algunos ataques con texto escogido, tales ataques pueden verse facilitados si se utiliza la misma clave para ambos fines, y en consecuencia es preferible evitarlo.

El criptosistema RSA presenta algunos inconvenientes para las firmas digitales parecidos a los que presentaba como sistema de cifrado. En particular, no se sabe a ciencia cierta si es tan difícil de romper como la factorización de grandes enteros. Incluso aunque así fuera, dados un mensaje original escogido m y la clave de cifrado de otro usuario (e,n), calcular la firma digital s tal que m - s^e(mod n) puede ser mucho más fácil si se tiene, además, (s',m'), donde s' es la firma digital del usuario legítimo para un mensaje m' muy parecido al mensaje m. En otras palabras, podría resultar fácil falsificar firmas digitales para algún mensaje dado después de haber visto las firmas digitales auténticas de varios mensaje parecidos.

******************************************************
Pues bien el RSA para la PS3 es como un puzzle de dificultad para
un niño de 4 años
******************************************************

Es decir, que se lo pule,por lo tanto, nos estamos enfrentando a una encriptacion QUE ES (y aqui me quedo sin palabras porque decir que es "relamente jodida" me estaria quedando muy muy corto)


PD: yo prefiero explicarlo a lo "cutre" con mis ejemplillos, porque sino,para entender esto.. hay que tener una carrera,hecha y derecha en mates,telecos o informatica.

(editado) corrigiendo y añadiendo algunas modificaciones
Otra cosa que no tengo clara, es donde reside el KEY MASTER. Probablemente, ahi este el kit de la cuestión (tal vez algún empleado descontento).... porque si es por HW veo complicado comprometer un procesador.

Entonces, que yo me aclare, el Key MASTER está dentro de cada uno de los procesadores como clave privada, pero además lo traen cada aplicación o juego incluida?
Joder...madre mía, mis mayores temores matemáticos están ahí. Mañana por la mañana me lo leeré, DioX xDDDDDDDDDDDDD

Bueno, y Nasdaq por todo :)
Es coña [qmparto] [qmparto] [qmparto] [qmparto] [qmparto]
Nitrok escribió:Otra cosa que no tengo clara, es donde reside el KEY MASTER. Probablemente, ahi este el kit de la cuestión (tal vez algún empleado descontento).... porque si es por HW veo complicado comprometer un procesador.

Entonces, que yo me aclare, el Key MASTER está dentro de cada uno de los procesadores como clave privada, pero además lo traen cada aplicación o juego incluida?


La key Master esta dentro del Cell y la comprovacion, se hace asi:

CELL Based on this philosophy, Secure Boot is a technique whereby during power-on time, from the first BIOS code that is executed to the operating system code, the code modules go through a cryptographic-based authentication check.  Although there are a variety of flavors of this, one way is to have a small boot module be authenticated by the hardware using a hardware key (the hardware root of trust), and then this module is now entrusted to authenticate the operating system.  If the authentication of the boot module or the operating system fails, the booting process is halted, but otherwise, the booting process is allowed to happen normally.  The idea is that since the first software to execute on the chip was authenticated by the hardware, and all succeeding software code is verified by the code that launched it, the chain of authentication ensures that all software on the system is indirectly or directly verified by the hardware root of trust at power-on time.

The drawback of this approach is it assumes that checking for compromises in the software at power-on time is enough.  It does not protect against software compromises that happen after power-on time.  However, most software-based attacks happen during runtime, and if this happens, the chain of authentication breaks, and any software that is launched after that time can not necessarily be trusted.

The Cell BE processor addresses this problem with its Runtime Secure Boot feature.  It lets an application secure boot from the hardware an arbitrary number of times during runtime.  Thus, even if other software in the system has been compromised in the past, a single application thread can still be robustly checked independently.  In essence, the application can renew its trustworthiness as many times as needed even as the system stays running longer and gets more stale.  Specifically, a hardware implemented authentication mechanism uses a hardware key to verify that the application has not been modified, and the authentication is based on a cryptographic algorithm.

This runtime secure boot, in fact, is tightly coupled with an SPE entering isolation mode.  An application must go through the hardware authentication step before it can execute on an isolated SPE.  When isolation mode is requested, first, the previous thread is stopped and cancelled.  Then, the hardware will automatically start fetching the application into the LS, and the hardware will verify the integrity of the application.  If the integrity check fails, the application will not be executed.  The check can fail for one of two reasons.  The application might have been modified within memory or storage.  Then, the assumption is that the functionality might have changed and it cannot be trusted anymore.  Or, the writer of the application does not know the cryptographic secret that is needed for a successful authentication. Otherwise, if the authentication check is successful, the hardware will automatically kick-start the application's execution in isolation mode. Because the hardware controls all of these steps, the verification of the application's integrity cannot be skipped or manipulated and will happen consistently and correctly.
Yo creo de todas formas que los tiros para poder meter homebrew y copias de seguridad en la PS3 van a ir por otro lado. Estamos debatiendo sobre atacar claves maestras que es algo casi imposible. A día de hoy sigue sin haber sido "descifrada" la clave de autenticación de los discos de Xbox 1, como para ponerse a sacar claves en la PS3 que está todo contenido en el procesador.

Yo creo que nos quedan 2 opciones, o bien atacar el lector, tal y como se hace en la 360, lo que no permitiría homebrew en un principio pero puede ser un paso intermedio, como ha logrado demostrarse en Wii, o bien atacar a la bios ahora que la tenemos extraida y podemos ojearla.

Todo lo que se ha dicho de cómo trabaja el procesador creo que es un callejón sin salida. Ojo, que no digo que no haya estado genial que se haya comentado, ha sido un curro de la leche por parte de devnul y los que mas o menos lo entendemos en mayor o menor grado pues lo agradecemos porque ha servido para aprender un poquito más como trabaja el trasto este.

Lo dicho, o lector (yo creo que será lo más problable) o bios. Del resto no me fío un pelo
Ojobenito escribió:
Lo dicho, o lector (yo creo que será lo más problable) o bios.


Efectivamente. Solo que la bios, conlleva el problema de que modificarla, significa tener la KEY por H/W para firmar, cosa que no tenemos.

(editado)

the hardware (cells) will automatically kick-start the application's execution in isolation mode. Because the hardware controls all of these steps, the verification of the application's integrity cannot be skipped or manipulated and will happen consistently and correctly.
A ver, devnul, que te veo puesto y me estoy picando con el tema,jaja

Aunque me ire de copas en breve quien sabe, cuando vuelva de madrugada lo mismo con una buena taja veo todo claro

Aclarame un par de conceptos que aun no los veo
Quien diablos tiene la llave publica y quien tiene la privada??

Es mas; cuantos juegos de llaves o comprobacioenes existen?
Deduzco que minimo dos, no?
Uno para comprobar la validez del BR y otro para comprobar la validez de procesos donde entrara en juego la firma digital sony.

Y deduzco que la llave esa general maestra solo se usara en la segunda, porque si no es asi, seria relativamente facil obtener parte de luz partiendo de cruzar BR...

Iluminame, por fa :P
Gracias

Feliz 2008
Tenemos dos vias de comprobacion criptografica, como bien dices

a) mediante los cells (que es la que hemos visto hasta ahora, con la master Key y sin saber aun que tipo de encriptacion utiliza,ni de cuantos bits ni nada, porque no esta documentado)

b) mediante el lector de BR

Los sistemas Blu-ray incorporan hasta cinco sistemas anticopias: AACS, BD+ y Rom Mark, SPDG e ICT.

El AACS es una mejora respecto al CSS del DVD. Su principal función es el control de la distribución de contenidos. Una de las consecuencias del AACS la de crear una lista negra de grabadores. Este sistema permite dar una clave para cada modelo de grabador. Esto facilita el seguimiento de que claves son descifradas y que grabadores permiten la copia de blu rays, la consecuencia sería revocar la clave y no incluirla en siguientes blu-rays garantizando la incompatibilidad con el grabador. Esta posibilidad ha despertado gran controversia ya que si se lleva a cabo usuarios que nunca le dieron un uso ilegal verían como su grabador queda inutilizado. Por ahora han anunciado que sólo se centrarán en reproductores industriales, que sean usados para la copia masiva. El sistema, en teoría, podría permitir incluso suministrar a cada reproductor individual un conjunto de claves con lo que se podría revocar las claves para dicho sistema impidiendo la reproducción sólo en él.

En un principio, la Asociación de Discos Blu-Ray decidió incorporar la restrictiva copia gestionada (MC). Inmediatamente, las compañías informáticas involucradas protestaron debido a su alta restricción. Al final decidieron que el control de distribución de contenidos sería copia gestionada obligatoria (MMC), usada en el HD DVD y que permite al menos una copia de un disco para enviarla a otros dispositivos. En esta decisión, influyó el hecho de que HD DVD lo hubiese adoptado ya que el usuario podría decantarse por un sistema menos restrictivo en este aspecto.

Los discos Blu-ray tienen en su estándar un sistema experimental anticopia denominado BD+. Este sistema permite cambiar dinámicamente las claves para la protección criptográfica de los BD originales. Si una de estas claves es descubierta, los fabricantes no tienen más que cambiar la clave, de forma que las nuevas unidades del producto no puedan ser pirateadas con dicha clave descubierta. A petición de HP, se añadió la posibilidad de que un usuario pueda comprar dichas claves para realizar un número limitado de copias del disco que ha comprado, quitando derechos de copia a los usuarios que utilizan este formato. El BD+ puede comprobar también si el hardware ha sido modificado e impedir la reproducción.

También se ha acordado que los BD lleven una marca de agua digital. Bajo el nombre de ROM-Mark, esta tecnología estará presente en todos los discos originales y requiere un componente especial de hardware licenciado para poder insertar la marca de agua durante la copia. Todos los lectores de Blu ray deben buscar esa marca. De esta manera, la BDA pretende frenar la copia masiva de Blu-ray.

(Editado: Amplio informacion)

Que quiere decir todo esto? Pues que en caso de que se pudiera modificar el firmware del lector, lo que habria que hacer (por pasos inversos) seria

- Evitar que busque el ROM-Mark
- ..... MEEEEEEEEC MEEEEEEEEC ALARM ALARM !!!!

".. El BD+ puede comprobar también si el hardware ha sido modificado e impedir la reproducción."

Ñiau ñiau ñiaaaaaaaaaaaaauuu.......... el propio disco toca los cojones (es "inteligente") aunque modifiques el firmware del lector... y encima te lo pueden inhabilitar
Tengo la impresion de que deberia haber una tercera encriptacion;
una de verdad, jeje, de las de siempre.
Una encriptacion sobre contenidos tanto en el disco duro, como quizas, la misma para el contendido del BR.
Se sabe que o quien xD desencripta el disco? Al Cell le llega el dato desencriptado por parte de un componente diferente o recibe el paquete "tal cual" y ademas de su propia seguridad y de procesar el flujo de informacion lo desencripta?

Aparte que por pura realidad criptografica, esta seguridad deberia ser diferente a la del cell, no?
Si fuera mi trabajo establecerla combinaria una parte gestionada por la propia Llave Privada con una publica u otra privada establecida en otra parte...
Buenas, voy a intentar explicarlo yo con mis palabras (un poco más técnico) como solicitais algunos...

Aunque vuelvo a felicitar a devnul sobre todo por las risas, que además espero que me corrija si estoy equivocado.

A ver un proceso ha de ser ejecutado en una SPU.

Bien, este proceso viaja en un BUS de datos desde su origen (HD, Blue-Ray, Red... ect) hasta una parcela de memoria RAM que es exclusiva para ella.

Imaginemos que este proceso ocupa 14kb, pues ya tiene reservado para el solito la dirección física de memoria que comprende desde F0001 hasta F1900 (ejemplo hipotético).

Bien una vez que le llegue el momento de ser ejecutado, viaja nuevamente por el Bus de datos hasta una SPU.

La CPU de la PS3 tiene varias SPU'S que cada una ejecuta un proceso que NO SE MEZCLAN.

Cada SPU tiene asigando sus procesos y cada proceso se resuelve individualmente.

El trabajo del Hypervisor es monitorizar todo y cada una de las SPU'S y viendo que no hacen nada raro.

Cuando un proceso hace algo raro, el hypervisor simplemente elimina este proceso.

La primera vez que se realiza la eliminación no pasa nada, pero la segunda vez, según tengo entendido, el hypervisor lo recuerda y lo elimina incluso antes de llegar a cualquier SPU.

------------------------------------------------

El tema del cifrado, como bien nos ha explicado devnul se realiza en la misma CPU.

El proceso SIEMPRE VIAJA CIFRADO desde cualquier contenedor (HD, Blue-Ray, ect) hasta que va a ser procesado.

¡¡ATENCIÓN!!

Un proceso NUNCA puede ser procesado estando CIFRADO ya que la CPU no lo entiende, no es capaz de procesar estos datos.

Bien, una vez que el proceso cifrado se encuentra en la caché de la CPU es descifrado por la SPU para ser procesada, que dicha información se guarda en la caché del micro DESCIFRADA.

(Cada SPU tiene un espacio de caché reservada para el y otra SPU no puede utilizar dicho espacio).

Este esta información ahora sí va a ser procesada, que una vez la SPU asignada termine de procesarla, la volverá a CIFRAR para que pueda regresar a su destino.

El proceso CIFRADO < --- > DESCIFRADO se realiza a nivel CACHÉ <--> SPU con lo cual es prácticamente imposible interceptar ésta información, sobre todo teniendo en cuenta que está el HYPERVISOR supervisando absolutamente todo lo que se hace.

-------------------------------------------

No he leido, todavía, bien los posts de devnul pero mañana o pasado los pienso leer, que seguro aprendo cosas que ignoro o se me han pasado.

El tema de la llave maestra es porque Sony envia siempre los .pkg cifrados de tal forma que TODAS las consolas lo entienden (pueden descifrarlos y procesar esa información).
keops80 escribió:Buenas, voy a intentar explicarlo yo con mis palabras (un poco más técnico) como solicitais algunos...

Aunque vuelvo a felicitar a devnul sobre todo por las risas, que además espero que me corrija si estoy equivocado.

A ver un proceso ha de ser ejecutado en una SPU.

Bien, este proceso viaja en un BUS de datos desde su origen (HD, Blue-Ray, Red... ect) hasta una parcela de memoria RAM que es exclusiva para ella.

Imaginemos que este proceso ocupa 14kb, pues ya tiene reservado para el solito la dirección física de memoria que comprende desde F0001 hasta F1900 (ejemplo hipotético).

Bien una vez que le llegue el momento de ser ejecutado, viaja nuevamente por el Bus de datos hasta una SPU.

La CPU de la PS3 tiene varias SPU'S que cada una ejecuta un proceso que NO SE MEZCLAN.

Cada SPU tiene asigando sus procesos y cada proceso se resuelve individualmente.

El trabajo del Hypervisor es monitorizar todo y cada una de las SPU'S y viendo que no hacen nada raro.

Cuando un proceso hace algo raro, el hypervisor simplemente elimina este proceso.

La primera vez que se realiza la eliminación no pasa nada, pero la segunda vez, según tengo entendido, el hypervisor lo recuerda y lo elimina incluso antes de llegar a cualquier SPU.

------------------------------------------------

El tema del cifrado, como bien nos ha explicado devnul se realiza en la misma CPU.

El proceso SIEMPRE VIAJA CIFRADO desde cualquier contenedor (HD, Blue-Ray, ect) hasta que va a ser procesado.

¡¡ATENCIÓN!!

Un proceso NUNCA puede ser procesado estando CIFRADO ya que la CPU no lo entiende, no es capaz de procesar estos datos.

Bien, una vez que el proceso cifrado se encuentra en la caché de la CPU es descifrado por la SPU para ser procesada, que dicha información se guarda en la caché del micro DESCIFRADA.

(Cada SPU tiene un espacio de caché reservada para el y otra SPU no puede utilizar dicho espacio).

Este esta información ahora sí va a ser procesada, que una vez la SPU asignada termine de procesarla, la volverá a CIFRAR para que pueda regresar a su destino.

El proceso CIFRADO < --- > DESCIFRADO se realiza a nivel CACHÉ <--> SPU con lo cual es prácticamente imposible interceptar ésta información, sobre todo teniendo en cuenta que está el HYPERVISOR supervisando absolutamente todo lo que se hace.

-------------------------------------------

No he leido, todavía, bien los posts de devnul pero mañana o pasado los pienso leer, que seguro aprendo cosas que ignoro o se me han pasado.

El tema de la llave maestra es porque Sony envia siempre los .pkg cifrados de tal forma que TODAS las consolas lo entienden (pueden descifrarlos y procesar esa información).


Explicado perfectamente :) solo un pequeño detalle. La firma es con una clave publica (de sony) y la desencriptacion es con una clave privada (master Key, que de esta si que solo hay una) De publicas hay N.

Es como (ejemplo del hotel) un huesped tiene la llave de su habitacion (clave publica) con esa llave puede abrir su puerta pero no la de otra persona.

El gerente tiene una llave maestra (key master) que abre todas las piuertas .

Si una persona se queda encerrada en su habitacion (contenido cifrado porque nosabemos el nombre del imbecil que se ha encerrado en la habitacion) el gerente va ahi con su llave maestra, abre la puerta, y le pega dos collejas al tipo :) por cerrarse :)

Un detalle mas, la informacion desencriptada que guarda en la cache de esa SPU, no puede ser accedida mediante otra SPU,y solo tendra acceso la SPU propietaria de esa cache, por lo que es IMPOSIBLE, acceder al contenido de la cache.

MOULSIN decia...


Tengo la impresion de que deberia haber una tercera encriptacion;
una de verdad, jeje, de las de siempre.
Una encriptacion sobre contenidos tanto en el disco duro, como quizas, la misma para el contendido del BR.
Se sabe que o quien xD desencripta el disco? Al Cell le llega el dato desencriptado por parte de un componente diferente o recibe el paquete "tal cual" y ademas de su propia seguridad y de procesar el flujo de informacion lo desencripta?



La hay la hay... el propio BD y el propio BR se encargan de ello. Lo habia puesto justo encima del mensaje que has escrito , en las protecciones que llevan los BR y los BD



(EDITADO)

Por cierto, no se si se sabe exactamente que es una NAND... (ya que se pone el nombre pero no se si sabeis las caracteristicas que tiene) asi que pondre una comparacion de lo que teniamos hasta ahora (las NOR) y lo que tenemos ahora (las NAND) y las putadillas que representa tener una NAND


************************
* Memoria flash de tipo NOR *
************************

En las memorias flash de tipo NOR, cuando los electrones se encuentran en FG, modifican (prácticamente anulan) el campo eléctrico que generaría CG en caso de estar activo. De esta forma, dependiendo de si la celda está a 1 ó a 0, el campo eléctrico de la celda existe o no. Entonces, cuando se lee la celda poniendo un determinado voltaje en CG, la corriente eléctrica fluye o no en función del voltaje almacenado en la celda. La presencia/ausencia de corriente se detecta e interpreta como un 1 ó un 0, reproduciendo así el dato almacenado. En los dispositivos de celda multi-nivel, se detecta la intensidad de la corriente para controlar el número de electrones almacenados en FG e interpretarlos adecuadamente.

Para programar una celda de tipo NOR (asignar un valor determinado) se permite el paso de la corriente desde el terminal fuente al terminal sumidero, entonces se coloca en CG un voltaje alto para absorber los electrones y retenerlos en el campo eléctrico que genera. Este proceso se llama hot-electron injection. Para borrar (poner a “1”, el estado natural del transistor) el contenido de una celda, expulsar estos electrones, se emplea la técnica de Fowler-Nordheim tunnelling, un proceso de tunelado mecánico – cuántico. Esto es, aplicar un voltaje inverso bastante alto al empleado para atraer a los electrones, convirtiendo al transistor en una pistola de electrones que permite, abriendo el terminal sumidero, que los electrones abandonen el mismo. Este proceso es el que provoca el deterioro de las celdas, al aplicar sobre un conductor tan delgado un voltaje tan alto.

Cabe destacar que las memorias flash están subdividas en bloques (en ocasiones llamados sectores) y por lo tanto, para el borrado, se limpian bloques enteros para agilizar el proceso, ya que es la parte más lenta del proceso. Por esta razón, las memorias flash son mucho más rápidas que las EEPROM convencionales, ya que borran byte a byte. No obstante, para reescribir un dato es necesario limpiar el bloque primero para después reescribir su contenido.

**************************
* Memorias flash de tipo NAND *
**************************

Las memorias flash basadas en puertas lógicas NAND funcionan de forma ligeramente diferente: usan un túnel de inyección para la escritura y para el borrado un túnel de ‘soltado’. Las memorias basadas en NAND tienen, además de la evidente base en otro tipo de puertas, un coste bastante inferior, unas diez veces de más resistencia a las operaciones pero sólo permiten acceso secuencial (más orientado a dispositivos de almacenamiento masivo), frente a las memorias flash basadas en NOR que permiten lectura de acceso aleatorio. Sin embargo, han sido las NAND las que han permitido la expansión de este tipo de memoria, ya que el mecanismo de borrado es más sencillo (aunque también se borre por bloques) lo que ha proporcionado una base más rentable para la creación de dispositivos de tipo tarjeta de memoria.

*****************
*LO MAS DIVERTIDO*
*****************

Comparación de memorias flash basadas en NOR y NAND [editar]

Para comparar estos tipos de memoria se consideran los diferentes aspectos de las memorias tradicionalmente valorados.

* La densidad de almacenamiento de los chips es actualmente bastante mayor en las memorias NAND.

* El coste de NOR es mucho mayor.

* El acceso NOR es aleatorio para lectura y orientado a bloques para su modificación. Sin embargo, NAND ofrece tan solo acceso directo para los bloques y lectura secuencial dentro de los mismos (cosa que realmente ES INTERESANTE, pero no para nuestros intereses,mas bien lo contrario)

* En la escritura de NOR podemos llegar a modificar un solo bit. Esto destaca con la limitada reprogramación de las NAND que deben modificar bloques o palabras completas (segunda putadilla)

* La velocidad de lectura es muy superior en NOR (50-100 ns) frente a NAND (10 µs de la búsqueda de la página + 50 ns por byte).

* La velocidad de escritura para NOR es de 5 µs por byte frente a 200 µs por página en NAND.

* La velocidad de borrado para NOR es de 1 s por bloque de 64 KB frente a los 2 ms por bloque de 16 KB en NAND.

* La fiabilidad de los dispositivos basados en NOR es realmente muy alta, es relativamente inmune a la corrupción de datos y tampoco tiene bloques erróneos frente a la escasa fiabilidad de los sistemas NAND que requieren corrección de datos y existe la posibilidad de que queden bloques marcados como erróneos e inservibles (MUY INTERESANTE ;) )
Y en cuanto a los dump de las NAND que han dado tema a abrir este post. ¿Entiendo entonces que lo único que tenemos son unos archivos dumpeados sin más? Quiero decir, que tenemos un BIN o un HEX (u otra cosa, no se en que formato se habrá dumpeado) pero sin posibilidad de abrirlo e investigar un poco?
Ojobenito escribió:Y en cuanto a los dump de las NAND que han dado tema a abrir este post. ¿Entiendo entonces que lo único que tenemos son unos archivos dumpeados sin más? Quiero decir, que tenemos un BIN o un HEX (u otra cosa, no se en que formato se habrá dumpeado) pero sin posibilidad de abrirlo e investigar un poco?


He ampliado mi respuesta anterior explicando que es y como va una NAND.

Si el contenido del dump, hubiera estado desencriptado :) seria mmmmmmm hasta interesante y todo :)


PD: lo que entiendo de ese post, es que ha exo un programa para dumpear el contenido de la nand.
devnul me da q tu vas a dar con la forma de cargar backups
jajajaja :)

Desgraciadamente, el dia 2 se acaban mis vacaciones y vuelvo a mis proyectos de desarrollo de softw, por lo que mi tiempo libre es nulo.

Pero si es cierto, que me tiene MUY picado el tema y es una lastima no poder dedicarle mas horas al asunto.
devnul escribió:jajajaja :)

Desgraciadamente, el dia 2 se acaban mis vacaciones y vuelvo a mis proyectos de desarrollo de softw, por lo que mi tiempo libre es nulo.

Pero si es cierto, que me tiene MUY picado el tema y es una lastima no poder dedicarle mas horas al asunto.


q lastima no te dejan aprovechar esa pedazo de mente q tienes [bad] pq la verdad yo creo q lo acabarias sacando

x cierto tienes los mismo años q mi padre y felicidades q mañana es tu cumple x lo q veo [fies]

y tambien gracias x la explicacion del hotel xq no entiendo yo con 15 años lo haya entendido todo a la 1º con tu explicacion y gente de veintipico diciendo q no lo entiende. tu sigue asi maquina ;-)
blue_dragon escribió:
q lastima no te dejan aprovechar esa pedazo de mente q tienes [bad] pq la verdad yo creo q lo acabarias sacando

x cierto tienes los mismo años q mi padre y felicidades q mañana es tu cumple x lo q veo [fies]

y tambien gracias x la explicacion del hotel xq no entiendo yo con 15 años lo haya entendido todo a la 1º con tu explicacion y gente de veintipico diciendo q no lo entiende. tu sigue asi maquina ;-)


La fecha de nacimiento no es la correcta, odio poner datos para registrarme asi que estan puestos a la tuntun :) pero bueno soy del 78 :) y gracias por el comentario :)
feliz 2oo8 a la Scene, Devnul maquina! :D
Igualmente :)

Añado dos links interesantes, puesto que de encontrarse algo relevante se publicara aqui antes que en cualquier otro lado (por motivos asquerosamente obvios) :)

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=739

Y una curiosidad ;) Un bug tralallaa :)

http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=14019785�

Y aqui, todo el arsenal de guerra

http://www.ibm.com/developerworks/power/cell/documents.html



*********************************************
*Cell BE Security SDK v3.0 Installation and User's Guide *
*********************************************
User Guide

The IBM Security SDK for Cell BE is a complete package of tools for security-sensitive applications. Broadly speaking, users can choose between two approaches. With the first approach, the application developer simply signs and encrypts SPU (Synergistic Processing Unit) applications. The applications will remain encrypted until immediately before execution thus thwarting reverse engineering and piracy attempts. Furthermore, the application is verified for authenticity and integrity immediately before execution.

This feature makes tampering, reverse engineering and piracy much more difficult for the adversary. In essence, the platform and the tools provide a secure communication channel between the application developer and the legitimate application user. For applications which require a higher level of protection, there is the second approach which builds upon the first approach.

This approach invokes the hardware SPU isolation mode whereby the hardware provides a “vaulted” execution environment for the SPU application. The applications are decrypted and verified immediately before execution just as in the first approach, but the decrypted and verified application is further protected during execution.

This feature is unique to the Cell BE and is considered a processor architecture differentiator.


http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/AEBFE7D58B5C36E90025737200624B33/$file/CBE_Secure_SDK_Guide_v3.0.pdf

Publication Number: v3.01

Revision Date: 10/09/07
El enlace del bug no funciona....

¿No le interesa a IBM que le encuentren uno?

[sati] [sati] [sati] [sati] [sati] [sati] [sati] [sati] [sati]
some bugs on cell SDK in vmx2spu.h

At first, I thougt that it was my fault.
But, There are some funny bugs in cell SDK.

/opt/IBM/cell-sdk-1.1/sysroot/usr/spu/include/vmx2spu.h:1518 'VEC_SPLAT_S23'->'VEC_SPLAT_S32'
/opt/IBM/cell-sdk-1.1/sysroot/usr/spu/include/vmx2spu.h:2378 'VEC_LIERAL'->'VEC_LITERAL'

and when I compiled with "vmx2spu.h", I had to change some header files.
/opt/sce/toolchain-3.2/spu/spu/include/stdio.h:290 'new'->'new_val'
==> because "new" is a reserved keyword
/opt/IBM/cell-sdk-1.1/src/include/spu/stddef.h: 30 comment out(//...) typedef char wchar_t;
==> because of re-definition

I compiled my code that includes some vmx intrinsics as follwing:
/opt/sce/toolchain-2.3/spu/bin/spu-g++ -W -Wall -Winline -Wno-main -I. -v -I .. -I ../include -I /home/dhcho/sdk/sysroot/usr/spu/include -include spu_intrinsics.h -O3 -fno-exceptions -fno-rtti -c spu.cpp

I used tool-chain 2.3 instead of tool-chain 3.2. Because the spu-g++(version 4.0.2) in toolchain 3.2 has a problem to compile vmx2spu.h
Is there anyone who success to compile vmx2spu.h on SDK 1.1?

Regards Ryan

IBM employee or contractor CellServ
Re: some bugs on cell SDK in vmx2spu.h
response to: RyanKim's post

There are known issues with vmx2spu.h in 1.1, and unfortunately they require both changes to header files and the compiler, so they cannot be fixed in 1.1, but should be in the next release.

--
IBM SDK Service Administrator
muy bien explicado,as dejado loco a medio eol con lo que sabes tio,por lo menos al que escribe esto.Lastima que no tengas tiempo,por que es mas interesante lo que as escrito en dos dias,que los 20.000 post sobre si ya se puede(podra)cargar copias.

Feliz año!!
Me estais haciendo recordar los viejos tiempos en #hackers de Undernet (de hace 10 años) y me esta entrando la morriña :)

Si tuviera la ps3 seria mas facil dedicarle mas tempo "util", y no tener que trastear con un emulador de cells broadbands para ver como funcionan,luego ver si se comporta igual en el otro lado etc..

Pero se que si la tengo, lo primero que voy a hacer es desmontarla, monitorizar los cells, y ponerme a programar como un descosido xD

Peeero... se me va de presupuesto una ps3 y tira mas la economia, que el pique personal que llevo con Sony e IBM.

De todos modos,aunque el dia dos vuelva al curro, intentare dedicarle tiempo a este tema el fin de semana, pero claro, no es lo mismo estar de vacaciones, relajado y poderme meter de lleno, que estar toda la puñetera semana diseñando e implementando nuevos algoritmos,softw,etc y luego el finde, trivial_intelectual xD

Siendo practicos, para piratear la ps3 se necesita pasta para tener..

a) Ps3
b) grabadora de BR
c) Juego/s Original/es
c) BRs Copia Juego Original


Y esto suponiendo que no se te joda ningun procesador, ni el lector de BR al hacer pruebas.

Lo que mas me pica, es que los CELLS no se han diseñado exclusivamente para estar en una "consola" (aunque sea de next-gen) sino que su verdadero target (y su futuro proximo negocio millonario) es la implementacion de esta arquitectura como servidores brutales, tanto por capacidad de proceso de trabajo como de seguridad implicita, pasando del Sistema Operativo.

Si se revienta el Hardware... (la seguridad me refiero) las empresas no pagarian un duro por lo que les estarian intentando vender, un chip capaz de tratar la informacion de forma inteligente, que tiene un nivel de seguridad por encima del Sistema Operativo, que no importa si atacas al SO porque el , esta al margen y por encima, vamos, que es Dios. Si se demuestra que hay (que la habra) alguna vulnerabilidad (otra cosa es que nosotros podamos utilizar dicha vulnerabilidad para nuestros intereses) en los CELLS, el negocio se les va a pique.

Como dije en un principio (coincidiendo en otro hilo con Hermes) a mi no me interesa ni la carga de Backups (porque no tengo ps3) ni el homebrew, es decir que no lo hago por ninguno de estos dos motivos, es simple y llanamente, un pique (llamale reto) personal.
ummmmm despues de este gran comentario, empiezo a sentirme un conejillo de indias de sony...

que puede decir: vamos a vender cinco millones de ps3, vamos a ver si alguien la destripa (cosa que quizas ellos sepan de ante mano que es imposible)... y luego, sabienbdo todo el mundo despues de un par de años de invulnerabilidad que es imposible meterle mano a este sistema de seguridad de encriptacion van a las grandes empresas de contenidos multimedia (esas que por culpa de la mal llamada pirateria han dejado de ganar millones de dolares) y les venden el invento pa que ellos a su vez nos obligen a comprar sus "ficheros multimedia" totalmente protegidos y encriptados sin posibilidad de pirateo....

mal asunto se plantea... me da a mi que vamos a estar pagando los juegos a 70 euros muchos años... lo unico que nos queda es el EBAy¡¡¡¡¡


por cierto, una pregunta personal Devnul, ¿que opinas con tus conocimientos de las capacidades tecnicas de esta consola? ¿es realmente tan potente como se nos vende, o por el contrario, tiene serias limitaciones como se comenta por algunos lares?

yo por mi parte flipo con esta maquina cada dia mas... y en el fondo, putada de encripatacion aparte, me encanta ver como los de sony se han comido la hoya para conseguir este trasto inquebrantable...

y por otro lado, yo que era de los que pensaba que la pirateria beneficiaba a sony, empieza a dudar de ese argumento...
Yo creo que si la beneficia, pero con estas medidas de seguridad me hace pensar que quiere tener el control ella misma(Sony) sobre cuando y como se cargaran backups en su maquina.
Y creo que no se lograria ultrajar esta maquina si no es por una infiltración de dicha compañia. Pienso que depende de varios factores :

-Que el Blueray no triunfe y que le coma terreno el HD-DVD.

-Que las consolas vendidas no lleguen a las espectativas de Sony.

-Que saquen algo mas rapido y ventajoso que el chip Cell (en el caso que tambien las ventas no sean del agrado de Sony).

-Ganar más pasta vendiendo grabadoras BR, discos virgenes de este formato, fabricarlo en masa y generar muchos beneficios.

Es mi opinión claro esta, pero creo que por ahi van los tiros. Y que tarde o temprano por alguna de las anteriores razones Sony deje una puerta abierta a su protegida consola. Si aun no ha salido nada me pongo en lo peor, o es imposible, o los que se han dedicado a ultrajar la maquina son un poco "novatos" en este terreno. Y creo que va a ser la primera opción, es IMPOSIBLE.

Pues si este sistema no es vulnerable a los hackers lo tenemos claro, parece que ya empiezo a ver un futuro muy negro en ordenadores con este tipo de procesadores sin posibilidades de usar software sin firmar.
No es solo por cargar backups como se ha dicho por paginas atras de este hilo, si no porque esta en juego nuestra libertad para evitar el control total de las empresas sobre nosotros. Un futuro negro se avecina con este pedazo de CELL (Ahora entiendo la mania de Sony por meterlo en la play3) .[enfado1]
Pañeros, ante todo FELIZ AÑO, y yo como persona y que vivimos en un pais democratico donde cada uno puede decir lo que crea, hombre claro esta sin insultar a nadie, yo segun escribis y yo leo si la estrategia de sony es la que comentais, que sepais que le queda poco tiempo a sony en este mundo del entretenimiento,, por que como habreis visto ya con varias consolas como no se puedan trucar, para avaratar precios, va de culo y cuesta abajo, por que hasta el mismisimo tito Bill G**es, se a dado cuenta de que consola que no se truque va a las cañas, y yo estoy seguro que si el tio Bill, quisiera banearia a todos sea cual fuesea el firmware que tubiese, y os aseguro que este año nuevo que empieaza se van a seguir haciendo avances en la scene de la 360, y como a sony se le pase por la cabeza no habrir el grifo, os aseguro que le queda este año, de vida, y mas sabiendo que para mi parecer y mi opinion como decia rocio jurado que en paz descanse, va a volver a este mundo del entretenimiento " LA MAS GRANDE " de todas y con muchas años de experiencia " SEGA ", y esta seguro que ha aprendido del pasado.
aprilia escribió:Pañeros, ante todo FELIZ AÑO, y yo como persona y que vivimos en un pais democratico donde cada uno puede decir lo que crea, hombre claro esta sin insultar a nadie, yo segun escribis y yo leo si la estrategia de sony es la que comentais, que sepais que le queda poco tiempo a sony en este mundo del entretenimiento,, por que como habreis visto ya con varias consolas como no se puedan trucar, para avaratar precios, va de culo y cuesta abajo, por que hasta el mismisimo tito Bill G**es, se a dado cuenta de que consola que no se truque va a las cañas, y yo estoy seguro que si el tio Bill, quisiera banearia a todos sea cual fuesea el firmware que tubiese, y os aseguro que este año nuevo que empieaza se van a seguir haciendo avances en la scene de la 360, y como a sony se le pase por la cabeza no habrir el grifo, os aseguro que le queda este año, de vida, y mas sabiendo que para mi parecer y mi opinion como decia rocio jurado que en paz descanse, va a volver a este mundo del entretenimiento " LA MAS GRANDE " de todas y con muchas años de experiencia " SEGA ", y esta seguro que ha aprendido del pasado.


+10000
cierto es eso d q por muchos hackers q haya estudiando el sistema PS3, hasta q a sony no le salga d los mismísimos no se van a cargar backups....claro que ya tiene que ir aflojando porq wii y xbox 360 stán ya "reventadas" y komo siga sin ceder.....se van todos los fieles de sony a la competencia.
saludos y feliz 2oo8
Feliz 2008

Como bien decis, por un lado están los intereses de Sony por vender consolas masivamente (es su negocio).

Pero os olvidais que como bien nos dice Devnul que las aplicaciones de la arquitectura CELL no estaba pensada en un principio para ser implantada en el negocio de las consolas.

Por otro lado está el negocio de las películas, música y juegos.

A IBM no le interesa en absoluto, como bien indicó Dev, que se le hackee el sistema, ya que entonces toda la inversión que realizó se quedaría en evidencia.

A Sony le interesa que su consola sea pirateable (pero tiene que hacer su teatrillo).

Por experiencia Sony no es su primera consola que pone en el mercado.

Entre los años 1994 hasta 2006, se han vendido 250 millions de PlayStation en todo el mundo, juntando ventas de PSOne, PS2, PSP y PS3.

Sony ha vendido, seguro que, más consolas que juegos en lo que lleva de negocio con las consolas.

Yo mismo he visto con mis propios ojos estas navidades a la gente comprando juegos de PSP y PS2 a mansalva que por el contrario de PS3 ya era más raro de ver.

Si, hay menos consolas vendidas de PS3 que de PS2 o PSP pero...

Pienso que mientras no se puedan correr las copias no van a vender demasiadas.

También se puede pensar que esto es algo que deseamos todos los que hemos adquirido una PS3 (que es cierto), pero pensad que ya hubo filtración del firmware debug con carga de isos y emulación de blue-ray, es un claro ejemplo de como Sony quiere una vulnerabilidad en su consola.

Recordemos que lleva un año en el mercado y han tenido que modificar el hardware para avaratar costes, incluso perdiendo dinero como he llegado a oir (cosa que no me creo demasidado).

Un compañero ha dicho que los hackers que están intentando acceder a la consola son unos novatos y tiene toda la razón.

Pensad que esta arquitectura es la primera vez que la tienen en sus manos, ya que todos los sistemas son de un solo procesador y no existe el hypervisor.

Estudiar esta arquitectura va a costar tiempo, pero no penseis que no se conseguirá...

Como bien indicó Dev, en IBM existe un foro y muchísima documentación sobre la arquitectura CELL inclusive el emulador SDK 3.0 que corre bajo linux.

Bueno, no me enrollo más.

Con todo esto quiero decir que no desespereis que algo llegará, más tarde o más temprano ya que si no PS3 no tendrá futuro y Sony lo sabe.

El ejemplo más claro está en la bajada de precio de PS3 que en un principio esperaron un año para esta bajada mientras Sony decía que era imposible y que no la rebajarían.

Siempre es el mismo cuento, pero al final... ceden.

Si no hay consumo, no hay negocio y si no hay negocio...
devnul escribió:
Para ver el contenido de los datos desencriptados? No ayudaria mucho.

Imagina que el codigo de la NAND es el siguiente:

[...]


Lo del medio no lo entiendo, pero bueno, más o menos se entiende en su conjunto [360º] .

Supongo que también será imposible hacer un programa que coja los códigos de la nand e ir creando claves de encriptación aleatorias, y por fuerza bruta irlas probando.

No sé parece muy rebuscado [360º] .

Saludos y muchas gracias por aclararnos las dudas, eres el amo [plas] .
keops80 escribió:Feliz 2008

Como bien decis, por un lado están los intereses de Sony por vender consolas masivamente (es su negocio).

Pero os olvidais que como bien nos dice Devnul que las aplicaciones de la arquitectura CELL no estaba pensada en un principio para ser implantada en el negocio de las consolas.

Por otro lado está el negocio de las películas, música y juegos.

A IBM no le interesa en absoluto, como bien indicó Dev, que se le hackee el sistema, ya que entonces toda la inversión que realizó se quedaría en evidencia.

A Sony le interesa que su consola sea pirateable (pero tiene que hacer su teatrillo).

Por experiencia Sony no es su primera consola que pone en el mercado.

Entre los años 1994 hasta 2006, se han vendido 250 millions de PlayStation en todo el mundo, juntando ventas de PSOne, PS2, PSP y PS3.

Sony ha vendido, seguro que, más consolas que juegos en lo que lleva de negocio con las consolas.

Yo mismo he visto con mis propios ojos estas navidades a la gente comprando juegos de PSP y PS2 a mansalva que por el contrario de PS3 ya era más raro de ver.

Si, hay menos consolas vendidas de PS3 que de PS2 o PSP pero...

Pienso que mientras no se puedan correr las copias no van a vender demasiadas.

También se puede pensar que esto es algo que deseamos todos los que hemos adquirido una PS3 (que es cierto), pero pensad que ya hubo filtración del firmware debug con carga de isos y emulación de blue-ray, es un claro ejemplo de como Sony quiere una vulnerabilidad en su consola.

Recordemos que lleva un año en el mercado y han tenido que modificar el hardware para avaratar costes, incluso perdiendo dinero como he llegado a oir (cosa que no me creo demasidado).

Un compañero ha dicho que los hackers que están intentando acceder a la consola son unos novatos y tiene toda la razón.

Pensad que esta arquitectura es la primera vez que la tienen en sus manos, ya que todos los sistemas son de un solo procesador y no existe el hypervisor.

Estudiar esta arquitectura va a costar tiempo, pero no penseis que no se conseguirá...

Como bien indicó Dev, en IBM existe un foro y muchísima documentación sobre la arquitectura CELL inclusive el emulador SDK 3.0 que corre bajo linux.

Bueno, no me enrollo más.

Con todo esto quiero decir que no desespereis que algo llegará, más tarde o más temprano ya que si no PS3 no tendrá futuro y Sony lo sabe.

El ejemplo más claro está en la bajada de precio de PS3 que en un principio esperaron un año para esta bajada mientras Sony decía que era imposible y que no la rebajarían.

Siempre es el mismo cuento, pero al final... ceden.

Si no hay consumo, no hay negocio y si no hay negocio...



AAAAAAAAAAMENCISIMO EN TODO.

SALUDOS
es la prime vez q leo algo parecido no entiendo muxo del tema, pero me a gustado muxo y creo q e entendido bastantes cosas y e aprendido bastante del funcionamiento, creo aber entendido q solo los procesadores de la ps3 pueden codificar y descodificar los arxivos, nose si seria correcto, pero nose podria abrir una ps3 conectarla al pc meterle una serie de datos y ver q tipo de codificacion utiliza? ya se q no es tan facil como lo planteo yo, pero me gustaria saber q impedimentos abria en ello, aparte de la posibilidad de joder la ps3...
gracias al caballero de la explicacion del hotel muy currado, jeje y a todos los demas con las explicaciones.
275 respuestas
1, 2, 3, 4, 5, 6