Good.
I remind you that this is a thread PAYLOAD DEVELOPMENT and not make adjustments to it to different systems, that must be occupied other in their respective threads.
On the other hand, this payload is not the same as that used Kakarot, which, if you are inserting hex and you do funny things, do not be surprised and what is required is for someone to compile and hang it in your thread concerned.
That said, happened to handle other issues I've seen out there
Why do not you upload the project to github?
For many reasons:
First, it was born because the payload of psgroove was not public (or at least I did not see the source code) and that individuals were limited to work in the payload without the ability to load games. So I poured port1_config_descriptor and disassembly, helped by the comments in ps3wiki.lan.st on the payload and AerialX contribution that ends up in charge of some games without disk.
The idea was to have a source that could build and improve, without restrictions of moral or legal to affect other people, we posed a hindrance to those who think differently or do not have such restrictions and would like to make our contribution sand.
On the other hand, do not think it's fair (or as we say in plan colleague: "legal") add a parallel psgroove github, when the original authors already have it that way, or think it is fair to add my copyright as author a payload that is not mine, since the original authors are part of what is known as "psjailbreak." From my point of view, the payload code belongs to some anonymous gentlemen with a copyright doubtful, but still belongs to them and I help with some improvements as a user and hobbyist programmer (non-profit course), simply. And therefore I can not (or should not) add copyright, but I feel very free to add improvements.
If others want to, and even change the code to have the excuse to do so, it is their right, but I think you can not foul the GPL for example, by replacing the code with a license and payload which is not well put a "Copyright Hermes", unless the original team does, and that allows me to be co-authored with my changes. Not if the original authors will like the idea that other hand metamos your code, but it's not like they have been very respectful and legal and at least I bring improvements and I take it, just from other code without .
I also think the scene should be a collective effort, not group, when a group is formed, this implies a restriction on the participation of other users and a constraint on development.
For example, suppose that tomorrow I hang the project on github. Who can raise their contributions?. I give only to those who leave and since I administer, all those ideas that do not marry my philosophy, and ultimately could be added would be in the same
A clear example is the following: I have a work philosophy that Kakarot for example, does not share do you think we can cooperate in this regard?. I think it's an emphatic no, he can include what you like about my code and I can include what I like hers, but both follow different paths and have conflicting ideas. Therefore the github not work.
So simple. Rar all-inclusive seems to me a very good solution to facilitate the development and portability of the payload to certain people, of course, can make your patches or changed sources, and even follow his own path in some respects. The github would be nice if this really was open source friendly and had a willingness to work all in the same direction and this had an inordinate size, but here at the moment, have not even been input to the payload beyond adding a few "pokes" for games and have a. S that is less than 25KB uncompressed, I do not think that is big problem
Why not support other versions of firmware?
There are two reasons: first, that I have only a PS3 and has the 3.41 firmware. The second is that I think is a mistake to work on past versions, since they offer less compatibility with games, the more difficulty to find patches and in the end, only serves to multiply the work x 10 to get worse outcome.
I know some do it to keep Linux, etc, but in life you can not have everything and in my opinion, is an illogical attitude to work for example, to 3.15, when there are games that we call for 3.42 and it seems more logical to move forward and focus on knowing what he's doing the 3.41 firmware (which is standard) than anything else.
peek / poke, syscall syscall 36 and 8
Explain to these high need for these syscalls, almost seems to me perogruyo: my frankly, the syscalls to peek and poke do not like, because only move data of 8 bytes and are very simplistic, frankly. But, although I have a better solution (memcpy by syscall8) the golden rule must have for any developer, is the backwards compatibility where possible. Also poke and peek lv2 windows are used by some and it seems a bit stupid limit.
For this reason the 36 syscall should not be deleted, as manager open while the other lets you switch easily, we are passing the buck to those who develop the program, which will have to deal with those who can not change the syscall 36 (which psjailbrak have, for example) and limit ourselves in the event that this team take something that we can harness all.
The syscall 8 is a very useful toolbox. Despite the opinion of some, I think it is so difficult to understand that it is essentially a switch / case that joins other functions to that syscall and syscall8.h enough explanation of its operation, except that anyone can ask about it here they do not bite .
The syscall 8 as I explained at the time, lets you copy, fill with zeros, perform routines in the kernel or even redirect devices and files using a data structure, as explained in syscall8.h
But has three interesting features: a mode allows us to determine that this is the access permissions and the other two allow us to disable or enable the use of syscalls we use.
So syscall8_disable (key), allows applications to hide poke / peek / syscall 36 syscall itself even that only works 8 syscall8_enable expecting a (key) right.
The 64-bit key is used to enable only possible syscalls again with the correct key and thus prevent an application or game, brute force, be easy to draw the correct key, as it also limits the number of retries.
It seems to me a hell of solution to avoid dangerous situations of syscalls applications that allow access to LV2 is a shame that some people seem to not understand the use that have these functions and that the only rule out that no I have written a book with the functions in assembler to say that even a neophyte like me ppc assembler, I would understand (and more relying on the description in syscall8 on its operation).
Why stay in 0x7ff000 the payload? Is not it dangerous?
I'm staying there because we do not have space to store the code. So we have two options: either modify the code to fit in its original place, depriving us of potential or stayed elsewhere that does not seem to bother, because the code is just as LV2 2 MB before to house the payload.
Dangerous is everything in life and if someone appeals to a game back of the payload crashes, perhaps due to reasons other than to house the code in one place in all the dumps I've done, is occupied by zeros (if seen otherwise, there would not have chosen to include the code)
And I am not of those who do things without most, if not quite the soil tested and go into games and go out and relaunch others eye. And the truth is that since I use open manager (the original, not those who are using you who do not have source code and include the same crap that alter something, just the option to turn on / off key), with all OMANXXXXX folder games, I had no crashes rare, except in games that require hard, if not entered, as is obvious.
Obviously, I have all games on the market and I can not tell if there are exceptions that break the rule, but most likely a game pete for anything other than the position of the payload in the kernel.
Greetings
Reply With Quote
Originally Posted by PS3 News 
