Embedding Win32 dll
-
It is posible to embed a Win32 dll into .Net dll?
-
It is posible to embed a Win32 dll into .Net dll?
No, but you can call it using P/Invoke (search for DllImport). Yes, even I am blogging now!
-
It is posible to embed a Win32 dll into .Net dll?
Yes. You can use Win32 dll's in your .NET dll. The idea P/Invoke is there to help you out. Please refer this link Interoperability Sreejith Nair [ My Articles ]
-
Yes. You can use Win32 dll's in your .NET dll. The idea P/Invoke is there to help you out. Please refer this link Interoperability Sreejith Nair [ My Articles ]
I'm afraid my question was misunderstood. I did use the P/Invoke (and C++ Interop as well) to call some functions in Win32 dll, but when I want to run the program on different computer, I need to copy the dlls I called, to the same directory Where the .Exe resists. There is any way do embed the dlls into the .exe? My problem is security. I'm afarid that somebody will replace the dlls with his own. Strong name isn't an option here, since the dlls are Win32 ones. Thanks, Yaakov
-
I'm afraid my question was misunderstood. I did use the P/Invoke (and C++ Interop as well) to call some functions in Win32 dll, but when I want to run the program on different computer, I need to copy the dlls I called, to the same directory Where the .Exe resists. There is any way do embed the dlls into the .exe? My problem is security. I'm afarid that somebody will replace the dlls with his own. Strong name isn't an option here, since the dlls are Win32 ones. Thanks, Yaakov
You Wrote :when I want to run the program on different computer, I need to copy the dlls I called, to the same directory Where the .Exe resists. No. Each and every Windows operating system contain this Win32.dll file (excluding Windows 95. I think here it is Win16.dll) in it's System32 directory. So you don't want to copy the calling .dll. Refer using DllImport Attribute. Hope you understood.Please see that url that i attached in my last thread.:-O Sreejith Nair [ My Articles ]
-
You Wrote :when I want to run the program on different computer, I need to copy the dlls I called, to the same directory Where the .Exe resists. No. Each and every Windows operating system contain this Win32.dll file (excluding Windows 95. I think here it is Win16.dll) in it's System32 directory. So you don't want to copy the calling .dll. Refer using DllImport Attribute. Hope you understood.Please see that url that i attached in my last thread.:-O Sreejith Nair [ My Articles ]
sreejith ss nair wrote: So you don't want to copy the calling .dll. Hi. I DO want to copy the dll, since it isn't a windows dll. it's a dll of some third party API. The program doesn't load without the dll in the running directory. I'll repeat my problem to make it clear. I use an external Win32 (i.e. not .Net) dll which contains function foo(). The dll isn't part of Windows. I'm afraid that somebody will place in the folder a dll with the same name, that contains some malicious function foo(), who do some evil job before he calls in turn to the original foo(). I thought I can avoid this, if I find a way to embed the called dll in my application. I'm open to another suggestion or information. Thanks for your help.
-
sreejith ss nair wrote: So you don't want to copy the calling .dll. Hi. I DO want to copy the dll, since it isn't a windows dll. it's a dll of some third party API. The program doesn't load without the dll in the running directory. I'll repeat my problem to make it clear. I use an external Win32 (i.e. not .Net) dll which contains function foo(). The dll isn't part of Windows. I'm afraid that somebody will place in the folder a dll with the same name, that contains some malicious function foo(), who do some evil job before he calls in turn to the original foo(). I thought I can avoid this, if I find a way to embed the called dll in my application. I'm open to another suggestion or information. Thanks for your help.
Yaakov
-
sreejith ss nair wrote: So you don't want to copy the calling .dll. Hi. I DO want to copy the dll, since it isn't a windows dll. it's a dll of some third party API. The program doesn't load without the dll in the running directory. I'll repeat my problem to make it clear. I use an external Win32 (i.e. not .Net) dll which contains function foo(). The dll isn't part of Windows. I'm afraid that somebody will place in the folder a dll with the same name, that contains some malicious function foo(), who do some evil job before he calls in turn to the original foo(). I thought I can avoid this, if I find a way to embed the called dll in my application. I'm open to another suggestion or information. Thanks for your help.
There is no way to do this. Even if you packaged the .DLL into a resource in your .EXE, you'd still have to unpack it, save the .DLL file to the folder where your app is installed, and then call it. But, someone that malicious could also just put a replacement .DLL into the folder where your app is installed, either tag it ReadOnly, or some other methdo to keep your app from putting the .DLL down successfully, whatever, and then your app would still call the bad .DLL. The only method you can use to validate the .DLL is to run some kind of checksum, or some other file validation, on the .DLL file before you call it. But this is no way guarantees that the file your looking at is legitimate and it will also keep your application tied to a specific version of the .DLL file. But this is a calculated risk that EVERY Windows application takes. There is just no reliable way to do this with a Win32 .DLL. Every Win32 .DLL can be impostered by a custom written replacement, using the same signatures and GUID's as your .DLL. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
There is no way to do this. Even if you packaged the .DLL into a resource in your .EXE, you'd still have to unpack it, save the .DLL file to the folder where your app is installed, and then call it. But, someone that malicious could also just put a replacement .DLL into the folder where your app is installed, either tag it ReadOnly, or some other methdo to keep your app from putting the .DLL down successfully, whatever, and then your app would still call the bad .DLL. The only method you can use to validate the .DLL is to run some kind of checksum, or some other file validation, on the .DLL file before you call it. But this is no way guarantees that the file your looking at is legitimate and it will also keep your application tied to a specific version of the .DLL file. But this is a calculated risk that EVERY Windows application takes. There is just no reliable way to do this with a Win32 .DLL. Every Win32 .DLL can be impostered by a custom written replacement, using the same signatures and GUID's as your .DLL. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Dave Kreskowiak wrote: ...the same signatures and GUID's as your .DLL. Thanks for making things clear. How can I get the GUID and the signature? Yaakov
-
Dave Kreskowiak wrote: ...the same signatures and GUID's as your .DLL. Thanks for making things clear. How can I get the GUID and the signature? Yaakov
The GUIDs are scattered abou in the registry. You'll need to search for the object names exposed by the .DLL in order to find them. The function signatures cannot be had unless you have the source code for the .DLL. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
The GUIDs are scattered abou in the registry. You'll need to search for the object names exposed by the .DLL in order to find them. The function signatures cannot be had unless you have the source code for the .DLL. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Thanks for your answer. And here is another one which related to the previous. I looked for the Al.exe documentation in the MSDN, and it explains the /link argument: /link[resource]:file[,name[,target[,private]]] Links a resource file to an assembly. The resource specified by file becomes part of the assembly; the file is not copied. The file parameter can be in any file format. For example, you can specify a native DLL as the file parameter. This will make the native DLL part of the assembly so that it can be installed into the global assembly cache and accessed from managed code in the assembly. Isn't that what I was looking for? However, I tried this, and I get the message: /link:... option not recognized. Yaakov
-
Thanks for your answer. And here is another one which related to the previous. I looked for the Al.exe documentation in the MSDN, and it explains the /link argument: /link[resource]:file[,name[,target[,private]]] Links a resource file to an assembly. The resource specified by file becomes part of the assembly; the file is not copied. The file parameter can be in any file format. For example, you can specify a native DLL as the file parameter. This will make the native DLL part of the assembly so that it can be installed into the global assembly cache and accessed from managed code in the assembly. Isn't that what I was looking for? However, I tried this, and I get the message: /link:... option not recognized. Yaakov
Interesting. But I have no clue how you're going to access the .DLL inside the assembly. Also, if your .DLL is a COM component and must be registered, I have no idea how you're going to get that accomplished while it's sitting inside a .NET assembly. It's just never been a requirement for me. If someone is going to do something malicious with my code, they're going to succeed weather I want them to or not. It's just up to that persons determination. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome