Metldr dump entra y sirvete

Highwind escribió:Todo va viento en popa, son fechas críticas (fiestas y demás) y tiene vida aparte de la scene como entendereis, además, no se quiere crear falso hype ni nada, por eso estamos un poco ausentes del hilo.

Gracias por la info, parecía que estaba desaparecido.

Respecto a los que dicen que se cierre el hilo...ya les vale, ahora que están hablando los que saben del tema y ahora que los trolls , flamers, etc... ya no asoman y quereis cerrarlo.

El hilo como bien dice es sobre el Metldr dump, y ha sido publicado por lo tanto no veo porque la gente quiere que cierren el hilo.

CFW-Prophet escribió:

Gonzakpo escribió:Yo ya no lo sé si es posible. Estuve hablando con una persona y me iluminó un poco más en el asunto. Dumpear la RAM es posible pero eso solo nos facilitará todas las keys pero públicas. Eso significa que tampoco podríamos crear un CFW porque no podríamos firmar sin la clave privada. La única posibilidad de calcular la clave privada es teniendo dos firmas lv0 descifradas. Y para obtener eso se necesita conseguir el bootloader descifrado pero este nunca llega a la RAM :S

En fin, hasta nuevo aviso, lo de dumpear la RAM solo sirve para conseguir claves publicas. Pero aún falta la clave privada para conseguir un CFW. Y el método para hacer esto por ahora es muy superior a mi entendimiento de la materia.

Lo unico que dumpearas seran los loaders (.ELF) que van encapsulados dentro del lv0 sabemos que el bootldr en primer lugar va y descifra el lv0 con la pck 0 pero si queremos estar por encima de sony hasta la eternidad seria conveniente que tuviesemos esta pck 0 que usa el bootldr (Que es per console pero nos basta con que uno de nosotros descifre cada lv0 de sony hasta el fw 6.60, etc permitiendonos cfw y fixes para siempre ademas de acabar con la necesidad de hacer de nuevo un dump en cada fw que sony saque .) aunque como dices para obtener las privadas (Para hacer un custom 4.00 instalable en consolas en dicho fw) al menos necesitamos el lv0 descifrado cosa que solo se puede lograr con el exploit de math modificado tal como hizo darkvolt.

Claro que obtenemos las publicas debido a que en el dump encontrariamos el appldr descifrado y de ahi sacamos todos los keysets analizando el dump con ida pudiendo descifrar eboots de juegos nuevos ademas de tener la posibilidad de firmar un custom fw 4.00 con las keys privadas de 3.55 por lo que el custom solo seria instalable desde el fw 3.55 o con flasher similar al 3.56 que hay ahora pero esto solo beneficiaria por un momento a algunos (quizas los interesados en psn pero...) igual sony moveria ficha, me alegra saber que alguien cerca de mi tambien esta interesado en esto me gustaria ayudarte pero por el momento no puedo mucho mas que los demas solo te podria ayudar despues con ida en caso de ser necesario y en darte mas detallitos .

Ya que usarias hw extra fpga para hacer el dumpeo y necesitas underclockear el bus de la ram te conviene saber que existen otros puntos en la mobo que te podrian ayudar a hacer esto mas facil aun es decir podemos ralentizar el proceso en la ps3 ademas de el underclocking para hacer mas rapida la captura...

no , dentro de lv0 no te encontrarás los elf's precisamente en eso ando liado , al descifrar el lv0 nuevo te llevas una gran sorpresa te lo aseguro , no puedo sacar appldr ni isoldr ni lv1ldr ni lv2ldr no ay ningun elf que se identifique como loader , pero tiene una sección de 419kb's exactos que no puedo ni mirar ..

el bootldr no tiene ningún flag que evite que se evite su reload

el bootldr se comunica y descifra y trabaja TODO bajo dma directamente al xdr en el inicio

el bootldr no se puede cargar con las tools de glevand tendrás que hacerlo todo via peek & poke ( duro ya lo sé )

el bootldr busca la nor en el address 0x24010000000 el bootloader en el inicio lo lee en 0x2401FC000000 que como imaginarás es un address del sb bus no de la nor , osea que la xdr la puedes dejar quieta via hardware ya que la controla el SC = syscon si intentas leer o grabar un area sin permisos o sin los flags correctos (0,1,2,3) nada del otro mundo.. te mete un panic de la ostia y se apaga
¿ por qué ? he ahí el problema ....ya que al no poder cargarlo nativamente no puedo ver que hace en esa ultima sección tan jugosa , sigo trabajando en ello igualmente..

No entendi ni papa,pero muchas gracias por el curro que te pegas fiera
Saludos.

LittleMan escribió:No entendi ni papa,pero muchas gracias por el curro que te pegas fiera
Saludos.

igual no le entendi nada al buen DarkVolt , a mi parecer me da una impresion un tanto pesimista...

espero equivocarme!

suerte a todos

por lo que veo todo marcha perfecta mente estas atascado los problemas mas complejo aveces tienen una sencilla solución es cuestión de equilibrio , saludos

DarkVolt escribió:

CFW-Prophet escribió:

Gonzakpo escribió:Yo ya no lo sé si es posible. Estuve hablando con una persona y me iluminó un poco más en el asunto. Dumpear la RAM es posible pero eso solo nos facilitará todas las keys pero públicas. Eso significa que tampoco podríamos crear un CFW porque no podríamos firmar sin la clave privada. La única posibilidad de calcular la clave privada es teniendo dos firmas lv0 descifradas. Y para obtener eso se necesita conseguir el bootloader descifrado pero este nunca llega a la RAM :S

En fin, hasta nuevo aviso, lo de dumpear la RAM solo sirve para conseguir claves publicas. Pero aún falta la clave privada para conseguir un CFW. Y el método para hacer esto por ahora es muy superior a mi entendimiento de la materia.

Lo unico que dumpearas seran los loaders (.ELF) que van encapsulados dentro del lv0 sabemos que el bootldr en primer lugar va y descifra el lv0 con la pck 0 pero si queremos estar por encima de sony hasta la eternidad seria conveniente que tuviesemos esta pck 0 que usa el bootldr (Que es per console pero nos basta con que uno de nosotros descifre cada lv0 de sony hasta el fw 6.60, etc permitiendonos cfw y fixes para siempre ademas de acabar con la necesidad de hacer de nuevo un dump en cada fw que sony saque .) aunque como dices para obtener las privadas (Para hacer un custom 4.00 instalable en consolas en dicho fw) al menos necesitamos el lv0 descifrado cosa que solo se puede lograr con el exploit de math modificado tal como hizo darkvolt.

Claro que obtenemos las publicas debido a que en el dump encontrariamos el appldr descifrado y de ahi sacamos todos los keysets analizando el dump con ida pudiendo descifrar eboots de juegos nuevos ademas de tener la posibilidad de firmar un custom fw 4.00 con las keys privadas de 3.55 por lo que el custom solo seria instalable desde el fw 3.55 o con flasher similar al 3.56 que hay ahora pero esto solo beneficiaria por un momento a algunos (quizas los interesados en psn pero...) igual sony moveria ficha, me alegra saber que alguien cerca de mi tambien esta interesado en esto me gustaria ayudarte pero por el momento no puedo mucho mas que los demas solo te podria ayudar despues con ida en caso de ser necesario y en darte mas detallitos .

Ya que usarias hw extra fpga para hacer el dumpeo y necesitas underclockear el bus de la ram te conviene saber que existen otros puntos en la mobo que te podrian ayudar a hacer esto mas facil aun es decir podemos ralentizar el proceso en la ps3 ademas de el underclocking para hacer mas rapida la captura...

no , dentro de lv0 no te encontrarás los elf's precisamente en eso ando liado , al descifrar el lv0 nuevo te llevas una gran sorpresa te lo aseguro , no puedo sacar appldr ni isoldr ni lv1ldr ni lv2ldr no ay ningun elf que se identifique como loader , pero tiene una sección de 419kb's exactos que no puedo ni mirar ..

el bootldr no tiene ningún flag que evite que se evite su reload

el bootldr se comunica y descifra y trabaja TODO bajo dma directamente al xdr en el inicio

el bootldr no se puede cargar con las tools de glevand tendrás que hacerlo todo via peek & poke ( duro ya lo sé )

el bootldr busca la nor en el address 0x24010000000 el bootloader en el inicio lo lee en 0x2401FC000000 que como imaginarás es un address del sb bus no de la nor , osea que la xdr la puedes dejar quieta via hardware ya que la controla el SC = syscon si intentas leer o grabar un area sin permisos o sin los flags correctos (0,1,2,3) nada del otro mundo.. te mete un panic de la ostia y se apaga
¿ por qué ? he ahí el problema ....ya que al no poder cargarlo nativamente no puedo ver que hace en esa ultima sección tan jugosa , sigo trabajando en ello igualmente..

Hola. No entiendo por qué dices que el bootldr se carga en la xdr. Según tengo entendido y de acuerdo a lo que había leído el bootloader descifrado se carga en una LS de un SPE en isolation mode. No llega nunca a la xdr. Esto me lo confirmo Mathieulh también que supuestamente ya consiguió todo lo que nosotros no.

¿Si ya sabes como recargar el bootloader no puede usar directamente el exploit de Mathieulh para hacer un dump del mismo?

Saludos.

DarkVolt escribió:...no , dentro de lv0 no te encontrarás los elf's precisamente en eso ando liado , al descifrar el lv0 nuevo te llevas una gran sorpresa te lo aseguro , no puedo sacar appldr ni isoldr ni lv1ldr ni lv2ldr no ay ningun elf que se identifique como loader , pero tiene una sección de 419kb's exactos que no puedo ni mirar ..

El lv0 nuevo? eso que quiere decir, que se puso con el nuevo OF 4.0? sobre cual firm está trabajando?

Mucho ánimo DarkVolt, tu puedes.

DarkVolt escribió:

CFW-Prophet escribió:

Gonzakpo escribió:
no , dentro de lv0 no te encontrarás los elf's precisamente en eso ando liado , al descifrar el lv0 nuevo te llevas una gran sorpresa te lo aseguro , no puedo sacar appldr ni isoldr ni lv1ldr ni lv2ldr no ay ningun elf que se identifique como loader , pero tiene una sección de 419kb's exactos que no puedo ni mirar ..

el bootldr no tiene ningún flag que evite que se evite su reload

el bootldr se comunica y descifra y trabaja TODO bajo dma directamente al xdr en el inicio

el bootldr no se puede cargar con las tools de glevand tendrás que hacerlo todo via peek & poke ( duro ya lo sé )

el bootldr busca la nor en el address 0x24010000000 el bootloader en el inicio lo lee en 0x2401FC000000 que como imaginarás es un address del sb bus no de la nor , osea que la xdr la puedes dejar quieta via hardware ya que la controla el SC = syscon si intentas leer o grabar un area sin permisos o sin los flags correctos (0,1,2,3) nada del otro mundo.. te mete un panic de la ostia y se apaga
¿ por qué ? he ahí el problema ....ya que al no poder cargarlo nativamente no puedo ver que hace en esa ultima sección tan jugosa , sigo trabajando en ello igualmente..

Hola. No entiendo por qué dices que el bootldr se carga en la xdr. Según tengo entendido y de acuerdo a lo que había leído el bootloader descifrado se carga en una LS de un SPE en isolation mode. No llega nunca a la xdr. Esto me lo confirmo Mathieulh también que supuestamente ya consiguió todo lo que nosotros no.

¿Si ya sabes como recargar el bootloader no puede usar directamente el exploit de Mathieulh para hacer un dump del mismo?

Saludos.

El sistema para poder cargar el bootldr, lo puedes hacer usando un peek / poke de lv1 (tal y como se hace en el MA, que para eso los tiene).
Si modificas la memoria del lv1 en ejecucion, puedes decirle que lea el bootldr y que cargue el bootldr (si sabes donde parchear claro y entiendes todo el proceso de como se carga un loader), mandarle un lv0, que te desencripte la metadata (la cabecera), y con eso ya lo sacas tu posteriormente.

Una aplicacion usuario (mientras pueda usar un peek / poke de lv1) puede hacer eso sin mucho problema.
Todo esta en la ps3devwiki, es cuestion de leerlo y usar la herramienta apropiada, que existe, aunque todo o casi todo el mundo la desprecie.

Un saludo

edito
hay un hilo sobre el tema ya : hilo_psdev-crypter-tools-por-confirmar_1709077
suerte

psn_hypervisor escribió:
El sistema para poder cargar el bootldr, lo puedes hacer usando un peek / poke de lv1 (tal y como se hace en el MA, que para eso los tiene).
Si modificas la memoria del lv1 en ejecucion, puedes decirle que lea el bootldr y que cargue el bootldr (si sabes donde parchear claro y entiendes todo el proceso de como se carga un loader), mandarle un lv0, que te desencripte la metadata (la cabecera), y con eso ya lo sacas tu posteriormente.

Una aplicacion usuario (mientras pueda usar un peek / poke de lv1) puede hacer eso sin mucho problema.
Todo esta en la ps3devwiki, es cuestion de leerlo y usar la herramienta apropiada, que existe, aunque todo o casi todo el mundo la desprecie.

Un saludo

Pero si es tan fácil y sabes como hacerlo, ¿por qué no compartes tus métodos con nosotros? La información que haz soltado son todas generalidades y no dicen absolutamente nada concreto. Ni que herramienta usas, ni que parches en memoria, ni nada.

Además, tú método tiene un gran problema. Depende de tener peek&poke por lo que no es aplicable a las consolas nuevas. Se necesita un método que no dependa de un jailbreak previo.

Como haya que hacerlo a pelo con peek&poke DarkVolt se va a pegar una matada importante... Bendita sea la paciencia de los sceners men...

Yo ando preparando ya una de mis tres PS3 para hacer unas mini pruebillas

Croack!

Gonzakpo escribió:

psn_hypervisor escribió:
El sistema para poder cargar el bootldr, lo puedes hacer usando un peek / poke de lv1 (tal y como se hace en el MA, que para eso los tiene).
Si modificas la memoria del lv1 en ejecucion, puedes decirle que lea el bootldr y que cargue el bootldr (si sabes donde parchear claro y entiendes todo el proceso de como se carga un loader), mandarle un lv0, que te desencripte la metadata (la cabecera), y con eso ya lo sacas tu posteriormente.

Una aplicacion usuario (mientras pueda usar un peek / poke de lv1) puede hacer eso sin mucho problema.
Todo esta en la ps3devwiki, es cuestion de leerlo y usar la herramienta apropiada, que existe, aunque todo o casi todo el mundo la desprecie.

Un saludo

Pero si es tan fácil y sabes como hacerlo, ¿por qué no compartes tus métodos con nosotros? La información que haz soltado son todas generalidades y no dicen absolutamente nada concreto. Ni que herramienta usas, ni que parches en memoria, ni nada.

Además, tú método tiene un gran problema. Depende de tener peek&poke por lo que no es aplicable a las consolas nuevas. Se necesita un método que no dependa de un jailbreak previo.

creo que su trabajo va mas por la MA. suerte

Realmente me importa poco si su trabajo va por la MA o la PI o la DE o la LA o la QR, etc. Estamos acá para compartir y entre todos sumar. No sirve de nada pasearse dando indicaciones de cómo se deberían hacer las cosas pero al mismo tiempo no decir absolutamente nada.

Señores, yo creo que tenemos aquí a cuatro investigadores de la ostia, sin querer veo un TEAM Psn-hypervisor, DarkVolt, CFW-Profhet y Gonzakpo

luppi escribió:Señores, yo creo que tenemos aquí a cuatro investigadores de la ostia, sin querer veo un TEAM Psn-hypervisor, DarkVolt, CFW-Profhet y Gonzakpo

+1

Gonzakpo escribió:Realmente me importa poco si su trabajo va por la MA o la PI o la DE o la LA o la QR, etc. Estamos acá para compartir y entre todos sumar. No sirve de nada pasearse dando indicaciones de cómo se deberían hacer las cosas pero al mismo tiempo no decir absolutamente nada.

hace tiempo en este hilo dije que no era fácil y que iba a costar trabajo y que no tenemos todo lo necesario para acceder ni las herramientas necesarias, el autor del hilo lo confirmo anoche, es mas tan solo podemos entrar en consolas vulnerables bajo firmware de fabrica por debajo del 3.42 , por eso todo el trabajo se basa a partir de aquí , si se puediera modificar esos dichos datos estaria todo echo , y eso no se encuentra en la nor ni nad si no en la cell , aunque se puediera sacar no seria valido para todas las consolas habría que sacar la de cada una , si fuesen distintas ya se consiguió en su dia con el jailbreak

Gonzakpo escribió:Además, tú método tiene un gran problema. Depende de tener peek&poke por lo que no es aplicable a las consolas nuevas. Se necesita un método que no dependa de un jailbreak previo.

No importa si es aplicable o no a una consola nueva ya que no es necesario hacer el uso de un exploit como estos en dichas consolas bastara con brindarles los beneficios del exploit a dichas consolas.

Daros cuenta que si obtuvieramos las claves privadas del lv0 o pudiesemos firmar un lv0 gracias a las claves que obtuvimos de un exploit teorico podriamos firmar un cfw compatible con dichas consolas en esos fw en caso teorico firmar un cfw 3.73 con las claves privadas de dicho fw haria que funcionara en una consola nueva con ese fw 3.73

Luckymas es imposible modificar el bootldr o lo que digas que esta en el cell no tengais problemas es decir si sacamos la pck0 que esta "segun" guardada en un efuse en el cell, es destacable que como dices esta clave es unica PERO bastara con que una persona descifre el lv0 y luego publique sus resultados sean negativos o positivos asi que no es necesario que cada uno de nosotros saque la nuestra aunque seria ideal, darkvolt lo sabe si obtenemos las keys privadas nada importaria al fin y al cabo PODRIAMOS FIRMAR UN CFW y dependiendo de sus keys o de su updater (FW) este sera compatible con nuevas consolas.

La verdad darkvolt lo que dices sobre el lv0 es en cierto modo contradictorio pero era de imaginarse que no seria tan facil pero lo que dijiste deja entreveer que ya estas parcheando la ram en el boot? math hablo de lo dificil que era encontrar la direccion correcta y sobre los permisos ademas de varios factores que fastidiaban pero al menos ya tienes lv0 descifrado extraño o no muchos estabamos equivocados, queda seguir estudiandolo

Pokeaste la ram para cargar el bootldr en la x dr? o usaste el poke del lv1 como dice psn_hipervisor? la verdad no me imaginaba que pudiesemos tener la oportunidad de trabajar con el bootldr con el lv1, psn_hipervisor haber si nos puedes alumbrar mas en este asunto.

gonzakpo quizas el no ayude directamente pero al menos lo hara indirectamente .

Smacks escribió:Como haya que hacerlo a pelo con peek&poke DarkVolt se va a pegar una matada importante... Bendita sea la paciencia de los sceners men...

Yo ando preparando ya una de mis tres PS3 para hacer unas mini pruebillas

Croack!

eres el único que llegó a esa conclusión solo por eso te doy las gracias

y al resto de mortales :

que MA ni ostias , el peek & poke viene de la epoca del primer cfw 3.55 es más se consiguió parchear el uso del bdemu oficial y montarlo como si unidad se tratase pero virtualizando la ruta hacia otro lado ..

via peek & poke cargo el bootldr , luego mediante DMA se envia el lv0

el problema que existe para bootldr es que no se alimenta el lv0 por la via que bootldr espera.. al contrario de metldr que lo espera en otro lado.

y las direcciones de memorias esas tan importantes eran las que puse en mi ultimo post.

DarkVolt escribió:

Smacks escribió:Como haya que hacerlo a pelo con peek&poke DarkVolt se va a pegar una matada importante... Bendita sea la paciencia de los sceners men...

Yo ando preparando ya una de mis tres PS3 para hacer unas mini pruebillas

Croack!

eres el único que llegó a esa conclusión solo por eso te doy las gracias

y al resto de mortales :

que MA ni ostias , el peek & poke viene de la epoca del primer cfw 3.55 es más se consiguió parchear el uso del bdemu oficial y montarlo como si unidad se tratase pero virtualizando la ruta hacia otro lado ..

via peek & poke cargo el bootldr , luego mediante DMA se envia el lv0

el problema que existe para bootldr es que no se alimenta el lv0 por la via que bootldr espera.. al contrario de metldr que lo espera en otro lado.

y las direcciones de memorias esas tan importantes eran las que puse en mi ultimo post.

el MA trabaja en la 3.56 y tu lo sabes mejor que nadie

quieren que se les respete pero no respetan a los demas...

Amos a ver, dejemos las cosas claras:

All of this is accomplished exclusively by hardware means; no software, in the form of setting protection bits in an address translation table for
example, is involved in the process. Because of this hardware isolation, even the operating system and the hypervisor cannot access the locked up LS
or take control of the SPE core. Therefore, a hacker who has gained root or hypervisor privileges is not a threat to an application executing on an
isolated SPE. The supervisory privileges will not enable him to control the application, nor will it allow him to read or write the memory used by it.
The execution flow and the data of the isolated application are safe.

Fuente: The Cell Broadband Engine processor security architecture http://www.ibm.com/developerworks/power ... lsecurity/

Lo que viene a decir que desde el OS (gameos) o desde el Hypervisor es IMPOSIBLE acceder a la LS una vez que se ha lanzado una aplicación, y por supuesto, una vez que la aplicación termina la memoria del SPE es borrada.

Y como ya dije anteriormente :

The Vault protects an application from other software which might have been modified or compromised. However, that still leaves open the question
of what happens if the application itself has been modified. For example, an adversary can modify the application so that when the application
accesses valuable data within the Secure Vault, it copies the data to outside of the Vault into an openly accessible area. Such a modification needs to
be detected so that the application is not executed. One counter-measure might be to design a software-implemented loader which does an
authentication check on the application and only executes it when the authentication succeeds. However, the loader might be modified so that it does
not check for authentication correctly and allows compromised code to execute within the Vault. Or, an adversary might circumvent the loader
entirely, and the authentication step is skipped. A hardware solution is needed so that the authentication step is consistently and correctly executed.

Fuente: The Cell Broadband Engine processor security architecture http://www.ibm.com/developerworks/power ... lsecurity/

Lo que viene a decir que, si el atacante es capaz de modificar una aplicación, modificar su cargador o encontrar una vía alternativa para que este se salte el proceso de autenticar el programa, el atacante será capaz mediante el programa modificado de comprometer los datos de la LS, volcandolos a una zona accesible de la RAM.

Repito: desde LV1 leer la LS tu ru ru , no lo digo yo, lo dice este señor:
Kanna Shimizu is the Security Architect for the Cell Broadband Engine processor and Next Generation Computing Systems at IBM. She holds a B.S.
in Electrical Engineering from California Institute of Technology, a M.Sc. in Computer Science from University of Oxford, and a Ph.D. in Electrical
Engineering from Stanford University. Her interests include secure computing, content protection, formal methods, and financial mathematics.

del que yo por supuesto me fío.

El exploit que usó F0F para conseguir las llaves de los cargadores no hace otra cosa que corroborar todo lo anteriormente expuesto :

• „Only“ a bug in isolated loaders
• Chain of Trust already broken for all sold
consoles now.

(Extracto del documento de F0F de la CCC, de como conseguir las llaves de los cargadores)

El proceso de cargar bajo el SPU consiste en: se carga el cargador de forma aislada en el SPE, donde se descifra, se le pasa la dirección del programa en la memoria y el cargador, desde el spe, descifra el programa en la RAM. La memoria aislada de los SPE (Local Store) sólo es de 256kb, de ahí que los cargadores sean tan pequeños.

Así que, sólo si encontraís el fallo en el cargador de lv0 (bootloader) podréis extraer el Lv0 y el propio cargador de este, que es en este caso el bootloader.

Tal vez esto sea una pista:

Isolation
Loaders Table
All the binary files needed for isolation and decryption are already stored in HV memory !!!
They are probably loaded during HV initialization from FLASH.
The table has 9 entries.
Each entry is 16 bytes large.
0x00010100 (3.15)
Loaders Table Entry
offset 0x0 - pointer to data in memory
offset 0x8 - size of data
Here are the contents of the Loaders Table from HV 3.15:
Index Name Address of Data in HV Dump Size of Data
0 - 0x0C150000 0x1E5CC
1 metldr 0x00011000 0xE8D0
2 lv2ldr 0x00020000 0x16DA0
3 isoldr 0x00055000 0x12E44
4 appldr 0x00037000 0x1DAE4
5 EID0 0x00068000 0x860
6 - 0x00069010 0x8
7 - 0x00069020 0x50
8 - 0x00069070 0x8
Methods
get_iso_loaders_tab - 0x002B0B70 (3.15)
metldr
Loading metldr
The SPU is first stopped
Physical memory address of metldr is written to SPU registers Sig_Notify1 and Sig_Notify2
Isolation load request is enabled by writing SPU register SPU_PrivCntl
Isolation load request is made by writing value 0x3 into SPU register SPU_RunCntl
Methods
SPE_load_request_metldr - 0x002B00A4 (3.15)

Funte: Hypervisor Reverse Engineering - PS3Wiki https://ps3wiki.lan.st/index.php?title= ... ngineering


Aquí nos dicen que hay una tabla que usa el sistema para localizar los cargadores en la ram y como conseguirla y luego como se carga el metldr.
¿Estará también en esta tabla la dirección del Bootloader? y si es así, ¿por que no aplicar el mismo exploit filtrado de Mathieulh para cargar el metldr y volcar su contenido?
Y si no lo está? es posible modificar la tabla y copiar el boot-loader cifrado manualmente en una zona de la ram apuntada por la tabla modificada para así poder lanzarlo de nuevo?

Ahí queda eso.

Saludos.

Calantra escribió:Amos a ver, dejemos las cosas claras:

All of this is accomplished exclusively by hardware means; no software, in the form of setting protection bits in an address translation table for
example, is involved in the process. Because of this hardware isolation, even the operating system and the hypervisor cannot access the locked up LS
or take control of the SPE core. Therefore, a hacker who has gained root or hypervisor privileges is not a threat to an application executing on an
isolated SPE. The supervisory privileges will not enable him to control the application, nor will it allow him to read or write the memory used by it.
The execution flow and the data of the isolated application are safe.

Fuente: The Cell Broadband Engine processor security architecture http://www.ibm.com/developerworks/power ... lsecurity/

Lo que viene a decir que desde el OS (gameos) o desde el Hypervisor es IMPOSIBLE acceder a la LS una vez que se ha lanzado una aplicación, y por supuesto, una vez que la aplicación termina la memoria del SPE es borrada.

Y como ya dije anteriormente :

The Vault protects an application from other software which might have been modified or compromised. However, that still leaves open the question
of what happens if the application itself has been modified. For example, an adversary can modify the application so that when the application
accesses valuable data within the Secure Vault, it copies the data to outside of the Vault into an openly accessible area. Such a modification needs to
be detected so that the application is not executed. One counter-measure might be to design a software-implemented loader which does an
authentication check on the application and only executes it when the authentication succeeds. However, the loader might be modified so that it does
not check for authentication correctly and allows compromised code to execute within the Vault. Or, an adversary might circumvent the loader
entirely, and the authentication step is skipped. A hardware solution is needed so that the authentication step is consistently and correctly executed.

Fuente: The Cell Broadband Engine processor security architecture http://www.ibm.com/developerworks/power ... lsecurity/

Lo que viene a decir que, si el atacante es capaz de modificar una aplicación, modificar su cargador o encontrar una vía alternativa para que este se salte el proceso de autenticar el programa, el atacante será capaz mediante el programa modificado de comprometer los datos de la LS, volcandolos a una zona accesible de la RAM.

Repito: desde LV1 leer la LS tu ru ru , no lo digo yo, lo dice este señor:
Kanna Shimizu is the Security Architect for the Cell Broadband Engine processor and Next Generation Computing Systems at IBM. She holds a B.S.
in Electrical Engineering from California Institute of Technology, a M.Sc. in Computer Science from University of Oxford, and a Ph.D. in Electrical
Engineering from Stanford University. Her interests include secure computing, content protection, formal methods, and financial mathematics.

del que yo por supuesto me fío.

El exploit que usó F0F para conseguir las llaves de los cargadores no hace otra cosa que corroborar todo lo anteriormente expuesto :

• „Only“ a bug in isolated loaders
• Chain of Trust already broken for all sold
consoles now.

(Extracto del documento de F0F de la CCC, de como conseguir las llaves de los cargadores)

El proceso de cargar bajo el SPU consiste en: se carga el cargador de forma aislada en el SPE, donde se descifra, se le pasa la dirección del programa en la memoria y el cargador, desde el spe, descifra el programa en la RAM. La memoria aislada de los SPE (Local Store) sólo es de 256kb, de ahí que los cargadores sean tan pequeños.

Así que, sólo si encontraís el fallo en el cargador de lv0 (bootloader) podréis extraer el Lv0 y el propio cargador de este, que es en este caso el bootloader.

Tal vez esto sea una pista:

Isolation
Loaders Table
All the binary files needed for isolation and decryption are already stored in HV memory !!!
They are probably loaded during HV initialization from FLASH.
The table has 9 entries.
Each entry is 16 bytes large.
0x00010100 (3.15)
Loaders Table Entry
offset 0x0 - pointer to data in memory
offset 0x8 - size of data
Here are the contents of the Loaders Table from HV 3.15:
Index Name Address of Data in HV Dump Size of Data
0 - 0x0C150000 0x1E5CC
1 metldr 0x00011000 0xE8D0
2 lv2ldr 0x00020000 0x16DA0
3 isoldr 0x00055000 0x12E44
4 appldr 0x00037000 0x1DAE4
5 EID0 0x00068000 0x860
6 - 0x00069010 0x8
7 - 0x00069020 0x50
8 - 0x00069070 0x8
Methods
get_iso_loaders_tab - 0x002B0B70 (3.15)
metldr
Loading metldr
The SPU is first stopped
Physical memory address of metldr is written to SPU registers Sig_Notify1 and Sig_Notify2
Isolation load request is enabled by writing SPU register SPU_PrivCntl
Isolation load request is made by writing value 0x3 into SPU register SPU_RunCntl
Methods
SPE_load_request_metldr - 0x002B00A4 (3.15)

Funte: Hypervisor Reverse Engineering - PS3Wiki https://ps3wiki.lan.st/index.php?title= ... ngineering


Aquí nos dicen que hay una tabla que usa el sistema para localizar los cargadores en la ram y como conseguirla y luego como se carga el metldr.
¿Estará también en esta tabla la dirección del Bootloader? y si es así, ¿por que no aplicar el mismo exploit filtrado de Mathieulh para cargar el metldr y volcar su contenido?
Y si no lo está? es posible modificar la tabla y copiar el boot-loader cifrado manualmente en una zona de la ram apuntada por la tabla modificada para así poder lanzarlo de nuevo?

Ahí queda eso.

Saludos.

Efectivamente a eso de la tabla me referia.
Este es mi ultimo post en este tema, pues algunas actitudes dan que desear.

Con respecto a que el 3.55 fue el primer cfw con PEEK / POKE del lv1, para nada...el primero fue el 3.15 mediante el XorHack de Xorlorser y previamente el de Geohot, asi que de 3.55 na de na.
Si alguien necesita mi ayuda que mande mensaje privado, siempre que sea conocido aqui o por mi, ningun problema en ayudarle.

Un saludo

Calantra escribió:Amos a ver, dejemos las cosas claras:

All of this is accomplished exclusively by hardware means; no software, in the form of setting protection bits in an address translation table for
example, is involved in the process. Because of this hardware isolation, even the operating system and the hypervisor cannot access the locked up LS
or take control of the SPE core. Therefore, a hacker who has gained root or hypervisor privileges is not a threat to an application executing on an
isolated SPE. The supervisory privileges will not enable him to control the application, nor will it allow him to read or write the memory used by it.
The execution flow and the data of the isolated application are safe.

Fuente: The Cell Broadband Engine processor security architecture http://www.ibm.com/developerworks/power ... lsecurity/

Lo que viene a decir que desde el OS (gameos) o desde el Hypervisor es IMPOSIBLE acceder a la LS una vez que se ha lanzado una aplicación, y por supuesto, una vez que la aplicación termina la memoria del SPE es borrada.

Y como ya dije anteriormente :

The Vault protects an application from other software which might have been modified or compromised. However, that still leaves open the question
of what happens if the application itself has been modified. For example, an adversary can modify the application so that when the application
accesses valuable data within the Secure Vault, it copies the data to outside of the Vault into an openly accessible area. Such a modification needs to
be detected so that the application is not executed. One counter-measure might be to design a software-implemented loader which does an
authentication check on the application and only executes it when the authentication succeeds. However, the loader might be modified so that it does
not check for authentication correctly and allows compromised code to execute within the Vault. Or, an adversary might circumvent the loader
entirely, and the authentication step is skipped. A hardware solution is needed so that the authentication step is consistently and correctly executed.

Fuente: The Cell Broadband Engine processor security architecture http://www.ibm.com/developerworks/power ... lsecurity/

Lo que viene a decir que, si el atacante es capaz de modificar una aplicación, modificar su cargador o encontrar una vía alternativa para que este se salte el proceso de autenticar el programa, el atacante será capaz mediante el programa modificado de comprometer los datos de la LS, volcandolos a una zona accesible de la RAM.

Repito: desde LV1 leer la LS tu ru ru , no lo digo yo, lo dice este señor:
Kanna Shimizu is the Security Architect for the Cell Broadband Engine processor and Next Generation Computing Systems at IBM. She holds a B.S.
in Electrical Engineering from California Institute of Technology, a M.Sc. in Computer Science from University of Oxford, and a Ph.D. in Electrical
Engineering from Stanford University. Her interests include secure computing, content protection, formal methods, and financial mathematics.

del que yo por supuesto me fío.

El exploit que usó F0F para conseguir las llaves de los cargadores no hace otra cosa que corroborar todo lo anteriormente expuesto :

• „Only“ a bug in isolated loaders
• Chain of Trust already broken for all sold
consoles now.

(Extracto del documento de F0F de la CCC, de como conseguir las llaves de los cargadores)

El proceso de cargar bajo el SPU consiste en: se carga el cargador de forma aislada en el SPE, donde se descifra, se le pasa la dirección del programa en la memoria y el cargador, desde el spe, descifra el programa en la RAM. La memoria aislada de los SPE (Local Store) sólo es de 256kb, de ahí que los cargadores sean tan pequeños.

Así que, sólo si encontraís el fallo en el cargador de lv0 (bootloader) podréis extraer el Lv0 y el propio cargador de este, que es en este caso el bootloader.

Tal vez esto sea una pista:

Isolation
Loaders Table
All the binary files needed for isolation and decryption are already stored in HV memory !!!
They are probably loaded during HV initialization from FLASH.
The table has 9 entries.
Each entry is 16 bytes large.
0x00010100 (3.15)
Loaders Table Entry
offset 0x0 - pointer to data in memory
offset 0x8 - size of data
Here are the contents of the Loaders Table from HV 3.15:
Index Name Address of Data in HV Dump Size of Data
0 - 0x0C150000 0x1E5CC
1 metldr 0x00011000 0xE8D0
2 lv2ldr 0x00020000 0x16DA0
3 isoldr 0x00055000 0x12E44
4 appldr 0x00037000 0x1DAE4
5 EID0 0x00068000 0x860
6 - 0x00069010 0x8
7 - 0x00069020 0x50
8 - 0x00069070 0x8
Methods
get_iso_loaders_tab - 0x002B0B70 (3.15)
metldr
Loading metldr
The SPU is first stopped
Physical memory address of metldr is written to SPU registers Sig_Notify1 and Sig_Notify2
Isolation load request is enabled by writing SPU register SPU_PrivCntl
Isolation load request is made by writing value 0x3 into SPU register SPU_RunCntl
Methods
SPE_load_request_metldr - 0x002B00A4 (3.15)

Funte: Hypervisor Reverse Engineering - PS3Wiki https://ps3wiki.lan.st/index.php?title= ... ngineering


Aquí nos dicen que hay una tabla que usa el sistema para localizar los cargadores en la ram y como conseguirla y luego como se carga el metldr.
¿Estará también en esta tabla la dirección del Bootloader? y si es así, ¿por que no aplicar el mismo exploit filtrado de Mathieulh para cargar el metldr y volcar su contenido?
Y si no lo está? es posible modificar la tabla y copiar el boot-loader cifrado manualmente en una zona de la ram apuntada por la tabla modificada para así poder lanzarlo de nuevo?

Ahí queda eso.

Saludos.

Calandra, tu post simplemente impresionante. Me aclaraste bastantes cosas que tenía algo confusas. Ahora entiendo a que se refería exactamente psn_hypervisor (lo siento psn, pero resumes todo tanto que a veces es difícil entenderte!).

Yo tengo varias consultas, y supongo que despues le echaré un vistado a los documentos que linkeaste.

1) ¿Hay garantía de que esa tabla de loaders siga en pie? Lo más probable que no, por lo que habrá que obtenerla de nuevo (e investigar cómo la obtuvieron en primer lugar).

2) La tabla de Loaders le indica al bootloader de donde tomar el lv0 cifrado. Pero la pregunta es, ¿qué le indica al bootloader en donde guardar el resultado descifrado?

psn_hypervisor , xorloser en la 3.15 metía peek & poke mediante el pulso de 40ns , era temporal no un cfw , sigo en lo correcto , el primer cfw es decir con la modificación incluida en el lv1 y lv2 era el 3.55 , en vez de intentar ayudar me intentas desmontar y no..

y ya que conoces xorhack podrías usar para iniciar el projecto el template de spu isolation para xorhack.

No hace falta descifrar el bootloader para tener nuestros lv0 ya que no tenemos acceso a la LS cierto , pero no hace falta! via dma le envias el lv0 y via dma te devuelve el metadata y mucha mierda , con el metadata puedes modificar el unself para que no use keys si no directamente el metadata .. lo que tienes que tener un buen script que te capture la recepción a tiempo ya que al hacer reload correctamente al bootldr este carga medio correcto el lv0 y se reinicia y se queda esperando el resto de la cadena ( la iniciamos sin syscon y el syscon es el que monta , desmonta el mapeo en ram aparte de que el bootldr hace caso al spi config ring del syscon , eso también ay que emularlo ya que no todos los spe's son dignos de cargar bootldr ( fijaos en el config ring ).

y los documentos de ibm no os van a dejar el tema como "Facil" , pero no todo lo que dice ahí es completamente verdad , por ejemplo en el que el bootldr no se puede cargar si ay algo en memoria ya que no tiene acceso a la LS , la LS la podemos usar , no la podemos ver que es diferente, pero tiene su uso .

DarkVolt escribió:psn_hypervisor , xorloser en la 3.15 metía peek & poke mediante el pulso de 40ns , era temporal no un cfw , sigo en lo correcto , el primer cfw es decir con la modificación incluida en el lv1 y lv2 era el 3.55 , en vez de intentar ayudar me intentas desmontar y no..

Hola DarkVolt, no te enojes, no convirtamos esto en una batalla, psn no se dió cuenta del detalle , nos puede pasar a todos

DarkVolt escribió:y ya que conoces xorhack podrías usar para iniciar el projecto el template de spu isolation para xorhack.

Aquí va el enlace, por si alguien quiere hecharle un vistazo a lo que comenta DV.
http://www.megaupload.com/?d=GCJXTO0U

DarkVolt escribió:No hace falta descifrar el bootloader para tener nuestros lv0 ya que no tenemos acceso a la LS cierto , pero no hace falta! via dma le envias el lv0 y via dma te devuelve el metadata y mucha mierda

Disculpa mi ignorancia, pero... una pregunta... le envías el lv0 a quien, al SPU?, a metldr?, a isoldr?, en definitiva, ¿a quien se lo enviamos?
Y otra cosa, ese, llamemosle "algo" nos devuelve el metadata descifrado?, no tiene mucho sentido, entonces para que vamos a aislar un proceso si luego los propios métodos de protección nos facilitan el trabajo de desprotección (?).

DarkVolt escribió:, con el metadata puedes modificar el unself para que no use keys si no directamente el metadata

Perdoname que te corrija para matizar: podrás modificar el unself para usar directamente las llaves AES del metadata descifrado.

DarkVolt escribió:.. lo que tienes que tener un buen script que te capture la recepción a tiempo ya que al hacer reload correctamente al bootldr este carga medio correcto el lv0 y se reinicia y se queda esperando el resto de la cadena ( la iniciamos sin syscon y el syscon es el que monta , desmonta el mapeo en ram aparte de que el bootldr hace caso al spi config ring del syscon , eso también ay que emularlo ya que no todos los spe's son dignos de cargar bootldr ( fijaos en el config ring ).

Vale, supongo que esto respondería a mi anterior pregunta de a quien le enviamos el LV0, pero y como le envías el bootloader al SPE? o mejor, como inicias el bootloader de nuevo?

DarkVolt escribió:y los documentos de ibm no os van a dejar el tema como "Facil" , pero no todo lo que dice ahí es completamente verdad , por ejemplo en el que el bootldr no se puede cargar si ay algo en memoria ya que no tiene acceso a la LS , la LS la podemos usar , no la podemos ver que es diferente, pero tiene su uso .

Hombre, el Jefe de la Security de IBM, con una docena de masters de las mejores unis del mundo, no te va a decir que su sistema es facilmente vulnerable, pero los entendidos en la materia te dirán que el fallo no está en el Sistema de seguridad de IBM, si no en la implementación del mismo, vamos que SONY la lió parda, por lo que la info de IBM es correcta.

Saludos.

Calantra escribió:

DarkVolt escribió:psn_hypervisor , xorloser en la 3.15 metía peek & poke mediante el pulso de 40ns , era temporal no un cfw , sigo en lo correcto , el primer cfw es decir con la modificación incluida en el lv1 y lv2 era el 3.55 , en vez de intentar ayudar me intentas desmontar y no..

Hola DarkVolt, no te enojes, no convirtamos esto en una batalla, psn no se dió cuenta del detalle , nos puede pasar a todos

vale

DarkVolt escribió:y ya que conoces xorhack podrías usar para iniciar el projecto el template de spu isolation para xorhack.

Aquí va el enlace, por si alguien quiere hecharle un vistazo a lo que comenta DV.
http://www.megaupload.com/?d=GCJXTO0U

si es eso, teneis que modificar el xorhack para añadir el read_u32() y write_u32()

DarkVolt escribió:No hace falta descifrar el bootloader para tener nuestros lv0 ya que no tenemos acceso a la LS cierto , pero no hace falta! via dma le envias el lv0 y via dma te devuelve el metadata y mucha mierda

Disculpa mi ignorancia, pero... una pregunta... le envías el lv0 a quien, al SPU?, a metldr?, a isoldr?, en definitiva, ¿a quien se lo enviamos?
Y otra cosa, ese, llamemosle "algo" nos devuelve el metadata descifrado?, no tiene mucho sentido, entonces para que vamos a aislar un proceso si luego los propios métodos de protección nos facilitan el trabajo de desprotección (?).

digamos que una vez cargado el bootldr no le envia nadie el lv0 , si no que mas bien es el bootldr el que busca el lv0 en este caso no es como el metldr que queda esperando cualquier tipo de loader

DarkVolt escribió:, con el metadata puedes modificar el unself para que no use keys si no directamente el metadata

Perdoname que te corrija para matizar: podrás modificar el unself para usar directamente las llaves AES del metadata descifrado.

exacto

DarkVolt escribió:.. lo que tienes que tener un buen script que te capture la recepción a tiempo ya que al hacer reload correctamente al bootldr este carga medio correcto el lv0 y se reinicia y se queda esperando el resto de la cadena ( la iniciamos sin syscon y el syscon es el que monta , desmonta el mapeo en ram aparte de que el bootldr hace caso al spi config ring del syscon , eso también ay que emularlo ya que no todos los spe's son dignos de cargar bootldr ( fijaos en el config ring ).

Vale, supongo que esto respondería a mi anterior pregunta de a quien le enviamos el LV0, pero y como le envías el bootloader al SPE? o mejor, como inicias el bootloader de nuevo?

el bootldr se aisla y se inicia exactamente igual que el metldr solo cambia un flag en el arg de la llamada de 1 a 0, y el bootldr busca lv0 nadie se lo proporciona , he ahí el problema está mapeado en ram en boot gracias al syscon y cierto loader lo desmapea del "SB"

DarkVolt escribió:y los documentos de ibm no os van a dejar el tema como "Facil" , pero no todo lo que dice ahí es completamente verdad , por ejemplo en el que el bootldr no se puede cargar si ay algo en memoria ya que no tiene acceso a la LS , la LS la podemos usar , no la podemos ver que es diferente, pero tiene su uso .

Hombre, el Jefe de la Security de IBM, con una docena de masters de las mejores unis del mundo, no te va a decir que su sistema es facilmente vulnerable, pero los entendidos en la materia te dirán que el fallo no está en el Sistema de seguridad de IBM, si no en la implementación del mismo, vamos que SONY la lió parda, por lo que la info de IBM es correcta.

Saludos.
exacto , por eso su propio sistema de seguridad te excupe las metadata , la implementación

*-* alguien me ace un resumen rapido de que estado esta actualmente la cosa con tanto dato y tanta cosa no me e enterado de nada

Krassh escribió:*-* alguien me ace un resumen rapido de que estado esta actualmente la cosa con tanto dato y tanta cosa no me e enterado de nada

Pues yo lo definiria como hacen los guiris: WIP (working in progress)

DarkVolt escribió:el bootldr se aisla y se inicia exactamente igual que el metldr solo cambia un flag en el arg de la llamada de 1 a 0, y el bootldr busca lv0 nadie se lo proporciona , he ahí el problema está mapeado en ram en boot gracias al syscon y cierto loader lo desmapea del "SB"

Sera el 0 para asiganr el nº de SPE correspondiente supongo...

DarkVolt escribió:exacto , por eso su propio sistema de seguridad te excupe las metadata , la implementación

Bueno, sí, era de suponer que sería algo así.
Pos na, muchas gracias por la info y que tengas todo tipo de suertes con tus investigaciones, si necesitas algo ya sabes.

Saludos.

pacosoeda escribió:

Krassh escribió:*-* alguien me ace un resumen rapido de que estado esta actualmente la cosa con tanto dato y tanta cosa no me e enterado de nada

Pues yo lo definiria como hacen los guiris: WIP (working in progress)

xD buena deficinion pero en el proceso estarian acabando o van x la mitado como

Krassh escribió:

pacosoeda escribió:

Krassh escribió:*-* alguien me ace un resumen rapido de que estado esta actualmente la cosa con tanto dato y tanta cosa no me e enterado de nada

Pues yo lo definiria como hacen los guiris: WIP (working in progress)

xD buena deficinion pero en el proceso estarian acabando o van x la mitado como

Siguen en invesitagacion y teorias, por lo que no se podria definir si van a la mitad o apenas empezando o terminando.

...

esto q es????????????? un poco mas de info pa los q no sabemos del tema¡¡¡ por fa¡¡¡¡

Como diria Matias Prats, ¿pero esto que es? Mis conocimientos solo me llegan para ver que se trata de algo del LV0, del fw 4.0, retail y que no esta encriptado.

sergiokarra escribió:...

Y eso??????
Veo que esta descifrado el lv0 de la 4.00 Es esto correcto???????????

se supone que es el lv0 de 4.00 desencriptado y desempaquetado, lo vi antes en cierta pagina, ahora llega la pregunta del millon ¿sera cierto? es facil trucar una foto de estas, tambien se comenta que mañana sacara un video y dentro de poco liberara el cfw

Podría ser el inicio del dump del lvl0 de una consola retail con firm 4.0?
Se ve la cabecera y poco mas... a ver si se pasa algún gurú por aquí y nos da algún detallito.

Aún teniendo el LV0 desencriptado no es suficiente para obtener las keys del fimware como se creia según comentó DarkVolt, el tambien tiene el LV0 desencriptado y todavia no ha podido conseguir las keys.

3.55 : 34 9b bc 6c b4 01 19 46 5e f9 83 22 b7 1b 56 00 fd 6f dd c9 (KEYS?)
4.00 : 6e bc 16 e2 38 12 18 df d0 02 18 e1 66 2b fe 5b 65 50 f7 5a (KEYS?)

Matrox escribió:3.55 : 34 9b bc 6c b4 01 19 46 5e f9 83 22 b7 1b 56 00 fd 6f dd c9 (KEYS?)
4.00 : 6e bc 16 e2 38 12 18 df d0 02 18 e1 66 2b fe 5b 65 50 f7 5a (KEYS?)

Tachán tachán...


Croack!

¿Esto de donde lo sacais? ¿Mr. Egg?

basslover escribió:¿Esto de donde lo sacais? ¿Mr. Egg?

Yes.

no acostarse tarde esta noche todabia falta mucho pero mucho

eso lo he visto yo que lo han puesto hace poco en ps..sos.

LUCKYMAS escribió:no acostarse tarde esta noche todabia falta mucho pero mucho

Tendrias que llevarte un ZAS por agua fiestas!!

Smacks escribió:

Matrox escribió:3.55 : 34 9b bc 6c b4 01 19 46 5e f9 83 22 b7 1b 56 00 fd 6f dd c9 (KEYS?)
4.00 : 6e bc 16 e2 38 12 18 df d0 02 18 e1 66 2b fe 5b 65 50 f7 5a (KEYS?)

Tachán tachán...


Croack!

es buena noticia eso smacks tu que sabes del tema?ilumimanos

Matrox escribió:

LUCKYMAS escribió:no acostarse tarde esta noche todabia falta mucho pero mucho

Tendrias que llevarte un ZAS por agua fiestas!!

Pero que agua fiestas? el chico solo dice que no empezar a hypearse facilmente. Que por aqui teneis una facilidad de exitacion sobre humana xD.

PD: si smack, cuentanos

...
.

LUCKYMAS escribió:no acostarse tarde esta noche todabia falta mucho pero mucho

Ya que pareces una persona q no lanza las campanas al vuelo ni se hace pajas con cualquier pastie q sale, puedes explicarnos q es esto y si crees q es real?