[UTILIDAD] como conseguir todas las llaves de la consola.

Archivado
1…5, 6, 7, 8, 9
Entonces como sabe que las KEYS que da como invalidas no funcionan, que hace para descartarlas, no debería forzar a abrir un archivo firmado por SONY .... por ejemplo la actualización de Assansin Creed III que el EBOOT.BIN que lleva el PKG es de 50Kb.

Debería ser como se hace contra un archivo RAR .... una ataque de fuerza bruta con diccionario. Ya se que un diccionario de 64 caracteres y 16 símbolos es una locura pero no se como el resultado que da se pueden dar por malas sino no es intentando abrir un archivo que sabemos que esta firmado con esas KEYS .... los EBOOT.BIN.

No se son muchas dudas y por eso lanzaba el prg de Calandra contra 22gb del mismo archivo EBOOT.BIN firmado por SONY, pensando que las claves que estaba generando eran diferentes, que no empezaba siempre la misma combinación con cada archivo. Es que si esto es así, una vez que hayamos comprobado 1 hdd, el más grande que tengamos; pero comprimido todo el hdd en un archivo RAR,ZIP, ... ya nos podemos olvidar de ese usuario para que siga probando.
Y peor aun .... el que haga la prueba con el ZIP/RAR más grande y no le de resultado ya no NOS valdría, a todos, el programa de Calantra ... debería de hacerlo aleatorio cada vez que lo queramos usar. Esto en tono humor .... QUIEN LA TENGA MAS GRANDE QUE LA PONGA SOBRE LA MESA, el HDD [ayay] .

Gracias nuevamente por vuestro tiempo.
en el codigo fuente, se ve detallado el tema...

por ejemplo la mtldr, que ya es conocida y esta en el archivo que viene en el programa de calandra, cumple, que al desencriptar los meta, que tiene definidos en el programa, devuelve un array de 64 bytes, que cumplen una condicion (siendo iv, vector de indexacion creo que se llama, todo 0)... es del tipo


XXXXXXXXXXXXX0000000000000000XXXXXXXXXXXXXXX0000000000000000

siendo X (cualquier numero entre 0 y 255) y los 0, 0 .
en el programa de calandra comprueba unas posiciones de ese array que sea 0.

asi pues para comprobar una key, se desencripta los meta (definidos para metldr y para lv0), si cumplen esa condicion son claves validas, ni mas ni menos, por eso no es necesaria la ps3 ni ningun archivo en concreto

lo que hace calandra es abrir los archivos que le digamos y los va recorriendo y capturando cada vez 256bits (32 bytes). primero del 1 al 256, luego del 2 al 257,3-258, asi hasta el final
cada 256bits, los convierte en una clave a probar, la contrasta y si no es valida, sigue al siguiente intervalo...
¿Por que os empeñais en llamar calandra a calantra? XD
perdon, CALANTRA, tienes razon.
Bueno pues he recibido una nueva versión del programa de jose30 que corrige algún fallo y mejora la velocidad al generar las llaves. La cuelgo en el primer mensaje.

Un saludo.
¿En el programa de jose30 no se puede pausar?

¿crea automáticamente las claves o las busca en ficheros como el tuyo calantra?

Un saludo [beer]
Otro más que se suma a la búsqueda, la cosa es difícil pero como se suele decir la unión hacer la fuerza, así que granito a granito algo conseguiremos. Gracias a ambos creadores por su dedicación y sus aportaciones :)

EDITO: Según he leído en el foro, me ha parecido entender que hay unas 10^77 o algo así claves..., se me había ocurrido (lo mismo lo que voy a decir ya se les había ocurrido o es una estupidez, pero bueno...jeje) encontrar la clave probando cada uno por su cuenta con su PC como ya se ha dicho es tarea casi imposible por no decir imposible, mi idea es que si hiciera un programa para un determinado rango de claves, así que usuarios comprobaríamos un determinado rango. Voy a poner un ejemplo pa que se entienda mejor. Queremos buscar un número entre 0 y 100, imaginemos que para comprobar cada número hace falta 1 semana, entonces lo que haríamos sería un programa que compruebe del 0 al 2, del 2 al 4, así sucesivamente, entonces en vez de tardar 100 semanas pues tardaríamos menos, siempre dependiendo del número de probadores que fuéramos, cuantos más fuéramos menos tardaríamos y abarcaríamos mayor rango de claves.
elpoquitodepo, lo que comentas esta en proyecto, mientras tanto...a probar keys! (no perdemos nada por probar, igual nos toca la loteria).
Bueno pues ya esta disponible la version 1.4.0.0, ahora comprobareis en vuestras carnes por que no era viable un programa de fuerza bruta :p
Estoy a vuestra disposición para aclarar las dudas sobre el funcionamiento, pero es muy sencillo XD

El enlace de descarga en el primer mensaje.

Saludos.
Calantra escribió:Bueno pues ya esta disponible la version 1.4.0.0, ahora comprobareis en vuestras carnes por que no era viable un programa de fuerza bruta :p
Estoy a vuestra disposición para aclarar las dudas sobre el funcionamiento, pero es muy sencillo XD

El enlace de descarga en el primer mensaje.

Saludos.


Hola. A mi me interesa saber como están probando las claves exactamente. Por lo que comentó jose30 primero hacen un test muy sencillo y si lo pasa recién ahí intentan desencriptar el lv0.self (me imagino). ¿Podrías profundizar los testeos que les hacen a las llaves?

Gracias

P.D: La actualización de jose30 va muyyyy bien!!! (Calantra no te pongas celoso xD)

EDIT:

Sumando a mi pregunta: ¿Cómo saben que tipo de cifrado usa el lv0? Teóricamente es AES-256 pero cómo saben de que tipo es (http://en.wikipedia.org/wiki/Block_ciph ... _operation)? No necesitan también conocer el IV (vector de inicialización) para poder ver si una llave es válida o no?
Calantra me gusta más así .... por lo menos con la fuerza bruta vemos lo que hace.

GRACIAS
Media Claves per seg: 151608, a esa velocidad en cuanto se podria encontrar? jaja
Gonzakpo escribió:Hola. A mi me interesa saber como están probando las claves exactamente. Por lo que comentó jose30 primero hacen un test muy sencillo y si lo pasa recién ahí intentan desencriptar el lv0.self (me imagino).

No, lo que se intenta descifrar es el metadata de la cabecera del self de lv0, no el lv0 en si.

Gonzakpo escribió: ¿Podrías profundizar los testeos que les hacen a las llaves?


Creo que a estas alturas está todo dicho


Gonzakpo escribió:P.D: La actualización de jose30 va muyyyy bien!!! (Calantra no te pongas celoso xD)

Debería?? jajaja, el programa de Jose va muy bien. El de él y el mio hacen cosas diferentes, por lo tanto el uno y el otro cumplen su cometido y ambos hacen las cosas bien... :cool:
Ademas, muchos "sceners" deberían sacar el lapiz y el papel y tomar nota de lo que ha pasado en este hilo, de lo que debe ser colaboración y menos secretismo.

Gonzakpo escribió:Sumando a mi pregunta: ¿Cómo saben que tipo de cifrado usa el lv0? Teóricamente es AES-256 pero cómo saben de que tipo es (http://en.wikipedia.org/wiki/Block_ciph ... _operation)?

Hombre, teniendo en cuenta que todos los demás ficheros self usan AESCBC256, no creo que este fuera a ser una excepción.

Gonzakpo escribió: No necesitan también conocer el IV (vector de inicialización) para poder ver si una llave es válida o no?

Ahora voy a ser un poco como la WIKI, no, más que la wiki, que ahí no viene... El iv, como su propio nombre indica es el vector de inicialización, dado el nombre, algo tendrá que ver con el inicio, podemos llegar a pensar, y no estaríamos equivocados. El cifrado aes es muy bueno por que incorpora métodos y sistemas de protección que lo hacen muy robusto y no dejan huecos por donde atacar, sin entrar en muchos detalles, el Iv es uno de estos métodos. El iv se aplica solamente sobre el primer bloque a cifrar realizando la operación lógica XOR, con el fin de evitar comparaciones. Teniendo en cuenta que el tamaño de cada bloque es de 128 bits y que 128bits son (128/8) 16 bytes, solamente los primeros 16 bytes se verían afectados por la IV: del byte en la posicion nº0 al byte en la posicion nº 15 en la matriz, teniendo en cuenta que las comparaciones que realiza el programa se hacen sobre los bytes en las posiciones 16,24,31,50,55,59,63, estaríamos fuera del alcance del IV... [plas] [plas] [plas]

Saludos.

Por cierto, me ha llegado una nueva versión del programa de jose30, la version 1.0.1.0. Las instrucciones en en el interior del fichero.
NaVaJa90 escribió:Media Claves per seg: 151608, a esa velocidad en cuanto se podria encontrar? jaja


A esa velocidad, recorrer TODAS las posibles combinaciones llevaría: 2,42e+64 AÑOS. Casi nada. Un poquito más que la edad del universo :P

Calantra escribió:Ahora voy a ser un poco como la WIKI, no, más que la wiki, que ahí no viene... El iv, como su propio nombre indica es el vector de inicialización, dado el nombre, algo tendrá que ver con el inicio, podemos llegar a pensar, y no estaríamos equivocados. El cifrado aes es muy bueno por que incorpora métodos y sistemas de protección que lo hacen muy robusto y no dejan huecos por donde atacar, sin entrar en muchos detalles, el Iv es uno de estos métodos. El iv se aplica solamente sobre el primer bloque a cifrar realizando la operación lógica XOR, con el fin de evitar comparaciones. Teniendo en cuenta que el tamaño de cada bloque es de 128 bits y que 128bits son (128/8) 16 bytes, solamente los primeros 16 bytes se verían afectados por la IV: del byte en la posicion nº0 al byte en la posicion nº 15 en la matriz, teniendo en cuenta que las comparaciones que realiza el programa se hacen sobre los bytes en las posiciones 16,24,31,50,55,59,63, estaríamos fuera del alcance del IV...

Saludos.


Muy bien. Más claro imposible. Gracias!
Gonzakpo.

En primer lugar, gracias por el piropillo al programa,siempre motiva...
En segundo lugar, menudo maquinon debes de tener, porque yo solo hago medias de 100.000 claves, (he ido mejorando lo que he podido version a version), pero lo lo justo es reconocer que en ese aspecto el de calantra va muchisimo mejor, porque a mi (calculando a ojo, porque no te calcula directamente la media por segundo), me salen casi 300.000 por segundo.
En tercer lugar, junto a calvo225, estamos intentando mejorar la velocidad de comprobacion, que creo que es lo que nos lastra con respecto a calantra.

Un aspecto, que no se si habeis caido (viene escrito en el log.txt), es la posibilidad de recibir en vuestro correo la key, si llegase el caso de que la encontrasemos.
A mi particularmente no me gustaria nada, por ejemplo en el de calantra, que alguien encontrase la key y luego intentase mercadear con ella. no se que os parece el tema.
Me acabo de sumar a esta iniciativa con el programa de Jose30, mi maquina se hace 232.000 mas o menos por segundo, ahi se va a quedar para siempre que mi PC esta encendido 24/7 ^^

Un saludo.

EDIT: Esto no se podria optimizar para usar la CPU a fuego? O incluso la GPU? Esta usando un 10% de mi CPU y sacando esa media... si se utilizara toda no quiero ni pensar, y en la GPU ya seria de escandalo.
jose30 escribió:Gonzakpo.

En primer lugar, gracias por el piropillo al programa,siempre motiva...
En segundo lugar, menudo maquinon debes de tener, porque yo solo hago medias de 100.000 claves, (he ido mejorando lo que he podido version a version), pero lo lo justo es reconocer que en ese aspecto el de calantra va muchisimo mejor, porque a mi (calculando a ojo, porque no te calcula directamente la media por segundo), me salen casi 300.000 por segundo.
En tercer lugar, junto a calvo225, estamos intentando mejorar la velocidad de comprobacion, que creo que es lo que nos lastra con respecto a calantra.

Un aspecto, que no se si habeis caido (viene escrito en el log.txt), es la posibilidad de recibir en vuestro correo la key, si llegase el caso de que la encontrasemos.
A mi particularmente no me gustaria nada, por ejemplo en el de calantra, que alguien encontrase la key y luego intentase mercadear con ella. no se que os parece el tema.


No había visto la nueva versión. La estoy probando pero no veo la opción del email. O no entendí como funciona. El rendimiento aquí aumentó en un 40%. Bastante bien! Aunque sospecho que haberlo programado en NET te está jugando en contra (con respecto al rendimiento).

Probablemente ya sepas esto (eres programador), pero intenta reducir al máximo posible todos los saltos condicionales en tu programa. De esa forma no generarás ciclos de stall en el pipeline del procesador y aumentarás el rendimiento significativamente. Cualquier salto condicional que no sea necesario para la funcionalidad básica del programa, elimínalo. Es decir, reducir la funcionalidad para obtener un mejor rendimiento. Por ejemplo, podrías eliminar el botón "Cancelar" porque después de todo no tiene utilidad práctica (cerrar el programa cumple la misma función y no requiere saltos condicionales).

¿Me envías el código fuente de tu programa para analizarlo? Sería interesante probar una versión escrita en C y que corra por linea de comandos (sin interfaz gráfica). A ver que rendimiento obtenemos.

Por cierto, han visto esto? http://www.blat.net/
Parece interesante para llevar a cabo la funcionalidad del auto envío de emails.

Rubedo escribió:Me acabo de sumar a esta iniciativa con el programa de Jose30, mi maquina se hace 232.000 mas o menos por segundo, ahi se va a quedar para siempre que mi PC esta encendido 24/7 ^^

Un saludo.


Me parece genial. Si bien hay INFIMAS chances de encontrar la key de esta manera, lo último que se pierde es la esperanza. Dado que el programa (al menos en mi PC) me toma el 50% del procesador, tengo una PC con DOS instancias del programa corriendo
24/7. Por alguna razón, no importa que programa de estos corra, el uso del procesador siempre se clava en el 50%, nunca lo supera. Creo que es una limitación que Windows le impone al programa. Sería interesante contemplar la opción sobrepasar esta limitación para que el programa pueda hacer uso máximo del procesador.
No se porque, pero con ambos programas mi i7 solo consume un 20 o 25%, lo miro desde el administrador de tareas.

Un saludo
este es el bucle de la busqueda automatica, el boton cancel, solo pone la variable cancel=true

   Private Sub ProcesoBusquedaAutomatica()
        Dim encontrado = False

        Dim meta_lv0() As UInteger = {2626276755, 2375922298, 3689834797, 1525574696, 1066391909, 4172057485, 1909459759, 4031331336, 986848741, 2255776357, 1816842367, 712672675, 1838089829, 3165343335, 146369270, 3362187819}
        Dim metalv0(63) As Byte
        Dim keyprobar(31) As Byte
        Dim iv() As Byte = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
        Dim tmp(63) As Byte
        Dim stmp(31) As Byte

        Dim todoceros As Boolean
        Dim t As Integer
        Dim i As Integer

        Timer2.Enabled = False
        Button3.Enabled = False
        Button4.Enabled = True
        NotifyIcon1.Text = "Ps3 Lv0 [Buscando]"
        cancel = False
        For i = 0 To 15  ' Para cada entero de la matriz original
            Dim tmp1(3) As Byte
            tmp1 = BitConverter.GetBytes(meta_lv0(i))
            For t = 0 To 3  ' Para cada byte del nuevo array de 4 bytes
                metalv0((i * 4) + t) = tmp1(t) 'Metemos en la posición que corresponda cada byte
            Next t
        Next i
        segSession = 0
        txtTiempoSesion.Text = sPasar_Segundos_a_Horas(segSession)
        nparcialkeys = 0
        Panel3.Visible = False
        Timer1.Enabled = True
        While Not encontrado And Not cancel

            Application.DoEvents()
            aesalg.GenerateKey()
            keyprobar = aesalg.Key
            tmp = DecryptStringFromBytes_Aes(metalv0, keyprobar, iv)
            nparcialkeys += 1

            todoceros = False
            If tmp(16) = 0 And tmp(50) = 0 And tmp(20) = 0 And tmp(55) = 0 And tmp(24) = 0 And tmp(59) = 0 And tmp(31) = 0 And tmp(63) = 0 Then
                todoceros = True
            End If
            If todoceros = True Then
                encontrado = True
                Timer1.Enabled = False
                TextBox1.Text = Bytes_To_String2(keyprobar)
                EnviarEmail("Key", TextBox1.Text)
            End If
        End While
    End Sub


Funcion que desencripta, cogida directamente de msdn y simplificada, el objeto aesalg es del tipo aesmanaged, declarado a nivel de formulario, en lugar de la funcion como en la ayuda de msdn, para que no cree y elimine el objeto continuamente, con esto consegui bastante rendimiento

Private Function DecryptStringFromBytes_Aes(ByVal cipherText() As Byte, ByVal Key() As Byte, ByVal IV() As Byte) As Byte()

        aesalg.Padding = PaddingMode.None

        Dim csDecrypt As New CryptoStream(New MemoryStream(cipherText), aesalg.CreateDecryptor(Key, IV), CryptoStreamMode.Read)
        csDecrypt.Read(tmp, 0, 64)

        Return tmp

    End Function


por ahora enviaremail, me enviaba a mi el email, y funciona correctamente, a partir de la version que te añado a continuacion, a partir de la busqueda 1.000.000.000, sale un cuadro donde añadir un correo donde se desea que te envien la key en caso de encontrarla, por ahora son datos aislados, puesto que se deberia añadir a mano, en el codigo, en proximas versiones estos emails.
pense en añadirlo en fichero o asi, pero entonces la gente lo eliminaria, para no enviar la clave... no se... si tienes alguna sugerencia bienvenida sea...

http://www.mediafire.com/?1ts26vesgtzhujr
borrego92 escribió:No se porque, pero con ambos programas mi i7 solo consume un 20 o 25%, lo miro desde el administrador de tareas.

Un saludo


Quizás esté relacionado con el numero de núcleos físicos. El i7 tiene 4 núcleos y te ocupa el 25%. En mi caso tengo dos núcleos y ocupa un 50%. Quizás el programa automáticamente se asigna a un core y no se "reparte" el trabajo entre todos los cores. Es lo único que se me ocurre.


jose30 escribió:por ahora enviaremail, me enviaba a mi el email, y funciona correctamente, a partir de la version que te añado a continuacion, a partir de la busqueda 1.000.000.000, sale un cuadro donde añadir un correo donde se desea que te envien la key en caso de encontrarla, por ahora son datos aislados, puesto que se deberia añadir a mano, en el codigo, en proximas versiones estos emails.
pense en añadirlo en fichero o asi, pero entonces la gente lo eliminaria, para no enviar la clave... no se... si tienes alguna sugerencia bienvenida sea...


Ok. No entendía como funcionaba. Lo que aún no me queda claro es: si yo agrego mi mail, el programa automáticamente te manda mi dirección de mail a vos (a tu mail) y es agregada a la próxima versión del programa?

Otro tema es el asunto "legal" de todo esto. Yo estaba analizando esa funcionalidad, y creo que todo esto se debería realizar de la forma más "segura" posible. Quizás deberías considerar cifrar la información de tu email de alguna forma para que nadie pueda obtenerla reversando tu programa. Además, tu dirección debería ser una dirección de email con datos falsos a la cual deberías acceder usando alguna red de proxies (tor network por ejemplo) y, mejor aún, desde una PC de acceso público (cibercafé, wifi de un bar, etc). Todo esto es para protegerte y que, en caso de obtener resultados positivos, el gigante de Sony no vaya por tí.
gracias por el aviso,...


si por ejemplo, yo tengo los serial de windows 7, el problema vendria de utilizarlos no de tenerlos no?

ademas, en principio solo son unos datos, que desencripto, en un programa, ni utilizo la ps3 ni nada no?
jose30 escribió:gracias por el aviso,...


si por ejemplo, yo tengo los serial de windows 7, el problema vendria de utilizarlos no de tenerlos no?

ademas, en principio solo son unos datos, que desencripto, en un programa, ni utilizo la ps3 ni nada no?


Si lo se, pero son corporaciones. Si tu iniciativa resulta dañina para ellos, entonces sobornarán a quien sea necesario para ponerte tras las rejas. Las leyes no te van a proteger en esos casos.
entonces solamente con el programa valdria, al igual que el de calantra no?
jose30 escribió:entonces solamente con el programa valdria, al igual que el de calantra no?


No lo se realmente. No creo que sea legal incluir un fichero perteneciente a la PS3. Por más que esté cifrado. Es propiedad de Sony.

Probablemente todo lo que sea copyright de la aplicación debería venir de forma separada a la aplicación en sí.
fichero perteneciente a sony? ke fichero?
en el codigo fuente, solo se incluyen una serie de numeros, que se desencriptan, o ahora que pasa, que los numeros tmb son propiedad de sony?
jose30 escribió:fichero perteneciente a sony? ke fichero?
en el codigo fuente, solo se incluyen una serie de numeros, que se desencriptan, o ahora que pasa, que los numeros tmb son propiedad de sony?


Tranquilidadddd que te va a dar un infarto!

No miré el fuente con profundidad sinceramente. Pero deduzco que necesitas el header del lv0 para intentar descifrarlo. Lamentablemente, esa porción de código, por más pequeña que sea, es propiedad de Sony. Sin embargo, no creo que eso tenga relevancia. Pero bueno, tampoco para que te enojes! Son consejos nada más.

Mientras tanto el programa sigue corriendo y.....nada :P
tranquilo, no me altere ni nada, solamente me sorprendio lo de los ficheros, que yo sepa, solo utilizamos un array de "numeros" para descrifar, que "coincidan" con los de sony, me la pela, ya ves... si viene sony para meterme entre rejas, por lo menos tendre alojamiento y comida, asegurada, jejeje
ademas, es practicamente imposible que encontremos la key, es mas facil que ganemos la liga (con las ayuditas a otros...), jejeje

sugerencia, tendriamos que crearnos un canal irc, para ponernos en contacto, gente que quiera colaborar en hacer un programita realmente potente... incluso pensar en trabajo distribuido de keys... no se... cuanto mas abarquemos y mas nos unamos... mejor, creo yo...
No se que comentaros sobre el tema legal que ha sacado Gonzakpo, podría ser serio pero contad conmigo .... ya no me pueden quitar nada ..... estoy embargado por mi "querida" ex-mujer.... Lo que más me extraña es que SONY no haya hecho nada contra el TB, pues esta gente algo tienen que tener para desencriptar los EBOOT.BIN de los OFW +3.60 y firmar sus actualizaciones de sus dongles con unas KEYS que no disponemos (que pueden que sean las mismas de SONY).
Y más aun, no se si habéis curioseado los EBOOT de los FIX que ponen pero aunque los podamos desencriptar con unself siguen siendo ilegibles o por lo menos no tan legibles como los EBOOT de los OFW -3.50.

Palos de ciego estamos dando, pero más me gustaría darle un palo a los del TB, la SCENE siempre ha sido GRATUITA o sin animo de LUCRO y a los que han pagado 60€ pon un pincho que podría salirnos gratis y que digan "no pero ya les hemos rentabilizado", no perdona sacarle rentabilidad a algo es comprarlo por 60 y poder venderlo por 40. [+furioso] No comprarlo por 60 y que valga 0.

Contad conmigo aunque sea como cabeza de turco.......

Envidio vuestros ordenadores .. tengo los dos PGR funcionando y consume el 100% de la cpu [boing] que mierda de ordenador tengo ....... un I7 para mi es como si me dijerais que estoy usando el internet explorer del año pasado. AMD 64 y a mucha honra.

Pensad en el anonimato.
Saludos y MUCHAS GRACIAS.
PODEMOS
jose30 escribió:tranquilo, no me altere ni nada, solamente me sorprendio lo de los ficheros, que yo sepa, solo utilizamos un array de "numeros" para descrifar, que "coincidan" con los de sony, me la pela, ya ves... si viene sony para meterme entre rejas, por lo menos tendre alojamiento y comida, asegurada, jejeje
ademas, es practicamente imposible que encontremos la key, es mas facil que ganemos la liga (con las ayuditas a otros...), jejeje

sugerencia, tendriamos que crearnos un canal irc, para ponernos en contacto, gente que quiera colaborar en hacer un programita realmente potente... incluso pensar en trabajo distribuido de keys... no se... cuanto mas abarquemos y mas nos unamos... mejor, creo yo...


En este preciso momento ando con poco tiempo por estudio. Pero cuando me libere pensaba implementar (nuevamente) lo mismo que habían hecho ustedes pero descartando totalmente la interfaz gráfica, usando C para el programa principal y utilizando alguna rutina de AES superoptimizada escrita en assembly. Simplemente quería experimentar hasta cuantas llaves por minuto podemos llegar a probar. Luego podrían venir otro tipo de optimizaciones pero por lo pronto pensaba hacer eso lo más rápido posible (en lo que respecta al tiempo de implementación).

Respecto al "ataque" coordinado. Realmente creo que sería demasiado complicado y no se hasta que punto sacaríamos provecho de ello. Si quisiéramos dividir el espacio de claves posibles en rangos, tendríamos rangos para otorgarle a cada ser humano de este planeta. Es decir que podemos dividir el problema todo lo que queramos, pero nunca vamos a poder abarcarlo todo. Y en ese sentido, no se si vale tanto el esfuerzo. Quizás hacerlo aleatoriamente sea la mejor opción y a la larga más sencilla para nosotros y para los usuarios.

Creo una vez que consigamos algo super optimizado y que haga máximo provecho de los procesadores multi-core/hilo de ahora, me parece que deberíamos darle mayor difusión al programa. Sobre todo en las páginas de USA en donde hay muchos niños aburridos con procesadores i7 desperdiciados jaja. Por ahora solo vi el programa de Calantra en PS3Hax y nadie sabia bien que era o como funcionaba. Otros se limitaron a criticarlo (las mismas criticas que recibió aquí). Pero no vi ningún tipo de iniciativa colectiva.

En fin, esto puede tardar una infinidad de tiempo o un segundo. Pero al menos estamos haciendo algo.
Calantra escribió:
Gonzakpo escribió: No necesitan también conocer el IV (vector de inicialización) para poder ver si una llave es válida o no?

Ahora voy a ser un poco como la WIKI, no, más que la wiki, que ahí no viene... El iv, como su propio nombre indica es el vector de inicialización, dado el nombre, algo tendrá que ver con el inicio, podemos llegar a pensar, y no estaríamos equivocados. El cifrado aes es muy bueno por que incorpora métodos y sistemas de protección que lo hacen muy robusto y no dejan huecos por donde atacar, sin entrar en muchos detalles, el Iv es uno de estos métodos. El iv se aplica solamente sobre el primer bloque a cifrar realizando la operación lógica XOR, con el fin de evitar comparaciones. Teniendo en cuenta que el tamaño de cada bloque es de 128 bits y que 128bits son (128/8) 16 bytes, solamente los primeros 16 bytes se verían afectados por la IV: del byte en la posicion nº0 al byte en la posicion nº 15 en la matriz, teniendo en cuenta que las comparaciones que realiza el programa se hacen sobre los bytes en las posiciones 16,24,31,50,55,59,63, estaríamos fuera del alcance del IV... [plas] [plas] [plas]


Esto en cierto, en parte.

Aunque el IV sólo participa en los 16 primeros bytes, sin el IV correcto, ¿sabremos? que la key es válida, pero no podremos desencriptar el lv0. Tocaría jugar de nuevo a la loto para obtener los 16 bytes correctos del IV.

Por otro lado, estás probando una condición necesaria, ¿cómo sabes que es suficiente?. Una key válida produce el resultado que compruebas, key/16 ceros iv/16 ceros. Ese método, aunque chapucero, vale para las failoverflow tools, ya que usan un conjunto pequeño de claves. Pero, ¿qué impide que una clave inválida genere el mismo patrón?

Animo.
hola me he descargado el firmware 4.0 de ps3 y he desempaquetado el .pup y tengo el programa buscando el lv0 y el otro buscando el met loader, decidme si ago bien o tengo k buscar en otro firmware gracias a todos
titocath escribió:hola me he descargado el firmware 4.0 de ps3 y he desempaquetado el .pup y tengo el programa buscando el lv0 y el otro buscando el met loader, decidme si ago bien o tengo k buscar en otro firmware gracias a todos


Esta bien que hayas hecho eso, para ver como es, pero no vas a conseguirlo por ahí .... ¿porque? pues porque los archivos que has desempaquetado están encriptados, con lo cual aunque creas que lo puedes abrir con un editor hexadecimal no los puedes leer. Se necesitan las KEYS para desencriptarlo.

Si abres uno con el editor hexadecimal seguro que empieza así:
53 43 45 00 00 00 00 02 00 01 00 01 00 00 04 10 SCE.............
etc etc etc
Y así si estuviera desencriptado, leerías esto:
7F 45 4C 46 02 02 01 66 00 00 00 00 00 00 00 00 .ELF...f........
etc etc etc

Saludos
granberro escribió:
Calantra escribió:
Gonzakpo escribió: No necesitan también conocer el IV (vector de inicialización) para poder ver si una llave es válida o no?

Ahora voy a ser un poco como la WIKI, no, más que la wiki, que ahí no viene... El iv, como su propio nombre indica es el vector de inicialización, dado el nombre, algo tendrá que ver con el inicio, podemos llegar a pensar, y no estaríamos equivocados. El cifrado aes es muy bueno por que incorpora métodos y sistemas de protección que lo hacen muy robusto y no dejan huecos por donde atacar, sin entrar en muchos detalles, el Iv es uno de estos métodos. El iv se aplica solamente sobre el primer bloque a cifrar realizando la operación lógica XOR, con el fin de evitar comparaciones. Teniendo en cuenta que el tamaño de cada bloque es de 128 bits y que 128bits son (128/8) 16 bytes, solamente los primeros 16 bytes se verían afectados por la IV: del byte en la posicion nº0 al byte en la posicion nº 15 en la matriz, teniendo en cuenta que las comparaciones que realiza el programa se hacen sobre los bytes en las posiciones 16,24,31,50,55,59,63, estaríamos fuera del alcance del IV... [plas] [plas] [plas]


granberro escribió:Esto en cierto, en parte.

A si? no me digas... veamos...

granberro escribió:Aunque el IV sólo participa en los 16 primeros bytes, sin el IV correcto, ¿sabremos? que la key es válida
Sí, no es la primera vez que hago esto ¿sabes?, en PS3, en wii, en pc y en la maquina de petacos de la esquina simepre ha funcionado. [sonrisa]

granberro escribió: pero no podremos desencriptar el lv0. Tocaría jugar de nuevo a la loto para obtener los 16 bytes correctos del IV.
Estás equivocado, no me voy a extender en explicaciones, el que quiera que estudie o pruebe, el Iv se aplica SOLAMENTE sobre los 16 primeros bytes, el resto sale correcto sólo con la llave y como supongo tal vez sepas que en esos primeros 16 bytes está la cabecera del ELF y que esos datos son irrelevantes, lo que nos interesa son los cargadores y están más adelante [360º]

granberro escribió:Por otro lado, estás probando una condición necesaria, ¿cómo sabes que es suficiente?.
Es que un dia me levante por la mañana y tuve una revelación... XD sigue y [rtfm]

granberro escribió: Una key válida produce el resultado que compruebas, key/16 ceros iv/16 ceros. Ese método, aunque chapucero, vale para las failoverflow tools, ya que usan un conjunto pequeño de claves.
Tremenda tonteria, este es el único proceso de prueba si se conoce el contenido de lo cifrado y como da la casualidad que se cumple en el resto de ficheros SCE con clave conocida, creo que es suficiente razón. Pero ya que tú lo calificas de chapucero, anda iluminanos a todos y explica al público como lo lo harias tú. (oigo un ZAS?)

granberro escribió: Pero, ¿qué impide que una clave inválida genere el mismo patrón?

Ah no sé, pregúntales a los Srs. Joan Daemen y Vincent Rijmen, los padres de la criatura son ellos, yo sólo pasaba por aquí... [sonrisa]

granberro escribió:Animo.


Te lo cambio por suerte. ;)
Por otro lado, estás probando una condición necesaria, ¿cómo sabes que es suficiente?


A mi, me hizo hasta cierta gracia, esta parte, segun el nos van a salir multiples claves y todo. Yo entiendo, que toda key ke cumpla eso, saldra, asi eske pueden segun el salir varias. no?. ¿estoy un poco espeso o es asi?
ok entonces que archivo tengo que mirar?, y tienes razon no me encontro nada de nada, gracias a todos
titocath escribió:ok entonces que archivo tengo que mirar?, y tienes razon no me encontro nada de nada, gracias a todos


Escanea el disco duro integramente. Estarás un par de días probando llaves.
jose30 escribió:
Por otro lado, estás probando una condición necesaria, ¿cómo sabes que es suficiente?


A mi, me hizo hasta cierta gracia, esta parte, segun el nos van a salir multiples claves y todo. Yo entiendo, que toda key ke cumpla eso, saldra, asi eske pueden segun el salir varias. no?. ¿estoy un poco espeso o es asi?


Yo iba de buen rollo, o eso pretendía, pero com veo que el tema va de ZAS y de dar, sólo os voy a "dar" un consejo. Coged las f0f tools y un self del tipo que queráis, poned a cero el IV que le corresponda en la carpera .ps3 y haced un readself a ver que pasa.

Saludos
graNBerro

PS: En la Wii funciona porque los cap*** de Nintendo no saben lo que es el IV
granberro escribió:
jose30 escribió:
Por otro lado, estás probando una condición necesaria, ¿cómo sabes que es suficiente?


A mi, me hizo hasta cierta gracia, esta parte, segun el nos van a salir multiples claves y todo. Yo entiendo, que toda key ke cumpla eso, saldra, asi eske pueden segun el salir varias. no?. ¿estoy un poco espeso o es asi?


Yo iba de buen rollo, o eso pretendía, pero com veo que el tema va de ZAS y de dar, sólo os voy a "dar" un consejo. Coged las f0f tools y un self del tipo que queráis, poned a cero el IV que le corresponda en la carpera .ps3 y haced un readself a ver que pasa.

Saludos
graNBerro

PS: En la Wii funciona porque los cap*** de Nintendo no saben lo que es el IV


Hola granberro. Estoy de acuerdo con que el trato a veces es un poco "rudo" aquí. Los muchachos son un poco susceptibles...

Pero volviendo al tema principal, no se que pasa con las tools de f0f pero si el cifrado es AES-256 CBC entonces el proceso de descifrado es el que se esquema a continuación:

Imagen

En fin, como puedes ver, teniendo la Key sin el IV la única porción del archivo que "no se puede" descifrar es el primer bloque de 16 bytes. Para descifrar el resto de los bloques con tener la KEY únicamente alcanza.
[quote="Gonzakpo]En fin, como puedes ver, teniendo la Key sin el IV la única porción del archivo que "no se puede" descifrar es el primer bloque de 16 bytes. Para descifrar el resto de los bloques con tener la KEY únicamente alcanza.[/quote]
¡¡¡Exacto!!!

Pero ten en cuenta que ese primer bloque es necesario para desencriptar la siguiente sección. Con AES256CBC sólo hay encriptados 4x16 bytes.
haber es la primera vez que me meto en esto, te refieres al disco duro del pc o de la play... gracias
titocath escribió:haber es la primera vez que me meto en esto, te refieres al disco duro del pc o de la play... gracias


Hola, se refiere al disco duro del pc, el disco duro multimedia u otro cualquiera. El programa de Calantra usa los ficheros para generar las claves que luego prueba. Cuantos más ficheros, cuanto más grandes sean pues más claves probará el fichero.

Es una manera alternativa al usar claves generadas aleatoriamente. El problema es que puede que este repitiendo muchas claves. Si revisa el hilo en algunos mensajes esta explicado de manera más detallada.

Otra cosa, Calantra, en tu programa al intentar continuar la busqueda de la clave por fuerza bruta, da un error al cargar el fichero, dice que el valor del numero de claves buscada no es un valor integer valido.

Lo que yo hago es copiar la clave en la que se ha quedado el proceso y continuo.

Gracias por el trabajo (sé que es casi imposible encontrar la clave) y por las explicaciones. Asi todos aprendemos algo. Por cierto gracias a Jose30 tambien.
granberro escribió:
Gonzakpo escribió:En fin, como puedes ver, teniendo la Key sin el IV la única porción del archivo que "no se puede" descifrar es el primer bloque de 16 bytes. Para descifrar el resto de los bloques con tener la KEY únicamente alcanza.

¡¡¡Exacto!!!

Pero ten en cuenta que ese primer bloque es necesario para desencriptar la siguiente sección. Con AES256CBC sólo hay encriptados 4x16 bytes.


Y vuelta la burra al trigo, eres un poco kansino, asín que te dejo un programa "para que te enteres" :
http://www.mediafire.com/?9zvcfka9fhpxd91

Junto con el ejecutable viene un fichero de texto (lv0.txt) :
Hola Soy una cabecera, si no usas la llave correcta no me podras leer.














Hola soy un loader, y tengo un monton de cosas bonitas para ti.













Hola soy un loader, y tengo un monton de cosas bonitas para ti.










Hola soy un loader, y tengo un monton de cosas bonitas para ti.

dale al boton de cifrar, selecciona ese fichero y guardalo con el nombre que quieras, en la ventana del programa te mostrara el fichero cifrado como texto :
'lº|Ô¸†ûgFtÅ’Ò@3¯ª€Œ[YiÎS3zjÂCçü}xÈÜ##ÐÁj…B+6ù€œ£A*~ˆ [¼ò2QœF±Dxξ‚ZÖMíž-@ø±eµaú°Yûûk€ˆÝÖç¼h8qÓ«†ðׯ“Ñql‚Îu¯TòB/\.š£0Ú¶“5-úãS˜z´µN,ü¬£h’ê#V“Ú3›ÔEç, @hS&tœ O¶ÏŠñ!½·¤Ê_=ÀíçÀl‡UUNó+×öv`”OÞŸÁéí¯px“8ñ<uKQ-SÏR¿e˜ ZñãµL«ÞBG˜‚8àˆFÊsj‘Æ.Šf…ó¥>;ÅJŸ)"ƒôr¿iácÞ¢5#;¸SÚ•ûibiÇ𐫠ˆ{
Û
¨´?K P5=Ïq–#íp?Ö }EÀf£ ÚÞ²

Ahora dale al boton de descifrar y selecciona el fichero cifrado que guardaste, cambia la iv por todo ceros o borra el campo que lo hace el programa solo, guarda el fichero y en la ventana te mostrara :
Hnnb$Vi~(|dj,nomecera, si no usas la llave correcta no me podras leer.














Hola soy un loader, y tengo un monton de cosas bonitas para ti.













Hola soy un loader, y tengo un monton de cosas bonitas para ti.










Hola soy un loader, y tengo un monton de cosas bonitas para ti.


Como podras observar el contenido de los cargadores no se ha alterado pese a haber usado una Iv de ceros, solamente se pierde la cabecera, los primeros 16 bytes.

Si esque, como quieres no ganarte un ZAS si lo cuestionas todo todo todo sin idea, no llevas la razón y aun sigues erre que erre, un poco de confianza joer, que si me he tirado más de 1000 lineas de código en esto es por que se lo que estoy haciendo y por que se puede hacer.

Y lo de sistema chapucero ya me llegó al alma... y de ahí mi tono "sarcástico".

Ale, un saludo y tan amigos [beer]
Calantra escribió:...
Y vuelta la burra al trigo, eres un poco kansino, asín que te dejo un programa "para que te enteres" :
....

Pues nada chaval, a tirar millas. Como dicen por mi tierra, pa ti la perra gorda, que yo ya estoy mayor para aguantar gilipolleces.

[beer]

Por si te dar por bajarte del burro, aqui tienes una pista´
int sce_decrypt_header(u8 *ptr, struct keylist *klist)
{
   u32 meta_offset;
   u32 meta_len;
   u64 header_len;
   u32 i, j;
   u8 tmp[0x40];
   int success = 0;

   meta_offset = be32(ptr + 0x0c);
   header_len  = be64(ptr + 0x10);

   for (i = 0; i < klist->n; i++) {
      aes256cbc(klist->keys[i].key,
           klist->keys[i].iv,
           ptr + meta_offset + 0x20,
           0x40,
           tmp);

      success = 1;
      for (j = 0x10; j < (0x10 + 0x10); j++)
         if (tmp[j] != 0)
            success = 0;
   
      for (j = 0x30; j < (0x30 + 0x10); j++)
         if (tmp[j] != 0)
                success = 0;

      if (success == 1) {
         memcpy(ptr + meta_offset + 0x20, tmp, 0x40);
         break;
      }
   }

   if (success != 1)
      return -1;

   printf(" Metadata key id: %s\n", klist->keys[i].id);

   memcpy(tmp, ptr + meta_offset + 0x40, 0x10);
   aes128ctr(ptr + meta_offset + 0x20,
        tmp,
        ptr + meta_offset + 0x60,
        0x20,
        ptr + meta_offset + 0x60);

   meta_len = header_len - meta_offset;

   aes128ctr(ptr + meta_offset + 0x20,
        tmp,
        ptr + meta_offset + 0x80,
        meta_len - 0x80,
        ptr + meta_offset + 0x80);

   return i;
}
granberro escribió:
Calantra escribió:...
Y vuelta la burra al trigo, eres un poco kansino, asín que te dejo un programa "para que te enteres" :
....

Pues nada chaval, a tirar millas. Como dicen por mi tierra, pa ti la perra gorda, que yo ya estoy mayor para aguantar gilipolleces.

[beer]


Te lo acaban de demostrar y nada....Jajaja
Buena es la fiesta. Cambiando un poco el ambiente, ¿entonces la key que se busca es de 16 Bytes? (16 de iv más la key serían 256 bits). O por el contrario, ¿la key sigue siendo de 256 bits a parte del iv que no buscas?
Lo digo porque lo mismo se podría jugar un poco con la estadística y probabilística y descartar más de la mitad de keys a probar en fuerza bruta
belmonte_drums escribió:Buena es la fiesta. Cambiando un poco el ambiente, ¿entonces la key que se busca es de 16 Bytes? (16 de iv más la key serían 256 bits). O por el contrario, ¿la key sigue siendo de 256 bits a parte del iv que no buscas?
Lo digo porque lo mismo se podría jugar un poco con la estadística y probabilística y descartar más de la mitad de keys a probar en fuerza bruta


Solo se prueban los 256 bits de la llave. No se buscar el IV. Es irrelevante para nuestros fines.

De todas formas, no te emociones, las probabilidades de encontrar "solo" la llave son tan remotas que es más probable que cualquiera de nosotros gane la lotería.
Gonzakpo escribió:
belmonte_drums escribió:Buena es la fiesta. Cambiando un poco el ambiente, ¿entonces la key que se busca es de 16 Bytes? (16 de iv más la key serían 256 bits). O por el contrario, ¿la key sigue siendo de 256 bits a parte del iv que no buscas?
Lo digo porque lo mismo se podría jugar un poco con la estadística y probabilística y descartar más de la mitad de keys a probar en fuerza bruta


Solo se prueban los 256 bits de la llave. No se buscar el IV. Es irrelevante para nuestros fines.

De todas formas, no te emociones, las probabilidades de encontrar "solo" la llave son tan remotas que es más probable que cualquiera de nosotros gane la lotería.


Ya, por lo que he leído he llegado a la conclusión de que el iv es irrelevante, solo quería saber si el iv va incluido en la key de 256 bits o no, porque no me queda claro.
@KaKaRoToKS: Awesome video on how public key cryptography works(easier to understand than my post on ECDSA) thanks to @andersjedheim http://www.youtube.com/watch?v=3QnD2c4Xovk&sns=em
Gonzakpo escribió:De todas formas, no te emociones, las probabilidades de encontrar "solo" la llave son tan remotas que es más probable que cualquiera de nosotros gane la lotería.


¿Quieres decir que si ejecuto estos programas tendré aún más probabilidades de que me toque la lotería? voy corriendo a comprar un décimo para este sábado.
XD

No hace falta ni responder a mi mensaje, es por intentar poner un poco de humor / ironía al tema, que falta le hace.
Sigo el hilo desde el principio y veo que, por mucho que se use el programa, mucha gente tendra los mismos archivos en su PC: windows (aunque sean diferentes comparten tela), office, openoffice, firefox ...... Y eso es mucho tiempoi INUTIL de computación.

Al principio se propuso que la clave que inspecciona se genere aleatoriamente (lo veo aun mas facil de programar, y no, yo no lo hago por que no se programar para PC) y lo veo un proceso mucho mas eficaz, pues dado el numero posibles de claves es mas problable que se encuentra la clave entre todos a que se repita una probada por otra persona e incluso el que quiera puede dejarlos dias, meses, años o siglos buscando de forma continua o dejarlo en el ordenata del curro (se me ocurre añadirle un "limitador" o ponerlo como salva pantallas).

No se si ya estara implementado pero no seria mala idea que, si saca la clave, la intentase postear en algun sitio publico o similar. No vaya a ser que le suene la flauta a algun listillo y nos quedemos sin caramelo.

PD: lo estoy pensando y creo que es igual de probable que se repita una clave ya comprobada que sacar la buena. Al final son todas "iguales", no?
407 respuestas
Archivado
1…5, 6, 7, 8, 9
Volver a Scene