Re: [Vaman] Query

1 view
Skip to first unread message

Gurjeet Singh

unread,
Nov 21, 2005, 2:18:56 PM11/21/05
to darshan mistry, Vaman group, compg...@googlegroups.com
A .lib file is to a .dll file as a .h file is to a .c file. The
linker uses the lib file to resolve the functions' addresses that an
exe will call into the dll. So, after compiling and linking an
application, you dont need the lib file. If you want to install your
aplication on some computer, then you need to copy only the exe and
the dll on that machine. But if you want others to be able to use the
functionality provided by your dll, then you need to provide them with
the dll and the lib too!

Look at any fresh installation of windows, you will find only
kernel32.dll in system32 folder, and no corresponding lib. But when
you install Visual Studio, or for that matter any development
environment, it comes with a kernel32.lib. This enables the dev-env to
link your exe or dll with the kernel32.dll.

Now, if I understood the problem correctly, you want to be able
intercept all calls into kernel32.dll (or your DB2 CLI). Let's say
kernel32.dll has just CreateProcessA() in it and you want to intercept
the calls to this function.You (hypothetically) rename
kernel32.{dll,lib} to kernel32old.{dll,lib} and then create your own
versions of kenel32.{dll,lib}.

Now the problem in this scheme is, that the exe that wanted to
call CreateProcessA() knew that the function starts at an address
0xAAAAAAAA within the k32.dll. But when you created your version of
the k32.dll, linker decided to put your CreateProcessA() at offset
0xBBBBBBBB in your dll. And this is causing the error message you are
seeing.

There are two possible solutions to this:
1) Look for a mechanism provided by the CLI library to hook into the
calls of that dll. For eg., Win32 API provides mechanisms for us to
know when and how a process is being created so that someone can hook
into that mechanism and provide the functionality of informing the
user whether they are about to invoke a malicious program!

2) Re-link your applications against your newly created dll and lib
files. This way, the information embedded in the exe will be updated
to point to your dll and then you can redirect the calls into the
DB2_CLI_old.dll.

Hope it helps.

On 11/18/05, darshan mistry <darmi...@yahoo.com> wrote:
> Thanks guys for your time and reply.
>
> I want to make a wrapper to DB2 CLI driver. I have
> already tried to make a wrapper dll which complies to
> CLI Specification. But when applications try to
> connect through my wrapper i get an error "Function
> not found at Ordinal xxxx ".
>
> It seems that i am missing a function in the wrapper,
> but applications use CLI specification and I have
> implemented all the CLI functions. So why am i getting
> this error.
>
> Another thing, when i change the lib, it still has
> some reference to the old name. Try to open the lib in
> visual studio and search the old dll reference. So i
> was wondering how would this work.
>
> Darshan.
>
> --- amol gandhi <amol...@yahoo.com> wrote:
>
> > Hey ,
> > why domnt u do it this way
> > write a wrapper dll on the test .dll and replace
> > the test.dll with the wrapper dll in ur application.
> > It should work fine
> > Regards,
> > Amol Gandhi
>
> >
> > darshan mistry <darmi...@yahoo.com> wrote:
> > Hi,
> >
> > Can we rename a DLL and corresponding lib and
> > replace
> > it with a new DLL & lib. And then call link the old
> > lib in the new lib.
> >
> > For eg.
> > there is test.dll and test.lib.
> > I want to rename it to testOld.dll and testOld.lib.
> > Then I will create a test.dll and test.lib which is
> > a
> > wrapper to the old test.dll
> > Applications(executables) that use test.dll should
> > now
> > use new test.dll.
> >
> > Reason : this way i can make a wrapper to any dll
> > and
> > then track the calls made to the dll.
> >
> > Darshan.
> >
> >
> >
> >
> >
> > __________________________________
> > Yahoo! FareChase: Search multiple travel sites in
> > one click.
> > http://farechase.yahoo.com
> >
> >
> > ---------------------------------
> > YAHOO! GROUPS LINKS
> >
> >
> > Visit your group "Vaman" on the web.
> >
> > To unsubscribe from this group, send an email
> > to:
> > Vaman-un...@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the
> > Yahoo! Terms of Service.
> >
> >
> > ---------------------------------
> >
> >
> >
> >
> >
> >
> > ---------------------------------
> > Yahoo! FareChase - Search multiple travel sites in
> > one click.
>
>
>
>
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>
>
>
> ________________________________
> YAHOO! GROUPS LINKS
>
>
> Visit your group "Vaman" on the web.
>
> To unsubscribe from this group, send an email to:
> Vaman-un...@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> ________________________________
>

rushabh lathia

unread,
Nov 21, 2005, 11:40:41 PM11/21/05
to Gurjeet Singh, darshan mistry, Vaman group, compg...@googlegroups.com
Nice answer gurjeet,
 
You are right that address of the function will be a problem.
But this will be only problem if the DLL or LIB is statically bind with the application.
 
But as per the darshan's question I am sure that DB2 is not bind with the CLI statically.
 
In vaman we have started the same thing while building OLEDB Provider.
Here is DB2 will load the CLI Library at runtime, It's a COM Dll and it will read
the entry from the registry and then load the DLL.
 
In Vaman we have frst made the dummy VMOledb.dll, with the alll standard function
of the Oledb Provider, then we rename that .dll to MS Oledb dll, and changed the path
in registry, 
 
Now what happen from the application side, suppose there is one VB application calling MS Oledb, so it will first load the DLL, and all application knows the CLSID,
So it will go in registry to check the path and load the dll from there.
 
In this case as we have replaced MS Oledb with our dummy Dll, it will load our dll,
Now any call application will do it will go to our dll.
 
More Detail :
 
Because it was a COM dll, it used to call QueryInterface function to ask for the handle
of an interface, and there was used to check that if we wnt to support this functinality the what the interface we need to provide and after checking that we implemented that
interface and tht's how .. NRCB started to work .. .
 
So Darshan, u need to made ur dummy dll and make a change in the registry for the
path information , then all calls will come 2 ur dll.
 
Thanks
Rushabh
Reply all
Reply to author
Forward
0 new messages