First of all I wasn't very much into reversing until now, so excuse me if my question is dumb.

I have a windows DLL most likely made with Visual C++. It's been developed in 1998 and has Mfc42.dll (4.21.7022) and mfc42u.dll and msvcirt.dll (5.00.7022) distributed with it.

I managed to see function names exported by the DLL (it is easy) but not their parameters of-course. These functions are not called directly by any application, but I know they are called indirectly. I think they're being called by some other APIs, but the chain is unknown to me.

My question is: Is it possible to extract the function signatures (function parameters and return value), write some kind of bindings (that should be possible) and finally call them myself?

The last addition is that DLL in question has DllRegisterServer and DllUnregisterServer functions.


The DLLs I'm talking about are from an old speech synthesizer L&H TTS3000. I wanted to research it more for fun than for something real and as it is extremely old and retired that shouldn't run into any trouble. So if any one wants to reproduce these DLLs you can browse to this page: http://www.v3mail.com/download/ttsengines.htm and download any of the extra voices. They are not available (files are deleted) but they could be downloaded using web.archive.org. So here is a dumpbin example for one of the english voice DLLs

dumpbin Engvf160.dll /exports
File Type: DLL

  Section contains the following exports for ENGVF160.dl

           0 characteristics
    373160B4 time date stamp Thu May 06 13:28:20 1999
        0.00 version
           1 ordinal base
          99 number of functions
          18 number of names

    ordinal hint RVA      name

         97    0 0000E23A DllRegisterServer
         98    1 0000E25B DllUnregisterServer
         99    2 000099A0 TtsEgGetCodeInfo
          1    3 0000E280 vfClose
          2    4 0000E308 vfGenPcm
          3    5 0000E389 vfGetCaps
          4    6 0000EE61 vfGetSil
          5    7 0000EEA3 vfGetSpkr
          6    8 0000EF11 vfGetVersion
          7    9 0000F63D vfGetVol
          8    A 0000EF4E vfOpen
          9    B 0000F16D vfP2Tic
         10    C 0000F479 vfSetSegDb
         11    D 0000F482 vfSetSil
         12    E 0000F4D6 vfSetSpkr
         13    F 0000F550 vfSetSynthRange
         14   10 0000F67F vfSetVol
         15   11 0000F6D3 vfTuneSpkr


        7000 .data
       7B000 .rdata
        3000 .reloc
        1000 .rsrc
        F000 .text


... Section contains the following imports:

             63470020 Import Address Table
             634EA1C0 Import Name Table
                    0 time date stamp
                    0 Index of first forwarder reference

                308  lstrlenA
                1F5  OutputDebugStringA
                2FF  lstrcmpiA
                17D  GetWindowsDirectoryA
                2F9  lstrcatA
                302  lstrcpyA
                 5D  DisableThreadLibraryCalls

             63470000 Import Address Table
             634EA1A0 Import Name Table
                    0 time date stamp
                    0 Index of first forwarder reference

                176  RegQueryInfoKeyA
                162  RegDeleteKeyA
                15B  RegCloseKey
                172  RegOpenKeyExA
                15F  RegCreateKeyExA
                186  RegSetValueExA
                164  RegDeleteValueA

             63470040 Import Address Table
             634EA1E0 Import Name Table
                    0 time date stamp
                    0 Index of first forwarder reference

                291  malloc
                 F1  _ftol
                2B3  sqrt
                18E  _pctype
                115  _isctype
                 61  __mb_cur_max
                2C1  strncpy
                2B0  sin
                258  fprintf
                113  _iob
                2B2  sprintf
                2BA  strcpy
                25E  free
                299  memset
                10F  _initterm
                 9D  _adjust_fdiv
                297  memcpy
  • 1
    So you seem to be dealing with a COM server of some kind. Of course you can try to find the signatures. If you're lucky the type library is included in the resource section already. Does it export more functions than the two you named? It may be helpful if you offer the output of dumpbin or a screenshot with CFF Explorer or something along these lines.
    – 0xC0000022L
    Apr 6, 2016 at 15:18
  • Yes, it does have way more functions than I listed and their names make sense in context of the library usage purpose. I can provide dumpbin output, what keys should I include (e.g. exports or anything else)?
    – Gonzalez
    Apr 6, 2016 at 16:09
  • Exports and imports are both helpful. You might also be able to tell something about the parameters and return values by examining the functions - calling conventions might make it possible to identify what external values are being used by the functions. Apr 6, 2016 at 16:21
  • I've edited my post.
    – Gonzalez
    Apr 6, 2016 at 19:22

1 Answer 1


The Bad News

DllRegisterServer and DllUnregisterServer are two functions involved in the registration of a COM server DLL into the system. Therefore, their export is a good indication you're dealing with a COM server DLL. COM servers are infamous of their many indirect calls, mainly because a DLL server exposes from itself objects designed to be used by other executables and DLLs. You're likely to have to deal with many indirect calls between different executables.

The Good News

Now, the good news are that because COM defines functions to and objects in such a freestyle way, it also encourages creation of Type Library files (*.tlb). Those files have a machine-readable format that defines the classes, methods, interfaces in details. If you can find the Type Library file(s) for your DLLs, you could extract all function arguments (Including names!), function return types, etc. directly from those files.

Type Library files are likely to be in the application's directory, with other application resources or as part of the PE file itself. There are several Type Library file readers, as well as python implementation (pythoncom.LoadTypeLib from the win32 package).

Documentation is a bit scarce, but having a Type Library will make the entire reverse engineering easier.

If all else fails

In the unfortunate case you can't find the Type Library file, you'll have to reverse engineer the functions you're interested in intercepting, and extract the meaning (and types, and sizes) of parameters from the functions themselves. This is often a bit trickier compared to having both caller and callee, but is quite doable. I the case of a in-process COM server, you can even debug the calls to your COM server quite easily (by debugging the executable that loads the DLL/com server, the COM client, and placing breakpoints on methods of the COM server).

One last thing, there are some automated tools that attempt to automatically generate a DLL proxy, here's one.


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.