ISO Loaders & why they don’t work on HBL

via http://wololo.net/2012/06/12/iso-loa...t-work-on-hbl/

The most requested feature ever for the HBL, is an iso loader: many “developers” promised the release of an iso loader for HBL, but nobody managed to code one so far. To understand what an iso loader is and why it won’t work on HBL, first, we have to know what a .iso file is.



What are isos?

The ISO 9660 is a filesystem standard for optical discs (CDs, DVDs, and even UMDs use it). It’s pretty simple to implement if you’re a developer, and it’s widely documented.

An .iso file is just a raw disc image, that you can burn on a disc, or mount with some software, that does nothing but implement the ISO 9660 filesystem.

If you have a CFW, and your CFW can run isos and has a vsh menu, you’ll notice an option in your vsh menu called “ISO Driver”: usually, a custom firmware has more than just one implementation of the filesystem (driver), each one can have its advantages and works differently (some implement caching, other implement .cso support, and so on).

The OFW itself has an ISO driver, as UMDs use that filesystem aswell: some CFW drivers just patch that driver to make it work with your .iso files.

Now you may be asking yourself “Can’t HBL do the same?”

Well, it can’t patch the OFW driver as it is a kernel module, it’s in kernel memory, and HBL runs in usermode: it can’t just write to kernel memory! It can’t implement a kernel mode driver (like the ones CFWs have) because that requires access to some kernel-only functions (such as sceIoAddDrv).

Yet, an .iso dumped from an UMD contains some resource files and…an EBOOT.BIN, what’s that?

Couldn’t HBL implement the iso specifications?

The EBOOT.bin inside your iso is just a usermode executable (ELF or PRX), so HBL could technically implement the 9660 filesystem, get that EBOOT.BIN and load it?
Not so fast! First of all, the executable is encrypted, and decryption requires kernel access. But this could be easily bypassed by decrypting the executable on a hacked PSP.

The main problem is that some games come with some kernel modules bundled with them (not sure why, backwards compatibility probably).

When the PSP system executes a game from an UMD, it looks for those modules, and allows the game to load them in order to override some OFW modules.

Doesn’t that make the system somewhat vulnerable? Probably, but since only certified software houses should be able to burn images onto UMDs, it’s not very risky.

The HBL just can’t load those modules, as loading kernel modules requires kernel permissions; mounting the ISO as a “legit” UMD would make the OFW do that for us, but that requires a kernel mode driver.














So, when HBL executes a game which requires some of those “extra” modules, the game will just not work, as it will most likely check if those modules were loaded or not.

Conclusion

I hope now you understand why we developers, find so annoying such requests. Also, let’s face it, most people who ask for an iso loader are pirates: I’m not saying people who really backup their own games to protect them don’t exist, but they’re just a small part of the “group”.

Again, I tried to keep this as simple as possible, if you didn’t understand something, let me know in the comments

– Freddy

http://wololo.net/2012/06/12/iso-loa...t-work-on-hbl/