Index
> Windows > [solved] Why does this produce an invalid DLL file? |
| Author |
|
|
revolution 08 Dec 2017, 00:18
You probably need a "fixups" section in there. Even a dummy one if there are no actual relocations needed. I seem to remember this problem from some time ago and IIRC this was the solution. Windows is quite fussy about DLLs being correctly laid out.
|
|||
08 Dec 2017, 00:18 |
|
|
Ben321 08 Dec 2017, 02:02
revolution wrote: You probably need a "fixups" section in there. Even a dummy one if there are no actual relocations needed. I seem to remember this problem from some time ago and IIRC this was the solution. Windows is quite fussy about DLLs being correctly laid out. Interesting. My new code is now: Code: format PE DLL entry dllmain include "macro\export.inc" section ".text" code readable executable dllmain: mov eax,1 ret 12 testfunction: ret section ".edata" export readable export "testdll.dll",testfunction,"testfunction" section ".reloc" fixups readable dq 0 Now it works, but it's not quite the same as other examples I've seen online. Other examples show "data export readable" instead of just "export readable" for the .edata section, and they show "data fixups readable discardable" rather than just "fixups readable" for the .reloc section. Is this critical for correct operation of DLL files (at least if the files are going to be more complex than just a simple test DLL file)? |
|||
|
08 Dec 2017, 02:02 |
|
|
revolution 08 Dec 2017, 02:21
I suspect that "data" is the default section type so Windows probably just assumes that if it is not "code". Or maybe fasm sets it as data? I can't check it right now, but you could compare two binaries and see if the "data" flag is actually set/unset in the two cases.
|
|||
|
08 Dec 2017, 02:21 |
|
|
Ben321 08 Dec 2017, 02:34
revolution wrote: I suspect that "data" is the default section type so Windows probably just assumes that if it is not "code". Or maybe fasm sets it as data? I can't check it right now, but you could compare two binaries and see if the "data" flag is actually set/unset in the two cases. I have checked some other DLLs, but I found most have their export table in the code section (or other section that isn't a dedicated exports section such as .edata), so comparing that to other DLLs isn't going to be easy. However the .relocs section does appear to have the data flag set. |
|||
|
08 Dec 2017, 02:34 |
|
|
revolution 08 Dec 2017, 02:46
What I meant was to assemble the fasm code twice, once with the "data" flag and once without. Then compare to see if the flag in the binary changes. I would check it myself but I can't right now. So that way you will know if Windows is just ignoring that flag.
|
|||
|
08 Dec 2017, 02:46 |
|
< Last Thread | Next Thread > |
Forum Rules:
|