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
KaKaRoTo great work, thank you
Nice to see that someone remember about people that have different FW than 3.41.
Also very good your idea of standardization. As you wrote there is a terrible mess with PLs and other stuff.
I would like to ask is it possible that you could add to your “official hex package” binary for ATAVRXPLAIN? There is so much different hex files on all ps3 sites that is hard to find out which is correct one. XPLAIN board is quite popular so people, who do not know how to compile hex at own (like me 🙂 ), will be very grateful for such support for sure.
Thank you in advance…
Please don’t take this as harsh criticism.
I’m only trying to point out what I see and why I think there is a problem here.
I’m on your side.
I also think this needs to be the standard for all future development and solid ground for homebrew to be developed.
I want the homebrew to begin, as HomeBrew for a PS3 should put the HomeBrew for the Wii to shame, but first we need a good platform to work with, and this is it.
The main thing I see as being a stopping block is that only a very select few can use the PSFreedom code because nowhere exists a place that explains the processes needed to compile this for anything except a N900.
What happens next is this leaves everyone at the mercy of the select few with this knowledge, and then development comes to a halt.
All you have left is the people begging for someone to compile it for them so they can run ‘backups’ (yea, right, backups…)
Like for example, the n900 readme says to “Type ‘make n900’ to build the target for the N900”
When anyone just uses that information, all they will see is “make: *** /usr/src/kernel-2.6.28/: No such file or directory.” and it halts.
Next try ‘make dingoo’…same basic results.
..
Next git clone a copy of psgroove and type ‘make’
You get no errors and a compiled code.
(Of course they will need to adjust the parameters in the makefile to get the correct hex for their board, but that’s a simple task and all the instructions are there to guide you.)
I would love to see this become the standard for all users, but we need more info for this to happen.
My suggestions:
Is there any way to get the people that are spending so much time porting this to different devices to post up the setup they used to compile?
What exact distro did they use?
Where did they get it from and is there a pre-compiled ISO or .VDI for it?
( If not, what modifications did they make to the “stock” kernel? )
What parameters did they need to set to get this to compile?
With this basic information, this will take off faster than you can imagine…
(Thanks for taking the time to read this)
@budzio: evilsperm just added support for XPLAIN in the build_hex script. I’ll update the files now.
@Smyers75: No worries, I like positive criticism, and you are right!
I do like openness and I try to keep everything documented and not hide knowledge.. unfortunately, I’m not good at writing docs/readmes..
For how to build for N900, instructions are here : http://psfreedom.com/wiki/Nokia_N900
Basically, for any target you want to build for, you need the kernel source for that target and you need it in /usr/src.. the makefile usually takes the common path for that target.
The same applies to other targets, for dingoo/iphone you need to patch the kernel first I think, and the patches are available in the dingoo/iphone directories.
For android, it’s a bit more complicated, I personally never tried it on android, and i leave the porting to others, but there is psfMod http://www.psfmod.klutsh.com/ which should work for any device that supports amon ra’s recoveries and the build instructions are the same as cyanogen roms.
I don’t think that anyone hides the information, I think that we just need someone to sit and gather that information and write it in a proper manner.. but it’s all available/easy to those who know how to use google a bit.
I’m all for improved standards and clean code. When it works that is 😉 I tried using one of your hex’s today:
psgroove_teensy_at90usb162_16mhz_firmware_3_41.hex
This was in conjuction with Gaia Manager rc7 and the first two games I tried to run (updated versions of GoW2 and Assassins Creeed II) and the ps3 just froze. The only other game I tested, Little Big Planet (also updated) ran fine but then this ran fine before any of tthe fixes for game updates.
It doesn’t matter to 99% of people how messy the code is or wether it’s written properly, what matters is wether it works or not. And the messy combination of “hermes, waninkoko and Mathieulh” works. Simple as.
Again many thx for info and tar update.
@deltop, humm.. I’ve seen others complain about these issues, I have no idea why it happens though.. maybe someone can enlighten me! I have the god of war collection, and AC2, but I lent AC2 to a friend, but I could try GoW.. didn’t know it had an update though… maybe this weekend i’ll have some time to look at this and see what could cause it to crash.
until today, i didn’t know the payload had issues, otherwise, I would have fixed it before ranting, hehe
Heh, no worries I actually agree with you and very much so. The only thing I added myself to a Hermes and Waninkoko build were the 3 fixes that appeared over the past few days.
PATCH_INST(0x5745C, li %r31, 0)
PATCH_DATA(0x57410, 0x48000098)
PATCH_INST(0x57408, nop)
Now it’s a long long time since I did any proper coding but I was able to get those added and compiled into a working hex myself even before other people started spreading their own bastardised verisons lol. And it works, every game I have can be updated and launched. If you can get the same results but in a more correct and cleaner manner code wise then great 😉
Great work kakaroto! (and that comes after figuring out what it takes to use your payload on a PIC.) It’s great to not see duplicate entries in the package installer and paths with // in them which were obviously caused by shoddy/one char off string replacements.
One thing that has left me scratching my head is the removal of the ‘rest’ of the usb functions, that while not explicitly needed prevents the “unknown usb device” message.
Hey Kakaroto,
great to see you shed some light on this mess. Problem is that there isn’t much knowledge on what’s what. The basic exploit is kinda explained but the actual payload is still gibberish to most people.
Also… i know that your branch is dedicated to smartphones but is there a way that you could include and 8vx maker for poor TI-84+ owners?
maybe you could work with Brandon Wilson from the PS3JB project to improve his and your software. I think he did an amazing job and it should benefit from your amazing job as well.
Just my 2 cents 😉
In any case… AMAZING job man
@deltop: Ah, I see what you did there.. I think I understand why it wasn’t working… I’ve changed the patch now to just a ‘li %r3, 0’ in 0x572B8, it’s by far the best fix I think (assuming it works, and it should).
Please get the latest files I just uploaded and try with the new hex, let me know if it fixes the issues you’ve been having!
Thanks
This HEX (psgroove_teensy_at90usb162_16mhz_firmware_3_15) on Firmware 3.15 don’t work!
Tested with Gaia Manager v1.0 rc6 and rc7!
please help!
thanks
Great work kakaroto. Can i ask you to compile the new hex to PIC18FXXX related? Sorry if i’m a stupid to ask you this, but there is no how-to for that. Thanks.
Hey man, awesome stuff here! I couldn’t agree with you more regarding the “payload mess.”
I’ve been tracking your PL3 code for a while and I’m so glad you ported to PSGroove, since I’ve been having a go at it myself… and honestly I’m glad to go right to the source for this one. 🙂 Trying to understand how the exploits actually load and execute the payloads has been an adventure, since I’ve been trying to support fw 3.15 with all the new payloads as they’re released.
Anyway just wanted to pop in and say thanks. I just built for my own board, a ATAVRUSBRF01. If you want to update your build script, the MCU is at90usb162 and F_CPU is 16Mhz
hi kakaroto..nice writing there..well said…and u said that u cant write…:)
i’m totally agreed wit all the comments above.
i used HD2 running android to jailbreak my ps3..and i’m really greatful that darkstone did ported psfreedom to hd2…but sadly,its been weeks since darkstone compiled anything for the hd2.i’ve tried googled ways to create psfreedom.ko for hd2 version(if thats wat you called it), but my search end up badly as i dont know where to start in the first place 🙂 (sounds like stupid)
once again..i’m begging for someone to teach me how exectly can we make psfreedom.ko for hd2 from the hex you’ve posted….
thanx in advance.
Pingback: New Awesome Mount Point Manager - NZHawkPS3 - PSX PS2 PS3 Scene Hacking Modchip & Jailbreak Community
Great work and smart solution for the path remap problem, I mean the ethical one. I’m really thankful for the hexes too.
But please, add some kind of version tracking to the hexes too. If you don’t want to use major and minor version numbers, compilation date and time would do it too. Thanks. (Without this we can’t always be up to date and people may mention already fixed problems in forums as they already do.)
@Average Joe: I plan on making a major.minor release soon.. this is just a ‘git snapshot’ for those who are impatient basically…
I just need to test something and fix a possible bug (not sure if the bug is there yet), then i’ll make a release of PL3 and PSFreedom.
On the removal of peek&poke functionality.
Can’t say I agree with this.
I do agree that it was being misused, but not with its removal.
It’s a lot easier to use this feature with an app like Peek/Poke0.2 along with a fully decoded IDA of your LV2.bin to test a mod rather than to code up a hex and reboot the PS3 every time.
We don’t have docs on the LV2 dumps, so it’s difficult to fully understand what a function is doing until you ‘poke’ at it a bit and verify the results.
I was really looking forward to NZHawk adding the ability to Peek/Poke to load its own ‘mini payloads’ instead of having to either code up a hex or manually poke the addresses one-at-a-time…
(I also hope pl3 dropping this feature doesn’t stop them from release the new upgrade to Peek/Poke…)
The Blog post says “the default payload in PL3 has peek and poke disabled”
I take it that means the code is still available to us, provided we can reverse engineer the process the developers used to compile PSFreedom on devices other than the N900 ?
any chance support can be added for avrkey?
@Datalogger: when you compile PL3, you get ‘default_payload_x_yz.bin’ and ‘payload_dev_x_yz.bin’ (which is the same as default payload but with peek&poke. I said the default payload should not have peek&poke because most people don’t need it.. but I did also say that for people who know what it really is and who know how to use it, and need it for development purposes, then yes, those should use it.. I’m not saying “ban peek&poke”, I’m saying that the default, everyday-user payload should not have them, and that most ‘normal’ user applications should not (ab)use those syscalls.
Hopefully, you agree with that 🙂
Any chance anyone has the payload working on a Kiosk Ps3?
I know it has to have a different offset to the retail firmware for the payload, but it could be anywhere.
Kakaroto, agree completely with your rant. It’s driving me nuts trying to figure out what the hell is what out there. Standards are good for development and save a lot of time doing things from scratch.
@Mark_Webber: If you have a kiosk ps3, then follow the HOWTO file from PL3 to figure out how to find the correct offsets.. PL3 contains all the tools necessary to achieve this.
Don’t forget to commit your stuff to git and send me a pull request (no .rar/.zip please)
Yep I have one. Retired original 60gig when the slims were introduced =)
I’ll have a read over it all in the morning when I get home and send any results to you for reference/future use. Could turn out to be the missing link in the genome.
These came with the ability to “install package files” already after you unlock them… naturally it does not allow unsigned code, err yet 😉
I have to admit, messing with the internals of the PS3 has been more fun then I first thought.
I tested the last versions. still backups which give black screen on the old versions still give black screen. like Prince of persia 2.
I’ve tried your latest release with code fix with gaia_rc7 I can confirm that discless booting is not working for me. just boots back to xmb . also if direct boot and discless boot are both turned on it gives a black screen. Games do work with a game disc in the drive though including Assassins Creed 2 strangely enough it even seems to load much faster…Nzhawks Awesome Peek n Poker gives this ……………………………..
………………………………….
…………………………………
…………………………………
Throughout the memory area when trying to view. I’m assuming that it will need to be reprogrammed to support the new syscall you have implemented. Awesome Peek N Poker also did this same thing when I tried to compile jevinskies psgroove fork to use the dump payloads elf. I assumed it was my error and gave up after 2 days haha. (this was 3-4 days ago) Great work Kakaroto You are much appreciated just a few bugs to tweak ..
I ported psgroove with PL3 to STM32F103 arm mcu, but I can’t make it work (not fully debugged), if someone wants help me, plz leave message.
Kakaroto, thank you for your “stablishing a standard” effort, it was much needed, the scene is spiraling into a nonsense patch-mix-and-match payloads that would definitely not benefit neither homebrew, nor the “other half”.
I’m still on 3.15 and able to install homebrew with psfreedom recovery (which uses your payload). I’ve been trying now to use a avrstick, the one with only 8kb, by porting your payload to the small_groove port (based on psgroove).
AFAIK, to port your payload to small_groove, it should be enough to only copy your “default_payload_3_15” payload, into port1_config_descriptor, adjust payload size, because yours 3_15 is 0x980bytes in size vs. the 0xf00bytes of the psgroove one, and trim the repeating end section (0x00), and adjust accordingly the “port1_repeat” variable (smallgroove specific to save flash space). I’ve tried but not succeeded in getting it to run on my 3.15 machine.
But I digress, the question: Do you foresee any additional changes that should be applied in the original psgroove payload to the other config_descriptors in order to use your “default_payload_3_15” with it?
Thank you, and keep up the good work.
First of all Thx Kakaroto ^.^
Im having trouble flashing the olimex hex since olimex uses 8 not 16Mhz! Would you please kindly update the hex file for the olimex board?
thx in advance and regards
This is awesome.
Can you add support for Maximus with working LEDs to the makefile? Seems every board but Maximus is supported.
Hey man, I totally agree with everything you’re saying and you defiantly have me freaked out about hermes’ code being dangerous (I’m using version 2 payload still) but like you said, its such a mess out there that i am unsure if there even IS a version of PL3 for the ti-84 user.. Think ill be okay with hermes v2? is there a different one that you could recommend? am i overlooking the fact that the new hermes/Mathieulh/whatever ti-84 app var contains your PL3 payload? just concerned about the best step to take from here is all..
brilliant thread man and im lovin the work ye put in! i would love to migrate to ur payload but unfortunatly im currently using an ipod nano 1g to execute the code and i see there is no port yet, so i guess ill ave to sit tight an hope!
but thanks again very useful information
Hi People plz I could not find a compilation of my device, help me do it
psgroove_teensy_at90usb162_8mhz_firmware_3_41.hex
Is there any chance that someone can port the new payload hex files over to the TI84 for me? I would love to try this out but cant use it unless it’s on my TI84 calculator!
How would I go about turning this into a bin file for the Ti-84 Calculator hack?
I need a bin file according to the directions listed here -> http://brandonw.net/ps3jb/payload.php
i appreciate the quality in your post. nonetheless i wont be able to enjoy work as i erroneously bought a closed-source ps3key.
@all: NEVER BUY A PS3KEY EVER
I hate to bother you.. but I have tried everything..google searched the error, followed your instructions etc.
Trying to compile for N900 but getting the following:
I will be grateful for any guidance you can provide… thanks 🙂
[sbox-FREMANTLE_ARMEL: ~/PSFreedom] > make n900
make -C pl3
make[1]: Entering directory `/home/shred/PSFreedom/pl3′
make -C tools
make[2]: Entering directory `/home/shred/PSFreedom/pl3/tools’
make[2]: Nothing to be done for `all’.
make[2]: Leaving directory `/home/shred/PSFreedom/pl3/tools’
ppu-gcc -c shellcode_egghunt.S -o shellcode_egghunt.o
make[1]: ppu-gcc: Command not found
make[1]: *** [shellcode_egghunt.o] Error 127
make[1]: Leaving directory `/home/shred/PSFreedom/pl3′
make: *** [build] Error 2
[sbox-FREMANTLE_ARMEL: ~/PSFreedom] >
hermes no pondria un boton de “donate” 😉
I tested psgroove_blackcat_at90usb162_16mhz_firmware_3_41.hex + gaia_rc7 …and discless option didn’t work … then I tried to get back to Gaia Manager and the system froze.
Hi KaKaRoTo,
First of all, i would like to thank you for all your work.
Thanks to you, we all have a mean to port a working payload to many firmware versions.
Even if i had a 3.41 firmware version i have learned of lot by reading your explanations about how we can port PL3 to other firmwares…
Your IDA script is also very useful for developers who wish to reverse their lv2 dumps.
You are perfectly right the ps3 scene needs standardization for the payload, it is up to this payload to handle the patches and the different firmware versions and github is a really great tool to support the development of this payload.
Yet don’t take this as gratuitous criticism but i can hardly understand your comments about hermes. Why do you bash him that way while most of the mess from his payload simply comes from the original psjailbreak payload ?
You are blinded rude when you say that making a rar archive is a proof that he does not know how to code. I am really convinced that git is a wonderful SCM and that it is the best best to enable for collaborative development but such a remark may appear as gratuitous bashing.
I think that hermes does not deserve your comments and that collaboration to improve a payload is better than sterile wars…
On the other side i perfectly understand how you can be upset when you read comments on clueless forums that just ignore your work in favor of hermes while your payload is definitively better.
Anyway, many thanks for your work and your contribution again…
Garyfr
install these packages first:
ppu-sysroot: http://mirrors.kernel.org/ubuntu/pool/universe/p/ppu-sysroot/ppu-sysroot_2.0ubuntu3_i386.deb
ppu-sysroot64: http://mirrors.kernel.org/ubuntu/pool/universe/p/ppu-sysroot/ppu-sysroot64_2.0ubuntu3_i386.deb
ppu-binutils: http://lug.mtu.edu/ubuntu/pool/universe/c/cell-binutils/ppu-binutils_2.17cvs20070401-0ubuntu1_i386.deb“]
and only after:
ppu-gcc: http://mirrors.kernel.org/ubuntu/pool/universe/c/cell-gcc/ppu-gcc_4.1.1r840-0ubuntu7_i386.deb
Read more: http://www.ps3news.com/forums/ps3-hacks/psgroove-apploader-payload-aerialx-released-112728-7.html#ixzz12YTVHoSP
KaKaRoTo, you are a badass.
Pingback: The Payload Mess Explained | PS3 Hacks :: PS3 Homebrew :: PS3 Downloads
i dont know what it is. but. aftre launching one game in OBM it black screen system crashed and i was forced to restore corrupted files.
this was after i flashed your hex. but maybe its because you use Syscall 36 and OBM uses 35.
The Olimex hex you got there is 16Mhz only… most of us with Olimex AVR-USB-162 boards have the 8Mhz clock on it.
Bashing other people is always good thing to do 🙂 Hermes as well anyone currently working with PS3 with custom payloads are still wandering in somewhat great unknown. Usually things tend to be unstable and sometimes potentially dangerous somewhat.Live and learn, hating and bashing other peoples work really does not bring anything back.
Damn, I can’t seem to upload any of the pre-compiles onto my ecliPS3, it just errors when importing the file.
Is there anyway to upload to this, maybe a payload binary, or is it time to find an alternate hardware. Might just dig out my iPod instead (lol).
Great work by the way, I can somewhat follow what your saying and beyond anything else standardisation is more than needed.
The Olimex AVR-USB-162 is 8Mhz not 16Mhz.
Btw, can one destroy the chip by flashing your hex with wrong Mhz?
lol not to sound annoying with the where is this hex and that hex but anyone got hex for maximus avr board and i do agree with you on having a slandered but working together to achieve it should be more important than dissing others …
Hey I wanted to know was this payload ported for the Iphone 3g cause I tried to use the one posted on http://psfreedom.com/wiki/IPhoneLinux. The Direct boot or the updates aren’t working.