To quote from his comment on xorloser's blog, linked above:
I just release my lv2 kernel decrypter You need metldr, lv2ldr, RL_FOR_PROGRAM.img and lv2_kernel.self. You have first to dump your metldr from FLASH memory. lv2ldr you will find also in your FLASH memory or in decrypted CORE_OS_PACKAGE.pkg from PUP files.
RL_FOR_PROGRAM.img is a revoke list for programs and can be also found in PUP files. lv2_kernel.self is on your FLASH memory or in decrypted CORE_OS_PACKAGE.pkg.
First i send all files to PS3 and store them in memory. After that i load metldr in isolation mode and pass it the addr e ss of lv2ldr. The code is very low level and many things are done by directly manipulating SPU registers
If you have any questions or problems then feel free to contact me or ask here. I will try to help you. I will try to document my findings on my homepage
I also uploaded a code which can communicate with USB Dongle AUthenticator by using Dispatcher Manager without using any GameOS functions It’s exactly what GameOS does, just low level
Have fun guys
lv2_kernel.self from 1.10 firmware decrypted
Guys, just to make sure that you know LV2 decrypter is also PS2 emu decrypter, just change LPAR auth id in code PS2 emu is like GameOS, it’s LV2 and is decrypted by lv2ldr
Just decrypted vsh.self from 1.10 firmware Just like old good days
I decrypted software_update_plugin.sprx but didn’t have time to reverse it yet
Physical/Virtual memory address of an isolation module that should be loaded by metldr is written into SPU register SPU_In_Mbox. The SPU register SPU_In_Mbox is 32bit, so 64bit memory address is written in 2 steps.
MFC relocation is turned off by clearing R-bit in SPU register MFC_SR1. By doing this, HV enables real address mode for MFC of SPU.
On GameOS, it also works with relocation on. You just have to initialize SLB of SPU and insert valid SLB entries.
Physical/Virtual memory address of metldr is written to SPU registers Sig_Notify1 and Sig_Notify2
Isolation load request is enabled by writing SPU register SPU_PrivCntl
Isolation load request is made by writing value 0x3 into SPU register SPU_RunCntl
SPE_load_request_metldr - 0x002B00A4 (3.15)
lv2ldr is used to decrypt lv2_kernel.self
syscalls 0x10042 and 0x1004A use lv2ldr
syscall 0x10042 is used by HV Process 3 during LV2 LPAR construction
syscall 0x1004A uses different parameters as syscall 0x10042
SPE_load_request_lv2ldr_1 - 0x002AE82C (3.15)
SPE_load_request_lv2ldr_2 - 0x002AE8D8 (3.15)
64 bit memory address of lv2ldr is written into 32 bit SPU register SPU_In_Mbox
metldr is loaded
Decrypting SELFs with appldr and lv1_undocumented_function_99
lv1_undocumented_function_99 loads and prepares appldr for SELF decryption.
When appldr is ready to decrypt data, it sends a message via mailbox.
The address and the size of the encrypted data is passed to appldr via a shared memory.
Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!
Well, I didn't expect something like that, and actually even after reading this news item I still don't, but if it were true, well.
First of all: Gigabit Ethernet would be the fastest interface the PS3 has, but it has some other purpose. However - Be it USB or Ethernet, the question that remains would be: What could be calculated on an external device connected via a slow interface? Certainly: Only calculations that take a lot of processing power, but only produce a small amount of data for the software running on the system.
IMHO swapping graphics calculations out to an external device is quite out of question. What 'might' be done is something like AI calculations or stuff like that, but then again: Since when did the Cell processor become the bottleneck of the PS3? As far as I can tell the components limiting the gaming experience on the PS3 are the graphics chip and the main memory capacity. Both require vast transfer rates and extremely low latencies, which can not possibly be reached via the external interfaces available.
The Atari Jaguar wasn't up to much in the first place. How the SegaCD, Sega32X failed was the games were basically the same as the cartridge (Maybe a few new sequences). If sony did release the games that were a lot better using the addon, it may actually sell. This depends on the price of the add on though.
Well seeing how well Add-on's did in the past with Atari Jaguar CD,SegaCD,Sega32X etc etc... O.. Wait they all sucked and failed hard core.
Doing a Add-on for the PS3 would kill off Sony we done waited over the 5 year system life we deserve a NEW system not a Add-on, As it stands right now most people would be happy with the PS3 for the next 4-5 more years So i think they can come up with a PS4 that's under 500$ by then, Hell if it's a big improvement i would pay 600$ for a PS4.