Editing KaKaRoTo Kind of ´Jailbreak´

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 111: Line 111:
A: That is actually a multiparted answer:
A: That is actually a multiparted answer:
:* now that several binairies ([[Iso module]] + [[CoreOS]] minus the loaders that are inside lv0) can be decrypted, more investigation can be done in them, which give a new boost in (unrelated to the HeN) other targets, like:
:* now that several binairies ([[Iso module]] + [[CoreOS]] minus the loaders that are inside lv0) can be decrypted, more investigation can be done in them, which give a new boost in (unrelated to the HeN) other targets, like:
:** Hardwareless downgrades : [[Downgrading with PSgrade Dongle]] (lv1.self)
:** Hardwareless downgrades : PSgrade/JIG (lv1.self)
:** [[QA Flagging]] / systemtokens (spu_token_processor.self) and usertokens (spu_utoken_processor.self)
:** QA-flag / systemtokens (spu_token_processor.self) and usertokens (spu_utoken_processor.self)
:** [[Emulation#ps2emu|PS2 compatibility]] (mc_iso_spu_module.self , me_iso_for_ps2emu.self , sv_iso_for_ps2emu.self)
:** PS2 compatibility (mc_iso_spu_module.self , me_iso_for_ps2emu.self , sv_iso_for_ps2emu.self)
:** Getting [[Per_Console_Keys#per_console_root_key_1_.2F_EID_root_key|per_console_root_key_1 / EID_root_key]] on 3.56+/slim3K (lv1.self , aim_spu_module.self)
:** Getting perconsolekey1/eidkey on 3.56+/slim3K (lv1.self , aim_spu_module.self)
:** [[Dev_Tools#SceTool|Backsigning]] [http://pastie.org/4369367 applications] for <=3.55 and patch sys_proc_param_version (appldr.self , lv2_kernel.self)
:** Backsigning applications for 3.55 and below (appldr.self)
:Q: So does this mean a future release would be sooner?
:Q: So does this mean a future release would be sooner?
:A: Only God knows ;) But it can also be that because of the above, it would become meaningless/surpassed by better progress. So lets all hope for the best :)
:A: Only God knows ;) But it can also be that because of the above, it would become meaningless/surpassed by better progress. So lets all hope for the best :)
==== lv0 key Update ====
<div style="border-width: 1px; border-style:dashed; border-color:#000000; padding: 10px; background-color:#FFFFFF; color:#000000; ">Since the LV0 keys have now been leaked, I believe I can now share this info with you, to help out those who are trying to build their own 4.x CFW :
The NPDRM ECDSA signature in the SELF footer is checked by lv2. It first asks appldr to tell it whether or not the signature is to be checked, and appldr will only set the flag if the SELF is a NPDRM with key revision from 3.56+ (the ones without private keys). This means that the SELF files signed with the new 3.56+ keys still don't have their ecdsa checked (probably to speed up file loading).
If appldr says the ecdsa signature must be checked, then lv2 will verify it itself, and return an error if it's not correct.<br />
There are many ways to patch this check out.
# Patch out the check for the key revision in appldr
# Patch out the "set flag to 1" in appldr if the key revision is < 0xB
# Patch out the code in lv2 that stores the result from appldr
# Patch out the actual sigcheck function from lv2.
# Ignore the result of the ecdsa from lv2.
Here is one of the patches (the 4th one, patching out the check function from lv2) :<br />
In memory 0x800000000005A2A8, which corresponds to offset 0x6a2a8 in lv2_kernel.elf, replace :<br />
  e9 22 99 90 7c 08 02 a6
With :
  38 60 00 00 4e 80 00 20
This is for the 4.21 kernel (that was the latest one when I investigated this), I will leave it as an exercise to the reader to find the right offsets for the 4.25 and upcoming 4.30 kernel files.
And here's another bit of info... in 4.21 lv2, at memory address 0x800000000005AA98 (you figure out the file offset yourself), that's where lv2 loads the 'check_signature_flag' result from appldr, so if you prefer implementing method 3 above, just replace the 'ld %r0, flag_result_from_appldr' by 'ld %r0, 0' and you got another method of patching it out. Either solutions should work just the same though.
Enjoy homebrew back on 4.x CFW....
p.s: Thanks to flatz and glu0n who helped reversing this bit of info.</div>
https://twitter.com/KaKaRoToKS/status/260742786972798977
===== MFW Builder related patches =====
https://github.com/cfwprpht/mfw/blob/master/tasks/patch_cos.tcl


=== The Road beyond... ===
=== The Road beyond... ===
Line 165: Line 137:


<!--// No, don't expect any leaks - not even hidden :P //-->
<!--// No, don't expect any leaks - not even hidden :P //-->
==== What is forever missing? ====
* 3.56 and higher private keys
= Final Release =
'''source:''' http://kakaroto.homelinux.net/2014/12/ps3xport-released/
<div style="border-width: 1px; border-style:dashed; border-color:#000000; padding: 10px; background-color:#FFFFFF; color:#000000; ">
Ps3xport released!
On December 23, 2014, in Development, PS3, by kakaroto
Hello everyone!
It’s been quite a long time and I’m very happy about that :p
Let’s do the boring part first! This is my final release for the scene, I am not “coming back” or anything like that, so don’t get your hopes up, but I needed to release this so I’d be officially done. I have never actually announced that I’m leaving the scene but everyone figured it out. It wasn’t originally done intentionally actually, but life caught up with me, work, family, lack of time, etc.. so I had little time to work on the ps3. Also, my motivation was mostly gone due to not finding anything interesting anymore, a lot of drama and I’m not a huge fan of all the attention this all brings. I got into the scene because I was curious and I wanted to learn, and I have to say I’ve learned a lot of things these past years and it was an incredible journey, but as I had lack of time and started breathing, I realized that I’ve had enough of it so I left and I am very happy with that decision because you have absolutely no idea how much of a time drain and headache this was :p
Anyways, there was one thing I did just before I left, but I never got to release it, but today is your lucky day as it’s release O’clock where I am!. This release is a way to say Merry Christmas, Happy Holidays, etc.. to everyone, and a way for me to also say “I’m done for good, I don’t have anything left for you in a drawer somewhere” :). I’ve wanted to release this for a while now, and I even made a poll on ps3hax back in March 2012 asking people if I should (looks like ps3hax is down right now so here’s the google cache version) and the general response was not to release it until it can be useful (when an npdrm workaround is found) with some people saying to release if nothing new happens in the scene.. and I think I’ve waited long enough now to know nothing new on that front will happen.
So.. since I’ve announced the release, I’ve seen a lot of speculation about what it is and what it could be.. a lot of people seem to think (or mostly, want/hope for) a downgrade method, unfortunately that’s not the case. I’ve seen some ridiculous suggestions too, like someone asking if it’s a way to run PS4 and Xbox One games on PS3.. I’m sorry to say, that’s not it either :p As I’ve said in a tweet shortly after, this is nothing groundbreaking, this is code that hasn’t been touched in 3 years, so it’s already 3 years old, but I think it’s still something that can be very useful to the community.
So here it is, I’m introducing to you : PS3xport! I’ve uploaded it to my github account here : https://github.com/kakaroto/ps3xport
What does it do? Well, it’s basically a tool for manipulating the PS3 backup data. When I say “PS3 backup”, I’m not talking about a “backup” of a game, no.. I’m talking about the full PS3 hard drive backup that you can do by going to “System Settings->Backup Utility” on your XMB. That creates an encrypted directory on your FAT32 hard drive which allows you to format your PS3 and then Restore it just like it was before. I’ve reverse engineered the file format and encryption and PS3xport allows you to create new backup data from scratch, or dump existing ones, or delete specific files from a backup or do a whole lot of other things to your backup folders. This gives you total control over your /dev_hdd0 and /dev_flash2 filesystems, which will let you install homebrew on any console, even if it’s the latest OFW version. Unfortunately, just like it was 3 years ago, you wouldn’t be able to run those homebrew apps you install due to the NPDRM ECDSA signature missing. If you have your [[IDPS]] though for example, it could let you restore a backup from one PS3 to another PS3 without losing any of your data in the transfer.
So.. what’s this about “your [[IDPS]]”? yes, the backup has two sets of files, some can be decrypted right away and some can’t because they are encrypted with your IDPS (your unique ps3 device id) which is why they can’t be restored on a different ps3. If you have a CFW, you can easily get your [[IDPS]] (I’ve written [https://github.com/kakaroto/get_idp a small tool to do that, released on github], but apparently MM and Webman will also give you that information) and that will give you total control over your backup data as you would be able to decrypt and reencrypt it. If you have OFW and can’t get your [[IDPS]], then you will not be able to dump/decode all the files from your backup, but you will still be able to create a backup that can be restored on your PS3 with no limitations (this means for example that you can restore a backup from a CFW into an OFW without any issues). I was told however that someone can get [[IDPS]] from OFW consoles and in light of this release, they might [[IDPS#idpstealer|release their method]] soon, I can’t say more than that though, but be patient and good things come to those who wait :)
So my release is in two parts. First, the documentation of the file format was added to [[Archive.dat]] so any developer can understand how the backup archive files are created and can create their own tools. Reverse engineering that format took months of work and I won’t go into too much details about what had to be done to figure out the format but it was an incredibly long and difficult task to do that I had a lot of fun in doing. The second part of the release is of course the release of [https://github.com/kakaroto/ps3xport the ps3xport tool]. The tool is quite powerful and you can do a lot of things with it, but it’s a command line only tool and I honestly just tested it on Linux, it’s not really my job at this point to make a windows build, or make a GUI around it, etc.. but I’m sure it won’t be long before others in the scene pick it up and make a nice GUI for it and release windows binaries. I’ve written [https://github.com/kakaroto/ps3xport/blob/master/README.md a nice README file] so everyone can understand how the tool works and what it can do. I remember though that 3 years ago just before I stopped working on it, I wanted to add a “AddPKG” command to it which would just ‘install’ a pkg into the backup data automatically, unfortunately, I never got to do it, but it should be easy to do. While I’m at it, I’m also releasing [https://github.com/kakaroto/pkgtool a pkg extraction tool] which I found in an old directory (cool thing is the -p option in it, try it…) as well which is a PKG extraction tool that uses the PagedFile mechanism (see below) to allow for very fast pkg file access with very little memory usage even for huge pkg files, any dev can probably mix those two together to add the AddPKG feature to ps3xport.
On the software front, [https://github.com/kakaroto/ps3xport/blob/master/ps3xport.c ps3xport.c] will parse the commands then use the archive_* API which is in [https://github.com/kakaroto/ps3xport/blob/master/archive.c archive.c]. That will contain all the functions needed to manipulate the archive files. It uses a ChainedList which is my rudimentary implementation of a GList-like ordered list and the archive API also uses PagedFile objects which are pretty cool. PagedFiles are a wrapper around a file which allows you to read/write to a file using pages (I set it to 64KB per page I think) so it limits the hard drive access. The cool thing about it is that it has encryption and hashing built in, so you can just set the encryption key or ask for the file to be hashed, and whenever you read/write, the encryption will be done transparently, and the coolest thing about it is that you can actually seek in the encrypted file and it will still work (it recalculates the required IV whenever you seek). The encryption there works on the stream, so you don’t need to write blocks of 16 bytes every time (thanks to the paging of the data) and it has a cool ‘splice’ method which allows you to copy data from one PagedFile to another easily, so you could in theory re-encrypt a file using a different key using 5 function calls (open *2, set_key*2, splice).
That’s about it.
I’m really happy about this release, and I want to say Merry Christmas/Happy New Year to everyone, and of course..
So long, and thanks for all the fish!</div>
{{Reverse engineering}}<noinclude>[[Category:Main]]</noinclude>
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps3/KaKaRoTo_Kind_of_´Jailbreak´"