Re: Re: [Vaman] Query

[vaibhav d]

Rushabh, one correction here. The VMOLEDB was a COM
dll and the dll darshan is trying to wrap is a simple
c/c++ dll.

Darshan,
I think (not sure), the problem may be with the .def
you have created. If you have not created a .def then
you need to create one.

The __dllexport exports the functions/symbols on NAME
basis but earlier the functions/symbols were exported
using ordinals and not name.

If your .exe is locating the function using ordinal,
it wont find the function.

As gurjeet has mentioned this problem will go away if
you relink the .exe.

But if you cant, you need to create the .def file with
exactly the same function names and ordinals that were
there in the origenal dll.

Hope this information is helpfull.

Regards,
Vaibhav
--- Va...@yahoogroups.com <rusha...@yahoo.com>
wrote:
> 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
>
>
> Gurjeet Singh <singh....@gmail.com> wrote:
> 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.
=== Message Truncated ===





__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com