DLL Wrapper (I Think?)
in [Visual Basic]
|
Prev: WMI to use or not to use
Next: VB6 on Windows 7 64-Bit
From: Patrice on 8 Jan 2010 10:48 Hello > Since a real-time link is being maintained, is there anyway to keep my > programs (and the server DLL's) contained within a specific directory, > such that if the DLL has code which can be remotely manipulated by the > server, any server manipulation on my system is limited to the directory > where the my program resides? And what whould do the wrapper other than calling into the vendor provided DLL ? I don't see what would change. Do they have some licensing scheme that would give access to the source code ? If you have just the binaries, you could lock down this application possibly running under a VM and with a a low priviledged account. A Windows admin group could be better. -- Patrice
From: Jeff Johnson on 8 Jan 2010 11:53 "David" <dw85745NOT(a)earthlink.net> wrote in message news:uEgfKqGkKHA.5520(a)TK2MSFTNGP06.phx.gbl... > I'm hoping a DLL wrapper may be my solution? > > Problem: > If a third party DLL resides on your system, can that DLL be accessed > remotely by the third party or call home when it wants? > > Answer > Don't know. If it can do the above, would creating a DLL Wrapper solve > the problem? > > If the DLL was contained within a directory that had no rights other > than to be accessed by the DLL Wrapper functions would this top access or > call home?. That's not what a "wrapper" is. The term "DLL Wrapper" as used commonly by VB programmers refers to a secondary DLL (written in C[++]) which provides an interface to a DLL that VB cannot call directly. VB can only call DLL functions declared _stdcall, whereas many standard (i.e., non-ActiveX) DLLs were written with their functions declared _cdecl. A secondary DLL is created that simply duplicates these function signatures but with the _stdcall convention so that VB can call the "wrapper" method and the wrapper method simply forwards the call on to the original DLL and passes the results back to VB. So a wrapper is just an intermediary--a translator, if you will--and has nothing to do with sandboxing anything. The original DLL does whatever it does and is not restricted in any way, and generally this is exactly what you want.
From: David on 8 Jan 2010 12:30 Mr. Johnson: I get what a wrapper function is and thank you for your excellent explanation re the VB usage of the DLL and the need for a wrapper. because of how it was created. Taking this a step further -- in an attempt to limit the third party DLL, would Not putting the third party DLL within its own directory, with rights to go outside this directory, and then creating my own DLL that calls (interfaces with) the third party DLL, uses those DLL functions I need which are exported (available) for my use, possibly be effective? "Jeff Johnson" <i.get(a)enough.spam> wrote in message news:umrkQMIkKHA.2164(a)TK2MSFTNGP02.phx.gbl... > "David" <dw85745NOT(a)earthlink.net> wrote in message > news:uEgfKqGkKHA.5520(a)TK2MSFTNGP06.phx.gbl... > >> I'm hoping a DLL wrapper may be my solution? >> >> Problem: >> If a third party DLL resides on your system, can that DLL be accessed >> remotely by the third party or call home when it wants? >> >> Answer >> Don't know. If it can do the above, would creating a DLL Wrapper solve >> the problem? >> >> If the DLL was contained within a directory that had no rights other >> than to be accessed by the DLL Wrapper functions would this top access or >> call home?. > > That's not what a "wrapper" is. The term "DLL Wrapper" as used commonly by > VB programmers refers to a secondary DLL (written in C[++]) which provides > an interface to a DLL that VB cannot call directly. VB can only call DLL > functions declared _stdcall, whereas many standard (i.e., non-ActiveX) > DLLs were written with their functions declared _cdecl. A secondary DLL is > created that simply duplicates these function signatures but with the > _stdcall convention so that VB can call the "wrapper" method and the > wrapper method simply forwards the call on to the original DLL and passes > the results back to VB. So a wrapper is just an intermediary--a > translator, if you will--and has nothing to do with sandboxing anything. > The original DLL does whatever it does and is not restricted in any way, > and generally this is exactly what you want. >
From: David on 8 Jan 2010 12:43 Previous post should have said: with NO rights to go outside this directory "David" <dw85745NOT(a)earthlink.net> wrote in message news:e2aaBhIkKHA.5076(a)TK2MSFTNGP05.phx.gbl... > Mr. Johnson: > > I get what a wrapper function is and thank you for your excellent > explanation re the VB usage of the DLL and the need for a wrapper. > because of how it was created. > > Taking this a step further -- in an attempt to limit the third party DLL, > would Not putting the third party DLL within its own directory, with > rights to go outside this directory, and then creating my own DLL > that calls (interfaces with) the third party DLL, uses those DLL functions > I need which are exported (available) for my use, possibly be effective? > > > > "Jeff Johnson" <i.get(a)enough.spam> wrote in message > news:umrkQMIkKHA.2164(a)TK2MSFTNGP02.phx.gbl... >> "David" <dw85745NOT(a)earthlink.net> wrote in message >> news:uEgfKqGkKHA.5520(a)TK2MSFTNGP06.phx.gbl... >> >>> I'm hoping a DLL wrapper may be my solution? >>> >>> Problem: >>> If a third party DLL resides on your system, can that DLL be accessed >>> remotely by the third party or call home when it wants? >>> >>> Answer >>> Don't know. If it can do the above, would creating a DLL Wrapper solve >>> the problem? >>> >>> If the DLL was contained within a directory that had no rights other >>> than to be accessed by the DLL Wrapper functions would this top access >>> or call home?. >> >> That's not what a "wrapper" is. The term "DLL Wrapper" as used commonly >> by VB programmers refers to a secondary DLL (written in C[++]) which >> provides an interface to a DLL that VB cannot call directly. VB can only >> call DLL functions declared _stdcall, whereas many standard (i.e., >> non-ActiveX) DLLs were written with their functions declared _cdecl. A >> secondary DLL is created that simply duplicates these function signatures >> but with the _stdcall convention so that VB can call the "wrapper" method >> and the wrapper method simply forwards the call on to the original DLL >> and passes the results back to VB. So a wrapper is just an >> intermediary--a translator, if you will--and has nothing to do with >> sandboxing anything. The original DLL does whatever it does and is not >> restricted in any way, and generally this is exactly what you want. >> > >
From: Jeff Johnson on 8 Jan 2010 13:52
"David" <dw85745NOT(a)earthlink.net> wrote in message news:eNAqdoIkKHA.4672(a)TK2MSFTNGP06.phx.gbl... >> I get what a wrapper function is and thank you for your excellent >> explanation re the VB usage of the DLL and the need for a wrapper. >> because of how it was created. >> >> Taking this a step further -- in an attempt to limit the third party DLL, >> would Not putting the third party DLL within its own directory, with >> rights to go outside this directory, and then creating my own DLL >> that calls (interfaces with) the third party DLL, uses those DLL >> functions I need which are exported (available) for my use, possibly be >> effective? > Previous post should have said: > > with NO rights to go outside this directory You can't assign rights to a DLL. You can only assign them to users, so you'd have to call the DLL functions from the context of a different user. |