Re: [Alsa-devel] OSS driver removal, 2nd round

[Lee Revell <rlrevell@joe-job.com>]

On Sun, 2006-07-02 at 11:58 +0200, Jan Engelhardt wrote:
> >
> >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.

Is this likely to work with an app like Skype that takes extensive steps
to thwart reverse engineers?

(Of course a Skype beta with ALSA support was just released, so it's
much less important now)

Lee