So, to understand this correctly: You have essentially access to the source
code, but only with the owner present, and you want to modify the code
without the owner present, so that you can test the desired changes before
giving them to the owner?
Would it be possible that the owner could give you the binary form of the
driver in the form of, say, a .DLL or .LIB, with suitable header files?
That way, you could use the functions in the library/DLL, and then modify
the functionality with your own funcstions.
There is technical differences between a .SYS and a .DLL file: A .SYS file
is an executable file, same as a .EXE, whilst a .DLL is a not an executable
file. Sure, it’s just some flags that are different, but I’m not entirely
sure that you can use a .SYS as with EngLoadImage, in fact I’d be pretty
surprised if it DOES work.
Here’s what the DDK says:
A driver can use EngLoadImage to map an executable image into kernel-mode
memory. For example, a printer driver can call EngLoadImage to load a
minidriver.
EngLoadImage requires that the image file to be loaded have a .dll suffix.
The driver must include this suffix in the pwszDriver string.
To execute a section of code within the loaded image, the driver should
obtain the function address from EngFindImageProcAddress.
The file identified by pwszDriver must be located in the
%SystemRoot%\System32 directory or within a directory found in the
directory hierarchy under %SystemRoot%\System32.
Drivers that need to load a module as data only should call EngLoadModule
or EngLoadModuleForWrite instead of this function.
I don’t think EngLoadModule will work either, as it’s not going to link the
necessary sub-images (For instance, a video miniport driver need to be
linked to VideoPrt.sys, Hal.DLL and NTOSKRNL.EXE, and this will not happen
with EngLoadModule).
–
Mats
xxxxx@lists.osr.com wrote on 03/08/2005 07:57:41 AM:
Thanks mats,
Actually I have permission to view the source or change the code
with the help of owner. But the problem I am facing is the number of
changes
that I can make are constrained (as the changes should be made with
the help of third person). So if I can write a wrapper I can
experiment without any constraints. Suppose If I want to change a
function behavior I can easily make the change with this approach
(wrapper function). If my experiments become successful my changes can
go into the original code. When I search the DDK I found a function
called ENGLoadImage to load a .dll, but I am not sure why this is not
possible for “.sys” file. OS calls driver entry function of “.sys”,
so why can’t one driver call the driver entry of other “.sys” file.
If it is possible to call driver entry then we can call other
functions easily with some tricks.
If any one has some pointers on this or ideas of how to
achieve my requirements please help me out.
Thanks,
Santhosh.
Subject: Re:Query regarding Port/Miniport architectures
From: Mats PETERSSON
> Date: Mon, 7 Mar 2005 16:02:40 +0000
> X-Message-Number: 14
>
> Likewise for Video miniports. They are restricted to only using official
> “video miniport calls”. These calls are essentially the same as the
normal
> calls, but they make sure that the video driver doesn’t do anything
nasty.
>
> Like for NDIS, there are ways around this, but you’re then starting to go
> onto uncharted waters where you may find problems that aren’t obvious and
> definitely not documented because you’re doing things that are outside
the
> norm.
>
> I’m also unsure of whether the system supports loading a .sys image just
> like that, and more importantly, does the DLL’s that (potentially) get
> “loaded” twice for this approach like the fact that they are now loaded
> twice for the same hardware. Let me describe what I mean by this:
> m1.sys uses videoport.sys.
> m2.sys per definitition must use videoport.sys, but also loads m1.sys
which
> “reloads” videoport.sys. But we’re still only supporting one instance of
> hardware with M1 and M2 combined.
>
> I would strongly suspect that you’ll find interesting limitations in how
> the OS handles these situations, because it’s not meant to work that
way…
> 
>
> I’m not saying that it can’t work, but that it’s your task to find out
what
> potential problems you get from this.
>
> Also, loading an image doesn’t give you entry-points unless it’s a .DLL
> with exported entry points. So you can’t really know where your
M1_function
> resides in the .sys-file if you haven’t got any symbols to refer to. That
> will be a major stumbling block.
>
> Another stumbling block would be if one of the IOCTL’s that aren’t
> published for M1 is transferring some sort of control data or function
> pointers to the port driver, which are then called directly by the port
> driver. If you don’t understand EXACTLY how the port driver uses some
> particular data structure, you’ll be forever spending time to add to the
> driver.
>
> And finally, you’d better ask the owner of the original code if you’re
> allowed to use their miniport for this purpose, because they own the
rights
> for it, and will most likely not appreciate you using it “for free”
without
> their permission. I’m not a lawyer, but I’m pretty sure that copyright
laws
> and other such like are on the side of the owner of the original
miniport,
> and that any country which has even the most rudimentary copyright law
will
> forbid this sort of behaviour unless you have the permission of the
> original owners of the code.
>
> –
> Mats
>
> xxxxx@lists.osr.com wrote on 03/07/2005 03:43:15 PM:
>
> > Well you haven’t identified what type of miniport you are talking
about.
> > For instance storage miniports have some fairly strict rules on the
calls
>
> > that can be used in these drivers. Yes there are hacks to work around
> this,
> > but they are not the norm. An NDIS miniport driver can be NDIS-WDM and
> do
> > this though even there you are using an undocumented calls. For video
I
>
> > defer to Calvin and Mats who have already replied on this thread for
> data.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Santhosh Kumar K” wrote in message
> > news:xxxxx@ntdev…
> > > Thanks for the replies. Sorry for the delay.
> > >
> > > Seems there is a confusion in my question. Assume that I know
> > > everything about the M1 driver, say the functions it use, the IOCTLs
> > > it handle etc., What I am interested to know is “Can we load M1.sys
> > > from M2.sys (Miniport driver) and use the functionalities of M1.sys”
> > > For example say, M1 has a function named M1_function1. Can I be able
> > > to call M1_function1 from M2 driver?
> > > See the description below
> > >
> > > IN M2 driver
> > > ------------
> > > DriverEntry()
> > > {
> > > Handle = Load(M1.sys)
> > > }
> > > M2_function1()
> > > {
> > > With the help of above handle call M1_function1()
> > > }
> > >
> > > --------------
> > >
> > > So what we achieved here is, we trapped the functions of M1 driver.
> > > Here I am interested to know, are there any functions to load
> > > M1.sys from Miniport. This approach increases reusability.
> > >
> > > If we are able to write this way, then we can fake the OS by saying
M2
> > > as the original driver with some modifications in the .inf file.
> > > Even Undocumented functions are Ok to me as I am doing this for
> > > experimental purpose.
> > >
> > > If the answer is no. I like to know “why no?”
> > >
> > > Thanks
> > > Santhosh.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > It was unclear if the OP meant ‘filter’ or ‘replace’. You can’t
really
> > > filter miniports as they link to the port driver. (Of course you
could
> > > probably manage this through hooking, but we won’t go there.) If the
OP
> > > meant replace, then yes of course you can write what is essentially a
> > > function driver for a piece of hardware that replaces the hardware
> > > vendor’s
> > > function driver. You have to figure out how to get PnP to install
your
> > > function driver rather than theirs, other than that you are not
> wandering
> > > off the reservation at all.
> > >
> > > =====================
> > > Mark Roddy
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
> > > Sent: Thursday, February 24, 2005 10:09 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] Query regarding Port/Miniport architectures
> > >
> > > xxxxx@lists.osr.com wrote on 02/24/2005 02:58:48 PM:
> > >
> > >> > 1) Can we write a new miniport driver (M2) which trap all the
> functions
> > >> > that are exposed by M1 and fake itself as Miniport driver to
> > >> > Port driver".
> > >>
> > >> Assuming you’re talking about video miniport, the short answer: NO.
> > >> And I don’t think it’s possible for other mini/port pair.
> > >
> > > Are you saying that if I were to replace our miniport with a
different
> > > piece
> > > of code that performs exactly the same functionality, supplying
> suitable
> > > .INF to install this replacing miniport, that this wouldn’t work.
> > > Why not? [Admittedly, it would have to do the same work for all the
> > > interfaces that are between the display driver and the miniport in
our
> > > case,
> > > including any “private” functionality that we’ve got].
> > >
> > > As far as I know, Windows doesn’t know what filenames apply to which
> > > driver,
> > > and if I’ve got the relevant .inf to install a miniport and driver,
> then
> > > windows must surely allow this to installed.
> > >
> > > [That’s by no means any guarantee that the original poster can do
what
> he
> > > wants, because there are certainly some complications, particularly
in
> > > regards to private API’s that are not published by the original
> miniport
> > > provider. Further, there’s probably legal problems with “replacing
> another
> > > companies miniport”, if that’s what the original poster wanted to
do.]
> > >
> > > Calvin: Please understand that I’m not saying you’re wrong. Just that
> I
> > > don’t understand why it’s not technically possible to do…
> > >
> > > –
> > > Mats
> > >>
> > >> -
> > >> Calvin Guan Software Engineer
> > >> ATI Technologies Inc. www.ati.com
> > >
> > > —
> > > Questions? First check th…
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> ForwardSourceID:NT0000E51A