After using the XorHack for a while I realised it was missing some things so I decided it was time for an update. New syscalls have been added to give finer control over data access, now providing 8, 16, 32 and 64 bit reads and writes. Also some new ioctls were added to provide additional useful functions for your userland code. Lastly new userland applications were added which now give the ability to read, write and execute memory from the command line 
Hypervisor Exploit Changes
At the innermost level some more syscalls are now added to the hypervisor when initially exploiting the PS3. These use different syscall numbers to the previous exploit code in order to group them all together rather than scattering them all over the place. This should make keeping track of them easier. There are now nine syscalls added to the PS3 upon exploiting. These are added as syscalls 32 to 40 inclusive. Previously syscalls 16 and 20 were used for 64bit peek and 64bit poke, but these syscalls are no longer setup.
Kernel Module Changes
In the middle level I added interfacing support to the nine new syscalls as well as a new ioctl to let user apps convert lpar addresses to real addresses and yet another to let user apps perform an ioremap on memory. I also fixed the syscall that executes code via a real memory address since previously it wasn’t saving the link register, which is not good.. Lastly I tracked down the problem I was having with calling ioctls from userland code. It turns out there are issues sending ioctls to a 64bit kernel from 32bit userland code. When you send the ioctl from your userland code there is a hidden function that attempts to “make it compatible” before sending it on to the kernel. This was transparently causing some ioctls to not make it to my kernel code. Things like this are why I hate linux hehe. It looked like fixing this was going to require a rebuild of sections of the kernel, so instead I brute force tried all ioctl numbers until I found a nice bunch that made it through ok and settled for using them instead. When sending these ioctls a handle to the XorHack device is used, so I am not too worried about them going astray and wreaking havoc.
User Library changes
Finally the on outermost level I added support for calling the new syscalls to read and write 8, 16, 32, or 64 bits at a time. In doing so I support unaligned addresses without the user having to check or worry about such things. If the address being accessed is aligned it will access it in a single syscall of the specified size. If the address is unaligned it will either use multiple syscalls or a syscall of a larger access size. I also added functions to easily check if the system has been exploited yet, to perform the lpar address to real address translation, io-remapping of addresses and to execute code at a given real address. A new header file xorhack_sc.h was added which contains translations between syscalls as they would be used in kernel mode and the userland interface. I have only done a few here, but it should be enough to follow the pattern and create translations for any other syscalls. If anyone does complete these translations, please send it to me to include in the next version of XorHack.
Sample Application Changes
As well as the above additions and changes to userland code I have added three new command line applications; ps3peek, ps3poke and ps3exec which allow reading, writing and executing of memory. The ps3peek and ps3poke tools work in a similar fashion. Both are able to perform 8bit, 16bit, 32bit and 64bit data accesses and can access multiple amounts of the data size in one call. The ps3peek tool can print data to screen as hex values and ascii characters similar to the display of a hex editor, or be printed as binary data and redirected into a file. The ps3poke tool does not print data to screen but can write data to memory from values passed on the command line or values read from a file.
Here are some examples of what these tools can be used for.
Dumping the hypervisor
This reads 0x10000000 bytes (16MB) of data starting at address zero using a data access size of 8 bytes (64bits) and prints it in binary form which gets redirected into the hvdump.bin file. Note that the 64bit access is used since it requires 8 times less syscalls to get the same amount of information as if we used the default 8bit access.
ps3peek 0 -s 0x1000000 -d 8 -b > hvdump.bin
Reading the status register for spu0
ps3peek 0x20000044024 -d 4
Loading metldr..
Scripts can be written using ps3peek, ps3poke and ps3exec and utilising files to store values between calls. By doing so many tasks can be done such as the setting of the required registers to load metldr.
Everyone loves pictures
The following is a picture taken with my dodgy G1 iPhone camera to show peek and poke in action. One day I will get a decent camera…
I wouldn’t ask for status updates, he’d tell people, plus just asking for updates gets annoying to the people who work there asses off for the PS3 community
I’m not realy a coder but if i could help in anyway i do have a fat ps3 still on 3.15 FW with x3 max jailbreak.
If i can help in anyway please let me know. I’ll try my best
@graf or any dev there
is it possible that you can share the signature of major codes in process 6 so we can identify the code easily in different dumps?
based on os ver. 3.15 of course.
this will introduce more people interested in reversing the HV dumps and then we might have more chances digging out more info from the currently available dump.
@Jack Chen
have you already extracted Process 6 from HV dump ?
@graf
nope, I trace to the process object of process 6. the process object is there (not the same address as you described in the wiki since I am using a different dump with 16MB size). and of course with the pointer of pointer to the ELF image.
other then that, I have no info regarding to the entry point of the process, and the ELF image.
I did find some string which should be referenced by process 6, but there is no direct reference to there strings, nor are any possible OPD found.
sorry I am really new to PS3 scene. I am more familiar in X86 scene, and the early MN103 MCU of 360 dvd drive. in case anyone still remember the very first video posted for 360 dvd drive hack.
@Jack Chen
Look at function at address 0x00297640 in HV dump.
And from HV proc table you will be able to get all HV procs 
Feel free to ask questions about HV, i will try to help anyone who is really intereset in HV reversing and learning new stuff about HV 
I called this function get_proc_table_entry because it returns a pointer to a HV proc. This function references the HV proc table
@Jack Chen
The HV procs are not continuous in HV dump, you have first to extract/dump them from HV dump, every page of a proc have to be extracted from HV dump before you will be able to see any string refrences
HV procs use virtual address space, so they are only continuous within one page 
@graf
thanks a lot for your hint.
I was so lazy so I used a trick for the string search via bin search function in the IDA. so I could locate the strings quickly. this trick is very helpful in windows based RE. but as you mentioned, in PPC HV, the processes are located in different pages, that’s my current problem.
from a brute force analysis by me manually, in the HV dump I got on hand, the process object 6 is at 368cf0. I trace the ELF image to be at 0x357440. then I was stopped.
from the string search result. the string “_USB_DONGLE_AUTH_USB_DONGLE_” is at 0x74c188,
right before the string is encrypted master key@0x74c170,
I browsed the string section and after some time, I found a code section before the string section, and a possible OPD entry table after the string section. the possible OPD table starts from 0x 74E6D0, the offset in the entries are very interesting, codes shall be located in virtual address base 0x80000000, and the RTOC bsae shall be located as 0xC00145E8. I could map the code offset to the code section I found before the encrypted master key, but for the rtoc, I really don’t have any idea.
I will try to follow your hint later. now it’s time to get some sleep.
maybe some day we could setup a IDC script to extract these sections and identify every key code we need.
currently my goal is to locate the decrypt master code, try to extract the code, and see if it is possible to execute the part of code in a virtual machine, I found some info regarding to IBM Power PC simulator, but not really look into it yet. but if the process 6 used SPU in the master key decryption, then we’re out of luck.
btw, Mathieh (?not sure of my spelling) mentioned that no matter what kind of reboot we used, the PS3 will always reinitiate the LV1 memory, so it’s impossible to trigger the decryptmaster under gameOS and reboot to Linux to get the key in LV1 memory.
if that was true, then the only way we could do is to try to trigger the decrypt master function directly under linux and then exploit HV1. or we may do it in different way, use a PSGroove payload to trigger the decryptmaster, then try to exploit the LV1 under gameOS. I am not sure whether the HTAB exploit could be done under game OS or not, but since you can access LV1 with the code in payload, there shouldn’t be too much trouble I guess. I will take a look at it, too.
damn, too much to learn…. for a 40- aged man, it’s little bit tough.
thanks a lot.
By the way graf_chokolo, I did a little test here, I dumped the syscon eeprom from a 3.40 ps3 (retail), then updated it to 3.41 and dumped again, both dumps were perfectly identical so either hashes were not at the offsets I dumped (although I seriously believe I dumped the whole thing) or there are no hashes stored in the syscon’s eeprom. Anyway, looks like another riddle on our hands 😛
Guys, i know you are waiting for the USB Dongle Master Key from me
I have got now 2 fat PS3 with HV 3.15 but unfortunately no SX28 development board yet to exploit it 
But i was not idle and the last and this week i was working on reversing of self decryption. And now i’m able to decrypt SELFs and SPRXs on my exploited GameOS by using HV calls only and no GameOS functions at all
I reversed the interface to appldr which decrypts SELFs on GameOS 3.41.
So you wont’ get bored until i get the USB Dongle Master Key, i will make my findings and my source code public very soon and you will be able to decrypt your favourite games and programs by yourself
Let the fun begin, guys 
How about 3.50 selfs?
p.s. join ps3lv2 in mirc plx. :]
Here is a “small” teaser of decrypted Lv2diag.self from service JIG
http://pastie.org/1333833
Nice, try to do the same with manu_info isolated module from 3.50 PUP, that is what really interesting, cant wait to put it in my IDA.
@inf1
You cannot decrypt isolated SPUs with appldr, i think, because they are decrypted by isoldr.
I’m able to decrypt hdd_copy.self from 3.42 but not from 3.50
@graf
Wow, amazing progress and I’ll be watching your github for a release. Good work.
otheros.self decrypted
Pingback: Is this the end of jailbreak scene? - Page 7 - PSX PS2 PS3 Scene Modchip & Jailbreak Community
3.50 probably use other keys to decrypt selfs, well, you can probably do something on exploited 3.15.
Hey guys, can someone provide me with a game SELF because i don’t have any games for PS3
So i could test my code with game SELFs also. Just upload it somewhere and send me the link per email. But please don’t ask me to decrypt PS3 games for 
I don’t want any legal problems with $ONY 
Check your email.
Pingback: graf_chockolo has reversed interface to appldr, decrypting SELF/SPRX from GameOS! - PSX PS2 PS3 Scene Modchip & Jailbreak Community
And please only games that run on firmware upto 3.42
Dont send him GT5 self, it wont work without 3.50 keys…
graf, when you post manual how to decrypt self’s, please dont forget to update wiki how appldr works inside.
@graf_chokolo:
Are you able to decrypt lv2_kernel.self and the 3 ps2 emulators with your decryption code or those 3 are different?
Congratulations on your findings graf_chokolo !
P.S. Can you get to the irc chan when you have some free time ? I have some unrelated questions for you xD
@Chotto loaders use different key sets, lv2_kernel.self can only be decrypted by lv2ldr, lv1.self by lv1ldr (although you can only load this one once because of the ATA init), application selfs by appldr, isolated modules by isoldr and so on. Those are all decrypted and loaded by metldr.
Lv0 is more or less of an exception as it’s decrypted directly by the bootloader.
Those who have 3.50, we be able to upload copies?
My English is bad sorry
hi
hello graf_chokolo do you work for free downgrade ? downgrade to running on clones I mean ?
@graf
now i know why i got stocked
previously i followed the info of your HV RE page on ps3 wiki, the member variables of process object is described as below:
offset 0x10 – pointer to AddressSpace object
offset 0x30 – pointer to first PThread object of process
offset 0x38 – array of signal handlers (192 * 8 bytes)
i try to trace to the addressspace object, but only unreasonable data there
then i googled and found your comment on ps3news web site, describing that offset 0x18 of process objevt member variable is the address protection domain object we should trace, and i tried it and finally i got the protect sections linked. and the code and data i found around the encrypted master key are indeed belong to process 6, same as the opd table. and the effective address and real address do match the one being used in opd table.
it would be helpful if you could update the description of the member variables of process object in the wiki, that will help new comers like me a lot. btw, i found some description on the wiki might not be. orrect, how should i report this to you? via email or what?
@Mathieulh
Will be back on channel today in the evening
@jack chen
Feel free to report anything to me per email
Holy shit, guys !!!
I can see now every syscall used by Lv2diag.self 
Now we can look for exploits in SELFs
Hi, all,
I want to decrypt some 3.41 sprx and try patch it. I try to port graf’s awesome payload to my exploit dongle based on at90usb162, but wherever for 3.41 or 3.15, it is look like not work. When I run sendfile, I get some time out errors, and wireshark can not capture any packet from ps3.
Could someone can help me? or how to use graf’s payload?
Lv2diag.self uses services provided by HV processes a lot, especially Update Manager
Graf, quick question.
HMACSHA512 hSha512 = new HMACSHA512();
ret = hSha512.ComputeHash(<[byteArray]{ 0x00, 0x00, 0xFF, 0x00, 0x2E, 0x02, 0x02, 0xAA });
if(ret == encryptedMasterKey) return withSuccess;
Would the above pseudo code be correct?
Only reason I'm asking is because I've found a sequence of byte arrays inside a few dumps I've made and they seem like they could be keys.
They supposed keys I'm talking about are all 20 bytes in length.
I'm assuming we're encrypting the response code to get the hash matching?
First line was meant to be
HMACSHA512 hSha512 = new HMACSHA512([key to find]);
@graf_chokolo
When you make progress, could you also say things in simpler words, for newbs?
Something like:
there are:
metldr
lv1ldr
lv2ldr <= this one was pwnd
well done graf why dont you have a paypal account??we could donate money for your hard work
a dollars int much for a downgrader
but graf i say this there is always soem clever c.nt to outsmart the big boys
who do u think will win the sony smart ass or graf my money is on graf next year
@medi01 I don’t think blog is made with newbes in mind 😉
@X-Copy_III
I’m sure it’s not. However it makes into news headlines.
Having such explanations would allow semi-newbs to explain ultra-newbs WTF this is about. Otherwise we get Angry posts from Mathie (Jesus, I don’t know how to spell his nick) bashing semi-newbs for spreading BS. 😉
http://psx-scene.com/forums/607089-post40.html
@rockyu
Describe the problem exactly. What doesn’t work and what are you trying to do ?
First step is to program PSGroove with bootstrap code. Managed to do this ?
hello do someone work for downgrade? I mean do someone try to do downgrade running on clonings ?
I’ll shorten my question to make it easier to answer. 😀
What does the PS3 expect to receive from the JIG in terms of data?
I’ve read through the PSGrade.c file, but some of the responses “seem” like they’re on the wrong offset. How-ever it’s early here and I am sleepy lol.
If anyone could elaborate, I would be grateful.
graf you may wanna check the ps3news forum topic about your progress, someone is offering a free sx28 development board for you.
@graf_chokolo
lol, thanks for your reply! I compiled the bootstrap project and get bootstrap.h, then put that header file to my psgroove project, modified my port1_config_descriptor like this
const u8 port1_config_descriptor[] = {
0x09, 0x02, 0x12, 0x00, 0x01, 0x00, 0x00, 0x80, 0xfa, 0x09, 0x04, 0x00, 0x00, 0x00, 0xfe, 0x01,
0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfa, 0xce, 0xb0, 0x03, 0xaa, 0xbb, 0xcc, 0xdd,
# include ootstrap.h\n};
it is just for 3.41. I also modify PL3 project for 3.15 that simply replace default_payload with (# include ootstrap.h).
I traced the exploit process, but found the process is stop at p3_disconnected and waiting p5_wait_disconnected forever. I try to run sendfile and get timeout informations like this
sending packet #1 of #2
timeout ack for packet #1
sending packet #1 of #2
timeout ack for packet #1
sending packet #1 of #2
timeout ack for packet #1
sending packet #1 of #2
timeout ack for packet #1
no ack received for packet #1
then sendfile exit. What is my mistake? Thanks!
Also thanks for your great work!
@rockyu
Did you create bootstrap.h by applying bin2hex to bootstrap.bin ?
Same problem here as rockyu. btw it was me emailing you about 64-bit problem for pcap2bin.
the payload was the one u sent. so payload header, the payload and padding was ok.
Pingback: SELF/SPRX Decryption via 3.41 GameOS | PS3Hax Network
@graf_chokolo
yes, i use bin2hex to generate bootstrap.h
Pingback: SELF/SPRX Decryption via 3.41 GameOS | PS3Hax Network
@rockyu
You have also to pad the descriptor array to the original size of PSGroove descriptor with some dummy values after include statement. Did you do this ?