revokation checks for all firmwares.

[zecoxao]

@littlebalup
https://github.com/naehrwert/scetool/blob/master/rvk.cpp
scetool handles revokation packages.
the problem with scetool when decrypting is that only the latest revision is used.
so when handling firmware files/flash files for revokation, don't forget to set the keys file with only the key you want to use on the package (aka the one that works)

[littlebalup]

understood. i'll try asap.

[littlebalup]

@zecoxao
I successfully decrypted various revokation files. Thank you for the advises.

After multiple analysis and decryptions of RL_FOR_PACKAGE.img files from various ofw pup versions, the decrypted content (only 0x40 bytes) is the same since, at least, OFW1.80 pup. As the keys are the same before 3.56, the RL_FOR_PACKAGE.img files should be the same for all pups before 3.56... But it's not the case.

I also tryed to analyse and decrypted the trvk_pkg's from various flash dumps I have (clean dumps from virgin machines).
Most of them are encrypted with 3.55 keys, even the ones from dumps with 4.xx CoreOS. I found one that have trvk_pkg's encrypted with 3.56 keys (from a 2K5 3.56 mini version). So seems the trvk_pkg's are not updated at each firmware update. At least since 3.55. And maybe keep the one installed from factory? Maybe those files are useless on downgradeable machines, Replaced by pkg.rvk and prog.rvk files from CoreOS since 3.60?

Anyway, I failed to find a way to identify and predict trvk_pkg's md5 / per version.
But I learned a lot :)

[zecoxao]

on thing though. if you don't mind, i'd like if you made a database of sorts with the revokation lists you've decrypted together with key used and showed it on psx-place. as for the issue, i guess you can close this one :)