[DESARROLLO] PSGROOVE Payload Custom (V4B)

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¿?
kobol6666 está baneado por "saltarse el ban con clon"
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 [+risas]

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 [+risas] 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 XD.

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

estupefacto me deja este hombre,es el mejor y punto [beer]
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¿?


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... [decaio]

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 [+risas]

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 [+risas] 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 XD.

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


Da gusto leer lo bien y claro que explicas las cosas.
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 [+risas] )
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 [+risas] )


Era en modo irónico... las actualizaciones de los dongles salen mágicamente después de que Hermes las subiera por aqui.
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" [+risas]

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 [+risas], mientras que el .S si es el correcto :P

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 [+risas]

Lo siento de veras, pero bueno, estas cosas pasan [ayay]

PD: Estoy subiendo la versión 4B que corrige este problema.


A mi me está pasando en un dongle atmel, no en un iPhone, no tengo ni idea de que puede ser... Gracias por la ayuda.
Oren_Hishii escribió:Perdon por la ignorancia pero en que influyen las correcciones aplicadas a la v4b?


Si lees lo que dice Hermes

"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"
Gracias Hermes.

He podido compilar en windows la V4b sin modificar el raw2payload.c.
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" [+risas]
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.


Ando un poco pez aún en estos temas, pero en teoría en psfreedom.c se reservan y se copian hasta 3840 bytes (0xf00)

new_size = 3840;
new_config = kmalloc(new_size, GFP_KERNEL);
memcpy(new_config, port1_config_desc_prefix, prefix_size);
if (copy_from_user(new_config + prefix_size, buffer, payload_size)) {
...

Lo cual da para tu payload ... clavado (además veo en el hex que las rutas están en 0x9b4 en V3 y 0x9e8 en V4 respectivamente, es decir, por debajo del límite)

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.


Tras el "arreglo" de los quads que sugería en mi comentario el código generado tiene buena pinta, y de hecho funciona salvo por el tema del truncado este extraño... Es cierto que las cadenas no quedan en el mismo offset, no sé si eso es relevante... si quieres y tienes tiempo te lo puedo pasar y le echas un vistazo.

Gracias por todo...!
Alguien que suba la 4b compilada para golden at90usb162 ?¿
con el v4, que subio algun forero compilado para teensy no me va el assasins creed 2, pero si el f1 2010, little big planet..etc, tube que volver a la v3 que tenia anteriorment. Probare si con esta v4b se soluciona. ¿alguien puede compilarlo para teensy 2.0?? gracias
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 XD) 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


Hermes, yo lo unico que puedo decir, es que gracias a ti, a muchos nos has facilitado "la vida" en la scene, tanto en Wii que fue cuando empecé a seguirte, como ahora en ps3.

Entiendo tu postura y la comparto, porque en algún caso, me he encontrado en situación parecida. Lo mio no es la programación ni mucho menos, me dedico en mi tiempo libre a prensa deportiva (F1), y a hacer algún apaño en paginas web, ya sea para idas de ollas personales o como ayuda a mi entorno, y sin animo de lucro.

Mientras otros me han sacado el dinero (al igual que a otros usuarios), para tener actualizaciones a destiempo haciendo un copy & paste de tu codigo, he tenido que desterrar mi puñetero ps3key, para terminar usando mi HTC Hero como solución unica para mantenerme al dia.

En su momento mucho se habló de hacerte donaciones a una cuenta paypal debido a tu situación personal, y sinceramente, aunque lo tengas superhipermegaclaro y ultradecidido, como ves, muchos no nos hemos quedado parados ante la situación que has vivido, y sinceramente, creo que te mereces tu bastante más ese dinero que pague por mi zurullokey, que esa panda de Team, ( que si que si, que en Wii serían la ostia, pero aquí, y lo siento por a quien no le guste, NOS TIENEN EN PELOTAS).

Así que una vez más, y sintiendo ser repetitivo, te animo a que pases de todas esas mierdas de clones suplantadores de personalidad, y nos permitas, que te recompensemos de alguna manera. Espero que no sea sexualmente.... :D

Dejando todo eso de lado, y como despedida, darte las gracias por tu trabajo desinteresado, y por todo el apoyo que nos has prestado siempre a los que en esto, estamos más perdidos que un pulpo en un garaje.

Un fuerte abrazo desde galicia, y no cambies nunca.

Saludos.
hola una pregunta si compilo el psgroove de hermes la v4b se mete solo el syscall 8? como estan fueras los archivos

la v4b de hermes tiene algun cambio excepto la v4 solo la V4b solo fue mejorado para compilalo?

pd:hermes te doy mil gracias por todo el trabajo que estas haciendo saludos
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
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

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.
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 :)
is impossible to contact hermes in PM, is disabled for him

just wait for your answer right here
este no es el q se metio hace poco con hermes ?
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" [+risas]

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 [+risas], mientras que el .S si es el correcto :P

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 [+risas]

Lo siento de veras, pero bueno, estas cosas pasan [ayay]

PD: Estoy subiendo la versión 4B que corrige este problema.

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 .
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 :)

Your are right, I didnt realize, sorry!
He metido en mi pic este .hex siguiendo el tutorial de este hilo: hilo_psgroopic_1482990

pero el ps3 no me lo reconose, conecto al pc cargo el bootloader y luego le meto este .hex que tengo entendido sirve para jugar medal of honor, luego quito el jumper y lo meto en el ps3 y no me lo reconoce, alguien me puede ayudar?
try to reach him only here, i doubt u will find him via mps, hes disabled it, way 2 many mps to his box,

esto si que es increible, o es una broma de un usuario o que
hay una mejora? en la version 4b? solo de compilacion?
alguien me puede decir por favor si la V4 actualiza los juegos via internet como hacia el V3 + pacht?

Gracias, porque no saco nada en claro
hola hermes... no se como se compilan los archivos ke cuelgas al principio del hilo, "no soy bueno con esto de programar", hay alguna compilacion tuya de esta ultima version "V4B", gracias. a y pregunta... este tiene las mismas cosas ke la v3, no me keda muy claro ke es lo nuevo.
Si, los jogos con patch funcionan, inclusive sin el disco en el drive. La version perfeita es esta!
como puedo compilar la 4b para la placa avrkey?

Alguien sabria decirme si la V4B actualiza via internet como hacia la V3 +pack wani y math?
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 :D
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 [+risas], mientras que el .S si es el correcto :P

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 [+risas]

Lo siento de veras, pero bueno, estas cosas pasan [ayay]

PD: Estoy subiendo la versión 4B que corrige este problema.


Según entendí la 4b solo actualiza esos archivos de los binarios, pero los hex si estan completos y actualizados, ¿no? Vamos, que yo actualice un Golden AVR USB Board con el archivo psgroove_teensy_at90usb162_16Mhz.hex y supongo que es igualito al de la 4b, ¿no?
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 :D



Pero si ambos hablan en Lenguaje Maquina se entenderan
Hermes, te confirmo que con el cambio de los quads el binario resultante de compilar en Linux es idéntico:

#define QUAD_ABS(address) \
.long 0x80000000; \
.long BASE + address;

// Absolute .quads
//#define QUAD_ABS(address) .quad 0x8000000000000000 + BASE + address

Por otro lado, si ya quitas el .exe de la llamada a raw2payload y cambias la ruta al compilador haciendolo depender de una variable de entorno: PS3_COMPILERS= $(PS3DEV)/ppu/bin quedaría 100% portable :)

Saludos!
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]
kobol6666 está baneado por "saltarse el ban con clon"
hola ya somos 2,tengo el ps3break 1.1 el auctalizable t me he bajado todos los hex que hay hasta la fecha,la v4 de hermes)y me pone verify faulire,alguien tan amable lo tiene? [beer]
Alguien me puede pasar el hermes v4b compilado para el tensy 1.0?? GRACIAS
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!

GRACIAS POR LA AYUDA
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!


+1 espabilad un poco joder, que os lo tienen que dar todo mascado
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]


En este hilo tienes los hex que compila TSC

http://www.elotrolado.net/hilo_hex-del-ps3break-1-0-pic-sacado-para-su-estudio-tutorial_1492857_s680

Hex
PSGrooPIC_V1.8b_nBTL.rar
http://www.subirfacil.com/files/1FF3UDN7/PSGrooPIC_V1.8b_nBTL.rar
PSGrooPIC_V1.8b_wBTL.hex.rar
http://www.subirfacil.com/files/1VNS2ULY/PSGrooPIC_V1.8b_wBTL.hex.rar
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

Gracias por aportar algo
LuPoX escribió:
maee escribió:GRACIAS POR LA AYUDA
Gracias por aportar algo


En serio, pasaros por el post que hace referencia a vuestro dispositivo en este mismo foro y lo encontrareis.No podemos andar poniendo links a esa info pq aqui "SOLO" se debe aportar información tecnica ya que este post es de DESARROLLO

PD:Os pongo este enlace por si os ayudara.Es una aplicación online para compilar sources para dispositivos concretos...
http://www.project0.de/psgroove-maker/
está aqui uma solução para hermes v4 para iphone

http://psfreedom.com/wiki/IPhoneLinux

gracias
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 .


No fue claro HERMES diciendo que no sirve dar soporte para firmware viejos? lee lo que puso unas paginas atras: TODO NO SE PUEDE EN LA VIDA MACHO: o LINUX o los juegos, tu elijes...
Hi again!
Thanks to xanon on psx-scene forums, I have a correct translation (I suppose) of Hermes' response. So I thought I'd answer him back :

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.

Yes, it's different, port1_descriptor in your case is the actual port1 descriptor, so you have the usb descriptor, the padding, the magic cookie for the egghunter shellcode, then the actualy payload.. PL3 itself, as I said, is not 'a payload', it's a project, and it provides just the code.. then other projects can choose to send that payload any way they want.. if for example there is a new hack for 3.50 that doesn't even use USB, then the same payload could be reused without editing since the payload .bin/.h contains only the code.

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.

oh, you probably missed it then.. psgroove was released since day one on github.com/psgroove/psgroove (since they have no website, they put it there directly and just gave the github link on IRC). I suppose someone took that and made it into a rar file and that's how you got it..
Also, the work of AerialX was on github too, it was a fork with code cleaning from subdub which was a fork of psgroove.
The thing with github is that you don't make modifications and send them to the repository hoping it gets merged.. you create your own fork (a clone git repository) and you do your development there, so that's what subdub did, and AerialX liked it and wanted to improve it so he forked from subdub.. then I copied their code into PL3 just like you did. But I kept it all on github too.
About backups or what you want versus what the psgroove team wants, it doesn't matter, because you can always have your own fork and just redirect people to using your fork on github.. at least the development stays on git, and if I wanted to just take this one small change you did, I could do it directly with git.

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.

No it IS fair, that's the whole purpose.. look for example at the psgroove clones : http://github.com/psgroove/psgroove/network/members
The whole git system is made so that each person does a full clone of a repository.. you do not take ownership of the code or the project, you simply have a fork, which you can modify. Also, by definition, as soon as you modify a file, it adds your copyright to it.. To know the copyright of a file, we can simply ask git on who are the authors who modified the file, and everyone is co-author with shared copyrights. And it's not unfair or 'bad', it is what everyone wants, it is the recommended method of working with open source code.
Also, yes, PL3 also has shared copyright with the original psjailbreak people because some of the code there is theirs, but I've worked hard to removing their code and rewriting everything so we can have a pure GPL payload. And I'm almost done with that.

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.

Well, the thing with git is that it makes it a lot easier to add changes.. go back to that list of forks for psgroove ( http://github.com/psgroove/psgroove/network/members ). You can see near the bottom that jevinskie forked and did some changes to psgroove, I liked what he did and i wanted to improve on that, so I forked his branch and added my own code, then a few other people forked my branch... the fact that you use git makes it a whole lot easier to do all that because it's part of how the system works. And about copyright, like I said before, it's normal to share copyright. For example, you can see that from the start of PL3 (first commit), every file I had, I added my name, Aaron (AerialX) and subdub's names to the copyright headers (http://github.com/kakaroto/PL3/blob/mas ... yload.S#L4) simply because when I created it, those two wrote the base code, and since I modified it, then we were all sharing the copyright for it. We are all co-authors. For example also, you can see that waninkoko was working on PL3 and when he found the patch to add retail .pkg installation, he sent it to me, and I committed it here :
http://github.com/kakaroto/PL3/commit/3 ... 43f92ee26d
As you can see, it shows me as 'committer', but it shows 'waninkoko' as the author! There are many other commits from other people, and the authorship is kept. And like I said before, looking at the commit log for a file will tell you who are the authors, and by definition, they all share the copyright on that file.
If you're only using .rar files, you're loosing all that! You integrated waninkoko's patch into your own payload, but when I download the .rar, I don't see waninkoko's name as a contributor.
About being respectful to other people's code, I think that using git (or any other revision control system) is what makes it respectful, because like PL3, you could see the original authors and contributors to every part of the code.. you could even 'git blame' a file and see who added which line and when and why. I have received many patches, sometimes by email, or just a pastebin given to me on IRC, and I would often do a "git commit --author original_author" when I commit, so that I don't commit their code as if it was mine, and doing that is what I would call being respectful to everyone's contributions.

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.

I don't see a team anywhere.. there is no restriction, if I don't accept your patches for example on my repository, it doesn't matter, you have your own, the advantage is that if I fix a bug or commit something, you can easily get it "git pull kakaroto/master" from my repository and still keep your own commits.. and if you do a change that I like (a bugfix), I can also merge it into my repository without taking the other changes you made that I don't lke "git cherry-pick". There is no restrictions, there is just better infrastructure.

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.

That's the thing, git is a *distributed* revision control system, it's not like SVN.. everyone has their own complete clone of the repository, it really doesn't matter who has a right to commit, everyone commits to their own repository, and when they think they're done with a feature, they send a 'pull request' (asking you to pull commits from their repository into your own).
For example, look at how psgroove, it uses lufa-lib, but it did some changes to lufa-lib to allow it to work with psgroove, of course, the original authors of lufa wouldn't accept those changes (since they are specific to psgroove), so they have their own fork of lufa-lib. Then evilsperm wanted to add blackcat boards support and a few others, so he forked the lufa-lib repository from psgroove and added his changes. I wanted those changes, so I just switched to his fork (http://github.com/kakaroto/psgroove/com ... 96244e12b5 ) and everything continued working, I didn't have to copy anything over.. I just switched to his branch..
Then evilsperm sent the psgroove people a 'pull request' and they merged his changes. Then they sent the pull request to the original lufa-lib authors, who discarded the psgroove specific commits, and they merged support for blackcat, minimus, maximus, etc.. boards directly into lufa-lib. And all of this was as simple as a click of a button.. before that, the support for each board was in rar/zip files scattered in forums, etc.. and it wasn't working for most people because they had to find then extract those zip files manually, etc.. but with git, it was as simple as clicking 'pull request' and the lufa-lib project (http://github.com/abcminiuser/lufa-lib) just merged them, and now everyone will take advantage of all these changes.
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

my philosophy is mostly about correct code sharing. I took a few of your patches, and improved them and added them to PL3, if you do something and I can clearly see what it is, then we can share code like that, for example, you add the patch to do the 'b +0x98' to enable game installs (which is really ugly to do a relative branch), I see it, I look at the code, and find a better solution (to nop another instruction), I learned from what you did, and you see my solution and you like what I did, then you can merge it too.
If we do some other things differently, then it doesn't matter, you can have your own fork, and I can have mine, but at least, sharing the common code is easy, and especially sharing the knowledge is much easier with git..
For example, the lv2open (install game updates) I just talked about.. it's easy with git to just ask 'where did these lines come from'.. and you would see these commits :
http://github.com/kakaroto/PL3/commit/4 ... 34cd51a6d2 (oh, klutsh (not me) added it, and it's Math's pkg fix)
http://github.com/kakaroto/PL3/commit/6 ... ba4211268e (ok, kkk found the offsets for 3.15, and contributed it)
http://github.com/kakaroto/PL3/commit/7 ... 358e4030ad (now this is my improvement, you don't just see 'r3' instead of 'r31', you actually can see in the commit message why I did that change)
http://github.com/kakaroto/PL3/commit/a ... c40dd5b191 (and now, this is the actual fix to the games crashing, and you see why, when and how I added it)

With git, you can see that, and know exactly what I did and why, and it would help you add those improvements to your own code.. even if in that same file you have your syscall8 a bit lower, you can just merge all those commits, and you get the same changes, same fixes, and you keep your changes.
That's what I call collaboraiton. So why are you saying github isn't for you ? It doesn't matter how we work, as long as we can see each other's work and benefit from one another.

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.

the problem is that to add our own patches to your code, it becomes difficult, or just reading it, understanding it, knowing what you changed, and adding it to PL3 becomes difficult.
And github IS really open-source friendly.. git itself is fully open source (it is used by the linux developers and was developed by Linus Torvalds, so of course it's open source friendly!).
The code being 25K or 1K or 100MB doesn't matter, it's the content and how it evolves that matters.. even being able to debug your own code would become difficult after a while.. with git for example (and it happened to me actually), I realized at one point that my code wasn't working anymore and I had no idea why, but I remember it was working last week.. so I just told 'git bisect start', I told this the current commit is bad, and I told it the commit from last week is good, then it automatically checked out commits in between.. I would test them, then say 'git bisect good' or 'git bisect bad', until it bisects all the interval and tells me "this is the commit that broke it", and then I get a 1 or 2 lines diff that I can easily understand and can easily debug...
Yes, providing rar files is easy, yes, it allows you to quickly deliver the code, but it's a very short term solution, it's for a hack.. what I'm trying to accomplish here isn't about a hack, it's about creating a suitable code base for long term evolution. Without long term planning, the scene would quickly die. I hope you can understand that.

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.

That's the beauty of it, you don't need to have a non 3.41 firmware to support it. I created a framework for that, and when I add a new patch, I just add it for my firmware... it usually takes a day or two and all the other firmwares are compatible because people who actually have and use those other firmware, they care, and they will send patches, because it's easy to do. I know a few people with 3.01, 3.10 and 3.15 firmwares (some with debug machine, some with a kiosk machine, some with 2.x firmwares who also plan on porting pl3 to their respective firmwares), and as soon as I commit something, I know others will see it, and will start working and contributing.. That's the beauty of collaboration, that's the 'scene' working, not a single individual, not a single person, or a team.. just random people contributing, and that's the spirit of open source.
For example, the previous example with the lv2open, in the 4 commits, you could see that 3.15 support was added less than a day later, even before I could fix the crash properly.
Or if you just look at the page 2 and 3 of the commit log (http://github.com/kakaroto/PL3/commits/master?page=2 http://github.com/kakaroto/PL3/commits/master?page=3 ) you can see how Philippe Hug started working on 3.15 support, you can see how it slowly evolved, you can also see how in the middle of his work, he did a 'merge' with my own code because I added something that was useful to him to continue porting to 3.15, then when he was done, you can see my commit saying I merged the 3.15 branch from philhug.
So no, I don't believe supporting older firmwares adds any more effort, since other contributors take care of that effort. Also, you are maybe interested in backups, but not everyone is, some are simply interested in homebrew, and homebrew apps work just as good on 3.15 as they work on 3.41.. and I don't think we should forget about all those people who still use older firmwares (you have no idea how many people still do, and waited, even with the jailbreak available for 3.41, until I released support for their firmwares).
Also, I think the most important thing is that once 3.50 firmware gets hacked (assuming it does), then how will you port your payload to it ? It will be a lot of work, and then all your payload will have to be changed and it will be difficult to refactor it properly.. so having the support for multiple firmwares built into the code would just make it easy... adding the necessary defines, one by one, for 3.50 would be as simple as doing it for older firmwares.. How to do it on 3.15 is, in itself, a huge amount of knowledge that we need to keep with us for the future.
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.
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...
I'm not entirely sure I understood these paragraphs though, so I'll refrain from commenting in case I misunderstood you.

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

I see, thanks for the information. I haven't seen a syscall8.h, so I tried to understood it from ppc only, and although you might find it yourself, I don't personally do, so it doesn't really matter, this is a good example of something you could have and work on, in your git repository, that I simply wouldn't merge in mine. (again, your repository and mine are distinct, independent repositories, mine isn't the 'upstream', I can push commits to you, as much as you could push to me).
About asking, that's what I came here to do (before I saw this post though), and I hope you are willing to work together to improve things.

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.

Or you have a third choice... making the code smaller is of course impossible if you want to do certain things.. and moving the payload somewhere else really isn't the right solution...
The solution that I have in PL3 is that I call 'alloc' and I allocate memory that I own, that I know noone will ever overwrite, then I copy the code there (and I make sure the code is position independent), then I store the allocated pointer and use that pointer to call my function. We have 3808 bytes of data available for us with the payload (more if we wanted), but only 1296 that can go into the resident area of the kernel. We can put half of it in the resident area, and the rest can be allocated to RAM.
I know you tested your code, and that address was always empty, but it doesn't mean it won't get filled!!! I can also boot my PC and say "oh, I have 1GB of RAM, but only 200MB are used, so I can put anything I want in the remaining 800MB", but it's not true, because at some point, some game or some applications, in a special case that you haven't tested (when you 'reach level 10' for example or whatever), it would cause the kernel to allocate memory on that specific area and it would start overwriting your code. So no, it's not safe...
I'm not saying your code will crash and mine won't.. my code will probably crash in some situations, those are bugs that I do not know about and that I will eventually fix when I find them... but your code will crash and is not safe with this trick you did right here! It's a bug, and you seem to not want to fix the bug...
I do it for my 'map_open_path' function in PL3, and with the framework I set up, it's quite easy to do so :
// Allocate memory and copy PIC function map_open_path to it
ALLOC_AND_COPY_PROC(%r31, map_open_path, (map_open_path_end - map_open_path))

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.

Yes, you should know the citation that says "Testing does not guarantee the non-existence of bugs, it only guarantees they exist"... no matter how much you test, and no matter how many use cases you try, there will always be something that you didn't see, code will always have bugs, so saying that you tested your code and it doesn't crash, really isn't proof of the fact that it works.. like I said, maybe a game will do many syscalls, will open too many files maybe, or whatever and eventually the kernel will allocate the memory where your payload is, and everything will crash.. you just never tried that game, or you didn't use it long enough to trigger it.

Anyways, I see you have a lot of misconceptions about git/github, you probably never used it, maybe I convinced you to try it, or maybe you still don't believe it's right for you, either way, I hope you better understand it now.
For everything else, we may have different opinions, it doesn't mean we can't help each other out. Let me know what you think, I'd really like to have a real-time chat with you some day.

ps: it's 7:40AM here and I need to sleep, sorry if I say stupid stuff, I'm tired and don't have the energy to proof-read what I just wrote... oh and sorry for the long message :p

Good night.
KaKaRoTo
Dios que pedazo mensaje jajaja
Que alguien haga un resumen en español!! :p
Estoy de acuerdo con kakaroto, git es la herramienta mas apropiada para publicar los nuevos cambios que se realizan en el payload, y usar PL3 es la idea mas correcta por las razones ya comentadas. Al igual que le ha pasado a kakaroto, me resulta dificil ver y entender las modificaciones que Hermes realiza en cada version de su payload :/

I agree with kakaroto, git is the proper tool to release the new changes done in the payload, and using PL3 is the best idea because of the reasons given above. Just as already happened to kakaroto, it's hard for me to see and understand the changes Hermes does in each version of his payload :/
1485 respuestas