Hi all,
I see a lot of people asking me some questions and I notice a lot of ignorance in the net about the different payload and the latest PL3 payload. So I want to make things clear..
First of all, people should stop talking/requesting/using the hermes v3 payload, I don’t like his work, and the payload is not good, it might crash the system in some cases, it’s not written properly, and hermes doesn’t even seem to understand how git works.
Also, PL3 already includes (for some time now) all the good stuff from hermes, it already supports installing game updates, or running games without a disc, anything else that Hermes added is useless and dangerous could crash in some situations (requiring a reboot).
Some might have seen my tweets about my new payload being released, and many are asking me what is the difference between my payload and what is already available.
PL3 doesn’t support syscall 36 anymore, for multiple reasons, first, it was bad code, it was mapping a path to a single hardcoded value (/dev_bdvd or /app_home or /dev_flash or whatever is hardcoded in the payload) which means that, since we (the PSGroove and PSFreedom developers) don’t want to support running backups, all the official payloads weren’t working with the backup manager without being patched first. The syscall 35 I added in my payload is more generic though, it is the proper way of doing things. You can map any path to another other new path, the prototype looks like this :
syscall_35 (char *old_path, char *new_path);
This means that the payload doesn’t need to have a hardcoded /dev_bdvd path in it, or have extra code for mapping /app_home to something else.. or having syscall 36 change both /dev_bdvd and /app_home breaking homebrew when using a discless mode with a backup manager. You also don’t need a special payload to run the ‘firmware usb loader’.. It all just works because the choice of the path mapping is given to the homebrew applications themselves. This means that the backup managers will just map /dev_bdvd to what they want and they will work by default on my payload, there will be no need for a patched version of the payload to make them work.
This however means that the backup managers that depend on syscall 36 will stop working. For now Gaia Manager is the only backup manager available that is compatible with my payload. But I’m sure more will be ported to use syscall 35.
People need to understand that this new syscall 35 has to become the new standard, this is what all the payloads should use, nothing else, and this is what everyone should start using, not the old, crappy, backup-manager specific, PSJailbreak written, syscall 36.
We need to have some form of standardization for all these payloads, I’m tired of seeing about 100 different payloads floating on the internet, it doesn’t make sense. I always believed in a single payload that works for everyone, and that’s why I created PL3, that’s why it’s a project independent of PSFreedom (and PSGroove has been ported to it) and that’s where all the efforts should go. Also, by using PL3, you automatically gain support, and all the same features, for whatever previous firmwares PL3 already supports (3.01, 3.10, 3.15 and 3.41).
I have just recently seen this new payload that everyone is so happy about that includes “all the good things from 3 worlds”, the one created by Rancid, which includes the stuff from hermes, waninkoko and Mathieulh… and I was shocked to see how much people were happy about this.. people don’t really seem to understand that this wasn’t necessary at all? PL3 has had all those patches for a while now, so why did Rancid even bother making this payload that includes the patches from hermes, waninkoko and Mathieulh? Why would you spend your time doing something that already is available!
This blog post is meant to stop all this ignorance and let people know that they don’t need to look for a special payload, just use PL3 and you’ll get everything you need. It is also meant to explain to everyone what is different about my payload.
On a side, I have received a P3Hub device, kindly donated to me by the people from r4king.com, and I have now tried PSGroove for the first time! I’ve also created a fork of jevinskie’s port of PSGroove which is now improved and updated to support the latest PL3 version. This means that the PL3 payload is available for everyone, those using PSFreedom as well as those using PSGroove, so there is no excuse now on not using it or relying on badly written payloads developed by people who barely know how to code (yes, using winrar instead of git is a good indication of that).
Update: I forgot to rant about peek&poke!!! So let’s do it now… well, the default payload in PL3 has peek and poke disabled, and for a simple reason : Nobody needs them! and more importantly they are misued! I’ve look at the code of the different backup managers, and it looks like all of them use poke to patch the memory to ‘fix something’ because they think that it’s their job to do it.. no it’s not! If you have a working patch, then submit it to PL3 and if people complain, tell them “use the proper payload”, don’t try to take advantage of peek&poke to go and modify the kernel’s instructions! The reason is simple.. you are a homebrew app that does X, then do X, leave the kernel patching to the payloads! Just as PL3 doesn’t map /dev_bdvd to /dev_usb000/I.Like.This.Game/ and locks it out! Also, I’m on firmware 3.15, so when you decide to poke and patch the kernel with a hardcoded offset, you’re just screwing up my kernel because the offset is firmware dependent! it’s not the same depending on the firmware you use, and I don’t want you playing with it. So.. peek&poke are really not useful to anybody, they are not even available on a normal linux pc, so why would you want them in your default payload, right?! The only people who should use a payload with those syscalls enabled are real developers, people who want to analyze and patch the kernel on the fly while they are doing some development of, maybe, a kernel driver! That’s it. Anyways, that’s enough ranting from me for today!
P.s: In my branch of PSGroove, I wrote a script that build the .hex file for every supported device (from the README) for every supported firmware. You can find all the hex files here : PSGroove+PL3 hex files
Update: Thanks to evilsperm, I’ve updated the archive with hex files for these devices : Blackcat, Xplain, Olimex, UsbTinyMkII, Bentio and OpenKubus.
Update 2: Some people reported crashes with my payload when running backups with installed updates. I figured out the cause and fixed it now in git. The hex files above have also been updated
Thanks for reading.
KaKaRoTo
sudo apt-get install avr-gcc avr-libc
Update 2:
Found an VM image on the net with the “official” sdk, hacked of course, included with it. (6gig for those thinking of it)
Installed that, and am now installing your SDK into it as well.
I have tested it & is compiling the .hex files all fine, so once the second SDK is installed and then wireshark I should be good to go. errr, hopefully 😉
a little bit late but thanks kakaroto. like u i believe standardization is the key to everything. instead of a developer trying to come out with different payloads, it would be better if there is a standard one so that they will have more time on their hands to really concentrate on homebrew. i am not a fun of piracy but homebrew i like. thanks for ur hard work.
You’re welcome 🙂 And yes, having a unique project for payloads is the purpose of the PL3 project (people still seem to think PL3 is the name of a payload), a repository for unifying all payload development and a unique repository to contain all the different variations of the paylods (psfreedom and psgroove both use PL3 now, but both projects chose to use a different payload (peek&poke support in psgroove, but not in psfreedom)).
Ok, I have to admit now I am completely lost from the getgo after thinking I understood the process.
I’ll carry on playing with the info and see what turns up 😉
Did I mention I am a stubborn bastard 😉
lol, you do seem stubborn :p
Where are you blocked now ? did you get pl3 built and working at least ?
yep all of that is sweet now.
Just kicking off with the inital instructions to dump lv2.
Where do I disable the Jig Mode, and also change the payload that will be used?
I am sure it will come to me when I get into it…been sitting in front of the screen too long I think heh
Side note: where are you on the planet? You appear to be in/close to my time zone (Aus east coast)..or just hardly sleep like me.
haha, yeah, i’ve been told a lot that I have the australian timezone :p
I live in Canada, Montreal.. it’s currentl 6AM and about to go to sleep!
For the jig mode, comment the USE_JIG define from config.h
When it talks about bruteforcing the address, try changing the address (SHELLCODE_ADDR_BASE) in the :
#else /* USE_JIG */
part of psgroove/psfreedom.
if it doesn’t work, try with 0x50 instead of 0x4D, and keep bruteforcing around those values until it works.
then the rest of the instructions are pretty straight forward (I think/hope).
No wonder you type like an Aussie..they say we are the same eh (couldnt resist)
Once I get the Lv2 out of it I will shoot it over there for you to mess with as well. We all know you would smash it way before I do 😉
3 days, and covering Linux, Ps3 & PPC is a hell of a learning curve. Thanks to my DOS days is the only reason I have persevered this long..well that and the excellent instructor.
lol, I’m not even canadian! I’m Moroccan :p And I live in the french speaking side of Canada :p
I’ve been to Melbourne and Hobart (for linux.conf.au) and no, we don’t speak the same :p
I don’t need to tell it to use the dump_lv2. file?
Once the USE JIG is commented out it includes that right.
Errr, your not going to believe me, but I am getting the YLOD reaction at 4D. There has to be something else stopping it from running.
I will now try to get the dump from Lv2 and send it over.
Just for reference, with the Kiosk units before you can really do anything you need to goto the “Security Settings” do a button press combo on the controller and enter the unlock code. I am thinking this “may” have something to do with why it’s not installing the payload.
The YLOD reaction IS the expected result.. if it works, you get the YLOD (panic), if it doesn’t work, it would simply freeze..
so you’re on the right track 🙂
github.com/MarkWebber has the pcap in it. The original capture was only an 8meg file, so not 100% sure it’s correct.
I am being dragged out today so will run it through IDA when I get home and start the egghunt 😉
@Mark Webber: Ok i got it, but I suggest you delete the repository as soon as possible, the dump itself contains the kernel of the PS3, which is the binary distribution of copyright Sony code.
the lv2 may be ‘leaked’, but it’s still illegal to distribute it. so once you dump it, it should be “for your eyes only”.
I’m at work now, when i get home, i’ll try to find some free time to look into it.
c cool de savoir qui a des codeur du ps3 au quebec 🙂
keep up the good work!
Well after several hours of messing around I am still lost.
To date I have gone nowhere really since I got the Lv2 dump done.
Problem is currently: Run the pcap through the dump_lv2, loaded the cleaned file into IDA (with PPC selected) and loaded the IDC file.
The IDC gives an error if I leave it empty, but I have no idea what to put into the window that pops up either.
When the window pops up, press cancel, it should then scan the dump and do its thing
Runtime error at isSyscallTale+0x00000011: Attempt to call undefined function ‘Qword’
Thats the error I am getting pressing cancel. Same error I was getting before.
Ah, it’s because you need to run IDA64 (only works with 64bit version of IDA)
/me should add that to the readme…
Heh, Don’t worry, I am going to write it up for you in English when I get it all done =P
I’ll put it in terms even I can understand.
Ok, So I have found the locations and offsets in the payload are out of whack by a few bytes accross the board.
New plan is to get a second LV2 dump from one of my other “normal” Ps3’s and compare the two side by side and adjust as neeeded and see what happens.
For now it’s sleep time…have ot enrol the eldest daughter at high school in the morning for next year…wouldn’t miss it for the world 🙂
Hello,
I have a problem (really I don’t know if it’s a problem…).
When I compile psgroove for my Xplain (with the ps3toolchain or with the pre-compiled PL3 payload), the hex created is smaller than the ones I can find in the internet. My hex size is 28,7 KiB (29403 bytes) and it has less lines. I do it under ubuntu and the compilation hasn’t any errors. Psgroove 1.1 was compiled by me too, but it was identical to the hex in the internet.
I don’t know if it will work because i don’t know if it can damage the ps3.
Is my hex a bad one or would it work? I like compile it myself because if there are updates I don’t want to be asking for the hex to other people.
Sorry if you don’t understand me because my english is not perfect 🙂
It won’t hurt your system. I have used smaller versions before.
The psgroove\psfreedom hack lives in memory, not in your firmware.
As soon as power is removed it’s gone. Thats why we have to do the exploit each time you power on.
Ok, so after looking over both files, they appear to have all the same info at all the right places. It has to be in the ELF dumps maybe.
Where/what do we change to enable the dump_elf firmware to be used?
oh cool (it was probably expected, hehe), so 3.41 kiosk kernel is the same as 3.41 retail kernel.. The difference is probably in the vsh itself and config files.
You can just use the payload_dump_elfs_3_41.h as is, it should just work as far as I know.. you’ll get the elfs sent over ethernet (make sure you disable the wireless on the ps3 since once it boots it will kill ethernet if you use wifi).
Heh, 2 days of looking through code for that =P I was starting to see stuff that was not even there.
When I compile the code though, is there anything I need to do to tell it to use the dump_elf payload?
I have not had to swap payloads around before so I am not sure if something in one of the files needs to be editied.
Also, do I need to re-enable Jig mode?
Once you found the right address for the jig response (the same I suppose?) then enable the jig mode. and make sure that it runs properly. The jailbreak may not work, but at least it shouldn’t crash the system. To test the jig address, USE_JIG and use the panic shellcode to see if it panics.. if it does, then put everything back to ‘normal’ and make sure the payload doesn’t crash the system (to make sure all function offsets are good).
For the dump_elfs, if you’re using psfreedom, then just ‘cp payload_dump_elfs_3_41.bin /proc/psfreedom/payload’ before running the jailbreak.. if you use psgroove, then edit descriptor.h and change the
#define PAYLOAD payload_dev
into
#define PAYLOAD payload_dump_elfs
Should work then.
Well the “original” hex files untouched have always gone to green light (using a maximus) and have had no reports on screen of “unknown usb device connected” unless I mess up with the wrong version of hex. The purpose built maximus hex files were few and far between, so others were substituted.
Do you want a “review copy” of the elf dump pending all goes to plan?
ok cool, goes to green means it sends the data through jig, boots so the jig offset was right, no crashes, so all offsets are correct.. so yeah, only the vsh elfs need to be fixed then. the easiest part :p
good luck.
Ok, I think I have it all, but it seems to be missing the offset for elf2_func1_offset.
I am also getting an error launching homebrew (80029519) but it is letting it install so maybe they are connected?
cool!
but are you sure you’re missing the elf2_func1 stuff ? the elf2 is what allows installing pkg files. So if you can install, then you already got it to work.
if you can’t run unsigned apps, then it means you didn’t put the right offsets for elf1.
By the way, the HOWTO might be out of date.. I wrote it when the elf1/elf2 function patches did some stuff that has now changed.. at least, they should help you find the interesting functions.. then just compare with a retail 3.41 elf to see what instruction needs to be patched. The offset is then the position of the instruction – position of the start of the function.
(or set it to 0, and set the elfX_funcY to the instruction directly.. but it’s not a clean way of doing it).
I set elf2_func1_offset to 0x00 since it had the same address reporting as the offset in IDA. Seemed logical to me.
The current value for elf1_func1_offset is 0x00 but I don’t remember changing it either so I will go after that.
As a rather interesting side note, and I am not sure you have seen a Kiosk unit in full flight before: When we first turn them on we get an XMB, but after you use the controller to enter the unlock code things get renoved and added, sort of like a second XMB.
The funky thing is, I am not seeing the new menu items under “game” until after I use the unlock code even though it has all obviously gone through.
yes, you could set all offsets to 0, and just find the right instruction to patch and put it in the elfX_funcY macro. I find it nicer to set the func macro to the start of the function and the offset to the offset of the instruction to patch withing that function, but others may disagree.. don’t know, personal preference.
humm.. would be interesting to get the elf dumps, I suppose it switches from one xml to another.. and we patch the ‘normal’ xml, that’s why you need to unlock it before it actually reads the tool xml and reloads the xmb.
Would be interesting to see how it does that, maybe we can somehow tell it to do it manually without a kiosk vsh 🙂 Then we could have some fun with our own custom xmls 🙂
It has to be something else. I am comparing dumps from both machines side by side and the area is 100% correct.
I did notice that your offset was not dropped by 0x1000 though as per he guide, so I changed mine to be the same as the offset shown by IDA without success.
You need to use the same offset as shown by IDA for elf2, but you need to -0x1000 for elf1. Same when comparing with 3.41 retail, add 0x1000 to the offset to get the address on IDA.
Send me the files by mail (my nickname@this url), I could have a look.
Also, give me the offsets you got, should help me get started
LOL, and I just got the bloody thing. IDA was showing the correct offset at the bottom and I had been taking a further 0x1000 off that. <=-= id10t
I'll email the files over anyway and include the macro.h.s file I have modified along with it.
I seriously cannot thankyou enough for the assistance along the way..it has been character building to say the least comming from a hardware background 😉
Interesting…getting an error of 80029567 now.
Maybe the USB stick has issues but I will look into in when I get home from work.
Humm.. never seen that error.. btw, I pushed your changes into git already 🙂
http://github.com/kakaroto/PL3/commit/d18a5d6f158369e569c8b5c4fec49758bc74ed88
Thanks 🙂
It seems to be a problem with the final offset value.
If it’s 0x00 it will let the package install but not let it run. If it’s normal, it will run the package, but not let t install.
If you get time (I am off to work) can you check that last set of offsets 😉
Actually if they are not all 0x00 it seems to fail
Just had a quick look at your elf1 and elf2 offsets.. the elf1 offsets all seem to be good, but the elf2 one was wrong. I fixed it now and committed. Please test it. Thanks! 🙂
The patch works perfectly 🙂
I will have to go and have another look at the code now and see how I missed it.
Everything is installing and launching exactly as it should.
Did you find anything interesting in the “review” files?
Ok, now I am lost.
In the HOW TO for elf2_func1 it says to search for xxxxx and then look for the offset of r1dic1 which is the result of the search +4 bytes?
On mine it shows at 2ECD0 +4 = 2ECD4?
Was that leftover from a previous method?
Just curious since I will be putting together a pdf next week.
Humm.. yeah, the HOWTO is probably outdated.. I think that only explained what to patch to allow debug pkg to installed.. then the patch completely changed to something else (but I think still within the same function) to allow installing retail and debug .pkg alike…
Ahhh, that explains why when I first used it, it was installing everything.
I never went back to func2 after we figured the cause was the first one since everything was working at that point.
I am going to take a much more indepth look at it throughout the week and maybe try and learn a little more about PPC assembly along the way.
I am s sucker for punnishment =)
I will just like to thx u on the endeavors and work that have pulled tru on. Its nice to know that such talented programmers actually live in my hometown. I’m currently a student at vanier college in computer science and would love to see programming from a reverse engineer perspective. If you are ever free, maybe we can have lunch.
hello, when i jailbreak my ps3 with Hermes4(b) everything works perfect. When i use KAKAROTO’s payload 3 my ps3 start up but no xmb icons shows up.
I use rockbox on my IPOD VIDEO. What is the problem ?
Hey I really admired your blog post. Don’t stop the good work!
Kiosk (must update error)
#define patch_func9 0x4FC18 (offset 0x00)
Slowly working on the 3.50 spoof as well