Index
> Main > Writing a .dll file from memory before importing it? |
| Author |
|
|
LocoDelAssembly 21 Feb 2010, 19:48
Don't know if delayed imports can really work in this case but you can do a much safer thing by using LoadLibrary and GetProcAddress.
To include the dll inside your executable just do this: Code: embedded_dll: file 'something.dll' embedded_dll.size = $ - embedded_dll And then you can just use embedded_dll as a buffer for WriteFile. With CreateFile using CREATE_NEW + GetLastError you can know if the file exists, and if it doesn't exists, then you already have an open handle to perform the write. |
|||
21 Feb 2010, 19:48 |
|
|
fasmnub 21 Feb 2010, 20:09
@LocoDelAssembly, thanks, that looks like a possible solution. Would it be possible to import the embedded_dll from memory in this case without having to write a file?
Also, how would I make sure the exe doesn't error before it has chance to write the dll it depends on? |
|||
|
21 Feb 2010, 20:09 |
|
|
fasmnub 21 Feb 2010, 22:05
Ok, I've gone with the suggestion to write out the dll from memory, which is easy enough.. the trouble is, when I run the .exe without the .dll present, I get "The applications has failed to start.. couldn't find blah.dll"
So.. it seems that the .exe is checking for the exsistence of the imported file before it has chance to create it. GAH! Where exaclty in my code should I be creating the file, so it gets written before it needs to be imported as a library!? The problem is, I need to import libraries to write the file, then write it, then import the written file. Pulling my hair out here!!  |
|||
|
21 Feb 2010, 22:05 |
|
|
windwakr 21 Feb 2010, 22:20
fasmnub wrote: Ok, I've gone with the suggestion to write out the dll from memory, which is easy enough.. the trouble is, when I run the .exe without the .dll present, I get "The applications has failed to start.. couldn't find blah.dll" Remove any mentions of the file from your import section. Use LoadLibrary and GetProcAddress like Loco said when you need it's functions. |
|||
|
21 Feb 2010, 22:20 |
|
|
fasmnub 21 Feb 2010, 22:36
Quote:
Ah, makes sense. Can I use invoke to call functions in the same way if I use GetProcAddress, or are they handled differently? |
|||
|
21 Feb 2010, 22:36 |
|
|
windwakr 21 Feb 2010, 22:39
Ya, you would store the return of GetProcAddress somewhere, and just invoke like:
invoke [varforaddress],blah,blah,blah |
|||
|
21 Feb 2010, 22:39 |
|
|
fasmnub 21 Feb 2010, 22:40
Brilliant, thanks for your help and patience!!
|
|||
|
21 Feb 2010, 22:40 |
|
|
revolution 22 Feb 2010, 00:37
Since you are already storing the DLL in your exe then ...
Instead of writing a DLL to disk and reloading it into memory a second time, just statically link in all the functions directly in the exe. The saves you the extra steps of writing stuff to disk and asking the OS to load it again. It also keeps all the code in one file, easier to manage. |
|||
|
22 Feb 2010, 00:37 |
|
|
LocoDelAssembly 22 Feb 2010, 00:42
revolution, he may be needing to create some window hook that needs a DLL. And another chance is that he needs to add a third party DLL (legally I hope) that is not distributed in source nor object form.
|
|||
|
22 Feb 2010, 00:42 |
|
|
fasmnub 22 Feb 2010, 00:46
@revolution, I'm very interested in this solution! Could you give an example of doing this?
If I can pull function addresses from memory, and call them with invoke that would be ideal. I don't necessarily need to write a file to disk if I can access the dll from memory. If you could show me how this is done I'd be eternally grateful. @LocoDelAssembly, I need to do it this way because a .dll I'm using (yes, legally! :p) has no source available, and uses strange bindings which complicates things. I want to reduce the number of .dll's that need to tag along with the .exe as much as possible. |
|||
|
22 Feb 2010, 00:46 |
|
|
revolution 22 Feb 2010, 00:52
fasmnub: LocoDelAssembly points out some good questions. Is the DLL your code? Do you have the source code or the object file? If you answer 'no' to these questions then you probably can't integrate it into your exe without a lot of work to reverse engineer it and shoehorn it in.
|
|||
|
22 Feb 2010, 00:52 |
|
|
fasmnub 22 Feb 2010, 01:01
revolution, the .dll is a 3rd-party library which I don't have the source to, but is called from a wrapper .dll (mine) which fixes some problems and does error-checking etc..
I need to keep the .dll count at 1 (a single .dll is fine), but currently I need 2; my wrapper dll, and the 3rd party dll. So, if I can get my wrapper .dll embedded into the exe, that would be fine. Another solution I tried was using polink, but that errors on fasm macros hence my messy approach of juggling .dlls in memory. |
|||
|
22 Feb 2010, 01:01 |
|
|
revolution 22 Feb 2010, 01:49
If your app is for general release then writing DLLs to disk may cause problems. Vista/Win7 and any non-admin user for WinXP/2K won't be able to write the DLL to the program directory. You would have to write it to the data directory. This is a very messy solution because you then also should clean up at exit to remove the DLL from disk. If the app causes a fault or is forced closed from the task manager then you get no chance to clean things up.
Why do you say you "need to keep the .dll count at 1'? Is this need strong? Strong enough to make you want to go through all the problems of embedding DLLs within other files and then finding places to write them to disk (and cleaning up) etc.? For simplicities sake I would suggest that you just simply include all the DLLs as separate files. This is more standard, less problematic and only needs to be put onto disk once at installation time. It is also more transparent to the end user and less likely to trigger AVs (and users) into panic mode. |
|||
|
22 Feb 2010, 01:49 |
|
|
fasmnub 22 Feb 2010, 02:05
Quote:
You have a good point. Keeping .dll's with the file is much cleaner, and easier. I just get the impression shipping a wad of .dll's is frowned upon; that said, I certainly don't want my app to appear dodgy in the eyes of AV's. The only reason for wanting to keep the .dll's to a minimum, is that the app compiles and spits out an .exe for end-user, and would be nicer if that was relatively stand-alone. Right now I'm considering all options. |
|||
|
22 Feb 2010, 02:05 |
|
|
windwakr 22 Feb 2010, 03:06
fasmnub wrote: ...I just get the impression shipping a wad of .dll's is frowned upon... Lots of programs/games come with "wads" of dlls. Just look at this folder for the game Half-Life 2, for example: http://filesmelt.com/dl/wads_of_dlls.PNG |
|||
|
22 Feb 2010, 03:06 |
|
|
f0dder 22 Feb 2010, 14:57
fasmnub wrote: You have a good point. Keeping .dll's with the file is much cleaner, and easier. I just get the impression shipping a wad of .dll's is frowned upon; that said, I certainly don't want my app to appear dodgy in the eyes of AV's. 
fasmnub wrote: The only reason for wanting to keep the .dll's to a minimum, is that the app compiles and spits out an .exe for end-user, and would be nicer if that was relatively stand-alone. _________________  - carpe noctem |
|||
|
22 Feb 2010, 14:57 |
|
|
cthug 22 Feb 2010, 15:04
Can't you statically link your wrapper?
_________________ "There are only two industries that refer to their customers as 'users'." Edward Tufte |
|||
|
22 Feb 2010, 15:04 |
|
< Last Thread | Next Thread > |
Forum Rules:
|