-
Steam recently changed the default privacy settings for all users. This may impact tracking. Ensure your profile has the correct settings by following the guide on our forums.
- Thread starter Ben-to-b-free
- Start date
explosions
Member
The PSP Go! eboot is different. Anyone capture the response of the server to a valid license key?
EDIT: They're identical decrypted....huh. Encrypted, the file header, something I'm not sure what it is, and a line that says "Jim, their shields are still up!" are the only similarities.
EDIT: They're identical decrypted....huh. Encrypted, the file header, something I'm not sure what it is, and a line that says "Jim, their shields are still up!" are the only similarities.
I don't see any reason to why the go would have different encryption then the old psp's. The line's "Jim, their shields are still up!" for mccoy, "Aye, sir, I'm working on it!" for scotty and "We have a Klingon vessel on our screen" for uhura are probably part of the header that the kirk looks at while decrypting, and their values can be changed and the kirk will still decrypt it correctly (there are other checks though to prevent from editing). I could not find any documentation on this header for kirk. And it seems like psp developers (both sony and datel) have a thing for star trek.
explosions
Member
They decrypt to the exact same thing, however. I'm wondering if this means Datel went the extra length to find a flaw in the algo, just to make Sony look even more foolish.
I was hoping the string was there as an exploit in the decryption but then I edited the same bytes in a sony update and it also decrypted normally, hell in newer updates sony doesn't even care anymore and they just null out the bytes.
This "kirk header" is marked as unknown in yapspd
Code:
0xd4 0x7c ?explosions
Member
The thing I can't figure out is the Go/normal difference. Only 196 bytes/1.42 MB are the same, however they both decrypt to the EXACT same thing. They even seem interchangeable.
Are you sure there are no differences, because a single byte will change the entire encrypted file.
And how would the datel installer even know that your psp is a go!, they could check the usb details but I doubt they do that as there is an option to select a psp drive and you can select a huge hard drive and the software will not raise an error.
explosions
Member
I just ran the installer, once on a hard drive the other on my psp 1000 and I got 2 completely different files. The one I got from the hard disk (probably the go! file) would not run on the psp but the one they installed would. Also sony releases 2 different updates, one for go! and one for psp 1-3, so datel had to crack both of their encryptions.
explosions
Member
Take the one on your hard disk and replace only the param.sfo with the one from the one on your PSP, and then try it.
The response is a license file.
The license is checked by the function located at 0x15BA4. sub_15BA4(unk, 0x00, 0x05, 0x14, psid_checksum, lic_file_buf)
psid_checksum, is a sha-1 of the psid. lic_file_buf stores the contents of the license file. if the return of sub_15BA4 is "true", this means that the license is valid, otherwise the demo splash screens will be displayed.
explosions
Member
Ah, I see.
I was also able to write a PRX with two functions much like uhura, except always return 0xdeadbeef, patch the imports, psp-pack it, then inject it in the place of uhura.prx, and it generates a different ID, and I'm sure it would be fixed between PSPs, but that's just an observation.
I ran it on two PSP's, and it indeed generates the same console ID.
I ran it on two PSP's, and it indeed generates the same console ID.
explosions
Member
That sounds like what I'd do if I had the knowledge to do such a thing.
Oh, and the Go! and regular DATA.PSPs are encrypted with the same key, decrypt to the same ELF file, and are interchangeable(at least, from Go!->regular), however, they only have 196 bytes in common. This was figured out on IRC today. Posting it here for my notes/anyone that cares.
Code:
http://www.sendspace.com/file/l3ghc7In there are some tools to inject the replacement PRX (which is also in the folder) and extract the existing modules from inside of it.
Compile it on whatever platform you're using (I'm not sure if it would work on windows), via make. I couldn't cast char* to unsigned int due to a 64-bit compiler, so if the code looks funny (on nidpatch), that's why. I had to memcpy it.
run
Code:
./injector EBOOT.BIN uhura_rev.prx f2c20 2066That'll generate an EBOOT.BIN_injected
Then, in the same folder as all the eboot.pbp files
Code:
pack-pbp EBOOT.PBP PARAM.SFO ICON0.PNG NULL PIC0.PNG PIC1.PNG NULL EBOOT.BIN_injected NULLWhich will then generate an EBOOT.PBP, which you should copy over to the UPDATE folder, and then run it on your hacked PSP, and your license will be the same as anyone else who runs the thing. Make sure to delete ms0:/PSPAR, if it exists, first.
I don't see a point to doing this as you would still need a custom firmware to run this, and it is easier to just patch the assembly instead of making a whole new dummy prx. Now the best way would be to decrypt the license checker and create a program that would generate a new license that way it would work on all psp's.
Only cracked if someone buys a license then distributes it for that ID.
What we WANT to do is figure out their code format (Which as far as I can tell, in the binary, is the same format as before, see below)
Code:
Game ID and flags
Code header and flags
Code name
Address
Value
Address
Value
Code header and flags
Code name
Address
Value
Address
Value
...so on, note the address might have a flag in the last 8 bits (X0000000)This is assuming that what it downloads it unencrypted, which is highly unlikely. Though, once someone important (ie skills) gets their paws on it and is willing, it probably wouldn't take too long to crack it.