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/membersThe 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 ... 43f92ee26dAs 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
Good night.
KaKaRoTo
y pasar un .S que mide menos de 25KB sin comprimir, no creo que sea gran problema
.
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[decaio]](/images/smilies/nuevos2/decaido.gif "decaido")
![[ayay]](/images/smilies/nuevos/sonrojado_ani1.gif "enrojecido")
