Hi all,
I have a upper audio filter and between my own company & another company
wanting to use this filter, I have decided to instead of having 2
filters to maintain I will have instead 1 code block to maintain and
have the small differences as a dll. (which are I recall about 3
function calls in certain places to that dll).
Too solve this I have designed 2 drivers, the Audio upper class filter
ZwLoadDrivers the other one as needed on boot. On DriverEntry in the
plugin I (being lasy) stored the address location of the function in a
registry setting and load that in the audio upper class filter. I can
then call that function.
But I’ve noticed that if I try to call it again later on (in my IOCTRL
communication device) it goes AWOL on me. I am either coding the
function pointers wrong or there is a feature of the system itself to
prevent this?
Should I just create a communication device and send IOCtrl messages
instead? (It’s only a preference for direct calls instead of IOCtrl.)
I try searching for this on the net but only found threads where you
(NTDev) are for some security reason, very nervous about giving away
this information mainly because of the sony rootkit developer ask for
help here long ago.
Anyway any advice for be appreciated.
Cheer
Obble.
Hi all,
I have a upper audio filter and between my own company & another company
wanting to use this filter, I have decided to instead of having 2
filters to maintain I will have instead 1 code block to maintain and
have the small differences as a dll. (which are I recall about 3
function calls in certain places to that dll).
To solve this I have designed 2 drivers, the Audio upper class filter
ZwLoadDriver the other one as needed on boot. On DriverEntry in the
plugin I (being lasy) stored the address location of the function in a
registry setting and load that in the audio upper class filter. I can
then call that function. (Works according to windbg 
)
But I’ve noticed that if I try to call it again later on (in my IOCTRL
communication device) it crashes on me (null referance). I am either
coding the function pointers wrong or there is a feature of the system
itself to prevent using kernel function pointers from different drivers
which was gotten from a different thread?
Should I just create a communication device and send IOCtrl messages
instead? (It’s only a preference for direct calls instead of IOCtrl.)
I try searching for this on the net but only found threads where you
(NTDev) are for some security reason, very nervous about giving away
this information mainly because of the sony rootkit developer ask for
help here long ago.
Anyway any advice for be appreciated.
Cheer
Obble
NCH Obble Smith wrote:
I have a upper audio filter and between my own company & another
company wanting to use this filter, I have decided to instead of
having 2 filters to maintain I will have instead 1 code block to
maintain and have the small differences as a dll. (which are I recall
about 3 function calls in certain places to that dll).
To solve this I have designed 2 drivers, the Audio upper class filter
ZwLoadDriver the other one as needed on boot. On DriverEntry in the
plugin I (being lasy) stored the address location of the function in a
registry setting and load that in the audio upper class filter. I can
then call that function. (Works according to windbg )
But I’ve noticed that if I try to call it again later on (in my IOCTRL
communication device) it crashes on me (null referance). I am either
coding the function pointers wrong or there is a feature of the system
itself to prevent using kernel function pointers from different
drivers which was gotten from a different thread?
A few moments thought should convince you of why this is not the case.
Threads are irrelevant. The kernel address space is global (modulo
Terminal Server sessions). Much more likely scenarios are timing issues
(fetch the address before it has been saved, calling the DLL after it
has been unloaded, etc.).
Should I just create a communication device and send IOCtrl messages
instead? (It’s only a preference for direct calls instead of IOCtrl.)
I got a little confused about who was calling who there, but there are
certainly ways to solve this kind of problem. Storing pointers in the
registry is not a way that would have occurred to me.
http://www.osronline.com/article.cfm?id=24
Driver callbacks are one slick way to do this (ExCreateCallback and
friends). One driver can offer its services as a callback. The
callback can return a set of function pointers, like a COM object.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank you Tim, I’ll look into this right away.
Cheers
Obble.
On 3/03/2010 9:18 AM, Tim Roberts wrote:
NCH Obble Smith wrote:
> I have a upper audio filter and between my own company& another
> company wanting to use this filter, I have decided to instead of
> having 2 filters to maintain I will have instead 1 code block to
> maintain and have the small differences as a dll. (which are I recall
> about 3 function calls in certain places to that dll).
>
> To solve this I have designed 2 drivers, the Audio upper class filter
> ZwLoadDriver the other one as needed on boot. On DriverEntry in the
> plugin I (being lasy) stored the address location of the function in a
> registry setting and load that in the audio upper class filter. I can
> then call that function. (Works according to windbg )
> But I’ve noticed that if I try to call it again later on (in my IOCTRL
> communication device) it crashes on me (null referance). I am either
> coding the function pointers wrong or there is a feature of the system
> itself to prevent using kernel function pointers from different
> drivers which was gotten from a different thread?
>
A few moments thought should convince you of why this is not the case.
Threads are irrelevant. The kernel address space is global (modulo
Terminal Server sessions). Much more likely scenarios are timing issues
(fetch the address before it has been saved, calling the DLL after it
has been unloaded, etc.).
> Should I just create a communication device and send IOCtrl messages
> instead? (It’s only a preference for direct calls instead of IOCtrl.)
>
I got a little confused about who was calling who there, but there are
certainly ways to solve this kind of problem. Storing pointers in the
registry is not a way that would have occurred to me.
http://www.osronline.com/article.cfm?id=24
Driver callbacks are one slick way to do this (ExCreateCallback and
friends). One driver can offer its services as a callback. The
callback can return a set of function pointers, like a COM object.
> Too solve this I have designed 2 drivers, the Audio upper class filter
ZwLoadDrivers
No need in ZwLoadDriver or even SC database entry for a kernel-mode DLL, it will be loaded automatically by import resolution.
SCSIPORT.SYS was such in most Windows versions.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com