96w ago - 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."
80 Comments
Here is how I believe (after a bit of investigation) the playstation 3 discs' authentication procedure is being held:
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
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
—————————————————————————
INPUT:
r3 – address of string
OUTPUT:
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, 0×580(%r30)
ROM:00260764 bl print_str
%rtoc – pointer to TOC = 0x0000000034cc48
-0x5a98(%rtoc) = 0×00000000315528 = 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