› Foros › PlayStation 3 › Modchips y Softmods
Hermes escribió:Buenas.
Os recuerdo que esto es un hilo de DESARROLLO DEL PAYLOAD y no de adaptaciones de éste a distintos sistemas, que de eso, se deben ocupar otros en sus respectivos hilos.
Por otro lado, éste payload no es igual al que usa kakaroto, con lo cual, si lo estáis insertando hexadecimalmente y os hace cosas raras, no sería de extrañar y lo que se requiere, es que alguien lo compile y lo cuelgue en su hilo correspondiente.
Dicho esto, paso a manejar otras cuestiones que he visto por ahí
¿Por que no subes el proyecto a github?
Por múltiples razones:
En primer lugar, esto nació debido a que el payload de psgroove no era público (o yo al menos no vi código fuente) y a que ciertas personas, se limitaban a trabajar en el payload sin capacidad de cargar juegos. Así que volqué port1_config_descriptor y lo desensamblé, ayudado de los comentarios en ps3wiki.lan.st sobre el payload y la aportación de AerialX que acabó desembocando en la carga de algunos juegos sin disco.
La idea era disponer de un código fuente que se pudiera compilar y mejorar, sin que restricciones de tipo moral o legal que afectara a otras personas, nos supusieran una traba a quienes pensamos de forma diferente o no tenemos esas restricciones y quisiéramos aportar nuestro grano de arena.
Por otro lado, no creo que sea justo (o como decimos en plan colega: "legal") añadir un psgroove paralelo en github, cuando los autores originales ya lo tienen de esa forma, ni creo que sea justo añadir mi copyright como autor de un payload que no me pertenece, puesto que los autores originales forman parte de lo que se conoce como "psjailbreak". Desde mi punto de vista, el código de payload pertenece a unos señores anónimos, con un copyright dudoso, pero sigue perteneciéndole a ellos y yo contribuyo con unas mejoras como usuario y programador aficionado (sin ánimo de lucro eso si), simplemente. Y por tanto, no puedo (o no debo) añadir copyright, aunque me sienta muy libre de añadir mejoras.
Si otros quieren hacerlo, e incluso cambiar el código para tener la excusa de hacerlo, están en su derecho, pero yo pienso que no se puede ensuciar la GPL por ejemplo, colgando el código del payload con esa licencia y que tampoco está bien meter un "Copyright Hermes", salvo que el equipo original lo haga y eso me permita ser co-autor con mis cambios. No se si a los autores originales les gustará la idea de que otros metamos mano a su código, pero ellos tampoco es que hayan sido muy respetuosos y legales y al menos yo aporto mejoras y no me aprovecho, simplemente, del código de otros sin más.
También opino que la scene debe ser un trabajo colectivo, que no de grupo: cuando un grupo se constituye, eso supone una restricción en la participación de otros usuarios y una limitación en el desarrollo.
Por ejemplo, supongamos que mañana cuelgo el proyecto en github. ¿Quien puede subir sus aportaciones?. Solo a quien YO otorgue permisos y puesto que yo lo administraría, todas aquellas ideas que no casen con mi filosofía, no podrían añadirse y al final, estaríamos en las mismas
Un ejemplo claro es el siguiente: yo tengo una filosofía de trabajo que kakaroto por ejemplo, no comparte ¿creéis que podemos colaborar en ese sentido?. Yo creo que es un no tajante: el puede incluir lo que le guste de mi código y yo puedo incluir lo que me guste del suyo, pero AMBOS, seguimos caminos distintos y tenemos ideas contrapuestas. Por tanto el github no funcionaría.
Así que un simple .rar con todo incluido me parece una solución muy buena para facilitar el desarrollo y la portabilidad del payload a ciertas personas, que por supuesto, pueden aportar sus parches o fuentes cambiados e incluso seguir su propio camino en ciertos aspectos. El github estaría bien si esto realmente, fuera open source friendly y hubiese la voluntad de trabajar todos en el mismo sentido y esto tuviera un tamaño desorbitado, pero aquí por el momento, ni siquiera han habido aportaciones al payload mas allá de añadir un par de "pokes" para los juegos y pasar un .S que mide menos de 25KB sin comprimir, no creo que sea gran problema
¿Por que no se soportan otras versiones de firmware?
Hay dos razones de peso: la primera, que yo solo tengo una PS3 y tiene el firmware 3.41. La segunda es que opino que es un error trabajar en versiones del pasado, puesto que ofrecen menos compatibilidad con los juegos, mayor dificultad a la hora de encontrar parches y al final, solo sirve para multiplicar el trabajo x 10 para obtener peor resultado.
Yo se que algunos lo hacen para mantener Linux, etc, pero es que en la vida no se puede tener todo y en mi opinión, es una actitud ilógica trabajar por ejemplo, para 3.15, cuando ya hay juegos que nos reclaman 3.42 y parece mas lógico tratar de ir hacia delante y centrarse en conocer BIEN lo que hace el firm 3.41, (que es el estándar) que otra cosa.
peek/poke, syscall 36 y syscall 8
Explicar a estas altura la necesidad de estas syscalls, casi me parece de perogruyo: a mi sinceramente, las syscalls de peek y poke no me gustan, pues solo mueven datos de 8 bytes y son muy simplonas, francamente. Pero, aunque yo tengo una solución mejor (memcpy mediante la syscall8) la regla de oro que debe tener cualquier desarrollador, es la compatibilidad hacia atrás en lo posible. Tambien poke y peek son las ventanas a lv2 que usan algunos y parece un poco idiota limitarnos.
Por ese motivo la syscall 36 no se debe suprimir, ya que aunque open manager nos permite cambiar por otra facilmente, le estamos pasando la patata caliente a quien desarrolle el programa, que tendrá que lidiar con quienes no pueden cambiar la syscall 36 (los que tienen psjailbrak, por ejemplo) y también nos limitamos en el caso de que ese team saque algo que podamos aprovechar todos.
La syscall 8 es una caja de herramientas muy útil. Pese a la opinión de alguno, creo que no es tan dificil comprender que es básicamente un switch/case que conecta otras funciones a esa syscall y en syscall8.h hay suficiente explicación sobre su funcionamiento, aparte de que cualquiera puede preguntar sobre ello aquí, que no muerdo .
La syscall 8 como ya expliqué en su día, nos permite copiar, rellenar con ceros, ejecutar rutinas en el kernel e incluso redirigir dispositivos y ficheros utilizando una estructura de datos, tal y como se explica en syscall8.h
Pero tiene tres funciones interesantes: una nos permite fijar el modo en que se trata los permisos de acceso y las otras dos nos permiten deshabilitar o habilitar el uso de las syscalls que utilizamos.
Así pues syscall8_disable(key), nos permite ocultar a las aplicaciones poke/peek /syscall 36 e incluso la propia syscall 8 que solo funciona esperando un syscall8_enable(key) correcto.
La key de 64 bits se utiliza para que solo sea posible habilitar las syscalls de nuevo con la key correcta y así evitar que una aplicación o juego, por fuerza bruta, tenga fácil sacar la key correcta, dado que además, se limita el número de reintentos.
A mi me parece una solución cojonuda para evitar los supuestos usos peligrosos de las syscalls que permiten el acceso a LV2 y es una pena que parece que hay gente que no ha entendido el uso que tienen estas funciones y que las descarten tan solo por que no he escrito un libro junto a las funciones en ensamblador al opinar que hasta un neófito como yo en ensamblador de ppc, lo entendería (y mas contando con la descripción en syscall8 sobre su funcionamiento).
¿Por que alojas el payload en 0x7ff000? ¿No será peligroso?
Lo alojo ahí por que no tenemos espacio para alojar el código. Así que tenemos dos opciones: o modificamos el código para que quepa en su lugar original, privándonos de posibilidades o lo alojamos en otra parte que no parece molestar, dado que el código LV2 se acaba como 2 MB antes de donde alojamos el payload.
Peligroso es todo en la vida y si alguien apela a que volviendo de un juego el payload se cuelga, tal vez se deba a otras razones diferentes a las de alojar el código en un sitio que en todos los volcados que he hecho, está ocupado por ceros (si hubiera visto otra cosa, no hubiera elegido ese lugar para incluir el código)
Y yo no soy de los que hacen las cosas sin más, si no que las suelo probar bastante y entro en juegos y salgo y vuelvo a lanzar otros, ojo. Y la verdad es que desde que uso open manager (el original, no esos que estáis utilizando vosotros que no disponen de código fuente y que lo mismo incluyen chorradas que alteran algo, con solo la opción de activar/desactivar key), con todos los juegos en la carpeta OMANXXXXX, no he tenido cuelgues raros, salvo en los juegos que requieren disco, si no se introduce, como es obvio.
Obviamente, no tengo todos los juegos del mercado y no puedo saber si existen excepciones que rompan la regla, pero es mas probable que un juego pete por otra cosa que por la posición del payload en el kernel.
Saludos
Darkerkiko escribió:Espero que el adios de Hermes no signifique el estancamiento de la scene.... ahora que esto estaba con tan buena pinta
Ahora que o quien se supone que seguira avanzando en esto de la scene¿?
Hermes escribió:Buenas.
Os recuerdo que esto es un hilo de DESARROLLO DEL PAYLOAD y no de adaptaciones de éste a distintos sistemas, que de eso, se deben ocupar otros en sus respectivos hilos.
Por otro lado, éste payload no es igual al que usa kakaroto, con lo cual, si lo estáis insertando hexadecimalmente y os hace cosas raras, no sería de extrañar y lo que se requiere, es que alguien lo compile y lo cuelgue en su hilo correspondiente.
Dicho esto, paso a manejar otras cuestiones que he visto por ahí
¿Por que no subes el proyecto a github?
Por múltiples razones:
En primer lugar, esto nació debido a que el payload de psgroove no era público (o yo al menos no vi código fuente) y a que ciertas personas, se limitaban a trabajar en el payload sin capacidad de cargar juegos. Así que volqué port1_config_descriptor y lo desensamblé, ayudado de los comentarios en ps3wiki.lan.st sobre el payload y la aportación de AerialX que acabó desembocando en la carga de algunos juegos sin disco.
La idea era disponer de un código fuente que se pudiera compilar y mejorar, sin que restricciones de tipo moral o legal que afectara a otras personas, nos supusieran una traba a quienes pensamos de forma diferente o no tenemos esas restricciones y quisiéramos aportar nuestro grano de arena.
Por otro lado, no creo que sea justo (o como decimos en plan colega: "legal") añadir un psgroove paralelo en github, cuando los autores originales ya lo tienen de esa forma, ni creo que sea justo añadir mi copyright como autor de un payload que no me pertenece, puesto que los autores originales forman parte de lo que se conoce como "psjailbreak". Desde mi punto de vista, el código de payload pertenece a unos señores anónimos, con un copyright dudoso, pero sigue perteneciéndole a ellos y yo contribuyo con unas mejoras como usuario y programador aficionado (sin ánimo de lucro eso si), simplemente. Y por tanto, no puedo (o no debo) añadir copyright, aunque me sienta muy libre de añadir mejoras.
Si otros quieren hacerlo, e incluso cambiar el código para tener la excusa de hacerlo, están en su derecho, pero yo pienso que no se puede ensuciar la GPL por ejemplo, colgando el código del payload con esa licencia y que tampoco está bien meter un "Copyright Hermes", salvo que el equipo original lo haga y eso me permita ser co-autor con mis cambios. No se si a los autores originales les gustará la idea de que otros metamos mano a su código, pero ellos tampoco es que hayan sido muy respetuosos y legales y al menos yo aporto mejoras y no me aprovecho, simplemente, del código de otros sin más.
También opino que la scene debe ser un trabajo colectivo, que no de grupo: cuando un grupo se constituye, eso supone una restricción en la participación de otros usuarios y una limitación en el desarrollo.
Por ejemplo, supongamos que mañana cuelgo el proyecto en github. ¿Quien puede subir sus aportaciones?. Solo a quien YO otorgue permisos y puesto que yo lo administraría, todas aquellas ideas que no casen con mi filosofía, no podrían añadirse y al final, estaríamos en las mismas
Un ejemplo claro es el siguiente: yo tengo una filosofía de trabajo que kakaroto por ejemplo, no comparte ¿creéis que podemos colaborar en ese sentido?. Yo creo que es un no tajante: el puede incluir lo que le guste de mi código y yo puedo incluir lo que me guste del suyo, pero AMBOS, seguimos caminos distintos y tenemos ideas contrapuestas. Por tanto el github no funcionaría.
Así que un simple .rar con todo incluido me parece una solución muy buena para facilitar el desarrollo y la portabilidad del payload a ciertas personas, que por supuesto, pueden aportar sus parches o fuentes cambiados e incluso seguir su propio camino en ciertos aspectos. El github estaría bien si esto realmente, fuera open source friendly y hubiese la voluntad de trabajar todos en el mismo sentido y esto tuviera un tamaño desorbitado, pero aquí por el momento, ni siquiera han habido aportaciones al payload mas allá de añadir un par de "pokes" para los juegos y pasar un .S que mide menos de 25KB sin comprimir, no creo que sea gran problema
¿Por que no se soportan otras versiones de firmware?
Hay dos razones de peso: la primera, que yo solo tengo una PS3 y tiene el firmware 3.41. La segunda es que opino que es un error trabajar en versiones del pasado, puesto que ofrecen menos compatibilidad con los juegos, mayor dificultad a la hora de encontrar parches y al final, solo sirve para multiplicar el trabajo x 10 para obtener peor resultado.
Yo se que algunos lo hacen para mantener Linux, etc, pero es que en la vida no se puede tener todo y en mi opinión, es una actitud ilógica trabajar por ejemplo, para 3.15, cuando ya hay juegos que nos reclaman 3.42 y parece mas lógico tratar de ir hacia delante y centrarse en conocer BIEN lo que hace el firm 3.41, (que es el estándar) que otra cosa.
peek/poke, syscall 36 y syscall 8
Explicar a estas altura la necesidad de estas syscalls, casi me parece de perogruyo: a mi sinceramente, las syscalls de peek y poke no me gustan, pues solo mueven datos de 8 bytes y son muy simplonas, francamente. Pero, aunque yo tengo una solución mejor (memcpy mediante la syscall8) la regla de oro que debe tener cualquier desarrollador, es la compatibilidad hacia atrás en lo posible. Tambien poke y peek son las ventanas a lv2 que usan algunos y parece un poco idiota limitarnos.
Por ese motivo la syscall 36 no se debe suprimir, ya que aunque open manager nos permite cambiar por otra facilmente, le estamos pasando la patata caliente a quien desarrolle el programa, que tendrá que lidiar con quienes no pueden cambiar la syscall 36 (los que tienen psjailbrak, por ejemplo) y también nos limitamos en el caso de que ese team saque algo que podamos aprovechar todos.
La syscall 8 es una caja de herramientas muy útil. Pese a la opinión de alguno, creo que no es tan dificil comprender que es básicamente un switch/case que conecta otras funciones a esa syscall y en syscall8.h hay suficiente explicación sobre su funcionamiento, aparte de que cualquiera puede preguntar sobre ello aquí, que no muerdo .
La syscall 8 como ya expliqué en su día, nos permite copiar, rellenar con ceros, ejecutar rutinas en el kernel e incluso redirigir dispositivos y ficheros utilizando una estructura de datos, tal y como se explica en syscall8.h
Pero tiene tres funciones interesantes: una nos permite fijar el modo en que se trata los permisos de acceso y las otras dos nos permiten deshabilitar o habilitar el uso de las syscalls que utilizamos.
Así pues syscall8_disable(key), nos permite ocultar a las aplicaciones poke/peek /syscall 36 e incluso la propia syscall 8 que solo funciona esperando un syscall8_enable(key) correcto.
La key de 64 bits se utiliza para que solo sea posible habilitar las syscalls de nuevo con la key correcta y así evitar que una aplicación o juego, por fuerza bruta, tenga fácil sacar la key correcta, dado que además, se limita el número de reintentos.
A mi me parece una solución cojonuda para evitar los supuestos usos peligrosos de las syscalls que permiten el acceso a LV2 y es una pena que parece que hay gente que no ha entendido el uso que tienen estas funciones y que las descarten tan solo por que no he escrito un libro junto a las funciones en ensamblador al opinar que hasta un neófito como yo en ensamblador de ppc, lo entendería (y mas contando con la descripción en syscall8 sobre su funcionamiento).
¿Por que alojas el payload en 0x7ff000? ¿No será peligroso?
Lo alojo ahí por que no tenemos espacio para alojar el código. Así que tenemos dos opciones: o modificamos el código para que quepa en su lugar original, privándonos de posibilidades o lo alojamos en otra parte que no parece molestar, dado que el código LV2 se acaba como 2 MB antes de donde alojamos el payload.
Peligroso es todo en la vida y si alguien apela a que volviendo de un juego el payload se cuelga, tal vez se deba a otras razones diferentes a las de alojar el código en un sitio que en todos los volcados que he hecho, está ocupado por ceros (si hubiera visto otra cosa, no hubiera elegido ese lugar para incluir el código)
Y yo no soy de los que hacen las cosas sin más, si no que las suelo probar bastante y entro en juegos y salgo y vuelvo a lanzar otros, ojo. Y la verdad es que desde que uso open manager (el original, no esos que estáis utilizando vosotros que no disponen de código fuente y que lo mismo incluyen chorradas que alteran algo, con solo la opción de activar/desactivar key), con todos los juegos en la carpeta OMANXXXXX, no he tenido cuelgues raros, salvo en los juegos que requieren disco, si no se introduce, como es obvio.
Obviamente, no tengo todos los juegos del mercado y no puedo saber si existen excepciones que rompan la regla, pero es mas probable que un juego pete por otra cosa que por la posición del payload en el kernel.
Saludos
Seguro que todos los "teams" detrás de los clones sacan actualizaciones sin que Hermes las saque antes ¬¬, como ha estado sucediendo hasta ahora... o era al revés...
fs63 escribió:Seguro que todos los "teams" detrás de los clones sacan actualizaciones sin que Hermes las saque antes ¬¬, como ha estado sucediendo hasta ahora... o era al revés...
la triste realidad es que es al reves, los que sacan dispositivos psxxxxx, para mi son unos bastardos chupasangres, por eso dije por ahi lo de los donativos pa la peña que se lo curra, no para que se lucren, ni para establecer un contrato vinculante con la scene como me reprocharon por ahi; sino para que se tomen unas cañas a las que los invito gustosamente por el gran trabajo que han hecho.
A todos los demas, por favor pasad de comprar dispositivos por muy bonitos que sean, por menos de 20€ comprais todos los materiales y por lo menos yo me lo pase de p....... madre montandome mi propio psgroovepic y mi programador. (y con el trozo de placa que me sobro me hice una linterna con un par de led que tenia por ahi sueltos y resistencias que me sobraron )
Hermes escribió:Pues, teniendo en cuenta que las rutas de emulación se encuentran al final del payload y que los bytes que hay en USB_desc, en el payload de kakaroto no están ahí, pinta que el tamaño del descriptor que usáis en el iphone es menor que este y que estáis cortando el código "por la mitad"
Si tienes los fuentes, busca donde está el descriptor del puerto 1 y comprueba que los datos coinciden con los de USB_desc y que se envían 0xf00 bytes.
Tambien ojo, cuidado con lo que he contado esta mañana relativo a raw2payload.exe y los fopen.
Y.. otra cosa: he leido algo sobre compiladores que se atrancan con los .quad: mal asunto ese. Yo solo puedo contar que compilar con la ps3toolchain esa, fue una odisea (errores por todos los lados) y que conseguí obtener los compiladores y poco más, pero ifcaro tiene en su web unos compiladores ya montados, que al menos a mi, no me han dado problema en compilar, poniendo lo que he especificado unos post por detrás.
---------------------------------------------
Por otro lado... cometí un error al copiar al fichero rar los cambios, desde mi directorio de trabajo: resulta que port1_config_descriptor.bin y .h, son los de la version V3 , mientras que el .S si es el correcto
Lo podéis ver en las fechas de modificacion de los ficheros. Asi que si no habéis compilado el .S en realidad, lo que tenéis, es la V3 y claro, asi no van a actualizar los juegos
Lo siento de veras, pero bueno, estas cosas pasan
PD: Estoy subiendo la versión 4B que corrige este problema.
Oren_Hishii escribió:Perdon por la ignorancia pero en que influyen las correcciones aplicadas a la v4b?
Hermes escribió:Pues, teniendo en cuenta que las rutas de emulación se encuentran al final del payload y que los bytes que hay en USB_desc, en el payload de kakaroto no están ahí, pinta que el tamaño del descriptor que usáis en el iphone es menor que este y que estáis cortando el código "por la mitad"
Si tienes los fuentes, busca donde está el descriptor del puerto 1 y comprueba que los datos coinciden con los de USB_desc y que se envían 0xf00 bytes.
Hermes escribió:Y.. otra cosa: he leido algo sobre compiladores que se atrancan con los .quad: mal asunto ese. Yo solo puedo contar que compilar con la ps3toolchain esa, fue una odisea (errores por todos los lados) y que conseguí obtener los compiladores y poco más, pero ifcaro tiene en su web unos compiladores ya montados, que al menos a mi, no me han dado problema en compilar, poniendo lo que he especificado unos post por detrás.
Hermes escribió:Buenas.
Siento haberos hecho esperar, pero hoy tenía compromisos familiares y el hilo estaba cerrado cuando me he ido.
En primer lugar, comentar que he subido lo que tengo hasta este momento: incluye los parches que ya hemos comentado en otro hilo y algunos nuevos. La principal novedad es que se ha "limpiado" el código fuente para eliminar la doble relocalización del código, ya que nosotros no la necesitamos. También se ha incluido un nuevo sistema de parcheo dinámico que viene muy bien para posibilitar el redireccionamiento de /apps_home a /dev_bdvd en los juegos, para que reciban como primer parámetro la ruta del EBOOT.BIN de forma correcta, por si eso pudiera ocasionar algún problema.
Subo la V4 por que ya la tenía comprometida y por si otras personas quieren continuar desarrollandolo (la scene es un trabajo colectivo, que no en equipo: cada cual es libre de aportar lo que quiera y de la manera que quiera y en el momento que quiera).
En segundo lugar, os doy las gracias por el apoyo que habéis demostrado hacia mi
Si no os importa, me gustaría comentar unas cuantas cosas en lo que resta de post.
Tengo 41 años y a esa edad, uno tiene muy claro ciertas cosas y sabe por que aros quiere entrar y por cuales no. Como algunos saben, yo no soy un programador profesional, si no un trabajador de la construcción en paro (como muchos otros por desgracia), que dedica parte de su tiempo a una afición (el que esté en paro ayuda, por que en algo hay que matar el tiempo ) y que comparte lo que hace con los demás, por el simple detalle de que ya puestos ¿porque no beneficiarnos todos?
Curiosamente, me suelo meter en estos "fregaos" porque a veces veo que se hacen ciertas cosas sin timón y creo que puedo aportar ideas y mi punto de vista y en esto de la scene, nunca sobran un par de manos y un cerebro que aporte. Así que si toca arremangarse, nos arremangamos, todo ello por supuesto, sin ánimo de lucro o de sacar tajada de ninguna clase, por que no es eso lo que se busca.
Evidentemente, uno no es tonto y sabe que es lo que se cuece por estos lares: siempre hay peña que se aprovecha lucrándose del trabajo ajeno, sin aportar nada (o si aportan mejoras, las "cierran" para sí) y siempre hay gente que tira por tierra el trabajo de los demás. Esto es lo que me suele molestar, como es lógico y comprensible, pues evidentemente, yo no estoy aquí para que EMPRESAS que bordean la legalidad o no, se lucren sin aportar nada absolutamente y tengo el perfecto derecho, concurran esas circunstancias o no, de fijar en cuanto participo con la scene y de fijar mi propio código de trabajo con dicha scene y sus exclusiones.
En este caso, he decidido que debido a que una empresa está utilizando no solo el código, si no mi nick como gancho publicitario, haciendo entender equívocamente que yo estoy detrás de ese producto, dejar de desarrollar un código que hago por entretenerme y que os ofrezco a vosotros como personas anónimas que sois, sin intereses lucrativos tampoco.
Algunas personas no quieren entender esto y piensan "bah, es una pataleta en plan chiquillada" o "no se como se molesta, pues Hermes tambien es un nick adoptado y tal pascual".
En cambio yo lo que pienso es que quienes son ellos para juzgar mis decisiones y que soy el que menos pierdo si dejo de participar, asi que no se por que hay gente que piensa que yo gano algo participando. Y que le corresponde a quienes os cobran 30 pavos por un chip desarrollar ellos las aplicaciones o lo que se necesite y no a mí. Y que si yo considero que alguno ha traspasado una línea donde yo digo basta, no solo estoy en mi derecho, si no que parece lógico devolverles la pelota y decirles "ale, majos ¿no queréis llevaros los euros?. Pues coged vosotros el pico y la pala y arreando"
Yo no tengo un respaldo económico detrás, ni consolas debug, ni consolas retail con diferentes firmwares, ni dispositivos mas especiales que la teensy que me monté o la USBKEY que adquirí. ¿No es lo más lógico que quienes viven de esto, sean los que tienen que aportar las mejoras?¿o tengo que hacer yo las veces de departamento de I+D de forma involuntaria?
En fin, yo creo que está la cosa clara: por el momento, paso de seguir haciendo nada y va siendo el turno de otros de recoger el testigo y demostrar que además de fabricar chips y recaudar dólares, también aportan mejoras a sus clientes o a la scene en general, sin tomar solo código prestado o el nick de otras personas como gancho, porque en el fondo, no ofrecen nada.
Saludos
kakarotoks escribió:Hi,
KaKaRoTo here.. sorry for polluting this forum with english, but I'm not that good with spanish.
I can't figure out how to PM Hermes, so I thought I'd answer here instead.
Hermes: Could you try to contact me please? I've got some questions about some of the stuff you've done in your payload, and some people want to integrate that into PL3 but it's not easy to understand what you did.
Also, it would be a shame if you left the scene, you've been doing some awesome work, and I'd like to see you contribute to PL3.
Contact me if you're interested (at least in helping understand what you did).
Thanks,
KaKaRoTo
jbgoode escribió:If you want to contact Hermes privately just push the MP Button that is shown in the right of any of his messages. See ya.
Hermes escribió:Pues, teniendo en cuenta que las rutas de emulación se encuentran al final del payload y que los bytes que hay en USB_desc, en el payload de kakaroto no están ahí, pinta que el tamaño del descriptor que usáis en el iphone es menor que este y que estáis cortando el código "por la mitad"
Si tienes los fuentes, busca donde está el descriptor del puerto 1 y comprueba que los datos coinciden con los de USB_desc y que se envían 0xf00 bytes.
Tambien ojo, cuidado con lo que he contado esta mañana relativo a raw2payload.exe y los fopen.
Y.. otra cosa: he leido algo sobre compiladores que se atrancan con los .quad: mal asunto ese. Yo solo puedo contar que compilar con la ps3toolchain esa, fue una odisea (errores por todos los lados) y que conseguí obtener los compiladores y poco más, pero ifcaro tiene en su web unos compiladores ya montados, que al menos a mi, no me han dado problema en compilar, poniendo lo que he especificado unos post por detrás.
---------------------------------------------
Por otro lado... cometí un error al copiar al fichero rar los cambios, desde mi directorio de trabajo: resulta que port1_config_descriptor.bin y .h, son los de la version V3 , mientras que el .S si es el correcto
Lo podéis ver en las fechas de modificacion de los ficheros. Asi que si no habéis compilado el .S en realidad, lo que tenéis, es la V3 y claro, asi no van a actualizar los juegos
Lo siento de veras, pero bueno, estas cosas pasan
PD: Estoy subiendo la versión 4B que corrige este problema.
kakarotoks escribió:jbgoode escribió:If you want to contact Hermes privately just push the MP Button that is shown in the right of any of his messages. See ya.
Thanks, but there is no 'MP' in his posts! I originally went to his profile page, and the 'how to contact' section was empty.. I suppose he disabled private messaging.. probably because of the flood of stupid requests he kept getting
I'll check back here to see if he still reads posts on this thread. Otherwise, maybe someone who has his contact info can let him know I'm looking for him
Hermes escribió:
Por otro lado... cometí un error al copiar al fichero rar los cambios, desde mi directorio de trabajo: resulta que port1_config_descriptor.bin y .h, son los de la version V3 , mientras que el .S si es el correcto
Lo podéis ver en las fechas de modificacion de los ficheros. Asi que si no habéis compilado el .S en realidad, lo que tenéis, es la V3 y claro, asi no van a actualizar los juegos
Lo siento de veras, pero bueno, estas cosas pasan
PD: Estoy subiendo la versión 4B que corrige este problema.
Combomix escribió:va a estar complicada la union kakarotoks/hermes, no por diferencias irrenconciliables sino por los limites de idioma de ambos, ni kakarotoks entiende algo de español ni hermes lo suficiente de ingles (crei leer por ahy que hermes ingles solo lo basico).
Bueno, ojala salgan cosas buenas de ahy, estamos los fansa al pendiente para ver si sale algo bueno de todo esto
Oren_Hishii escribió:Este post no es para pedir compilaciones! buscar en los post de vuestros dispositivos que se iran poniendo ahi las nuevas versiones! tambien podeis googlear un poco!
Oren_Hishii escribió:Este post no es para pedir compilaciones! buscar en los post de vuestros dispositivos que se iran poniendo ahi las nuevas versiones! tambien podeis googlear un poco!
HYDE_666 escribió:alguien pueda pasar hermes v4 para ps3break 1.1 ya compilado por q lo e intentado y no mas no y me e quedado con las ganas de jugar al moh ayuda!!![buuuaaaa]
maee escribió:Oren_Hishii escribió:Este post no es para pedir compilaciones! buscar en los post de vuestros dispositivos que se iran poniendo ahi las nuevas versiones! tambien podeis googlear un poco!
GRACIAS POR LA AYUDA
LuPoX escribió:Gracias por aportar algomaee escribió:GRACIAS POR LA AYUDA
LUCKYMAS escribió:se podria hacer algo para parchear los juegos en ps3 con firmware inferiores a 3.41 para que no te pida actualizar el firmware de la ps3 a otro superior , intente modificar el PARAM.SFO de f1 2010 que me pide actualizacion firmware 3.40 y estoy en la 3.15 y se corompio todo el juego no lo reconoce el om si la modifico el .PARAM.SFO. Gracias y sigue en la brecha que es el buen camino .
May i remind you all that this is a thread of payload development, and not adaptations of it to different devices (i.e. iPods etc ) that should be taken care of in its respectful threads.
Anyways, this payload is not equal to that of kakaroto’s, if you are inserting it via hex and misbehaves it wouldn’t be a surprise and what is required is that someone compiles it and post it around in some thread.
This said, lets continue to other matters.
Why don’t you post this at github?
Multiple reasons:
First, this was born due to the fact that the payload used by psgroove was not public ( at least I didn’t saw source) and because certain people, limited themselves to work on the payload without the ability to run backups. So I took port1_config_descriptor and disassembled it, with help of comments on the ps3wiki.lan.st about the payload and collaborations of AerialX , this resulted in us being able to launch backups.
The idea was to have a source code that could be compiled and upgrade, without moral and or legal restrictions which could affect other people and let some of us who think different about this legal stuff, and let us do some contributions.
Anyways, I don’t think it’s fair or “legal” to add a psgroove parallel at github, with the owners having already one posted, and I don’t think it’s fair that I add my copyright as an author of a payload that does not belongs to me, due to the fact that the original developers form part of that thing known as psjailbreak. From my point of view the source code of the payload belongs to some anonymous people with a not so trusted copyright but it is theirs, and I contribute with some upgrades and not taking advantage of others people code.
If others want to do it and even change the code they are in their whole right to do it, but I think we should not be throwing dirt at the GPL, for example, posting payloads code with that license and neither is good adding a Hermes Copyright, unless the original team does it and that would made me co author with my changes. I don’t think original authors like the idea of some other people meddling in their source code, that said I also don’t think they have been very respectful and legal, at least I bring upgrades and not take advantage of others code.
Also I think the scene should be a collective work, not that of a team. When a team is made, a restriction is made to all outside users in meddling with the code.
Lets suppose tomorrow I would post the project at github, Who will be able to upload contributions? Well easy only the persons I decide, and basically all that ideas that I don’t like wouldn’t be taken into account, they would not be added and in the end we would have the same problem as we do now.
A clear example is this: I have a philosophy of work that kakarotos doesn’t shares, Think we would be able to work in that way? That’s an absolute NO, he can include what he likes of my code, and I can include what I like of his code but WE follow different paths and have different ideas. As a result github would not work
So for me a simple .rar with everything included should be a good solution to facilitate development and portability of the payload to some people, and basically they can apport their own patches or sources and even follow their own paths. Github would be great if this was really open source friendly and people had the will to work all in one same sense, this would have an outstanding size basically, but here right now at this post there have not been contributions made to the payload, just some pokes to some games and pass an .s file that weights around 25kb without being compressed, I don’t think that’s a big deal.
Why don’t I support older firmware?
Two reasons for that: first, I only have 1 ps3 and it has firm 3.41, second, I think it’s a mistake to work older firms when we should be worrying about newer versions of firmware, why because older firmware offer less compatibility with games and they give the most difficult time to work around this bugs at the end it only increases the work 10 times more.
I know some of you don’t update because you want to keep linux , etc. but sometimes in life we just can’t have all we want, and In my opinion its illogical to work for example firm 3.15, when there are already games asking for firmware 3.42 , and I think it’s more logical to seat and examinee, study really well what firmware 3.41 does.
I don't necessarily agree with you, but that's your opinion. I don't think we need a 'memcpy', because really, what is 'memcpy' but just a copy of 8 bytes one after the other.. so implementing the memcpy in the payload or implementing it in the homebrew application doesn't really make a difference, apart from bigger payloads...Peek/poke, syscall 36 and syscall 8
I don’t really like these peek and poke calls , they just move 8 bytes of data and are just too simple. Even though I have a better solution ( memcpy using syscall 8) rule of thumb here that every dev should have is having compatibility. Also poke and peek calls are the windows lv2 some uses and think its absurd to limit us.
For that matter syscall 36 must not suppress, even though open manager allows us to change it for other one real easy, we are passing the buck on to the dev making his program, this dev will have to work out with those who can’t change to syscall 36 ( those who have psjailbreak for example) and also limits us in the case that that team posts something that we all could benefit from.
Syscall 8 is a toolbox very useful. Despite someone’s opinion, I don’t think its too difficult to comprehend what it’s basically a switch/case that connects other functions to that syscall and in syscall8.h can be found a lot of explanation of its purpose, also anyone can ask of it here I don’t bite lol.
Syscall 8 allows us to copy, fill with zeros, run kernel routines and even redirect devices and files using a data structure, as explained on syscall8.h
But it has 3 interesting functions: one allows us to fix the access permits, and the other two are that we can enable or disable the use of the syscalls we are using.
So syscall8_disable(key) allows us to hide poke/peek/ syscall36 apps, and even syscall 8 which onlye works waiting for a syscall8_enable(key).
The 64 bit key is used so it is only possible to habilitate syscalls again with the right key, and this way we avoid an app or game find the right key by brute force also this way we can limit number of intents.
I think it’s a stupid reason to prevent the supposed dangerous uses of those syscalls which allow lv2 access and it’s a pitty that there are still people who have not understood the use of those functions and discard them just because I haven’t written a book with these functions, man even a neophyte like me in ppc assembler would understand it
Why you allocate payload on 0x7ff000? Isn’t that dangerous?
I allocate it there because we don’t have empty space. So we got 2 choices: we modify the code so it will only fit on its original spot, taking out our possibilities or we allocate it somewhere else where it should not bother us, given that the lv2 code ends like 2 MB before we allocated our payload.
Dangerous is everything in life, and if someone mentions, when returning from a game to the XMB payload hangs well it must not be to the place where we allocate our code, I have tested and verified it many times and all there is in those spots are pure zeros, If I had seen something else there basically I would not have chosen that address.
And I’m not of those who does things and nothing else, I do test all my apps and I go in and out of games launch and re launch test test test. Truthfully since ive been using open manager ( the original one not those with a lot of bugs made by other people without source code) with all games on folder OMANXXXX I have not had any weird hangs only with games which require disc, basically if disc is not inserted.
Obviously I don’t have all games on the market and thus I cannot know if there are excemptions breaking the rules, but its more likely that a game will hang or something similar due to another reason, not because or where the payload was allocated.
Cheers.