Yup... As mentioned... proprietary blob.
One possible trick might be to put a wrapper around this library to see what Touchwizz does differently from CM9. See camera/CameraWrapper.cpp and gpswrapper/gps.c as examples. This won't work if the TW firmware uses some additional nonstandard "backchannel" interface though. (I suspect that's the case for why some of the GPS functionality doesn't quite work right - it's clear that TW firmware has a way to feed extra parameters to the GPS engine, such as sensor aiding data, the interfaces for this aren't documented anywhere.)
If it's like the camera, the binary blob is probably not accessing the hardware directly but through some driver in the kernel, so it might be worthwhile to find out which one and add traces in it to see what the binary blob actually ask the driver to do.
Looking for /dev/something strings in the binaries might be a good start.
For a long-term goal of reimplementing libaudio this would be benificial - but it would be nice to figure out why our existing libaudio doesn't like to play nice with CM9 in this instance.
It's possible to enable verbose driver debug info for the MC1N2 in the kernel defconfig - it's how I reverse engineered the mic swap situation on I777. I really need to rewrite the path dumping code so it's easier to read. In its current state reading through all the stuff the kernel dumps is painful.