>
>There is an ALSA tool called aoss.
>What this does is hook any calls the application does to
>fopen/fwrite/fread/fclose/open/close/read/write/ioctl etc. and detects
>any calls to open /dev/dsp and /dev/mixer and diverts them to use
>alsa-lib. This therefore manages to divert the applications use of
>/dev/dsp before it even reaches the kernel. This therefore gives the
>application full use of all the alsa-lib features. So, for example,
>4-channel output would work in this mode. But, and this is the bit we
>need help with, if the application uses dlopen to dynamically open a
>plugin, the plugin's calls to open/close/read/write etc. are not hooked,
>so the application fails.
>
>Is there any way to also hook the IO calls of dlopened plugins?
>
Well you could patch the affected plugin's .dynstr table so that it should at
best try to call a function that has not yet been defined somewhere else (like
open); IOW, you change the .dynstr entry from 'open' to say 'my_open', and
regularly include libmy.so through e.g. LD_PRELOAD.
Of course the MD5 won't match afterwards, but I think the plugin should execute
as usual afterwards, since .dynstr is something no app should rely on.
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
