I'm not sure what other people have posted about this yet or not, but here's something to start with in your quest for lv0 heys.
OK, Iíve hit a bit of an impasse here, and so Iíve decided to share what Iíve gleaned from some of my research so far. It all came from a stupid (and I mean stupid) idea to get at bootldr, and then it turned into something else. What does bootldr have? lv0 keys. The problem with bootldr? It only loads when you start the system (loading it while the system is running results in the SPE stalling on a blocked channel), it gets unloaded by lv1 before lv1 has loaded lv2, and runs in isolation, so you canít see inside it, or affect it in any way, even if you could keep it running. So, the only way to find out whatís in there is to somehow break in. How do we do that? Mathieulhís buffer overflow exploit. (I would paste his description of it right here, but Iím too lazy to)
First, let me clear about this: I donít know nearly as much about this as I want to at this point. But, I will tell you what I know. When a SELF loader starts to load a SELF, it allocates an 0x2000 length buffer in the LS from 0x3E000 to 0x3FFFF (if you poke around any of the loaders, this will be painfully obvious within an hour or two). This area also happens to the only part of the LS visible from the outside while the loader is in isolation (see, wiki guys, shuffle22 was right). The first part of the file the loader loads into the buffer is the first 0x20 bytes of the file, which contains the SCE magic, header version, SELF type, meta offset, header size, and encrypted file size. If this passes muster, it then loads the rest of the file up to the offset specified in the header size field.
The header size is determined mainly by the number of program headers. The more program headers you have, the more encrypted offset headers you have, and the more metadata section info headers and keys youíll have. Ideally, if you want to grow the header, you add program headers, encrypted headers, and the requisite amount of metadata to the file to get to the desired header size. Of course, the metadata hasÖ. issues, to say the least, as the number of metadata sections and keys seems to have no actual bearing on the number of program headers. (It is also worth mentioning that when a header is loaded, all the data in the header is skewed minus 0x20, as it overwrites the first 0x20 that are already thereÖ this explains why the meta offset is always minus 0x20 to where it actually is.)
But hereís the interesting thingÖ In my tests with metldr, it would load whatever size I entered into the header size field without regard for its contents. I could fill everything from the end of the first 0x20 up until the end of the header with random data, and it would still load it. I could even set the meta offset to 0x00000000, and it would still load it. So, the only thing it seems to be checking is the header size field, to decide whether to load the header. One small problem: it only loads headers up to 0x800. PERIOD. Anything more than that, and it fails every time. It doesnít even try to load any other part of the header, and so it will never see any of the additional program headers you put in to make it think that the header really should be that big.
Now, I know that other loaders are certainly capable of using larger headers (appldr can up to at least 0x880 headers), but metldr, at any rate refuses to load headers that are larger than that. All I know is that all the information it has to decide whether or not to continue is coming from that 0x20 at the beginning of the header, and so the answer must be there. Iím sure Iím missing something important here (havenít bothered reversing loaders all that much), but if it wonít even load the header to look at whatís inside, then it doesnít seem doable. And yet, we know that this trick works (I canít think of any other good way to exploit metldr). So, feel free to start the discussion, but please stay on topic, flame-fests make good information hard to find.