Mensaje por Hermes 01 Oct 2010 18:16
Zam escribió:Bueno, pues efectivamente parece ser un problema de permisos de acceso a los archivos. He estado comprobando que una vez eliminado el parche (lanzando el poke por ejemplo) ya no se puede acceder a ciertos sitios.
Podéis comprobarlo, lanzando por ejemplo el servidor FTP e intentando entrar a las carpetas dev_flas2, dev_flash3, o a cualquier carpeta del HDD interno que no sea "games". En todas os va a dar error 550 (acceso denegado). Parece que el famoso parche lo que debe hacer es dejar campo abierto al acceso de archivos por el "usuario" activo en GameOS, sean cuales sean sus atributos de permisos. Al quitar el parche perdemos esa mejora y como los métodos que usábamos antes para pasar los juegos al disco no de daban atributos de acceso total (777 como bien decia Hermes), al quitar el parche ya no podemos acceder a ellos y empiezan las cosas raras.
Esto es una especulación, pero tras observar el comportamiento, es la conclusión que saco.
Una vez comprendido todo, ya he podido hacer funcionar el F1 con mandos.
salud.
Si, es un tema de permisos y aporto unos cuantos datos mas: al entrar en el F1, te dice que tienes los datos dañados y no funciona la reinstalación, porque seguramente, los permisos de los datos creados no permiten la modificación desde el juego.
Tambien he tratado de copiar el F1 desde disco duro interno a externo y se ha abortado la copia, sin mostrar errores, por lo que no ha sido un fallo en el proceso de copiado, si no accediendo/creando directorios.
He cometido un error con las prisas y he borrado el F1 del disco interno sin querer, pero quiero probar si es posible arrancar el juego desde disco duro externo, si se le copian con los permisos pertinentes desde el interno.
En todo caso, creo que ya tengo en mi mano unos cuantos datos interesantes para intentar refinarlo para un parche, que no nos de problemas ni con nuestros permisos, ni con los juegos (pero necesitaré tiempo para investigar un poco y desarrollarlo, si mi idea va por buen camino, así que no me atosiguéis)
Hermes escribió:Bueno señores: he hecho una compilación con una rutina nueva, suponiendo que la rutina de marras (la que estaba parcheada y daba problemas) recibe la ruta de un fichero en el registro %r3 y he añadido una comprobación para que en caso de usar disco duro retorne 1 y parece que funciona la cosa
Para los que no 'entienden' y piensan que hablo en chino, se trata de una rutina que retorna un 1 o un 0 en función de algo que le es pasado como parámetro (se supone que la ruta de un fichero) y que tiene relación con los permisos de acceso a los ficheros. El payload parchea eso y hace que retorne 1 siempre y eso es lo que daba problemas con juegos como el F1, por que digamos que hay caso donde debería devolver 0.
Así que en su lugar, lo que estoy tratando es de detectar cuando se accede al disco duro para fijar el 1 que nos da barra libre y dejar otras cosas a su aire.
Tambien me he ocupado de cubrir los dispositivos USB, pero todo esto requiere espacio y como ya teníamos que salirnos del espacio normal del exploit, por que es un pequeño y dejar una rutina en 0x700000, he decidido mover todo el código a 0x7ff000, lo cual añade 1MB extra al 1MB y pico que ya había de distancia desde los módulos a donde teníamos la tabla de parches que no nos cabía.
La razón es obvia: necesitamos espacio extra para trabajar y el punto donde está mas a salvo, es al final de esos 8MB que parece medir el Kernel (si me equivoco en esto,que alguien me corrija).
Si da algún problema (que no creo), siempre hay posibilidad de dar marcha atrás y hacer las cosas de otra forma, pero creo que lo mas inteligente, es correrlo hacia abajo, lo cual nos permitirá añadir mas cosas.
Hoy estoy cansado, así que mañana subiré el código para que lo toqueteéis
PD: Evidentmente, ya no hará falta el poke de marras: si lo hacéis, trabajará igual que antes, claro está
nascar escribió:Buenas gente, creo que aqui hay un lio de cojones.. según tengo entendido.
1- Creo recordar que El OM no tiene ftp, solo es para el /homebrew desde el usb.
2- Según e leído en el post de Hermes el F1 cuando pasas datos desde el ftp, se pierden archivos necesarios por culpa de los permisos para poder jugar al F1. ( Para que funcione se tienen que pasar a través de un disco extraible y con el Comgenie’s Awesome Filemanager ).Mensaje por Hermes 01 Oct 2010 18:16
Zam escribió:Bueno, pues efectivamente parece ser un problema de permisos de acceso a los archivos. He estado comprobando que una vez eliminado el parche (lanzando el poke por ejemplo) ya no se puede acceder a ciertos sitios.
Podéis comprobarlo, lanzando por ejemplo el servidor FTP e intentando entrar a las carpetas dev_flas2, dev_flash3, o a cualquier carpeta del HDD interno que no sea "games". En todas os va a dar error 550 (acceso denegado). Parece que el famoso parche lo que debe hacer es dejar campo abierto al acceso de archivos por el "usuario" activo en GameOS, sean cuales sean sus atributos de permisos. Al quitar el parche perdemos esa mejora y como los métodos que usábamos antes para pasar los juegos al disco no de daban atributos de acceso total (777 como bien decia Hermes), al quitar el parche ya no podemos acceder a ellos y empiezan las cosas raras.
Esto es una especulación, pero tras observar el comportamiento, es la conclusión que saco.
Una vez comprendido todo, ya he podido hacer funcionar el F1 con mandos.
salud.
Si, es un tema de permisos y aporto unos cuantos datos mas: al entrar en el F1, te dice que tienes los datos dañados y no funciona la reinstalación, porque seguramente, los permisos de los datos creados no permiten la modificación desde el juego
Tambien he tratado de copiar el F1 desde disco duro interno a externo y se ha abortado la copia, sin mostrar errores, por lo que no ha sido un fallo en el proceso de copiado, si no accediendo/creando directorios.
He cometido un error con las prisas y he borrado el F1 del disco interno sin querer, pero quiero probar si es posible arrancar el juego desde disco duro externo, si se le copian con los permisos pertinentes desde el interno.
En todo caso, creo que ya tengo en mi mano unos cuantos datos interesantes para intentar refinarlo para un parche, que no nos de problemas ni con nuestros permisos, ni con los juegos (pero necesitaré tiempo para investigar un poco y desarrollarlo, si mi idea va por buen camino, así que no me atosiguéis
De todos modos tambien a dicho esto a finales de la noche igual mañana nos da una sorpresa.
Hermes escribió:Bueno señores: he hecho una compilación con una rutina nueva, suponiendo que la rutina de marras (la que estaba parcheada y daba problemas) recibe la ruta de un fichero en el registro %r3 y he añadido una comprobación para que en caso de usar disco duro retorne 1 y parece que funciona la cosa
Para los que no 'entienden' y piensan que hablo en chino, se trata de una rutina que retorna un 1 o un 0 en función de algo que le es pasado como parámetro (se supone que la ruta de un fichero) y que tiene relación con los permisos de acceso a los ficheros. El payload parchea eso y hace que retorne 1 siempre y eso es lo que daba problemas con juegos como el F1, por que digamos que hay caso donde debería devolver 0.
Así que en su lugar, lo que estoy tratando es de detectar cuando se accede al disco duro para fijar el 1 que nos da barra libre y dejar otras cosas a su aire.
Tambien me he ocupado de cubrir los dispositivos USB, pero todo esto requiere espacio y como ya teníamos que salirnos del espacio normal del exploit, por que es un pequeño y dejar una rutina en 0x700000, he decidido mover todo el código a 0x7ff000, lo cual añade 1MB extra al 1MB y pico que ya había de distancia desde los módulos a donde teníamos la tabla de parches que no nos cabía.
La razón es obvia: necesitamos espacio extra para trabajar y el punto donde está mas a salvo, es al final de esos 8MB que parece medir el Kernel (si me equivoco en esto,que alguien me corrija).
Si da algún problema (que no creo), siempre hay posibilidad de dar marcha atrás y hacer las cosas de otra forma, pero creo que lo mas inteligente, es correrlo hacia abajo, lo cual nos permitirá añadir mas cosas.
Hoy estoy cansado, así que mañana subiré el código para que lo toqueteéis
PD: Evidentmente, ya no hará falta el poke de marras: si lo hacéis, trabajará igual que antes, claro está
Saludos
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
jomuto escribió:pero para los disco duros externo, no interfiere no? no hace falta canviar ruta, ese solo para si juegas con juegos en disco duro interno.
doble-h escribió:vale vale, pues con eso cambio la ruta para que me lea los juegos uno y otro... pero eso lo hago dentro de cada manager no? y si lo tengo externo es lo mismo?
martigs escribió:Para actualizar el open manager, si borro la version antigua, me borrara todos los juegos que tengo dentro del hd de la play? o instalo directamente la nueva y me reemplazara la antigua? que debo hacer porque cada vez que actualize tener que copiar los juegos atraves de usb o ftp es un poco una burrada...
cejudin escribió:A mi por ejemplo el OM 1.3 me deja la consola colgada cada 2 por 3 entonces tengo el BM para todos los juegos excepto los del parche que esos los abro con el OM...
doble-h escribió:cejudin escribió:A mi por ejemplo el OM 1.3 me deja la consola colgada cada 2 por 3 entonces tengo el BM para todos los juegos excepto los del parche que esos los abro con el OM...
+1! es una ventaja tener unos cuantos loader, como en la Wii el de Hermes + el Loader GX perfecta combinacion!
pues en la PS3 igual, y ahora cuando el key team tenga el suyo, tambien lo pondré, ahora si llega un dia, que haya uno que nadie le haga sombre ese solo
