Tortuga Cove - Your Source For Gaming and Hacking News

When metldr is encrypted at factory, a special keyset is set in the binary before encryption. Later when an isolated loader is loaded by metldr, it will copy the keyset to LS offset 0×00000. It consists of eid_root_key and eid_root_iv. To not having to use the same key for all eEID parts, several subkeys are generated from special data called individual information seed. These seeds are stored in the metadata header of isolated modules loaded by isoldr.

When isoldr will load a module, it will call a subroutine that encrypts each seed chunk (0×40 bytes) using eid_root_key and eid_root_iv. Then the so-called individual infos are passed in registers r7 to r22 (= 0×100 bytes in total) to the loaded module where they are used further. Usually isolated modules have a seed section of 0×100 bytes but all of them (except sb_iso_spu_module) have all zeroes but the first 0×40 bytes chunk. You can, for example, find the recently published EID0 seed in the metadata section of aim_spu_module. Appliance info manager is used to get e.g. the target ID or the PSID from EID0. This explains why the seed can also be found in isoldr directly, since that one is checking EID0 too.

As you can probably think, a fair amount of reversing time and knowledge has gone into finding this, so stop calling us *swearwords* for not releasing information that could potentially lead to more piracy, because we think that this would do more harm to the scene than just keeping some information in private (for now). Also I can only encourage everyone that thinks about us this way or is greedy demanding for developers/reverse engineers to release their stuff, to fire up isoldr in IDA or disassemble it with objdump and try to reverse all this from start to end. Well see, who is able to pull this through on his own.

Thnaks aKoN for the news.

Source: wwww.ps3hax.net