lenkagamine03 escribió:yo siempre me termine esperando el supuesto rgh para ps3 que una vez vagamente se anunciotengo dos ps3 cfw pero hubiera sido muy bueno que todas fueran hackeables
El hack que ejecuto GeoHot era a base de glitch, abrio la vulnerabilidad por comandos de software (por medio de OtherOS), y despues utilizo un ataque tipo glitch para burlar los checkeos (sc) del hypervisor. Geo conecto un fpga al bus de memoria, con un pulso de 40ns comprometio el HTAB, etc. La historia del hack de ps3 es tan interesante como la del 360 (y curiosamente muy ligada). Asi que tecnicamente si hay un rgh ps3.
[spoiler]Tmv_Josue escribió:Me sirvió este hilo @HetsR ya que desde hace tiempo no me paso por aquí, no has pensado en pasarlo a la Wiki para darle mas estilo y consistencia entre todos?? y poner enlaces a hilos (de EOL) y páginas oficiales?? se lee muy bien solo que quedaría mas a mano los enlaces para continuar con la lectura o buscar los origenes.
Lo mas similar es el projecto free60 pero ya habra alguien recopilando una que otra cosa.
MiralaTijera escribió:HetsR escribió:lenkagamine03 escribió:primero que nada mil gracias por todo tu trabajo MLT y respecto al post siempre me llamo la atencion por que no es posible un xploit via softmod si se conocen las keys y demas
Te diría que realmente no ha habido necesidad de hacerlo, el RGH es muy fácil de conseguir, te lleva literalmente 15 minutos para soldar 5 cables.
.............................................................
Edit: respecto a lo que ha anunciado el compañero @MiraLaTijera ,preguntando a un mod de otro foro me dice lo siguienteBueno, Dual Nand no se puede conseguir sin soldadura de hardware, por lo que suena muy poco probable.
Es una fuente muy fiable con bastante experiencia en la scene, modera uno de los foros "top" en el tema, lo que me lleva a impaciantarme más por lo que has comentado
Un saludo!
Dile que es perfectamente posible redireccionando las peticiones MMIO de la nand
RING RING RING Info clave de alguien que sabe de lo que habla. (vease enlaces en El RGH a nivel componente) (sobre el comentario de HetsR que el rgh es facil de conseguir igual recomiendo los enlaces)
HombreTriton escribió:Tequendama escribió:@HombreTriton
habláis de un xploit web??
pues es lo mas altruista que e escuchado ya que si se lograse entrar al núcleo por una vulnerabilidad web a priori de haber aprovechado una en el explorador ( que supongo es la misma vulnerabilidad de los iphone) ,pues la gente no tendría que mandar hacer rgh a una tienda o ltu ,ni quizás un downgrade o la instalación de un cobra ode , en fin cualquiera pudiese bien ver un tutorial de youtube e instalar el webkit y las tiendas o centros donde instalan estas cosas se irian al carajo
supongo que no trabajas con esto verdad ??
un saludo
Sí y no a tú última pregunta pero hice más de 2000 RGH´s desde el 2012.
Consulté por el tema de las Winchester más que nada, la entrada vía RGH está cerrada y ya quedó demostrado. Quizás hay otra entrada por hardware pero seguro que no es el RGH que todos conocimos.
PS4 se llega a acceder al kernel desde el navegador, aunque no sea público aún pero eso existe.
A lo que voy es que seguramente debe existir una vía de entrada similar para PS3 y Xbox 360.
MMMMMMM.............................., solo dejo esto aqui, el rgh es imparchable sin un rediseño del cgpu y el southbridge.
Habiendo dicho esto, la vulnerabilidad del exploit no existe como tal en placa winchester, aun si consiguieramos una referencia para el glitch (post), el propio cgpu filtra cpu rst e ignora el pulso. Habiendo dicho esto, se parcheo el hack, la vulnerabilidad sigue presente.
Tequendama escribió:@HombreTriton pues el mercado de videoconsolas esta mas migrante que nunca , las generaciones se van a acortar mas y mas nuevas consolas van a salir y mas seguras ,no es mas que la "obsolescencia programada" en todo su esplendor.
ademas ya hay muy pocos scener que comparten sus trabajos y la tendencia va seguir igual
un saludo
Me da tristeza escuchar eso. Hay mucho desarrollo que creo ira surgiendo, mas con info recientemente publicada. Y aun hay uno que otro open source warrior.
Sanji_san escribió:Gran información, pues asi no se trata solo de soldar unos cables, sino de saber bien lo que se esta haciendo, con respecto a la publicacion del colega miralatijera, se refiere a que ya no tendremos necesidad de instalar un chip para ejecutar el RGH? o se refiere a que a traves de software podremos hacer una dual nand para acceder al online usando la consola con su nand original, teniendo ya instalado el rgh, sin utilizar el kit de dual nand?
si el RGH como dicen, se haria por soft, osea nada de soldar chips, esto quiere decir que las winchester tambien se podrian hacer?
Respondido por la scene (ya hay rgh sin chip) mas si requiere soldadura.
El hilo habla de una desaceleracion del cpu de 8x en rgh2.
En trinity el chip hanna solo permite ralentizar el cpu por un factor de 3.1
En corona igual de 3 a 4 x. (rgh2)
En rgh 3 se desacelera entre 600 y 700 x.
(igual mencionar las diferencias algoritmicas en el codigo del CB entre fat y slim (de pasada el error que cometio microsoft que permitio portear el hack de fat a slim). (rgh2) Esta parte no es una correccion pero le daria contexto.
La seccion Cómo funciona el sistema de seguridad de Xbox 360 seria mejor eliminarla o por lo menos añadir info sobre (todos tienen relevancia sobre el hack);
CPU key
E fuses
Ejecutables firmados
Actualizaciones de firmware
El southbridge (de pasada el 8051/8052)
La encriptacion del hdd
El hypervisor (como funciona)
La seguridad del bootloader y sus syscalls
La encriptacion de la memoria
La seccion RGH1 no esta actualizada, hay forma de glitchear las consolas que menciona y la simplificacion resulta en desinformacion ie : "El fallo de restablecimiento funciona mediante la utilización de bucles de bloqueo de fase (PLL) para reducir la CPU en 128 veces y enviar un pequeño impulso eléctrico al punto CPU_RST (CPU reset). Esto hace que los registros de la CPU devuelvan datos falsos y permitan la ejecución de código no firmado."
Esta aseveracion en realidad me cuesta trabajo entender de forma tecnica ( datos falsos??)
Se refiere a esto:
- La consola inicia el bootloader
- La architectura (x86) y naturaleza de la consola envia codigos de 8 bits en el bus post
-Estos codigos nos dan info de cada parte del proceso de ejecucion del BL
Parte1;
- La desencriptacion del BL se da en POST 0xD8 (Aqui info de la nand pero intentare simplificar)
-Esperamos a que la consola nos indique que esta ejecutando la funcion antes mencionada esto esta en el codigo con el que se programa el glitcher (por esto no se puede glitchear winchester de esta manera, no existe esta referencia).
-El glicher envia el comando a I2c en rgh 1, para desacelerar el cpu.
-La verificacion del BL (SHA1) se da en POST 0xDA, aqui esta la magia, Si la firma del codigo coincide la consola inicia, si no el sistema se resetea.
- El glitcher espera el codigo 0xDA, despues envia el pulso:
- El glitch es un pulso de 3 a 12 nanosegundos que se envia justo cuando se ejecuta una funcion de comparacion de memoria (memcmp). Este comando recide en la verificacion del BL (SHA1).
- El pulso crea un bug o error en el proceso que arroja un valor de 0x00 en memcmp independientemente de los datos que comparo.
- Si el pulso electromagnetico llega a CPU RST en el momento preciso, el cpu da por realizada la verificacion del BL pues nos arroja un valor de 0x00 en memcmp (aqui podemos ejecutar codigo sin firmar)
- Si el valor no es el adecuado un parche al SMC reinicia el proceso.
- Si el glitch funciona y el BL se da por bien servido, el glitcher envia el comando a I2c de volver a la velocidad default.
- El HV toma control y sede funciones al kernel (empieza la animacion de boot)
- Insertar aqui info sobre fuentes de tiempo del smc (un chip intel con memoria y firmware propio), hana, ana, el cristal de 27 mhz nativo, pero de nuevo, buscare simplicidad.
- A esto hay que añadir como se extrae la cpu key, los parches al CB, etc.
Dato curioso ; Un smc retail checa desde el sensor de inclinacion de la consola (tu 360 sabe si esta vertical u horizontal, hasta temperaturas, valores del sensor ir, el estado del drive dvd, y algunas curiosidades mas.
Esperemos el hilo se valla volviendo mas " cientifico". me gustaria mencionara el protocolo que utiliza la consola para comunicar el codigo que menciono ( es PCI Express con velocidad de 500mbs). Las funciones de escritura de RAM del SB, y como proteje al cpu de programadores externos, la comunicacion entre SB y CPU por medio de una unidad FIFO / PEPS de 64bits (tambien usado en otras consolas (aqui hay relevancia con el jtag pues la vulnerabilidad de software (al fin el jtag es un hack de software) se aprovechaba de un error de programacion que solo comparaba 32b de un comando y lo ejecutaba como de 64b.)
Algunas sugerencias;
El Hypervisor (datos tecnicos) Este lo dejo yo de inicio:
Es un programa de 128 kb y tiene el nivel mas alto en la jerarquia del boot.
Que hace:
Previene el acceso a secciones que no estan dentro de su progranacion,
IE previene el acceso a la memoria o a algunas partes de ella.
IE previene que se modifiquen valores en memoria RAM encriptando los datos y desencriptandolos
solo cuando el CPU los obtubo del Lv2.
Usa el protocolo W^X (W XOR X) .
Tiene la capacidad de encriptar ejecutables y otros archivos.
Tiene la capacidad de bloquear el BL.
Funciona con system calls y hashes.
Es muy similar al del PS3.
El HV y el RGH:
Les dejo esto por lo pronto, en realidad aqui solo pondre una traduccion del recurso y algunos datos interesantes que no estan ahi:
https://free60.org/Hypervisor/
- La nand y el KV o keyvault (clave unica por consola)
- -Proteciones de memoria yLV1, LV2
-El Bootrom de 32kb y comandos del BL
- Las claves RSA de microsoft
- El kernel
- La jerarquia del hardware en ejecucion de comandos y el BL; Partes :
1 - Verificaciones HMAC, SHA1, ROT. la SRAM y dus derivados..
2 - comunmente llamada CB, posteriormente CBA y CBB.
3 - 4BL o CD
4 - CF y y verificaciones de nand
5 - CD ( el hypervysor entra en modo Dios y ejecuta el kernel )
Ah y casi se me olvida, aqui entran los efuses.
Esto no incluye la cadena de confianza en el boot, detalles del bug en comparacion de memoria, el dato que inicio todo (un misterioso personaje (cjak) nos hace saber que podemos reducir la velocidad del cpu a 25mhz usando PLL_Bypass), el generador de numeros al azar, las acciones de microsoft y como su verificacion de CBB resulto en falla, protecciones del drive dvd, el hack DGX y diferencias con el rgh, el nuevo punto PLL en slims (hace exactamente un año y otros datos y evoluciones del hack.)
Aprovecho aqui para darle una mencion y agradecimiento al legendario BlackCat que permitio el uso del hack DGX sin necesidad de hardware de TX. Un honor siempre Black.
Espero en cuanto me lo permitan mis responsabilidades compartir una recopilacion de toda esta info y de lo interesante que ha sido entender y vulnerar las medidas de seguridad de este hardware.
Info basica del RGH (disponible en el proyecto free60 o wikipedia):
Sobre encriptacion RC4
CB, CBA, CBB y zero pair mode
Como se llegaba a los timings
0x00 en memcmp (la clave del hack)
La secuencia del BL y los codigos post relevantes
