flat assembler
Message board for the users of flat assembler.

Index > Main > Writing a .dll file from memory before importing it?

Author
Thread Post new topic Reply to topic
fasmnub



Joined: 26 Jan 2010
Posts: 14
fasmnub
I need to do the following in fasm..

1. Check if blah.dll exsists in the current folder
2. If not, write it out from memory (the .dll will be stored in the exe as data)
3. Include it as a library, and import functions as per usual

also..

Is some kind of.. delayed .dll import..thing possible in fasm? Possibly related.

Is this even possible? If so, what is the best approach? Examples would be great.

Rolling Eyes
Post 21 Feb 2010, 19:38
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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.
Post 21 Feb 2010, 19:48
View user's profile Send private message Reply with quote
fasmnub



Joined: 26 Jan 2010
Posts: 14
fasmnub
@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?
Post 21 Feb 2010, 20:09
View user's profile Send private message Reply with quote
fasmnub



Joined: 26 Jan 2010
Posts: 14
fasmnub
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!! Sad
Post 21 Feb 2010, 22:05
View user's profile Send private message Reply with quote
windwakr



Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
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"

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!! Sad


Remove any mentions of the file from your import section. Use LoadLibrary and GetProcAddress like Loco said when you need it's functions.

_________________
----> * <---- My star, won HERE
Post 21 Feb 2010, 22:20
View user's profile Send private message Reply with quote
fasmnub



Joined: 26 Jan 2010
Posts: 14
fasmnub
Quote:

Remove any mentions of the file from your import section. Use LoadLibrary and GetProcAddress like Loco said when you need it's functions.


Ah, makes sense. Can I use invoke to call functions in the same way if I use GetProcAddress, or are they handled differently?
Post 21 Feb 2010, 22:36
View user's profile Send private message Reply with quote
windwakr



Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
Ya, you would store the return of GetProcAddress somewhere, and just invoke like:
invoke [varforaddress],blah,blah,blah
Post 21 Feb 2010, 22:39
View user's profile Send private message Reply with quote
fasmnub



Joined: 26 Jan 2010
Posts: 14
fasmnub
Brilliant, thanks for your help and patience!!
Post 21 Feb 2010, 22:40
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17492
Location: In your JS exploiting you and your system
revolution
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.
Post 22 Feb 2010, 00:37
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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.
Post 22 Feb 2010, 00:42
View user's profile Send private message Reply with quote
fasmnub



Joined: 26 Jan 2010
Posts: 14
fasmnub
@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.
Post 22 Feb 2010, 00:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17492
Location: In your JS exploiting you and your system
revolution
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.
Post 22 Feb 2010, 00:52
View user's profile Send private message Visit poster's website Reply with quote
fasmnub



Joined: 26 Jan 2010
Posts: 14
fasmnub
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.
Post 22 Feb 2010, 01:01
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17492
Location: In your JS exploiting you and your system
revolution
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.
Post 22 Feb 2010, 01:49
View user's profile Send private message Visit poster's website Reply with quote
fasmnub



Joined: 26 Jan 2010
Posts: 14
fasmnub
Quote:

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.


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.
Post 22 Feb 2010, 02:05
View user's profile Send private message Reply with quote
windwakr



Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
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

_________________
----> * <---- My star, won HERE
Post 22 Feb 2010, 03:06
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.
Shipping more than a single file isn't frowned upon - doing dodgy stuff that can likely trigger antivirial programs definitely is Smile

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.
Don't worry, really. One EXE and two DLLs? No sweat!

_________________
Image - carpe noctem
Post 22 Feb 2010, 14:57
View user's profile Send private message Visit poster's website Reply with quote
cthug



Joined: 03 Apr 2009
Posts: 36
Location: /home/Australia
cthug
Can't you statically link your wrapper?

_________________
"There are only two industries that refer to their customers as 'users'." Edward Tufte
Post 22 Feb 2010, 15:04
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.