Suite a ce message et ce message de Kakaroto qui critique le travail d'Hermes, celui-ci a posté sa réponse ...Voici la réponse en espagnol:
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
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
Et une traduction google:
Bon.
Je vous rappelle qu'il s'agit d'un thread [b] [u] CHARGE DE DEVELOPPEMENT [/ u] [/ b] et ne pas faire des ajustements à des systèmes différents, qui doivent être occupés dans leurs filets respectifs.
D'autre part, cette charge utile n'est pas le même que celui utilisé Kakarot, qui, si vous insérez hexagone et vous faire des choses drôles, ne soyez pas surpris et ce qui est nécessaire pour quelqu'un de compiler et de l'accrocher dans votre fil concernés.
Cela dit, des événements à traiter d'autres questions que j'ai vu là-bas
[B] Pourquoi ne pas vous envoyer le projet à github? [/ B]
Pour de nombreuses raisons:
Premièrement, il est né parce que la charge utile de psgroove n'était pas public (ou du moins je n'ai pas vu le code source) et que les individus ont été limitées à travailler dans la charge utile sans la possibilité de charger des jeux. J'ai donc versé port1_config_descriptor et le démontage, aidé par les commentaires ps3wiki.lan.st dans la charge utile et la contribution AerialX qui finit en charge de certains jeux sans disque.
L'idée était de disposer d'une source qui pourrait construire et améliorer, sans restriction d'ordre moral ou juridique d'affecter d'autres personnes, nous avons posé un obstacle à ceux qui pensent différemment ou qui n'ont pas de telles restrictions et que vous souhaitez apporter notre contribution sable.
D'autre part, ne pense pas qu'il soit juste (ou comme on dit en collègue plan: «juridique») ajouter un github parallèle psgroove, lorsque les auteurs d'origine l'ont déjà de cette façon, ou pense qu'il est juste d'ajouter mes droits d'auteur en tant qu'auteur une charge utile qui n'est pas le mien, puisque les auteurs originaux font partie de ce qui est connu sous le nom "psjailbreak." De mon point de vue, le code charge appartient à quelques gentilshommes anonyme avec un droit d'auteur douteuse, mais appartient toujours à eux et je l'aide avec quelques améliorations comme un utilisateur et programmeur amateur (bien sûr sans but lucratif), tout simplement. Et donc je ne peux pas (ou ne devrait pas) ajouter le droit d'auteur, mais je me sens très libre d'ajouter des améliorations.
Si d'autres veulent, et même changer le code pour avoir le prétexte de le faire, c'est leur droit, mais je pense que vous ne pouvez pas faute de la GPL par exemple, en remplaçant le code avec une licence et une charge utile qui n'est pas bien mis un "Hermes droit d'auteur", à moins que l'équipe d'origine le fait, et qui me permet d'être co-auteur avec mes modifications. Non, si les auteurs originaux, comme l'idée que d'autre part metamos votre code, mais ce n'est pas comme ils ont été très respectueux et juridique et au moins je apporter des améliorations et je le prends, seulement à partir d'un autre code, sans .
Je pense aussi que la scène doit être un effort collectif, pas de groupe, quand un groupe est formé, ce qui implique une restriction à la participation des autres utilisateurs et une contrainte au développement.
Par exemple, supposons que demain je raccroche le projet sur github. Qui peut élever leurs contributions?. Je donne seulement à ceux qui partent et depuis que je l'administration, toutes ces idées qui ne se marient pas ma philosophie, et, finalement, pourrait être ajoutée serait dans le même [rires]
Un exemple clair est le suivant: j'ai une philosophie de travail que Kakarot par exemple, ne partage pas votre avis, nous pouvons coopérer à cet égard?. Je pense que c'est un non catégorique, il peut comprendre ce que vous aimez mon code et je peux comprendre ce que je comme la sienne, mais les deux suivent des chemins différents et ont des idées contradictoires. Par conséquent, la github fonctionne pas.
Tellement simple. Rar tout compris me semble une très bonne solution pour faciliter le développement et la portabilité de la charge utile à certaines personnes, bien sûr, peut faire vos patchs ou des sources changé, et même suivre son propre chemin, à certains égards. Le github serait bien si c'était vraiment open source amicale et avait une volonté de travailler ensemble dans la même direction et que cela avait une taille démesurée, mais ici en ce moment, n'ont même pas été saisie à la charge utile au-delà de l'ajout d'un peu "pokes" pour les jeux [rires], et ont a. S qui est inférieure à 25 ko non compressé, je ne pense pas que c'est gros problème
[B] Pourquoi ne pas soutenir d'autres versions de firmware? [/ B]
Il ya deux raisons: d'abord, que je n'ai qu'une PS3 et a le firmware 3.41. La seconde est que je pense que c'est une erreur de travailler sur des versions antérieures, car ils offrent moins de compatibilité avec les jeux, le plus de difficulté à trouver les correctifs et en fin de compte, ne sert que de multiplier les travaux x 10 pour obtenir plus mauvais résultat.
Je sais que certains le font pour garder Linux, etc, mais dans la vie on ne peut pas tout avoir et à mon avis, c'est une attitude illogique de travail par exemple, à 3,15, quand il ya des jeux que nous appelons pour 3,42 et il semble plus logique d'aller de l'avant et de se concentrer sur la connaissance de ce qu'il fait le firmware 3.41 (qui est la norme) que toute autre chose.
[B] coup d'oeil / poke, syscall syscall 36 et 8 [/ b]
Expliquez à ces besoins élevés pour ces appels système, semble presque à me perogruyo: mon franchement, les appels système de jeter un regard et piquez n'aime pas, parce que les données ne se déplacent que de 8 octets et sont très simpliste, très franchement. Mais, même si j'ai une meilleure solution (memcpy par syscall8) la règle d'or doit avoir pour n'importe quel développeur, est la rétro-compatibilité, si possible. Aussi poke and peek lv2 fenêtres sont utilisés par certains et il semble une limite peu stupide.
Pour cette raison, le syscall 36 ne devrait pas être supprimé, en tant que gérant ouverte tandis que l'autre vous permet de passer facilement, nous refiler la responsabilité à ceux qui élaborent le programme, qui devra faire face à ceux qui ne peuvent pas changer le syscall 36 (qui psjailbrak ont, par exemple) et se limiter au cas où cette équipe prendre quelque chose que nous pouvons utiliser tous.
Le syscall 8 est une boîte à outils très utiles. Malgré l'avis de certains, je pense qu'il est si difficile à comprendre qu'il s'agit essentiellement d'un switch / case qui rejoint d'autres fonctions que syscall et syscall8.h suffisamment d'explications de son fonctionnement, sauf que n'importe qui peut demander à ce sujet ici ils ne mordent pas XD.
Le syscall 8 comme je l'ai expliqué à l'époque, vous permet de copier, remplir avec des zéros, exécuter des routines dans le noyau ou même rediriger les périphériques et fichiers en utilisant une structure de données, comme expliqué dans syscall8.h
Mais a trois caractéristiques intéressantes: un mode nous permet de déterminer qu'il s'agit d'autorisations d'accès et les deux autres nous permettent d'activer ou de désactiver l'utilisation des appels système que nous utilisons.
Alors syscall8_disable (clé), permet aux applications de cacher poke / PEEK / syscall 36 syscall lui-même, même qui ne fonctionne que 8 syscall8_enable s'attend à une droite (touche).
La clé de 64 bits est utilisé pour permettre que les appels système à nouveau possible avec la bonne clé et donc d'éviter une application ou un jeu, la force brute, facile à tracer la bonne clé, car elle limite également le nombre de tentatives.
Il me semble un enfer d'une solution pour éviter les situations dangereuses d'une application syscalls qui permettent l'accès à l'LV2 est dommage que certaines personnes semblent ne pas comprendre l'utilisation qui ont ces fonctions et que la seule règle que ne J'ai écrit un livre avec des fonctions en assembleur-à-dire que même un néophyte comme moi assembleur PPC, je comprends (et plus en s'appuyant sur la description syscall8 sur son fonctionnement).
[B] Pourquoi rester dans 0x7ff000 la charge utile? N'est-il pas dangereux? [/ B]
Je reste là parce que nous n'avons pas d'espace pour stocker le code. Nous avons donc deux options: soit modifier le code pour tenir dans son lieu d'origine, nous priver du potentiel ou séjourné ailleurs qui ne semble pas déranger, parce que le code est tout aussi LV2 2 MB avant à la maison de la charge utile.
Dangereuses est tout dans la vie et si l'appel de quelqu'un pour un jeu de fond de la tombe en panne de charge utile, peut-être pour des raisons autres que la maison du code dans un seul endroit dans toutes les décharges que j'ai fait, est occupé par zéros (s'il est vu autrement, il n'aurait pas choisi d'inclure le code)
Et je ne suis pas de ceux qui font des choses les plus sans, si pas tout à fait une analyse de sol et aller dans les jeux et les sortir et relancer les yeux d'autres. Et la vérité est que depuis je utiliser un gestionnaire ouverte (l'original, pas ceux qui vous aide qui n'ont pas de code source et inclure la même merde que modifier quelque chose, l'option pour activer la touche marche / arrêt), avec tous les jeux OMANXXXXX dossier, je n'avais aucune plante rare, sauf dans les jeux qui nécessitent dur, s'ils ne sont pas, c'est évident.
Évidemment, j'ai tous les jeux sur le marché et je ne peux pas dire si il ya des exceptions qui brisent la règle, mais probablement d'un jeu pete pour rien d'autre que la position de la charge utile dans le noyau.
Salutations
Je vous rappelle qu'il s'agit d'un thread [b] [u] CHARGE DE DEVELOPPEMENT [/ u] [/ b] et ne pas faire des ajustements à des systèmes différents, qui doivent être occupés dans leurs filets respectifs.
D'autre part, cette charge utile n'est pas le même que celui utilisé Kakarot, qui, si vous insérez hexagone et vous faire des choses drôles, ne soyez pas surpris et ce qui est nécessaire pour quelqu'un de compiler et de l'accrocher dans votre fil concernés.
Cela dit, des événements à traiter d'autres questions que j'ai vu là-bas
[B] Pourquoi ne pas vous envoyer le projet à github? [/ B]
Pour de nombreuses raisons:
Premièrement, il est né parce que la charge utile de psgroove n'était pas public (ou du moins je n'ai pas vu le code source) et que les individus ont été limitées à travailler dans la charge utile sans la possibilité de charger des jeux. J'ai donc versé port1_config_descriptor et le démontage, aidé par les commentaires ps3wiki.lan.st dans la charge utile et la contribution AerialX qui finit en charge de certains jeux sans disque.
L'idée était de disposer d'une source qui pourrait construire et améliorer, sans restriction d'ordre moral ou juridique d'affecter d'autres personnes, nous avons posé un obstacle à ceux qui pensent différemment ou qui n'ont pas de telles restrictions et que vous souhaitez apporter notre contribution sable.
D'autre part, ne pense pas qu'il soit juste (ou comme on dit en collègue plan: «juridique») ajouter un github parallèle psgroove, lorsque les auteurs d'origine l'ont déjà de cette façon, ou pense qu'il est juste d'ajouter mes droits d'auteur en tant qu'auteur une charge utile qui n'est pas le mien, puisque les auteurs originaux font partie de ce qui est connu sous le nom "psjailbreak." De mon point de vue, le code charge appartient à quelques gentilshommes anonyme avec un droit d'auteur douteuse, mais appartient toujours à eux et je l'aide avec quelques améliorations comme un utilisateur et programmeur amateur (bien sûr sans but lucratif), tout simplement. Et donc je ne peux pas (ou ne devrait pas) ajouter le droit d'auteur, mais je me sens très libre d'ajouter des améliorations.
Si d'autres veulent, et même changer le code pour avoir le prétexte de le faire, c'est leur droit, mais je pense que vous ne pouvez pas faute de la GPL par exemple, en remplaçant le code avec une licence et une charge utile qui n'est pas bien mis un "Hermes droit d'auteur", à moins que l'équipe d'origine le fait, et qui me permet d'être co-auteur avec mes modifications. Non, si les auteurs originaux, comme l'idée que d'autre part metamos votre code, mais ce n'est pas comme ils ont été très respectueux et juridique et au moins je apporter des améliorations et je le prends, seulement à partir d'un autre code, sans .
Je pense aussi que la scène doit être un effort collectif, pas de groupe, quand un groupe est formé, ce qui implique une restriction à la participation des autres utilisateurs et une contrainte au développement.
Par exemple, supposons que demain je raccroche le projet sur github. Qui peut élever leurs contributions?. Je donne seulement à ceux qui partent et depuis que je l'administration, toutes ces idées qui ne se marient pas ma philosophie, et, finalement, pourrait être ajoutée serait dans le même [rires]
Un exemple clair est le suivant: j'ai une philosophie de travail que Kakarot par exemple, ne partage pas votre avis, nous pouvons coopérer à cet égard?. Je pense que c'est un non catégorique, il peut comprendre ce que vous aimez mon code et je peux comprendre ce que je comme la sienne, mais les deux suivent des chemins différents et ont des idées contradictoires. Par conséquent, la github fonctionne pas.
Tellement simple. Rar tout compris me semble une très bonne solution pour faciliter le développement et la portabilité de la charge utile à certaines personnes, bien sûr, peut faire vos patchs ou des sources changé, et même suivre son propre chemin, à certains égards. Le github serait bien si c'était vraiment open source amicale et avait une volonté de travailler ensemble dans la même direction et que cela avait une taille démesurée, mais ici en ce moment, n'ont même pas été saisie à la charge utile au-delà de l'ajout d'un peu "pokes" pour les jeux [rires], et ont a. S qui est inférieure à 25 ko non compressé, je ne pense pas que c'est gros problème
[B] Pourquoi ne pas soutenir d'autres versions de firmware? [/ B]
Il ya deux raisons: d'abord, que je n'ai qu'une PS3 et a le firmware 3.41. La seconde est que je pense que c'est une erreur de travailler sur des versions antérieures, car ils offrent moins de compatibilité avec les jeux, le plus de difficulté à trouver les correctifs et en fin de compte, ne sert que de multiplier les travaux x 10 pour obtenir plus mauvais résultat.
Je sais que certains le font pour garder Linux, etc, mais dans la vie on ne peut pas tout avoir et à mon avis, c'est une attitude illogique de travail par exemple, à 3,15, quand il ya des jeux que nous appelons pour 3,42 et il semble plus logique d'aller de l'avant et de se concentrer sur la connaissance de ce qu'il fait le firmware 3.41 (qui est la norme) que toute autre chose.
[B] coup d'oeil / poke, syscall syscall 36 et 8 [/ b]
Expliquez à ces besoins élevés pour ces appels système, semble presque à me perogruyo: mon franchement, les appels système de jeter un regard et piquez n'aime pas, parce que les données ne se déplacent que de 8 octets et sont très simpliste, très franchement. Mais, même si j'ai une meilleure solution (memcpy par syscall8) la règle d'or doit avoir pour n'importe quel développeur, est la rétro-compatibilité, si possible. Aussi poke and peek lv2 fenêtres sont utilisés par certains et il semble une limite peu stupide.
Pour cette raison, le syscall 36 ne devrait pas être supprimé, en tant que gérant ouverte tandis que l'autre vous permet de passer facilement, nous refiler la responsabilité à ceux qui élaborent le programme, qui devra faire face à ceux qui ne peuvent pas changer le syscall 36 (qui psjailbrak ont, par exemple) et se limiter au cas où cette équipe prendre quelque chose que nous pouvons utiliser tous.
Le syscall 8 est une boîte à outils très utiles. Malgré l'avis de certains, je pense qu'il est si difficile à comprendre qu'il s'agit essentiellement d'un switch / case qui rejoint d'autres fonctions que syscall et syscall8.h suffisamment d'explications de son fonctionnement, sauf que n'importe qui peut demander à ce sujet ici ils ne mordent pas XD.
Le syscall 8 comme je l'ai expliqué à l'époque, vous permet de copier, remplir avec des zéros, exécuter des routines dans le noyau ou même rediriger les périphériques et fichiers en utilisant une structure de données, comme expliqué dans syscall8.h
Mais a trois caractéristiques intéressantes: un mode nous permet de déterminer qu'il s'agit d'autorisations d'accès et les deux autres nous permettent d'activer ou de désactiver l'utilisation des appels système que nous utilisons.
Alors syscall8_disable (clé), permet aux applications de cacher poke / PEEK / syscall 36 syscall lui-même, même qui ne fonctionne que 8 syscall8_enable s'attend à une droite (touche).
La clé de 64 bits est utilisé pour permettre que les appels système à nouveau possible avec la bonne clé et donc d'éviter une application ou un jeu, la force brute, facile à tracer la bonne clé, car elle limite également le nombre de tentatives.
Il me semble un enfer d'une solution pour éviter les situations dangereuses d'une application syscalls qui permettent l'accès à l'LV2 est dommage que certaines personnes semblent ne pas comprendre l'utilisation qui ont ces fonctions et que la seule règle que ne J'ai écrit un livre avec des fonctions en assembleur-à-dire que même un néophyte comme moi assembleur PPC, je comprends (et plus en s'appuyant sur la description syscall8 sur son fonctionnement).
[B] Pourquoi rester dans 0x7ff000 la charge utile? N'est-il pas dangereux? [/ B]
Je reste là parce que nous n'avons pas d'espace pour stocker le code. Nous avons donc deux options: soit modifier le code pour tenir dans son lieu d'origine, nous priver du potentiel ou séjourné ailleurs qui ne semble pas déranger, parce que le code est tout aussi LV2 2 MB avant à la maison de la charge utile.
Dangereuses est tout dans la vie et si l'appel de quelqu'un pour un jeu de fond de la tombe en panne de charge utile, peut-être pour des raisons autres que la maison du code dans un seul endroit dans toutes les décharges que j'ai fait, est occupé par zéros (s'il est vu autrement, il n'aurait pas choisi d'inclure le code)
Et je ne suis pas de ceux qui font des choses les plus sans, si pas tout à fait une analyse de sol et aller dans les jeux et les sortir et relancer les yeux d'autres. Et la vérité est que depuis je utiliser un gestionnaire ouverte (l'original, pas ceux qui vous aide qui n'ont pas de code source et inclure la même merde que modifier quelque chose, l'option pour activer la touche marche / arrêt), avec tous les jeux OMANXXXXX dossier, je n'avais aucune plante rare, sauf dans les jeux qui nécessitent dur, s'ils ne sont pas, c'est évident.
Évidemment, j'ai tous les jeux sur le marché et je ne peux pas dire si il ya des exceptions qui brisent la règle, mais probablement d'un jeu pete pour rien d'autre que la position de la charge utile dans le noyau.
Salutations
Source : http://psx-scene.com/forums/f6/hermes-answer-kakaroto-68941/Message original : http://www.elotrolado.net/hilo_desarrollo-psgroove-payload-custom-v4b_1490355_s880#p1722200839
Flux RSS