forums.ps2dev.org

piracy bad

I was thinking more towards UMD dumping. So they'de stop the SDK compiled UMD reading examples from running? I think with the games gone by and in development now then that would be a tad difficult. I thought specific UMDs could only be read by their own game boot code because they're keyed, seems ...

More likely 1.51 is in response to firmware dumper.

If you'd mentioned practising law for 'donkeys years' then you'd have a point worth the trouble. I made a presentation to management on the legalities of reverse engineering hardware Atari Jaguar days. But that in the end it was was pointless. Seem to be ignoring the point, I could quote homebrew c...

The reasoning and general acceptance of using sce prefixes. Well if this is the case, why not just dump the official sce includes <SNIP> You'll get there a LOT quicker! And the whole point of LEGAL - i.e clean room reversing and legitimate use of the developed libraries then goes out of the window....

rr 'loading' loads in at 0x0800 4000 afaik

encryption still in hardware

switched ON OR OFF by software

assume cockup or failsafe (making sure the patch would work either way) making uncrypted executables run on psp1.0.

The reasoning and general acceptance of using sce prefixes. Well if this is the case, why not just dump the official sce includes into the domain? after changing tab sizes and removing copyright notices, maybe change the ordering of the calls a little just to really confuse sony. You'll get there a...

file directory to the firmware? it might have a set of modules all linked together in binary block.

you may as well ask for a hexdump

theres firmware images in the official sdk, for devkit, most likely will hang consumer units.

don't forget umds contain firmware updates too, so flash your firmware, play a game off umd, and patch mismatch skullduggery beckons

looks scarily like official sdk library call names to me, maybe use notscehonestgodIoOpen()

? from copied juarez?

a crash or mishandled exception in kernel results in shutdown, games code is allowed to hang indefinately if wished. in other words wipeout save handler could get stuck in an infiniteloop saying stuff is just not right to itself - and consequently not *executing those nops & loop*

Grover wrote:Im not sure if this is the right place for this but, if the version 1.0 Jap versions (like I have) were updated then the EBOOT.PBP installer they run, must be unencrypted right?

wrong... and encryption checking/switching is in kernel space, which in userland is protected.

Running unnapproved program code on a closed system by means of reverse engineering hardware and software designed for protecting the closed system - ie. circumventing copy protection is illegal in some countries. Add that to the list?

By definition thats whats trying to be achieved here.

any dev could dump a umd anytime. and now anyone with the sdk could compile ythe sdk sample for reading a umd iso, and run it on a v1.0 psp.. dumpy dumpy it's hardly rocket science. face it or not the juarez scene and homebrew dev scene tend to be inextricably linked, wether it;'s unliked or encoura...

when sony pulls youre companies developr licence because of this then you get sacked IMHO, as soon as the firsrt marked pdf floods through the ftp

lmx wrote:So even if a developer wanted to read raw, tis not possible.

I take that ludricrous statement back. developees can probably dump data on the stick. it would probably fail trc, but I guess homebrewers would get fed up of the trc process pretty quick.

raw read and rite is tomemory card is dissallowed by sony, all save data passes through encryption. So even if a developer wanted to read raw, tis not possible. might as well use crayons to get data into psp memory. all keys in hardware, no referene to them in software I would imagine to be safe

So you're trying to reverse engineer something that Sony expressly doesn't want to to reverse engineer by any means possible, still against Sonys wish to protect their intellectual property? I'de suggest running any form of homebrew program will have to circumvent Sonys copy protection / operating s...

Guessing* unhandled errors in the elf are just handled by a brute force kernel kick in the teeth (reset), until the next kernel update when scei will add another error message. And talking abouyt exploits publicly are probably the best way to get another kernel update out quicker ;) You have another...

umm, lol. so you think it's running decrypted program code?

psp kernel bails as soon as it finds something awry with an encrypted elf. you are just getting executabe corrupt errors.

try again

play direction = opposite. don't need to be brave to find that out, a friendly dev could have told you

Devkits can be booted in production mode and play consumer umds. They can also boot unencrypted DVDs with the game fileset on them. Sony encrypt each game with its own unique key publisher side, and as a bonus I think games cant read other games discs... As for adventure maker thing - unlikely Sony ...

Game share does indeed send an encrypted pbp.