The MASM Forum Archive 2004 to 2012

General Forums => The Campus => Topic started by: ecube on December 10, 2006, 08:31:55 AM

Title: Exports
Post by: ecube on December 10, 2006, 08:31:55 AM
Is there a way to have your exe built with masm export functions like a dll or anything similiar? Other than using a com approach, is there any other way?
Title: Re: Exports
Post by: Relvinian on December 10, 2006, 09:19:42 AM
Quote from: E^cube on December 10, 2006, 08:31:55 AM
Is there a way to have your exe built with masm export functions like a dll or anything similiar? Other than using a com approach, is there any other way?

Any function can be exported...Doesn't have to be in a .DLL....Just have .DEF file and/or use the 'export' keyword on your function.

Then to use those exports, like a DLL, you have to link with the .LIB.

Relvinian
Title: Re: Exports
Post by: ecube on December 10, 2006, 09:36:19 AM
Wow that's suprising, I should of known that too considering  i'm writing a pe encryptor...just never seen an .exe with an export table before so didn't even consider it, thanks a lot Relvinian.  :thumbu +rep points
Title: Re: Exports
Post by: Vortex on December 10, 2006, 09:58:03 AM
Relvinian,

Sorry but the method you described does not work if you wish to create an EXE exporting functions. A command similar to this one :
link /SUBSYSTEM:WINDOWS /DEF:srcfile.def srcfile.obj
creates a DLL.
Title: Re: Exports
Post by: ecube on December 10, 2006, 10:17:42 AM
http://support.microsoft.com/kb/72849

appears to work, though during compilation the function isn't running correctly yet.


*Edit
Now it works fine after I created a def file and linked it :D! Fantastic!
Title: Re: Exports
Post by: Synfire on December 10, 2006, 10:22:35 AM
The only difference between a DLL and an EXE is the value of  IMAGE_FILE_HEADER.Characteristics and the extention (as far as the header is concerned). So you _should_ be able to build exportable functions within your exe. My only concern would be with the handling of a "DllMain" as opposed to your applications entrypoint.
Title: Re: Exports
Post by: PBrennick on December 10, 2006, 01:10:54 PM
E^Cube,
I am glad to hear that you got it to work. Would you mind posting a small example showing it in action?

Paul
Title: Re: Exports
Post by: ecube on December 10, 2006, 09:16:10 PM
Hey,
actually I seem to have only got it to partially work. The example I uploaded calls the exported procedure which simply adds whatever you specify to eax, I provided two samples, test.exe links with exportexe.lib and dynamictest uses loadlibray and getprocaddress to call the exported procedure. If I try and use a windows api function like MessageBox however, in the exported procedure I get a stack overflow in test.exe during calling that procedure, can someone tell me how to fix this?

[attachment deleted by admin]
Title: Re: Exports
Post by: PBrennick on December 10, 2006, 10:29:30 PM
I am not certain it can be fixed. I am not certain it can be done.
Paul
Title: Re: Exports
Post by: ecube on December 10, 2006, 10:32:34 PM
It can be fixed and it can be done :) many apps export functions such as ollydbg,autocad, etc etc.. i'll fix it, probably just a small issue in my code.
Title: Re: Exports
Post by: PBrennick on December 10, 2006, 10:35:08 PM
Keep us posted, then.
Paul
Title: Re: Exports
Post by: ecube on December 11, 2006, 06:27:46 AM
Ok I got it to work, the problem before was a reloc issue so all addresses were off, i'll upload source in a moment,  I changed the base address with a link switch and have it generate a .map file so you can see all the addresses if you have to adjust later on. And let me just say I asked just about everyone and they all didn't have a clue, they told me to "just use dlls" lol...


*Edit

code uploaded

[attachment deleted by admin]
Title: Re: Exports
Post by: hutch-- on December 11, 2006, 09:39:32 AM
cube,

here is an example of a DLL calling an exported procedure in its parent exe.

[attachment deleted by admin]
Title: Re: Exports
Post by: ecube on December 11, 2006, 10:14:42 AM
Hutch,
Nice!, thanks for the upload, looks good. I like the fact an exe can call exported procedures from another exe and vis versa while both are running, seems to be a great way to communicate thus far.
Title: Re: Exports
Post by: Vortex on December 11, 2006, 05:25:23 PM
E^Cube,

Thanks for the example, nice work :U
Title: Re: Exports
Post by: Vortex on December 11, 2006, 08:16:36 PM
E^Cube,

\MASM32\BIN\link  /DEF:exportexe.def  /base:0x47290000 /MAP /MAPINFO:FIXUPS /SUBSYSTEM:WINDOWS exportexe.obj

The address 0x47290000, has it a special meaning? How did you calculate this value?
Title: Re: Exports
Post by: ecube on December 11, 2006, 11:58:18 PM
Thanks Vortex,
to answer your question as far as I can tell that number doesn't have any signifigance other than its a multiple of 64k and it changes the entry point. I could be entirely wrong ofcourse I have to test more. The problem as I said before was a reloc issue, so I adjusted the base address to see what would happen and it appears to have fixed it. Before for instance I tried a simple string copy operation in the exported procedure and have the calling exe then messagebox the buffer with the new string only it didn't copy the new string, it messagbox'd the string that was in itself instead of the exported function because they had the same address, so by adjusting the base address it gave it a higher address and resolved the conflicts. That's my understanding at this point.
Title: Re: Exports
Post by: hutch-- on December 11, 2006, 11:58:26 PM
cube,

Its worth keeping in mind that there are other methods of cross executable communication as well. Sending a private message with the HWND_BROADCAST value is one way of activating an event in an external exe file and where you need to transfer data in any quantity, you can use a memory mapped file that is accesible to both exe files that open it.

Where I can see you getting into trouble with the technique you are using is that Microsoft are closing methods of this type that don't run in the same memory space so you may end up with a broken app in a later OS version. It is viable with a DLL as it runs in the same memory space as the exe that calls it and you can directly address a procedure in either direction.