PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

Home PS4 News - Latest PlayStation 4 and PS3 News

July 13, 2010 // 3:05 pm - Today George Hotz aka GeoHot has announced he is retiring from Sony PS3 and Apple iPhone hacking, citing that the demand for updates from end-users will never stop.

In his exit from the PS3 scene, GeoHot left many legitimate PlayStation 3 users without OtherOS and without the promised 3.21OO PS3 Custom Firmware.

The good news? Others whom GeoHot shared the PS3 METLDR info and LV2 dump with are currently using his work to continue hacking the PS3 console, with rumors from IRC (for what those are worth LOL) indicating a public "end-user" PS3 hack may arrive before September 2010 from their camp.

Unfortunately though, just like the past Dark_AleX and "M33" PSP releases, an incoming PS3 hack will probably be from a fictitious group and won't include anything useful to PS3 Devs such as dumps, reversals, sourcecode, etc.

Hopefully once a hole that Sony can't block is public, other PlayStation 3 Devs will begin working on the PS3 though... and sharing all the juicy the technical details along the way for others who wish to learn.

This will help ensure the PS3 scene won't fall victim to the hypocritical and ridiculous "anti-piracy, users deserve nothing" attitude that began the downfall and led to the fate of the current PSP scene.

To quote: His PS3 username, Twitter account, and blog are all now shut down. His last tweet said, "it was a cool ride, and i've learned a lot about a lot. perhaps one of these days i'll do a more formal goodbye."

Along with that post, he wrote in his blog explaining his reasons for retiring from the scene. He says that he "didn't fully realize most of the current scene don't care unless they are getting something," but now he does.

He then continued a bit more in his post with the following: "The real reason behind no release isn't technical. It's just that it will never stop, after blackra1n, people demand unlock, after blacksn0w, people demand untethered. I miss the days when jailbreaking and unlocking were difficult, it attracted a much higher caliber crowd."

GeoHot Retires from PS3 and iPhone Hacking, Others to Lead On

PlayStation Follow us on Twitter, Facebook and join us at our new site WWW.PSXHAX.COM!

#80 - PS4 News - August 9, 2010 // 10:02 pm
PS4 News's Avatar
Another update - graf_chokolo says:
I was analyzing the memory dump of the hypervisor and found some interesting stuff.

hvcall table: 0x003601E4
lv1_invalid_hvcall: 0x002BF1E4
lv1_get_logical_partition_id: 0x002E0984
system_call_int (aka hvcall): 0x00000c00

It seems that the hypervisor saves some important context information in register HSPRG0

Found strlen function. Address: 0x002AFCC4

It is used a lot in the code, i think to output strings on console

i also found some strange code that traps to system call interrupt with system call number 0x100c0 ???
location: 0072E738
there is a lot of system calls like that
found the code that prints "BDVD: Drive Not ready Timeout\n" :-)
location: 00263D38

i think console output is memory mapped just as everything else :-) code 002AFF44: i think console is mapped near 0x0000024000FFF310

PCI Express use 1GB MMIO area.(sys.lv1.large_pciex is 1.)
DDR : 0x2000_0000 - 0x2FFF_FFFF 256MB
PCI : 0x3000_0000 - 0x3FFF_FFFF 256MB
PCI Ex : 0x4000_0000 - 0x7FFF_FFFF 1GB

i also found some kind of spinlock implementation
CELL's PPE support symmetrical multi threading with 2 threads, so you need some kind of locking, spinlocks are busy waiting locks
look at opcodes: cctpl, cctpm, lwarx and stwcx
also i found a lot of places with eieio opcode, it's a sign for some device access code, hehe :-)

It’s pretty simple if you know PowerPC assembler

Code snippet:

ROM:002AFCC4 mr %r9, %r3
ROM:002AFCC8 li %r3, 0
ROM:002AFCCC lbz %r0, 0(%r9)
ROM:002AFCD0 cmpwi cr7, %r0, 0
ROM:002AFCD4 beqlr cr7
ROM:002AFCD8 loc_2AFCD8:
ROM:002AFCD8 addi %r3, %r3, 1
ROM:002AFCDC lbzx %r0, %r3, %r9
ROM:002AFCE0 cmpwi cr7, %r0, 0
ROM:002AFCE4 bne cr7, loc_2AFCD8
ROM:002AFCE8 blr


r3 – address of string
r3 – string length

And i found a lot of places where this function is used to obtain the length of a string and print it on console, like error messages.

For example this peace of code prints “new ATA_Command ERROR\n”:

ROM:0026075C ld %r4, -0x5a98(%rtoc)
ROM:00260760 std %r9, 0580(%r30)
ROM:00260764 bl print_str

%rtoc – pointer to TOC = 0x0000000034cc48
-0x5a98(%rtoc) = 000000000315528 = pointer to “new ATA_Command ERROR\n”

And i think i found console output functions which prints strings or numbers.

print_str: 00266ED8
print_number: 00268E44
print_console: 002AFEF8
printf: 00290FFC

I think i just found memset and memcpy functions:

memset: 002AFEB8
memcpy: 002AFEC8

They are optimzed and use dcbz instruction, hehe

Found some sort of debug level variable which controls debug messages output. If it is > 0 then debug messages are printed, hehe

TOC of variable: 00347310
Address of variable: 0035663C

It’s 0 in the dump i’m analyzing

Found a new function which parses and returns a loader parameter, hehe
Location: 002B1318

For example parameter “sys.lv1console.mode”
Location: 002B0A2C

Loader parameters are stored at 00002C10.

What about the flags at 00002100?

00002108 : “allow bypass of HV for unrestricted memory r/w access”
00002120 : “disable decryption SPU”
00002164 : “set console type : 00000001 = retail & 00000004 = test”
0000217c : “allow play of unlicensed game”
000021f4 : “magically makes you an elite hacker”

Found some kind of kernel memory allocator: 002B8AE8
Used in alot of places to allocate memory, hehe

Found functions strcpy and strchr.
strncpy: 0028FFFC
strnchr: 0029DDD4

They are used in file system module.

Figured out what hypervisor saves in HSPRG0, hehe :-)
It is a key structure and is accessed in every hv call.
I know now where it is in the dump, hehe

What Mathieulh believes to be the PS3 Disc Authentication Procedure:
Here is how I believe (after a bit of investigation) the playstation 3 discs' authentication procedure is being held:

Whenever you insert a disc (bluray one that is) the ps3 drive will look at a special area of the disc called the Pic Zone (the BD ROM Mark is actually used in movie discs but not in game unlike what I first thought).

The PIC Zone which stands for Permanent Information & Control data Zone contains informations/data related to the disc's authentication which is done by the playstation 3 bluray drive. This area cannot easily be dumped (you'd pretty much need a bluray drive with a hacked firmware) and of course that specific area cannot be burned on any kind of discs or with any kind of burners commercially available.

There is no absolute certainty to what data the PIC zone actually contains, I initially thought that Sony would use a public/private cryptography cypher to authenticate the discs but that is quite unlikely considering the limited resources of the drive controller. There isn't any kind of hard cryptographic layer on the discs as I first expected, so the security on the discs themselves is much less invasive as I initially thought. Yet the fact that the PIC zone can't be rewitten without any kind of special equipment (basically a bluray discs factory) does its job well when it comes to preventing backups.

The authentication procedure itself is done through the use of a per bluray drive key pair, one being located on the drive controller itself while the other is stored encrypted in the playstation 3's EID area located on NAND. This key is also used while updating the drive which firmware's will be physically re-encrypted using that very same key and stored that way. As such you cannot swap a drive controller board from one ps3 to another, at least on earlier "fat" models.

I have no idea if the drives are still paired with unique keys on the newer "slim" systems, though I do not know why it would be done another way. This also means that physically dumping the drive's firmware would lead nowhere with it being stored in an encrypted form. The only way to get a plain version of it would be to dump the drive controller's ram at runtime. Beside although I am not entirely sure about this, it is very unlikely that a command exists to read the firmware from the drive, should it exist, the dumped binary would still be encrypted, thus connecting the drive to a computer (the ps3 slim bluray drive uses a regular SATA or PATA bus depending on the model) literally leads nowhere..

Finally once the authentication procedure is done, there is another protection which happens to be a per sector software cryptographic layer, which I have the algorithm for (but which I can't share because I wasn't the one that initially reversed it) that cryptographic layer is the very same used on playstation 3 master discs as on retail ones with the exception of the key being used, masterdiscs are identified through their special masterdisc sectors locted at offset 0x7000 (sector 14) on the disc. The encryption itself is done in sector ranges rather than files, where the key for each sector is defined by the address of the said sector in correlation with an initial static key, on retail discs, there is a per disc key located at offset 0x800 on the disc with a header composed of "Playstation3" and the discs' title id such as "PlayStation3 BCES-00141" I assume that this key is in encrypted format and likely decrypted through lv2 by appldr.

The software cryptographic layer is done in such way that the disc sectors will be transparently decrypted so long as you are running a game or a playstation 3 application, this explains how easy it is to dump a disc's content whenever you can run playstation3 code on top of lv2.

The EBOOT.BIN as well as other self and sprx binaries themselves aren't tied to the disc's encryption, however their metadata may contain specific flags (in fact the ones on game discs always do) that will prevent them from being loaded from anywhere other than an authenticated disc (masterdiscs != authenticated discs) This would explain why someone on a debug console for instance can't just grab the games' binaries, put them on a masterdisc and hope for the game to just play. Other flags are being involved such as a "no debug" flag that will pretty much prevent you from loading your binary into sony's debugger.

Because the binaries on the discs still have to be signed as they are verified and decrypted by appldr, in the event that you would somewhat trick the drive into thinking that your disc is a genuine playstation 3 disc, you could still not have your own fself ("fake" secure elf, complied with Sony's sdk) in there and get it to run, thus this would never lead to homebrews no matter what some clueless people may claim about it.

Game binaries still have to run on top of lv2, not to mention that they actually need to be decrypted by appldr (though the last part can be done from otheros)

It'd be easier to decrypt lv2, patch it and load the patched version (which would always mount your discs as authenticated ones). That's if you want backups, homebrews need much more invasive patches on retail systems, This is mostly due to the fact that appldr is the one checking the binaries' signatures which will only be returned to the xdr if the check and decryption passes.

You cannot load fself either because appldr will check your console's target id and if it doesn't match the one of a debug system (0081 or 0082) it wont return the binary to the xdr. (it will return an error instead). lv2 itself has no code to check the selfs signatures, decrypt them, deflate them or load them into memory. It would have to be added straight into the kernel should you want to run unsigned "application" code, that or you would have to exploit appldr. More than that, I wont tell.

Sony Jig Dongle Authentication by Gary Gray:
after a week of looking for a way to decrypt some parts of the public hv dump i finally managed to rebuild everything up and started reversing for so promising strings "usb_dongle_authenticator".

i've reversed all the scheme used. the official sony usb debug dongle has unique two-byte dongle_id (which can be revoked btw by the bit-field revokation list builtin to the formware) and a dongle_key. the latter could be generated with simple sha1-hmac of the dongle_id with a secret master key.

the authentication uses a classic hmac scheme and works as follows. console sends the challenge which is basically 20 bytes of random values and stores it. the usb dongle sha1-hmacs the challenge with the dongle_key and sends it to the console along with the dongle_id. console recovers dongle_key from master key and dongle_id and sha1-hmacs the stored challenge value. if the result is the same as the dongle response - authentication is passed.

a few words about the master key. it is stored in encrypted form in the ppe memory and is decrypted by crypto spu on demand. if the decryption fails - dummy master key (which is stored in raw format in memory and therefore is known) is used.

now, if the jailbreak dongle really passes the authentication it probably needs to patch the master key check to be able to work with already known dummy master key. on the other hand one might try to authenticate usb dongle and dump hv memory after that with geohot's exploit. this would probably give him the real master key since it is for some reason copied to the ppe memory.

Dump of all repository nodes from HV 3.15

[Register or Login to view code]

List of useful functions in the 3.41 LV2 kernel

Function Notes Offset in 3.41

char *strcpy(char *dest, const char *src) 0x04D2F0
int strlen(char *str) 0x04D318
int strncmp(const char *s1, const char *s2, size_t n) 0x04D344
int memcmp(void *v1, void *v2, size_t n) 0x04C454
void *memcpy(void *dest, const void *src, size_t n) 0x07C01C
void *memset(void *s, int c, size_t n) 0x04D144

Function Notes Offset in 3.41

void* snprintf(char *str, size_t size, char *format, ...) 0x04E4D8
int printf(char *format, ...) This prints to the serial debug console. 0x28A654

Function Notes Offset in 3.41

void* alloc(size_t size, int unk) unk is possibly pool? PSGroove uses 0x27. 0x062088
void dealloc(void* ptr, int unk) unk is possibly pool? Should be the same value of unk given to alloc. 0x0624C8
void process_utils::create_initial_system_process() Called to start the first userspace process, which is normally "sys_init_osd.self" but it can also launch recovery mode or update mode. 0x287D50
void Panic(int unk) This function does not return. 0x288568

PUP File Format

PUP (Playstation Update Package) files are update files for the PSP and PS3.


[Register or Login to view code]

This is then followed by a table of file entries.

File Entries

[Register or Login to view code]

Entry Filenames

[Register or Login to view code]

#79 - skullorz - August 5, 2010 // 1:23 pm
skullorz's Avatar
Left us with nothing except an old PS3 firmware. He should've finished the new one, then left, if you asked me.

Thats what I would do.

#78 - ixfor - August 5, 2010 // 2:52 am
ixfor's Avatar
he should've never "retired" ..

#77 - PS4 News - July 28, 2010 // 5:13 am
PS4 News's Avatar
Yea, the issue really is that someone else's files, specifically METLDR which is used to do the interesting stuff in recent months, won't help other Devs... so a more complete method and scripts (beyond what is already documented) would be required versus the resulting files themselves.

GeoHot briefly mentioned that in his conference HERE near the end of the second video... basically confirming it needs to be dumped on the PS3 of the person who is planning to use it.

Some more updates:
encrypted binary=008C00 and scattered above that is just a customized YDL boot loader, start analyzing at 002200 for protocol.

If you couldn't get my otheros.bld to work it's cause I packed it wrong. The binary inside works..People were saying it's fake..

I've always been interested in RISC. PS3 also has a cool instruction set and abstraction, but once you navigate it all there is nothing left

Oh yeah and interfaces not accessible to fuzzing. Just put external loading on a low privilege LPAR, it at least protects assets

2XSPE+ROM+Unencrypted SPU loader+encrypted DMA=uncrackable PS3.

Both level of disk encryption are handled by FW routines, so jumping to code that expects decrypted data segfaults or whatever

There are a lot of header and data types that look like they dictate allocation and some loader, signature has it's owm section

You can script PUP via headers in a distributed binary, and you don't even need to decrypt most stuff inside

The update package keys as I said though are in spu_pkg_verifier.self, good luck dumping these xD

It's all mapped and unpacked in memory, you eventually hit metadata and more binaries. Binary structures have 'envelopes'

What do you call key for pup? The pup is just a container hashed with hmac-sha1 the key is in software_update_plugin.sprx

I know that part, an elf structure inside has intermediate encryption data in a section, and uses the two sdk calls to unpack.

Good luck to whoever decides to do the emulation for backups..simple patching isn't possible, it'll take a lot of RCE and programming.

ROM only supplements the LS when you use mailboxes in that 600KB, it's just decrypted buffer. I'm done with PS3.

I found the PS3 interesting and finally had access to some today. There is a dword at base of XDR use by ROM to communicate with PPU.

oh nevermind..key for pup is pushed in a allocation by a stub inside a binary. It's like it unpacks in layers.

It'd be funny if PKI repacking couldn't be done, and people had to rely on a tethered memory patcher. I see the code for pup, but no keys...

I see why geohot lost interest. The rest isn't interesting. Backups can be done by emulation, the PKI for repacking could be hard

x360 had page protection and memory checksums..PS3 helps attackers by providing easy to use decryption protocols the rest is easy just RCE..

CECH-2501A can be glitched and code can be ran by under-clocking with a cheap FPGA. GameOS uses same abstraction as OtherOS too.

ROM creates 600KB in XDR after SPU LS passes a crypto check and uses a isolated protocol. It can't be read by any PPU privilege state though

#76 - xUb3rn00dlEx - July 28, 2010 // 1:39 am
xUb3rn00dlEx's Avatar
Just a quick question here. We no doubt have very talented hackers in our community. Why couldn't we say, oh I don't know, "borrow" the files that geo and his comrades have? You know, the old school "I'm going to use my PC to see what is on your PC because I need a few things before I get going" technique? Or has that become immensely hard? (And the illegality of it has become so technical it's just not worth it?)

#75 - PS4 News - July 28, 2010 // 1:23 am
PS4 News's Avatar
I gave jimmidy's OtherOS BLD file a try tonight on my 1.10 PS3, and it doesn't appear to be a gzip file so I received the following error: The data is corrupted. (80040002)

That said, perhaps later PS3 versions support a different packing format or he simply screwed up lol, after all, he did say he doesn't even have a PS3 of his own.

If anyone else gives it a try, feel free to reply...

Edit: When re-packed into a gz the OtherOS.bld installs, for those who wish to check it out I have attached the repacked version below.

#74 - Jomppe - July 27, 2010 // 8:07 pm
Jomppe's Avatar
I thought this could be useful, from

This otheros.bld sets up PPU+SPU0 and decrypts a custom build binary I patched into it:

their is something that looks like a encrypted SPU binary when updates are unpacked in XDR, it looks like it gets loaded too.

Sony uses decrypt_in decrypt_out via the shared LS while isolation is on, all SDKs share the same code.

I've tried a couple of the loaders just trying to get them to push something back out on xdr. I've got otheros.bld doing work

I'm doing exactly what Sony code does when it has a loader isolated and initiates mailbox. I've looked at plenty of their code.

it was all negative values too, even when I ignore that and give it a pointer and range to buffer out it doesn't do anything.

I set SPE and PPU states up exactly like the Sony code does, and went to initiate PKI mailbox and SPU only pushed a vector.

This just brings into question the claim that their was successful decryption of binaries..and even if the PS3 was defeated

loader basically checks what is mapped when it's loaded and even emulation of mailbox init doesn't work.

because one of the loaders is mapped in a lvl2 and dumps and it has a few threads that wait for SPU feedback through a vector

loaders and ROM thread check LPAR-state and lvl2 thread states before doing DMA PKI

#73 - tjay17 - July 25, 2010 // 2:12 am
tjay17's Avatar
If he hadn't ran his mouth about "what he found" then we would probably still have other os and someone who really wanted to do something and not try to get a name from it might have had homebrew and maybe a homebrew channel like on the wii to get new apps could be on the ps3.

#72 - Haksam - July 24, 2010 // 7:44 pm
Haksam's Avatar
the whole world got to see what happens when a crazy clown messed around with a corporate like Sony.

It was a good experiment and something we don't enjoy watching the drama unfold, but at the end of the day, Sony shove everyone with a,
"Its all just business".

#71 - rockon4you - July 23, 2010 // 7:07 pm
rockon4you's Avatar
Quote Originally Posted by PhilipJWitow View Post
Wow, this is kind of unexpected.

I haven't heard from the guy for weeks and was wondering what he was up to. Looks like the crazy security of the PS3 holds up once again. :|

It's also interesting none of the news sites covered this. Hmm.

Well as you know, many of ps3 holders to this day don't even care about the modding. Some people just love the true experience of the ps3 without hacking. Myself, I work on computers all day, which is irritating. College is stressful with learning all the computer software uses. But, ever since the Linux kernel came into the atmosphere of PS3 news and all other hacking sites, it became an epic worldwide topic for people to discuss.

Btw PhilipJWitow, you got a good point about how none of the other sites covered that info. I love ps3 news though because they always have the most up to date psn stuff and also ps3 exclusive news that people would love to hear. Good Job Ps3 news! Keep it a comin' !!!!