So I've been looking at Sm4sh CROs for some time and after a small realization about the nature of CROs my Sm4sh IDB has become at least 10 times better. In any case, I have some more insight on how the Sm4sh dt/ls file system works on a higher level (ie from a C++ standpoint). Fair warning in advance, it's entirely possible I'm misinterpreting the function of some things, but the names are definite:
First the lib::resource class is instantiated, and lib::Resource::find is called, which returns a Resource instance. Usually the original instance is destroyed by lib::Resource::~Resource, sometimes sooner sometimes later. lib::Resource::lock takes the lib::Resource::find instance and a boolean (uncertain what it does as a boolean for now) and then returns a buffer, which is then copied out before calling lib::Resource::unlock which allows additional resources to be loaded.
Based on this, my guess as to the best way to redirect to SD would be to only intercept lib::Resource::lock, since Resource instances are actually passed around by several functions, so a direct mapping of each function to fopen/fclose/etc wouldn't work out well. lib::Resource:: path_str() exists, which might make the job a bit easier since we could use the instance passed to us to get the actual path, then do our file code using the path gained from the instance. Probably the only tricky part might be hooking the functions properly and making 100% sure to know how the code works before doing it.
EDIT:
Full list of dt/ls Resource functions:
lib::Resource::Resource(char const*, bool)
lib::Resource::~Resource()
lib::Resource::clear()
lib::Resource::data_size()
lib::Resource::find(char const*, bool)
lib::Resource::findf(char const*, ...)
lib::Resource::is_exist()
lib::Resource::is_loaded(bool)
lib::Resource::is_locked()
lib::Resource::load(int)
lib::Resource::lock(bool)
lib::Resource::operator=(lib::Resource const&)
lib::Resource:: path_str()
lib::Resource::unlock()
Not sure what load and clear do, but I don't see them used much.