0

This is the code I've managed to build so far to implement DLLSkeleton.dll: http://archive.org/download/lowlevelDLL32_try0000/x86_WinAPI_ASM_PE_EXE_Skeleton32--v2017-07-26.zip

I'm trying to make a DLL purely in assembly. So far I've been able to create the export table and a function with an ordinal, 01, to export the TestHello function.

The DLL runs properly when loaded by usedll.exe, but only when the functions don't contain anything. When I add a call to MessageBoxA, the program crashes silently but I don't know how.

I've imported just about all standard WinAPI functions from the DLL. It works without problems when I create an EXE from scratch (for example http://devel.archefire.org/downfile.php?path=/PRJ/clockcount/&filename=2017-10-22--ClockCount.zip), but when I call something like MessageBox from the DLL, it doesn't work.

I've included the current code of the test DLL in pure assembly in the first ZIP. The export and import tables work well, the DLL is loaded properly when functions only contain a RET instruction (RET 12 for DllMain, which does nothing). So what else could be wrong when calling WinAPI functions from the DLL importing USER32.dll and others using the import table?

Improve this question
4
  • 1
    Questions on software development are off-topic here, but can be asked on Stack Overflow.
    – Megabeets
    Nov 7, 2017 at 14:16
  • It will probably won't be answered in Stack Overflow since this problem is dealing with implementing a 32-bit PE DLL directly in NASM Assembly, without involving any linker, make tools or import library objects, only assembly, and I'm currently stuck at crashing when using the WinAPI from the DLL, although it seems to work well if only using my own routines.
    – Sam V
    Nov 7, 2017 at 14:44
  • 1
    github.com/corkami/pocs/blob/master/PE/tinydll.asm
    – julian ♦
    Nov 7, 2017 at 15:17
  • 2
    Why not use a debugger to step into the call and see where it fails?
    – dsasmblr
    Nov 7, 2017 at 15:19

1 Answer 1

Reset to default
1

I have managed to implement a first attempt of a DLL, a DLL called WinAPI32.dll intended to import the entirety of the standard WinAPI and MSVC library from Windows 9x to Windows 10, and then export any custom functions and later data.

This will only load from a simple program, equally produced purely in assembly because of a bug/weakness I haven't been able to find yet. Another possibility is that the Iczelion test programs from tutorials 7 and 17 (which helped me understand the DLL function export table) aren't robust at importing libraries at run time, whereas I am importing the function of my DLL with the import table and it works. Probably many test programs and their DLLs (and some programs) are poorly implemented at loading the DLL functions they import at run time. Probably my first attempt of using the import library at assembly time is more robust in this case, but I will need to come up with a better version of the DLL and loading EXE.

See the binary if you want a fast preview of the implementation result: http://sourceforge.net/projects/x86winapiasmpedllskeleton32/files/2017-11-07--Pure_ASM_PE_EXE_DLL_32_bin.zip/download

Mirror (copy together the EXE and the DLL in the same directory): http://sourceforge.net/projects/x86winapiasmpedllskeleton32/files/2017-11-07--Pure_ASM_PE_EXE_DLL_32_src.zip/download

It's the full source code for the DLL and the DLL-loading program. So far I can only load the produced DLL with this program, but not with other standard programs like the ones from Iczelion, maybe because they load with LoadLibrary/GetProcAddress and I load with the static import table, and maybe the Iczelion test programs aren't robust enough, but I will have to implement a better version.

At least this is already a DLL implemented 100% in assembly code without the need of a linker or import library objects, but I had to use PEDUMP.EXE from wheaty.net to get the exports from the DLLs and an included HTML5 tool to generate the assembly code for the export table.

Improve this answer
2
  • This does not answer the question why the first attempt was not working. Did you want to update your question to address comments? use the edit button then.
    – Igor Skochinsky ♦
    Nov 8, 2017 at 12:42
  • The first message only contained initial but bogus/unusable code. This second message contains minimally usable code that at least works when the included DLL functions are imported via the import table instead of using LoadLibrary/GetProcAddress.
    – Sam V
    Nov 8, 2017 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.