[SCENE] CTurt anuncia kernel exploit en PS4

fresnillo escribió:Seamos realistas, cturt ha estado muy solo, y ha investigado desde 0 cómo hacer todo, en eso de fake no tiene nada.

De lo que presume es de que ha encontrado un fallo que puede intentar explotar, el resto... en mi opinión es todo prematuro, pero para mí que está la posibilidad y que no hay que menospreciarla. Hay que reconocer que nadie ha dado importancia al exploit de webkit más que él por el simple hecho de que los que conservamos un firmware tan antiguo somos raros.

Luego ya como ha estado él abandonado mucho tiempo pues... quiere reconocimiento, fama, seguidores... y wololo le lleva intentando hacer la pelota un cierto tiempo con anuncios de "homebrew" que algunos calificamos como de un intento y ya (con la psvita hace tiempo pasó lo mismo, cturt quería correr su emulador de gameboy a marchas forzadas en la PS4 y se ofendió porque hay mucha gente que a eso que hizo no le llama un verdadero homebrew, por el simple hecho de que sólo leía ciertas cosas que el navegador le proporcionaba usando sockets y ya). De todas maneras su "sdk", aunque sólo lo entienda él y un amigo suyo, va avanzando poquito a poquito.

Se está creando mucha expectación, y no me parece del todo mal. Cada uno que sea como quiera, pero o se meten expertos de verdad con experiencia en el tema y empiezan a ayudarle o un cargador de homebrew por lo menos no lo vemos hasta el año que viene bien avanzadito (y segúramente se meterán con los anuncios que hace cturt por twitter).

Saludos

Análisis de la seguridad de PS4 y el estado de la piratería
Dado que no ha habido grandes anuncios públicos sobre PS4 piratería durante mucho tiempo, quería explicar un poco acerca de lo lejos que PS4 piratería ha llegado, y lo que es la prevención de la progresión.

Voy a explicar algunos conceptos de seguridad que por lo general se aplican a todos los sistemas modernos, y los descubrimientos que he hecho de la realización de pruebas de ROP en mi PS4.

Si no está particularmente familiarizada con la explotación, debería leer mi artículo sobre la explotación de juegos de DS a través de pila aplastar vulnerabilidades en guardar archivos primero.

Usted puede descargar mi configuración completa aquí para ejecutar estas pruebas a ti mismo; es en la actualidad para el firmware 1.76 solamente.


Información básica acerca de la PS4

Como usted probablemente sabe la PS4 cuenta con una CPU AMD x86-64 personalizado (8 núcleos), y hay un montón de investigación disponibles para esta arquitectura de CPU, aunque esta versión específica podría desviarse ligeramente de los estándares conocidos. Por ejemplo, PFLA (Página Ejército de Liberación de fallos) publicó una prueba de concepto implementación de una máquina de Turing completo utilizando sólo los errores de página y el x86 MMU durante el 29C3 congreso, comprobar su impresionante vídeo a través de YouTube. También es interesante si usted está tratando de ejecutar código dentro de una máquina virtual y desea ejecutar instrucciones de la CPU.
- Reportaje Eurasia 3251

Además de contar con una arquitectura de CPU bien documentado, gran parte de los programas informáticos utilizados en la PS4 es de código abierto.

Más notablemente, Orbis OS de la PS4 se basa en FreeBSD, al igual que el sistema operativo de la PS3 era (con partes de NetBSD también); pero así como FreeBSD 9.0, otro software notable utilizan incluye Mono VM, y WebKit.


Punto de entrada WebKit

WebKit es el motor de renderizado de código abierto que hace que las páginas web en los navegadores para iOS, Wii U, 3DS, PS Vita, y la PS4.

Aunque tan ampliamente utilizado y madura, WebKit tiene su parte de las vulnerabilidades; usted puede aprender sobre la mayoría de ellos mediante la lectura de Pwn2Own escribir-ups.

En particular, el navegador PS4 firmware 1.76 utiliza una versión de WebKit que es vulnerable a CVE-2.012-3.748, un desbordamiento de búfer basado en heap en el JSArray :: sort (...) método.

En 2014, nas y Proxima anunciaron que habían sido éxito capaz de puerto de esta hazaña al navegador del PS4, y puesto en libertad el código PoC públicamente como el primer punto de entrada en la piratería de la PS4.

Esto nos da lectura arbitraria y escribir el acceso a todo el proceso de WebKit puede leer y escribir en, que puede utilizarse para volcar los módulos, y sobrescribir los remites en la pila, dejando a controlar el Contador de Programa (ROP).

Desde entonces, muchas otras vulnerabilidades han sido encontradas en WebKit, que probablemente podría permitir módulo de dumping y ROP en firmwares posteriores de la PS4, pero a partir de la escritura, nadie ha portado alguna de estas hazañas a la PS4 públicamente.


¿Qué es la retinopatía del prematuro?

A diferencia de los dispositivos primitivos como los DS, la PS4 tiene un núcleo que controla las propiedades de diferentes áreas de la memoria. Páginas de memoria que están marcados como ejecutable no puede ser sobrescrito, y las páginas de memoria que están marcados como permisos de escritura no se puede ejecutar; esto se conoce como Data Execution Prevention (DEP).

Esto significa que no podemos simplemente copiar una carga en la memoria y ejecutarlo. Sin embargo, podemos ejecutar código que ya está cargado en la memoria y marcado como ejecutable.

No sería muy útil para saltar a una sola dirección, si no podemos escribir nuestro propio código a esa dirección, por lo que utilizar ROP.

Programación Orientada a Retorno (ROP) es sólo una extensión de pila tradicional destrozos, pero en lugar de sobrescribir un solo valor que el PC saltará a, podemos encadenar muchas direcciones diferentes, conocidos como aparatos.

Un gadget es por lo general sólo una única instrucción deseada seguido de un ret.

En el montaje x86_64, cuando un ret se alcanza la instrucción, un valor de 64 bits se extrae de la pila y el PC salta a la misma; ya que podemos controlar la pila, podemos hacer todo ret salto instrucción al siguiente aparato deseado.

Por ejemplo, desde 0x80000 mayo contiene instrucciones:

rax mov, 0
retirado
Y desde 0x90000 puede contener instrucciones:

rbx mov, 0
retirado
Si sobrescribir una dirección de retorno en la pila para contener 0x80000 seguido por 0x90000, entonces tan pronto como el primer ret se alcanza la instrucción de ejecución saltará a rax mov, 0, e inmediatamente después, el siguiente ret instrucción aparecerá 0x90000 de la pila y saltar a rbx mov, 0.

Efectivamente esta cadena establecerá tanto rax y rbx a 0, al igual que si hubiéramos escrito el código en un solo lugar y ejecutado desde allí.

Cadenas ROP no se limita sólo a una lista de direcciones sin embargo; asumiendo que desde 0xA0000 contiene estas instrucciones:

rax pop
retirado
Podemos establecer el primer elemento de la cadena para 0xA0000 y el orden del día, a cualquier valor deseado para rax.

Gadgets también no tienen que terminar en un ret instrucción; podemos utilizar aparatos que terminan en un jmp:

añadir rax, 8
jmp rcx
Al hacer que el RCX apuntan a una ret instrucción, la cadena continuará de forma normal:

chain.add ("rcx pop", "ret");
chain.add ("add rax, 8; jmp rcx");
A veces, usted no será capaz de encontrar el gadget exacta que necesita por sí mismo, pero con otras instrucciones después de ella. Por ejemplo, si desea establecer r8 a algo, pero sólo tienen este gadget, usted tendrá que ajustar r9 hasta cierto valor ficticio:

r8 pop
r9 pop
retirado
Aunque puede que tenga que ser creativo con la forma de escribir cadenas de ROP, es generalmente aceptado que dentro de una lo suficientemente grande volcado código suficiente, habrá suficientes aparatos para Turing-completa funcionalidad; esto hace ROP un método viable de pasar por DEP.


Encontrar aparatos

Piense en ROP como escribir un nuevo capítulo de un libro, utilizando sólo las palabras que han aparecido al final de las oraciones en los capítulos anteriores.

Es obvio a partir de la estructura de la mayoría de las frases que probablemente no será capaz de encontrar palabras como "y" o "pero" que aparece al final de las oraciones, pero vamos a necesitar estos conectores para escribir algo significativo.

Es muy posible, sin embargo, que una sentencia ha terminado con 'arena'. Aunque el autor sólo ha destinado a la palabra que se lee de la 's', si comenzamos a leer desde la 'a', aparecerá como una palabra totalmente diferente por coincidencia, 'y'.

Estos principios se aplican también a la ROP.

Dado que la estructura de casi todas las funciones sigue algo como esto:

; Guardar registros
empuje rbp
rbp mov, rsp
empuje r15
empuje r14
empuje r13
empuje r12
empuje rbx
sub rsp, 18h

; Cuerpo de la función

; Restaurar registros
añadir rsp, 18h
rbx pop
r12 pop
r13 pop
r14 pop
r15 pop
rbp pop
retirado
Es de esperar que sólo es capaz de encontrar pop gadgets, o más raramente, algo así como rax xor, rax permite establecer el valor de retorno a 0 antes de regresar.

Tener una comparación como:

cmp [rax], r12
retirado
No tendría ningún sentido ya que el resultado de la comparación no es utilizado por la función. Sin embargo, todavía hay una posibilidad de que podemos encontrar aparatos como estos.

instrucciones x86_64 son similares a palabras que longitudes variables, y pueden significar algo completamente diferente dependiendo de donde comienza la decodificación.

La arquitectura x86_64 es un conjunto de instrucciones CISC de longitud variable. Programación orientada a Volver en el x86_64 se aprovecha del hecho de que el conjunto de instrucciones es muy "densa", es decir, cualquier secuencia aleatoria de bytes es probable que sea interpretable como un conjunto válido de instrucciones x86_64.
- Wikipedia

Para demostrar esto, echar un vistazo al final de esta función del módulo WebKit:

000000000052BE0D mov eax, [RDX + 8]
000000000052BE10 mov [rsi + 10h], eax
000000000052BE13 o ptr byte [rsi + 39h], 20h
000000000052BE17 ret
Ahora echa un vistazo a lo que el código parece si empezamos la decodificación de 0x52be14:

000000000052BE14 cmp [rax], r12
000000000052BE17 ret
A pesar de que este código nunca fue pensado para ser ejecutado, está dentro de un área de memoria que se ha marcado como ejecutable, por lo que es perfectamente válido para su uso como un gadget.

Por supuesto, sería hora buenísimos consumir mirar todas las formas posibles de interpretar código antes de cada ret instrucción manualmente; y es por eso que existen herramientas para hacer esto para usted. La que yo uso para buscar aparatos ROP es rp ++; para generar un archivo de texto lleno de gadgets, sólo tiene que utilizar:

ganar-rp-x64-f mod14.bin --raw = x64 --rop = 1 --unique> mod14.txt

Fallos de segmentación

Si nosotros hacemos tratamos de ejecutar una página no ejecutable de la memoria, o tratar de escribir en una página que no se puede escribir de la memoria, un fallo de segmentación se producirá.

Por ejemplo, tratando de ejecutar código en la pila, que se asigna como leer y escribir solamente:

setU8to (chain.data + 0, 0xEB);
setU8to (chain.data + 1, 0xfe);

chain.add (chain.data);
Y tratando de escribir en código, que está asignado como leer y ejecutar solamente:

setU8to (moduleBases [webkit], 0);
Si se produce un fallo de segmentación, un mensaje que dice "No hay suficiente memoria del sistema libre" aparecerá, y la página dejará de carga:



Hay otras razones posibles para este mensaje que se mostrará, como la ejecución de una instrucción no válida o un llamada al sistema sin aplicarse, pero un fallo de segmentación es el más común.


ASLR

Address Space Layout aleatorización (ASLR) es una técnica de seguridad que hace que las direcciones base de módulos a ser diferente cada vez que inicie la PS4.

Se ha informado a mí que muy antiguas de firmware (1.05) no tienen ASLR activado, pero fue introducido en algún momento antes de firmware 1.70. Tenga en cuenta que ASLR kernel no está activado (por firmwares 1.76 e inferior por lo menos), lo que se demostrará más adelante en el artículo.

Para la mayoría de las hazañas ASLR sería un problema porque si usted no sabe las direcciones de los aparatos en la memoria, usted no tiene idea de qué escribir a la pila.

Por suerte para nosotros, no estamos limitados a sólo escribir cadenas ROP estáticas. Podemos usar JavaScript para leer la tabla de módulos, que nos dirá las direcciones base de todos los módulos cargados. El uso de estas bases, podemos calcular las direcciones de todos nuestros gadgets antes de activar la ejecución ROP, sin pasar por ASLR.

La tabla de módulos también incluye los nombres de archivo de los módulos:

WebProcess.self
libkernel.sprx
libSceLibcInternal.sprx
libSceSysmodule.sprx
libSceNet.sprx
libSceNetCtl.sprx
libSceIpmi.sprx
libSceMbus.sprx
libSceRegMgr.sprx
libSceRtc.sprx
libScePad.sprx
libSceVideoOut.sprx
libScePigletv2VSH.sprx
libSceOrbisCompat.sprx
libSceWebKit2.sprx
libSceSysCore.sprx
libSceSsl.sprx
libSceVideoCoreServerInterface.sprx
libSceSystemService.sprx
libSceCompositeExt.sprx
Aunque la PS4 utiliza predominantemente la [S igned] P PU R elocatable E x formato ecutable ([S] PRX) para los módulos, algunas referencias de cuerda a [S igned] E xecutable y L entintado F Ormat ([S] ELF) archivos de objetos También se puede encontrar en el libSceSysmodule.sprx volcado, como bdj.elf, web_core.elf y orbis-JSC-compiler.self. Esta combinación de módulos y objetos es similar a lo que se utiliza en la PSP y PS3.

Puede ver una lista completa de todos los módulos disponibles (no sólo las que se cargan por el navegador) en libSceSysmodule.sprx. Podemos cargar y volcar algunos de estos a través de varias de las llamadas al sistema de encargo de Sony, que se explicarán más adelante en este artículo.


Just-ROP

Uso de JavaScript para escribir y ejecutar cadenas ROP dinámicas nos da una tremenda ventaja sobre un ataque de desbordamiento de búfer estándar.

Además de pasar por ASLR, también podemos leer el agente de usuario del navegador, y proporcionar una cadena ROP diferente para diferentes versiones del navegador, dando nuestro exploit la mayor compatibilidad posible.

Incluso podemos usar JavaScript para leer la memoria en las direcciones nuestros gadgets 'para comprobar que son correctos, que nos da fiabilidad casi perfecta.

Escribir cadenas ROP dinámicamente, en lugar de generarlos con un guión de antemano, sólo tiene sentido.

He creado un marco de JavaScript para escribir cadenas de ROP, Just-ROP, por esta misma razón.


Advertencias de JavaScript

JavaScript representa números usando el IEEE-754 formato de doble precisión (64 bits). Esto nos proporciona la precisión 53bit, lo que significa que no es posible representar todos los valores de 64 bits, aproximaciones tendrán que ser utilizado para algunos.

Si usted sólo tiene que establecer un valor de 64 bits a algo bajo, como 256, entonces setU64to va a estar bien.

Sin embargo, para situaciones en las que usted necesita para escribir un buffer o estructura de datos, existe la posibilidad de que ciertos bytes se escriben incorrectamente si se ha escrito en trozos de 64 bits.

En su lugar, usted debe escribir datos en fragmentos de 32 bits (recordando que la PS4 es little endian), para asegurar que cada byte es exacta.


Las llamadas al sistema

Curiosamente, la PS4 utiliza la misma convención de llamada como Linux y MS-DOS para llamadas al sistema, con argumentos almacenados en los registros, en lugar de la forma tradicional de UNIX (que FreeBSD usa por defecto), con argumentos almacenados en la pila:

rax - número de llamada de sistema
RDI - Argumento 1
rsi - Argumento 2
rdx - Argumento 3
r10 - Argumento 4
r8 - Argumento 5
r9 - Argumento 6
Podemos tratar de realizar cualquier llamada al sistema con el siguiente método just-ROP:

this.syscall = function (nombre, systemCallNumber, arg1, arg2, arg3, arg4, arg5, arg6) {
console.log ("syscall" + nombre);

this.add ("rax pop", systemCallNumber);
if (! typeof (arg1) == "undefined") this.add ("RDI pop", arg1);
if (! typeof (arg2) == "undefined") this.add ("rsi pop", arg2);
if (! typeof (arg3) == "undefined") this.add ("rdx pop", arg3);
if (! typeof (arg4) == "undefined") this.add ("rcx pop", ARG4);
if (! typeof (arg5) == "undefined") this.add ("r8 pop", arg5);
if (! typeof (arg6) == "undefined") this.add ("r9 pop", arg6);
this.add ("r10 mov, rcx; syscall");
}
Sólo asegúrese de establecer la base de la chimenea en cierta memoria libre de antemano:

this.add ("rbp pop", stackBase + returnaddress + 0x1400);
El uso de las llamadas al sistema nos puede decir una cantidad enorme sobre el kernel PS4. No sólo eso, sino que el uso de las llamadas al sistema es muy probable que la única manera que podemos interactuar con el núcleo, y por lo tanto potencialmente desencadenar un kernel explotar.

Si usted es módulos de ingeniería inversa para identificar algunas de las llamadas al sistema de encargo de Sony, usted puede venir a través de una convención de llamada alternativa:

A veces Sony realiza llamadas al sistema a través de llamada regular sistema de 0 (que por lo general no hace nada en FreeBSD), con el primer argumento (RDI), que controla la llamada al sistema se debe ejecutar:

rax - 0
RDI - número de llamada de sistema
rsi - Argumento 1
rdx - Argumento 2
r10 - Argumento 3
r8 - Argumento 4
r9 - Argumento 5
Es probable que Sony hizo esto para tener fácil compatibilidad con la convención función de llamada. Por ejemplo:

syscall .global
syscall:
rax xor, rax
r10 mov, rcx
syscall
retirado
El uso de este, pueden realizar llamadas al sistema de C utilizando la función de convención de llamada:

int syscall ();

int getpid (void) {
syscall de retorno (20);
}
Al escribir cadenas de ROP, podemos utilizar cualquiera de convenciones:

// Ambos obtener el ID del proceso actual:
chain.syscall ("getpid", 20);
chain.syscall ("getpid", 0, 20);
Es bueno estar al tanto de esto, porque podemos usar lo que uno es más conveniente para los aparatos que están disponibles.


getpid

Sólo mediante el uso de la llamada al sistema 20, getpid (void), podemos aprender mucho sobre el núcleo.

El mismo hecho de que esta llamada al sistema funciona en absoluto nos dice que Sony no se molestó en mezclar los números de las llamadas al sistema como medio de seguridad por oscuridad (bajo la licencia BSD que podrían haber hecho esto sin la liberación de los nuevos números de llamada del sistema).

Así, automáticamente tenemos una lista de llamadas al sistema en el kernel PS4 a intentarlo.

En segundo lugar, llamando getpid (), reiniciando el navegador, y decir que es nuevo, obtenemos un valor de retorno 2 superior al valor anterior.

Esto nos dice que la aplicación del navegador de Internet en realidad consta de 2 procesos separados: el núcleo WebKit (que nos hacemos cargo), que maneja el análisis de HTML y CSS, la decodificación de imágenes, y la ejecución de JavaScript por ejemplo, y otro para manejar todo lo demás: mostrar gráficos, que reciben entrada del controlador, la historia gestionar y marcadores, etc.

También, aunque FreeBSD ha apoyado PID asignación al azar desde 4,0, secuencial asignación PID es el comportamiento predeterminado.

El hecho de que la asignación de PID se ajusta al comportamiento predeterminado indica que Sony probablemente no se molestó en añadir ningún mejoras de seguridad adicionales, tales como los que alentado por proyectos como HardenedBSD.


¿Cuántas llamadas personalizada sistema hay?

El FreeBSD 9 llamada al sistema la última norma es wait6, número 532; nada más alto que esto debe ser un Sony llamada al sistema personalizado.

La invocación de la mayoría de las llamadas al sistema de encargo de Sony sin los argumentos correctos devolverá error 0x16, "Argumento no válido"; sin embargo, ninguna de compatibilidad o de sistema sin aplicarse llamadas reportarán el "No hay suficiente memoria del sistema libre" error.

A través de ensayo y error, he encontrado que la llamada de sistema número 617 es la última llamada al sistema de Sony, nada más alto es sin aplicarse.

A partir de esto, podemos concluir que hay 85 llamadas al sistema Sony personalizados en el kernel de la PS4 (617 - 532).

Esto es significativamente menor que la PS3, que tenía casi 1.000 llamadas de sistema en total. Esto indica que tenemos menos de ataque posibles, pero que puede ser más fácil de documentar todas las llamadas al sistema.

Además, 9 de estos sistemas 85 llamadas siempre regresan 0x4E, ENOSYS, lo que sugiere que sólo puede ser exigible a partir de unidades de desarrollo, que nos deja con sólo 76 que están disponibles.

De estos 76, sólo el 45 se hace referencia en libkernel.sprx (que todas las aplicaciones no esenciales utilizar para realizar llamadas al sistema), por lo que los desarrolladores sólo tienen llamadas al sistema 45 personalizados que pueden utilizar.

Curiosamente, aunque sólo 45 están destinados a ser llamado (porque libkernel.sprx tiene contenedores para ellos), algunos de los otros 31 siguen siendo exigible desde el proceso del navegador de Internet. Es más probable que estos sistemas no deseado llama a tener vulnerabilidades en ellos, ya que probablemente han tenido la menor cantidad de pruebas.


libkernel.sprx

Para identificar cómo las llamadas al sistema de encargo son utilizados por libkernel, primero hay que recordar que es sólo una modificación de las FreeBSD 9.0 bibliotecas estándar.

He aquí un extracto de _libpthread_init de thr_init.c:

/ *
* Salida para el caso especial de este proceso en ejecución como
* O en lugar de inicio como el pid = 1:
* /
if ((_thr_pid = getpid ()) == 1) {
/ *
* Configuración de una nueva sesión para este proceso, que es
* Supone que se ejecuta como root.
* /
si (setsid () == -1)
PÁNICO ("No se puede establecer identificador de sesión");
si (revocar (_PATH_CONSOLE)! = 0)
PÁNICO ("No se puede revocar la consola");
if ((fd = __sys_open (_PATH_CONSOLE, O_RDWR)) <0)
PÁNICO ("No se puede consola abierta");
si (setlogin ("root") == -1)
PÁNICO ("No se puede establecer conexión con la raíz");
si (_ioctl (fd, TIOCSCTTY, (char *) NULL) == -1)
PÁNICO ("No se puede establecer el control de la terminal");
}
La misma función se puede encontrar en el offset 0x215F0 de libkernel.sprx. Así es como el extracto anterior se ve desde el interior de un vertedero libkernel:

llamar getpid
mov cs: dword_5B638, eax
cmp eax, 1
jnz loc_2169F corta

setsid llamada
eax cmp, 0FFFFFFFFh
jz loc_21A0C

RDI lea, aDevConsole; "/ dev / console"
llamar a revocar
eax prueba, eax
jnz loc_21A24

RDI lea, aDevConsole; "/ dev / console"
esi mov, 2
xor al, al
llamar abierta

R14d mov, eax
R14d prueba, R14d
js loc_21A3C
RDI lea, aRoot; "raíz"
setlogin llamada
eax cmp, 0FFFFFFFFh
jz loc_21A54

edi mov, R14d
esi mov, 20007461h
xor edx, edx
xor al, al
ioctl llamada
eax cmp, 0FFFFFFFFh
jz loc_21A6C

Módulo de Inversión de vertederos para analizar las llamadas al sistema

libkernel no es de código completamente abierto sin embargo; también hay una gran cantidad de código personalizado que puede ayudar a revelar algunas de las llamadas al sistema de Sony.

Aunque este proceso puede variar dependiendo del sistema de llamada que busca seguimiento; para algunos, es bastante fácil conseguir un entendimiento básico de los argumentos que se pasan a la misma.

La envoltura llamada al sistema será declarado en alguna parte de libkernel.sprx, y casi siempre seguir esta plantilla:

000000000000DB70 syscall_601 proc cerca
000000000000DB70 mov rax, 259h
000000000000DB77 mov r10, rcx
000000000000DB7A syscall
000000000000DB7C jb error corta
000000000000DB7E RETN
000000000000DB7F
000000000000DB7F error:
000000000000DB7F rcx lea, sub_DF60
000000000000DB86 rcx jmp
Endp 000000000000DB86 syscall_601
Tenga en cuenta que el r10 mov, rcx instrucción no necesariamente significa que la llamada al sistema toma por lo menos 4 argumentos; todos los envoltorios de las llamadas al sistema tienen, incluso las que tienen sin argumentos, como getpid.

Una vez que hayas encontrado la envoltura, puede buscar referencias externas a la misma:

0000000000011D50 mov edi, 10h
0000000000011D55 xor esi, esi
0000000000011D57 mov edx, 1
0000000000011D5C llamada syscall_601
0000000000011D61 eax prueba, eax
Corto loc_11D6A 0000000000011D63 jz
Es bueno ver a varios de ellos, sólo para asegurarse de que los registros no fueron modificados por algo no relacionado:

0000000000011A28 mov edi, 9
0000000000011A2D xor esi, esi
0000000000011A2F xor edx, edx
0000000000011A31 llamada syscall_601
0000000000011A36 eax prueba, eax
Corto loc_11A3F 0000000000011A38 jz
Consistentemente, los tres primeros registros de la convención de llamada al sistema (RDI, RSI, y RDX) se modifican antes de invocar la llamada, por lo que podemos concluir con seguridad razonable de que se tarda 3 argumentos.

Para mayor claridad, así es como nos gustaría replicar las llamadas en Just-ROP:

chain.syscall ("desconocido", 601, 0x10, 0, 1);
chain.syscall ("desconocido", 601, 9, 0, 0);
Al igual que con la mayoría de las llamadas al sistema, devolverá 0 en caso de éxito, como se ve por el jz condicional después de la prueba ing el valor de retorno.

Mirando hacia arriba nada más allá de la cantidad de argumentos requerirá un análisis mucho más profundo del código antes y después de la llamada a entender el contexto, pero esto debe ayudarle a empezar.


El Bruto obligando llamadas al sistema

Aunque módulo de ingeniería inversa vertederos es la forma más fiable de identificar las llamadas al sistema, algunos no están referenciados en absoluto en las descargas que hemos así que vamos a necesitar para analizar ciegamente.

Si suponemos que una cierta llamada de sistema podría tomar un determinado conjunto de argumentos, podemos fuerza bruta todas las llamadas al sistema que devuelven un valor determinado (0 para el éxito) con los argumentos que elegimos, e ignorar todo lo que ha devuelto un error.

También podemos pasar 0s para todos los argumentos, y la fuerza bruta todas las llamadas al sistema que devuelven errores útiles, tales como 0xe, "la dirección está mal", lo que indicaría que se toman al menos un puntero.

En primer lugar, tendremos que ejecutar la cadena de ROP, tan pronto como se carga la página. Podemos hacer esto fijando nuestra función al cuerpo del elemento onload:

<body onload = "explotar ()">
A continuación vamos a necesitar para realizar una llamada específica del sistema en función de un valor GET HTTP. Aunque esto se puede hacer con JavaScript, demostraré cómo hacer esto utilizando PHP para la simplicidad:

var Sony = 533;
chain.syscall ("sistema de llamadas de Sony", Sony + <? php print ($ _ GET ["b"]);?>, 0, 0, 0, 0, 0, 0);
chain.write_rax_ToVariable (0);
Una vez que la llamada al sistema ha ejecutado, podemos comprobar el valor de retorno, y si no es interesante, redirigir la página a la siguiente llamada al sistema:

si (chain.getVariable (0) == 0x16) window.location.assign ("index.php? b =" <? php print ($ _ GET ["b"]);> + (+ 1) .toString ( ));
Ejecución de la página con? B = 0 añadida al final se iniciará la fuerza bruta de la primera llamada al sistema de Sony.

Aunque este método requiere de mucha experimentación, pasando diferentes valores a algunas de las llamadas al sistema que se encuentran por la fuerza bruta y el análisis de los nuevos valores de retorno, hay algunas llamadas al sistema que debe ser capaz de identificar parcialmente.


La llamada al sistema 538

A modo de ejemplo, voy a echar un vistazo a la llamada al sistema 538, sin depender de ningún vertederos módulo.

Estos son los valores de retorno en función de lo que se pasa como primer argumento:

0 - 0x16, "Argumento no válido"
1 - 0xe, "la dirección está mal"
Puntero a 0s - 0x64 al principio, pero cada vez que la página se actualiza este valor se incrementa en 1
Otros posibles argumentos para tratar serían PID, ID del hilo, y descriptor de archivo.

Aunque la mayoría de las llamadas al sistema volverán 0 en caso de éxito, debido a la naturaleza del valor de retorno cada vez mayor después de cada vez que se llama, que parece que es la asignación de un número de recursos, tales como un descriptor de archivo.

El siguiente paso sería la de mirar los datos antes y después de realizar la llamada al sistema, para ver si se ha escrito para.

Dado que no hay ningún cambio en los datos, podemos suponer que se trata de una entrada por ahora.

Entonces intenté pasar una cadena larga como el primer argumento. Usted siempre debe tratar esto con cada entrada a encontrar porque no hay la posibilidad de descubrir un desbordamiento de búfer.

WriteString (chain.data "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");
chain.syscall ("desconocido", 538, chain.data, 0, 0, 0, 0, 0);
El valor de retorno de esto es 0x3f, ENAMETOOLONG. Por desgracia, parece que esta llamada al sistema limita correctamente el nombre (32 bytes incluyendo truncador NULL), pero nos dice que se esperaba una cadena, en lugar de una estructura.

Ahora tenemos algunas posibilidades para lo que esta llamada al sistema que está haciendo, lo más obvio que algo sea relacionada con el sistema de archivos (como una costumbre mkdir o abierta), pero esto no parece particularmente probable ya que un recurso se asignó incluso antes de que escribió ningún dato al puntero.

Para probar si el primer parámetro es un camino, podemos dividirla con múltiples / caracteres para ver si esto permite una cadena más larga:

WriteString (chain.data "aaaaaaaaaa / aaaaaaaaaa / aaaaaaaaaa");
chain.syscall ("desconocido", 538, chain.data, 0, 0, 0, 0, 0);
Dado que este también devuelve 0x3f, podemos suponer que el primer argumento no es un camino; es un nombre para algo que consigue asigna un identificador secuencial.

Después de analizar algunas más llamadas al sistema, me encontré con que el siguiente toda compartió este mismo comportamiento exacto:

533
538
557
574
580
De la información que tenemos hasta el momento, es casi imposible determinar exactamente lo que estas llamadas al sistema hacen, pero ya que se corre más pruebas, más información lentamente se dará a conocer.

Para ahorrar algo de tiempo, la llamada al sistema 538 está asignando una bandera evento (y no sólo tomar un nombre).

Utilizando el conocimiento general de cómo funciona un núcleo, se puede adivinar, y luego verificar, lo que las llamadas al sistema están asignando (semáforos, exclusiones mutuas, etc.).


Dumping módulos adicionales

Podemos volcar módulos adicionales siguiendo estos pasos:

Cargue el módulo
Obtener dirección base del módulo
Volcar el módulo
Yo intenté tediosamente carga y descarga cada módulo desde el navegador de Internet de forma manual, y envió los resultados en psdevwiki. Todos los módulos con Sí próximos a ellos pueden ser arrojados con este método.

Para cargar un módulo tendremos que utilizar el sceSysmoduleLoadModule función desde libSceSysmodule.sprx + 0x1850. El primer parámetro es el identificador de módulo para cargar, y los otros 3 solo se debe pasar 0.

El siguiente método Just-ROP puede ser utilizado para realizar una llamada de función:

this.call = function (nombre, módulo, dirección, arg1, arg2, arg3, arg4, arg5, arg6) {
console.log ("llamada" + nombre);

if (! typeof (arg1) == "undefined") this.add ("RDI pop", arg1);
if (! typeof (arg2) == "undefined") this.add ("rsi pop", arg2);
if (! typeof (arg3) == "undefined") this.add ("rdx pop", arg3);
if (! typeof (arg4) == "undefined") this.add ("rcx pop", ARG4);
if (! typeof (arg5) == "undefined") this.add ("r8 pop", arg5);
if (! typeof (arg6) == "undefined") this.add ("r9 pop", arg6);
this.add (module_bases [módulo] + dirección);
}
Así, para cargar libSceAvSetting.sprx (0xb):

chain.call ("sceSysmoduleLoadModule", libSysmodule, 0x1850, 0xb, 0, 0, 0);
Como la mayoría de las llamadas al sistema, éste debe devolver 0 en caso de éxito. Para ver el ID de módulo cargado que se asignó, podemos utilizar una de las llamadas al sistema de encargo de Sony, número 592, para obtener una lista de los módulos cargados actualmente:

var countAddress = chain.data;
var modulesAddress = chain.data + 8;

// La llamada al sistema 592, getLoadedModules (int destinationModuleIDs *, int max, recuento int *);
chain.syscall ("getLoadedModules", 592, modulesAddress, 256, countAddress);

chain.execute (function () {
recuento var = getU64from (countAddress);
for (var index = 0; index <contar; índice ++) {
logAdd ("Módulo: 0x" + getU32from (modulesAddress + índice * 4) .toString (16));
}
});
La ejecución de este sin cargar cualquier módulo adicional producirá la siguiente lista:

0x0, 0x1, 0x2, 0xc, 0xe, 0xf, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1e, 0x37, 0x59
Pero si lo ejecutamos después de cargar el módulo 0xb, hemos visto una entrada adicional, 0x65. Recuerde que ID módulo es no lo mismo que carga el módulo de identificación.

Ahora podemos usar otra de las llamadas al sistema de encargo de Sony, número 593, que tiene un ID de módulo cargado y un tampón, y se llena el buffer con información sobre el módulo de carga, incluyendo su dirección base. Desde el módulo de identificación cargado siempre es 0x65, podemos codificar en nuestra cadena, en lugar de tener que almacenar el resultado de la lista de módulos.

El tampón debe comenzar con el tamaño de la estructura que debe ser devuelto, de lo contrario error 0x16 será devuelto, "Argumento no válido":

setU64to (moduleInfoAddress, 0x160);
chain.syscall ("getModuleInfo", 593, 0x65, moduleInfoAddress);

chain.execute (function () {
logAdd (hexdump (moduleInfoAddress, 0x160));
});
Volverá 0 en el éxito, y llenar el búfer con una estructura que se puede leer así:

var name = readString (moduleInfoAddress + 0x8);
codeBase var = getU64from (moduleInfoAddress + 0x108);
var codeSize = getU32from (moduleInfoAddress + 0x110);
base de datos de var = getU64from (moduleInfoAddress + 0x118);
var datasize = getU32from (moduleInfoAddress + 0x120);
Ahora tenemos todo lo que necesitamos para volcar el módulo!

dump (codeBase, codeSize + datasize);
Hay otra llamada al sistema Sony, número 608, que funciona de una manera similar a 593, pero proporciona información ligeramente diferente sobre el módulo cargado:

setU64to (moduleInfoAddress, 0x1a8);
chain.syscall ("getDifferentModuleInfo", 608, 0x65, 0, moduleInfoAddress);
logAdd (hexdump (moduleInfoAddress, 0x1a8));
No está claro lo que esta información es.


Navegar por el sistema de archivos

La PS4 utiliza las llamadas al sistema FreeBSD 9.0 estándar para la lectura de archivos y directorios.

Sin embargo, durante el uso de leer para algunos directorios como / dev / funcionará, otros, como / fallarán.

No estoy seguro de por qué esto es, pero si utilizamos gendents lugar de lectura para los directorios, que trabajaré mucho más fiable:

WriteString (chain.data, "/ dev /");
chain.syscall ("abierto", 5, chain.data, 0, 0);
chain.write_rax_ToVariable (0);

chain.read_rdi_FromVariable (0);
chain.syscall ("getdents", 272, indefinido, chain.data + 0x10, 1028);
Esta es la memoria resultante:

0000010: 0700 0000 1000 0205 6469 7073 7700 0000 ........ DipSW ...
0000020: 0800 0000 1000 0204 0000 0000 6c6c 6e75 ........ nula ....
0000030: 0900 0000 1000 0204 0000 0000 7a65 726f ........ cero ....
0000040: 0301 0000 0402 6664 0000 0C00 0b00 0000 ........ fd ......
0000050: 1000 0a05 7374 6469 0000 6e00 0d00 0000 .... stdin .......
0000060: 1000 0a06 7374 646f 7574 0000 0F00 0000 .... stdout ......
0000070: 1000 0a06 6465 7272 0000 7374 1000 0000 .... stderr ......
0000080: 1000 0205 646d 656d 3000 0000 1100 0000 .... dmem0 .......
0000090: 1000 0205 3100 0000 646d 656d 1.300 0.000 .... dmem1 .......
00000a0: 1000 0206 7261 0000 1400 6e64 6f6d 0000 .... al azar ......
00000b0: 1000 0a07 7572 616E 646f 6d00 1600 0000 .... urandom .....
00000c0: 1400 020B 6465 6369 7464 5f73 6f75 7400 .... deci_stdout.
00000d0: 1700 0000 1400 6465 6369 020B 5f73 7464 ........ deci_std
00000e0: 7200 1800 0000 6572 1400 0209 6465 6369 err ......... deci
00000f0: 5f74 3200 0000 1900 7479 0000 1400 0209 _tty2 ...........
0000100: 6465 6369 7479 3300 0000 5f74 1A00 0000 deci_tty3 .......
0000110: 1400 0209 6465 6369 7479 3400 0000 5f74 .... deci_tty4 ...
0000120: 1b00 0000 1400 0209 6465 6369 7479 5f74 ........ deci_tty
0000130: 3500 0000 1400 0209 0000 1C00 6465 6369 5 ........... deci
0000140: 5f74 7479 3600 0000 0000 1400 0209 1d00 _tty6 ...........
0000150: 6465 6369 7479 3700 0000 5f74 1E00 0000 deci_tty7 .......
0000160: 1400 020A 6465 6369 7479 6130 0000 5f74 .... deci_ttya0 ..
0000170: 1f00 0000 1400 6465 6369 020a 5f74 7479 ........ deci_tty
0000180: 6230 0000 2000 0000 1400 6465 6369 020a b0 .. ....... deci
0000190: 5f74 6330 0000 2200 7479 0000 1400 020a _ttyc0 .. ".......
00001a0: 6465 6369 5f73 7464 696e 0000 2300 0000 deci_stdin .. # ...
00001b0:. 0C00 6270 6600 2400 0203 0000 1000 0A04 .... bpf $ .......
00001c0: 6630 0000 0000 6270 2900 0000 0203 0C00 bpf0 ....) .......
00001d0:. 6869 6400 0000 1400 0208 2c00 7363 655f escondió, ....... sce_
00001e0: 7a6c 6962 0000 0000 0000 1000 0204 2e00 zlib ............
00001f0: 7479 0000 0000 6374 3400 0000 0202 0C00 ctty .... 4 .......
0000200: 6763 0000 3900 0000 0203 6463 6500 0C00 gc..9 ....... dce.
0000210: 3A00 1000 0205 6462 0000 6767 6300 0000: ....... dbggc ...
0000220: 3e00 0000 0C00 0203 616A 6d00 4100 0000> ....... ajm.A ...
0000230: 0C00 0203 7576 6400 4200 0000 0203 .... 0C00 uvd.B .......
0000240: 7663 6500 4500 0000 1800 7469 020d 6e6f vce.E ....... noti
0000250: 6669 6361 7469 3000 0000 4600 6f6e 0000 fication0 ... F ...
0000260: 1800 020d 6e6f 7469 6669 6361 7469 6f6e .... notificación
0000270: 3100 0000 5000 0000 1000 0206 7573 6263 1 ... P ....... USBC
0000280: 746C 5600 0000 1000 0000 0206 6361 6d65 tl..V ....... vino
0000290: 7261 0000 8500 0000 0203 0C00 726e 6700 ra .......... rng.
00002a0: 0701 0000 0403 7573 6200 0C00 c900 0000 ........ usb .....
00002b0: 1000 0a07 7567 656e 302e 3400 0000 0000 .... ugen0.4 .....
00002c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
Usted puede leer algunos de estos dispositivos, por ejemplo: leer / dev / urandom llenarán la memoria con datos aleatorios.

También es posible analizar esta memoria para crear una lista limpia de entradas; mira browser.html en el depósito de un explorador de archivos completo:



Desafortunadamente, debido a la caja de arena no tenemos un acceso completo al sistema de archivos. Tratar de leer archivos y directorios que no existen pero están restringidos le dará error 2, ENOENT, "No existe el fichero o directorio".

Tenemos acceso a un montón de cosas interesantes, aunque incluyendo cifrado guardar datos, trofeos, e información de cuenta. Voy a ir por más del sistema de archivos en mi próximo artículo.


Sandboxing

Además de archivos relacionados con las llamadas al sistema en su defecto para ciertos caminos, hay otras razones para que una llamada al sistema al fracaso.

Por lo general, una llamada al sistema no permitido será solo error regresar 1, EPERM, "Operación no permitida"; como tratando de usar ptrace, pero otras llamadas al sistema pueden fallar por diversas razones:

Llamadas al sistema Compatibilidad están desactivados. Si usted está tratando de llamar mmap por ejemplo, debe utilizar el sistema número de llamada 477, no 71 o 197; de lo contrario se disparará una violación de segmento.

Otras llamadas al sistema, como la salida también dará lugar a una violación de segmento:

chain.syscall ("salida", 1, 0);
Tratar de crear una toma de SCTP ​​devolverá error 0x2B, EPROTONOSUPPORT, lo que indica que las tomas SCTP ​​se han deshabilitado en el kernel PS4:

// int socket (int dominio, tipo int, int protocolo);
// socket (AF_INET, SOCK_STREAM, IPPROTO_SCTP);
chain.syscall ("socket", 97, 2, 1, 132);
Y aunque llamando mmap con PROT_READ | PROT_WRITE | PROT_EXEC devolverá un puntero válido, el PROT_EXEC se ignora bandera. La lectura de su protección regresará 3 (RW), y cualquier intento de ejecutar la memoria dará lugar a una violación de segmento:

chain.syscall ("mmap", 477, 0, 4096, 1 ​​| 2 | 4, 4096, -1, 0);
chain.write_rax_ToVariable (0);
chain.read_rdi_FromVariable (0);
chain.add ("rax pop", 0xfeeb);
chain.add ("mov [RDI], rax");
chain.add ("rax mov, RDI");
chain.add ("rax jmp");
La lista de software de código abierto utilizado en la PS4 no muestra ningún tipo de software caja de arena como Capsicum, por lo que la PS4 debe utilizar ya sea puros cárceles de FreeBSD, o algún tipo de encargo, sistema propietario, sandboxing (poco probable).


Cárceles

Podemos probar la existencia de cárceles de FreeBSD está utilizando activamente en el kernel de la PS4 a través de la auditon llamada al sistema es imposible de ejecutar en un entorno encarcelados:

chain.syscall ("auditon", 446, 0, 0, 0);
Lo primero que el auditon llamada al sistema hace es comprobar encarcelado aquí, y si es así, volver ENOSYS:

si (encarcelado (TD> td_ucred))
retorno (ENOSYS);
De lo contrario, la llamada al sistema lo más probable retorno EPERM del mac_system_check_auditon aquí:

error = mac_system_check_auditon (TD> td_ucred, uap-> cmd);
si (error)
volver (error);
O desde el priv_check aquí:

error = priv_check (td, PRIV_AUDIT_CONTROL);
si (error)
volver (error);
Lo más lejos absoluta de que la llamada de sistema podría alcanzar sería inmediatamente después de la priv_check, aquí, antes de regresar EINVAL debido al argumento de longitud siendo 0:

if ((uap-> longitud <= 0) || (uap-> Duración> sizeof (auditon_udata sindicato)))
volver (EINVAL);
Desde mac_system_check_auditon y priv_check nunca volverán ENOSYS, teniendo la encarcelado pase cheque es la única manera ENOSYS podrían ser devueltos.

Al ejecutar la cadena, ENOSYS se volvió (0x48).

Esto nos dice que todo lo sandbox sistema de la PS4 se utiliza al menos basado en las cárceles debido a que el encarcelado cheque pasa.


FreeBSD hazañas 9.0 del kernel

No tiene mucho sentido tratar de buscar nuevas vulnerabilidades en el código fuente del kernel de FreeBSD 9.0 ya que desde su lanzamiento en 2012, ya se han encontrado varios exploits del kernel, que la PS4 podría ser potencialmente vulnerables a.

Podemos descartar de inmediato algunos de ellos por razones obvias:

FreeBSD 9,0-9,1 mmap / ptrace - Privilege Escalation Exploit - esto no funcionará, ya que, como se dijo anteriormente, no tenemos acceso a la ptrace llamada al sistema.
FreeBSD 9.0 - Intel SYSRET Kernel Privilege Escalation Exploit - no va a funcionar porque la PS4 utiliza un procesador AMD.
Kernel de FreeBSD - Múltiples vulnerabilidades - tal vez la primera vulnerabilidad conducirá a algo, pero los otros 2 se basan en sockets SCTP, que el núcleo PS4 ha deshabilitado (como se indica anteriormente).
Sin embargo, hay algunas vulnerabilidades más pequeños, lo que podría conducir a algo:


getlogin

Una vulnerabilidad que parece fácil de probar es el uso de la llamada al sistema getlogin a gotear una pequeña cantidad de memoria del kernel.

El getlogin llamada al sistema está diseñado para copiar el nombre de inicio de sesión de la sesión actual en la memoria espacio de usuario, sin embargo, debido a un error, todo el búfer siempre se copia, y no sólo el tamaño de la cadena de nombre. Esto significa que podemos leer algunos datos no inicializados desde el núcleo, lo que podría ser de alguna utilidad.

Tenga en cuenta que la llamada al sistema (49) es en realidad int getlogin_r (char * nombre, int len); y no char * getlogin (void);.

Por lo tanto, vamos a tratar de copiar algo de memoria del núcleo en una parte no utilizada de la memoria espacio de usuario:

chain.syscall ("getlogin", de 49 años, chain.data, 17);
Desafortunadamente 17 bytes es la mayoría de los datos que podemos obtener, ya que:

Nombres de usuario se limitan a MAXLOGNAME (de <sys / param.h>) caracteres, actualmente 17, que incluye nulo.
- FreeBSD Hombre Páginas

Después de la ejecución de la cadena, el valor de retorno de 0, lo que significa que la llamada al sistema funcionó! Un excelente comienzo. Ahora echemos un vistazo a la memoria que señalamos:

Antes de la ejecución de la cadena:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
Después de la ejecución de la cadena:

72 6f 6f 74 00 fe ff ff 08 62 61 82 ff ff ff ff
00
Después de decodificar los primeros 4 bytes ASCII como:

raíz
Así que el navegador se ejecuta como root! Eso fue inesperado.

Pero lo más interesante es que la memoria perdida se parece a un puntero a algo en el núcleo, que es siempre lo mismo cada vez que se ejecute la cadena; esto es una evidencia para apoyar las afirmaciones de Yifanlu que la PS4 no tiene ASLR Kernel!


Resumen

A partir de la información disponible en la actualidad, el núcleo de la PS4 parece ser muy similar al 9,0 núcleos existentes FreeBSD.

Es importante destacar que las diferencias que se encuentran presentes parecen ser del estándar de configuración del kernel cambios (como la desactivación de sockets SCTP), en lugar de código modificado. Sony también ha añadido varios de su propio sistema personalizado llamadas al kernel, pero aparte de esto, el resto del kernel parece bastante intacta.

En este sentido, me inclino a creer que las acciones PS4 la mayor parte de las mismas vulnerabilidades jugosas como kernel de FreeBSD 9.0!

Desafortunadamente, la mayoría de los exploits del kernel no se pueden activar desde el punto de entrada WebKit que tenemos actualmente debido a las limitaciones sandboxing (susceptibles de ser simplemente abastecerse cárceles FreeBSD).

Y con FreeBSD 10 estar fuera, es poco probable que alguien está escondiendo la basura cualquier hazañas privadas para FreeBSD 9, por lo menos que uno nuevo se libera de repente, estamos atascados con lo que está disponible actualmente.

Puede que no sea posible explotar el kernel PS4 mediante el aprovechamiento de algunas de las vulnerabilidades de corrupción de memoria del kernel existentes, pero sin duda would't ser fácil.

El mejor enfoque de aquí parece ser la ingeniería inversa todos los módulos que pueden ser objeto de dumping, con el fin de documentar ya que muchos de sistema personalizado de Sony llama como sea posible; Tengo el presentimiento de que vamos a tener más suerte la orientación de estas, de las llamadas al sistema estándar de FreeBSD.

Recientemente Jaicrab ha descubierto dos puertos UART en la PS4, que nos muestra que hay hackers de hardware interesados ​​en la PS4. Aunque el papel de los hackers de hardware ha sido tradicionalmente para volcar la memoria RAM de un sistema, al igual que con la DSi, que ya podemos hacer gracias a la WebKit explotar, también existe la posibilidad de un hardware desencadenado la vulnerabilidad del kernel que se encuentra, al igual que la PS3 original Geohot truco hipervisor. Sigue siendo más probable que un núcleo de explotación se encuentra en la PS4 través de vulnerabilidades llamada al sistema embargo.


Gracias

Flatz
SKFU
Droogie
Xerpi
BigBoss
Hambre
Takezo
Proxima