using a DLL without documentation

8 views
Skip to first unread message

Michael Kaplan

unread,
Mar 4, 1999, 3:00:00 AM3/4/99
to
Not really. You can dump its exports, you can look in the VC++ debugger in
the disassembly window to try and see what it is being passed to it on the
stack... but in the end you really need docs to do this, otherwise you won't
get too far or too fast along....

Michael

J Leung <j...@usa.net> wrote in message
news:7bms19$gut$1...@imsp009a.netvigator.com...
> Given a DLL without any documentation. (imagine a black box...)
> Is there any way to know how to use it's function?
>
>

Tim Slattery

unread,
Mar 4, 1999, 3:00:00 AM3/4/99
to
"J Leung" <j...@usa.net> wrote:

>Given a DLL without any documentation. (imagine a black box...)
>Is there any way to know how to use it's function?
>

No. All you can do is get the names of the functions. You can't get
the calling sequence (number and type of arguments) without
documentation - or decompiling and minutely examining the resulting
ASM code.

--
Tim Slattery
MS MVP(DTS)
Slatt...@bls.gov

jimmy

unread,
Mar 4, 1999, 3:00:00 AM3/4/99
to
J Leung wrote:
>
> Given a DLL without any documentation. (imagine a black box...)
> Is there any way to know how to use it's function?
You can get a list of exported functions with dumbin. That doesn't give
you parameters and calling convention. For those you can disassemble the
code itself and see (and guess) what happens there. By no means is the
success of this procedure ensured <g>.

J Leung

unread,
Mar 5, 1999, 3:00:00 AM3/5/99
to

David McCabe

unread,
Mar 5, 1999, 3:00:00 AM3/5/99
to
J Leung wrote:
> Given a DLL without any documentation. (imagine a black box...)
> Is there any way to know how to use it's function?

Depends. Check its exports, first. If it has DllGetClassObject listed, you
may be able to use OLEView to look at its type library, which will get you a
long way.

If that fails, look at the other exports. If they are C++ mangled names, you
could try de-mangling them (by hand? or does anyone have a tool to do this?)
to get the function definitions.

Other than that, you're stuck, short of disassembling the code to see what
happens.
--
Dave
david....@balliol.oxford.ac.uk
http://users.ox.ac.uk/~ball0597/

Eduardo Morcillo

unread,
Mar 6, 1999, 3:00:00 AM3/6/99
to
Hi,

OK, you can get the DLL's export table (with dumpbin.exe). So you got the
names but you don't know the parameters or how much data you have to push
into the stack.

But how VB knows the amout of that that have to push and pop? VB knows that,
otherwise it can't show the dialog "DLL bad calling...".

------------
Eduardo Morcillo
Free ActiveX Controls: http://www.geocities.com/SiliconValley/Foothills/9940


Michael Kaplan

unread,
Mar 6, 1999, 3:00:00 AM3/6/99
to
Um, wrong. VB does a simple LoadLibrary and GetProcAddress.... then sets up
the stack as your suggested params tell it too. You get back bad dll calling
convention (or a crash) if it does not get back what it expects later on.

Don't make VB out to be smarter than it is here.... it relies on YOU telling
IT what to do here.... relying on you is stupid in the case where you are
calling random DLL exports hoping to learn how to call them.

Michael

Eduardo Morcillo <eda...@geocities.com> wrote in message
news:OENh$3Ba#GA....@uppssnewspub05.moswest.msn.net...

Eduardo Morcillo

unread,
Mar 7, 1999, 3:00:00 AM3/7/99
to
Michael Kaplan wrote in message ...

>Um, wrong. VB does a simple LoadLibrary and GetProcAddress.... then sets up
>the stack as your suggested params tell it too. You get back bad dll
calling
>convention (or a crash) if it does not get back what it expects later on.

>Don't make VB out to be smarter than it is here.... it relies on YOU
telling
>IT what to do here....

I just thought that VB does something more intelligent than that.

> relying on you is stupid in the case where you are
>calling random DLL exports hoping to learn how to call them.
>
>Michael

I'm not crazy.

Michael Kaplan

unread,
Mar 7, 1999, 3:00:00 AM3/7/99
to
It does not do anything more intelligent then this.

I did not say you were crazy.... I just said that VB is relying on YOU for
info, which makes VB foolish in this scenario since you have no idea how to
call this thing.

Michael

Eduardo Morcillo <eda...@geocities.com> wrote in message

news:OEy00sIa#GA....@uppssnewspub05.moswest.msn.net...

Eduardo Morcillo

unread,
Mar 7, 1999, 3:00:00 AM3/7/99
to
Michael Kaplan wrote in message ...
>I did not say you were crazy....

I know. I just said that i'm not crazy to do something like try to make an
unknown function to work.

Michael Kaplan

unread,
Mar 7, 1999, 3:00:00 AM3/7/99
to
Well, good luck. from VB's standpoint, you are not very trustworthy in hold
ing up your end of the contract on declares. :-)

Michael

Eduardo Morcillo <eda...@geocities.com> wrote in message

news:uiQjVEOa#GA....@uppssnewspub05.moswest.msn.net...

Paul Kohut

unread,
Mar 15, 1999, 3:00:00 AM3/15/99
to
If this is a repost, sorry.

You can use the api "UnDecorateSymbolName" located in IMAGEHLP.LIB
for just such a purpose. Below is a console based program to unmangle API
functions found in the import and export tables of exe and dll files. You
can also unmangle function names found in LIB files. To use the program
is a two step process. First you need to run "dumpbin" and direct the output
to a file. Then run the program below on the newly crated file.

Later,
Paul Kohut


***********************Begin cut******************************
// Undecor.cpp
// Copyright 1998, Paul Kohut
// Released to public domain.

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <io.h>
#include <fcntl.h>
#include <imagehlp.h>

//Make sure the linker can find "IMAGEHLP.LIB"

void main( int argc, char *argv[])
{
char string[180];
char rb[1000];

FILE *file, *outfile;

if(argc < 3)
{
char *thisfile = new char[strlen(argv[0]) + 1];
strcpy(thisfile, argv[0]);
_strupr(thisfile);
printf("\nusage: %s <input file> <output file>\n", thisfile);
printf("output filename will have extension \".und\" appended\n");
printf("\n");
printf("Program to undecorate functions found in \"lib\", \"exe\", and
\"dll\" files.\n");
printf("\nTo use on \"lib\" files, first run \"dumpbin\" with the
\"/linkermember\" parameter\n");
printf("against a library file with output directed to a file.\n");
printf(" example: dumpbin /linkermember mylib > libfuncs\n");
printf("With the above example the output will go into a file called
libfuncs.\n");
printf("\nTo use on \"exe\" or \"dll\" files, run \"dumpbin\" with either
the");
printf("\n /imports or /exports parameter.\n");
printf(" example: dumpbin /imports myexe > impfile\n");
printf("\n");
printf("Once a file with undecorated names has been created run %s on
it.\n", thisfile);
printf(" example: %s impfile outfile\n", thisfile);
printf("\nA new file named \"outfile.und\" is created with the function
names\n");
printf("and parameters showing\n");
delete [] thisfile;
exit(1);
}

file = fopen(argv[1], "r" );
if(file == NULL)
{
perror("Open failed on input file");
exit(1);
}
else
{
char *outname = new char[strlen(argv[2]) + 5];
strcpy(outname, argv[2]);
strcat(outname, ".und");
outfile = fopen(outname, "w");
if(outfile == NULL)
{
perror("Open failed on output file");
fclose(file); fclose(outfile);
delete [] outname;
exit(1);
}

if(fseek(file, 0, SEEK_END) !=NULL)
{
perror("fseek failed");
exit(1);
}
size_t count = ftell(file);
rewind(file);
char *buffer = new char[count+1];
size_t amount_read = fread(buffer, sizeof(char), count, file );
fflush(file);
char *concString = buffer;
char *offset, *offset1;
char *size = buffer + (amount_read + 1);
offset = buffer;
offset1 = strpbrk(buffer, "\n");

while(offset <= size)
{
*offset1 = NULL;
offset1++;
strcpy(string, offset);
concString = strpbrk(string, "?");
if(concString) {
int iSize;
char *endString = strpbrk(concString, " ");
if(endString)
iSize = endString - concString;
else
iSize = strlen(concString);
strncpy(string, concString, iSize);
string[iSize] = NULL;
DWORD dwErr = UnDecorateSymbolName(string, rb, 1000, 0);
if(dwErr == 0)
{
dwErr = GetLastError();
char lpMsgBuf[1000];
FormatMessage( FORMAT_MESSAGE_FROM_SYSTEM,
NULL, dwErr, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
lpMsgBuf, 1000, NULL );
}


fprintf(outfile, "%s\n", rb);
}
offset = offset1;
offset1 = strpbrk(offset, "\n");
}
}
fclose(file); fclose(outfile);
}
********************End cut**********************************


Paul Kohut

unread,
Mar 15, 1999, 3:00:00 AM3/15/99
to

Michael Kaplan

unread,
Mar 15, 1999, 3:00:00 AM3/15/99
to
People were not complaining about decorated symbol names; they were
complaining about not having the DLL calls params.

Michael

Paul Kohut <pko...@ibm.net> wrote in message
news:7cite2$1d...@enews2.newsguy.com...


> If this is a repost, sorry.
>

Paul Kohut

unread,
Mar 15, 1999, 3:00:00 AM3/15/99
to
Nope, re-read all the related posts and the questions / comments
are geared towards calling parameters. Undecorating the C++
names will give you the calling parameters and their return types.

For standard C style functions in a DLL your stuck with using
a good debugger or disassembler, pretty much as others have said
before.

Later,
Paul Kohut

Michael Kaplan wrote in message <#Z6KdVvb#GA.265@cppssbbsa03>...

Paul Kohut

unread,
Mar 18, 1999, 3:00:00 AM3/18/99
to
In article <OxCVhtHc#GA.267@cppssbbsa03>, gju...@one.net says...
> Paul
<<snip>>
> For instance, tell me how undecorating the names listed in this DUMPBIN
> output of a C++ DLL gives me the parameter names?

> 1 0 0000100A ?BSTRToCString@@YA_NPAGAAVCString@@@Z
> 2 1 00001005 ?GetErrorMsg@@YAXPADH@Z
> 3 2 0000100F ?LastErrorMsg@@YAXPAD@Z
<<snip>>
> void DllExport LastErrorMsg(char *buf);
> void DllExport GetErrorMsg(char *buf, int err);
> bool DllExport BSTRToCString(BSTR bstr, CString &cstr);

Fixing a bug in the code I posted it produces the following:

bool __cdecl BSTRToCString(unsigned short *,class CString &)
void __cdecl GetErrorMsg(char *,int)
void __cdecl LastErrorMsg(char *)

> I'm sorry, once a DLL is compiled, you're basically SOL as far as knowing
> how to call its exports (if all you have is a DLL)...

No, I can't get the original parameter names as defined by the
coder, but knowing the parameter types is a lot better than having
to look at stack entry and exit code via disassembly. When function
names are well defined, especially in the 3 samples you provided,
and the parameter list not to long, it's pretty easy to figure out
what each parameter might be.

I originaly wrote the posted code to get a list of functions and
calling parameters "types" for a large set of LIB files that had
not been documented by the prior programmer. About 40% of the
functions I was able to figure out how to use just by looking at
the unmangled function names. Of the 60 or so percent left I
was only able to figure out how to use maybe 10%. Still it's
better than what I started out with...

Another area were this code is useful (at least for me) is
when Autodesk puts out a new release of Autocad. The first thing
I do is dump it's imports / exports and unmangle the names. Then
run the list through a comparision routine and only keep new or
changed API's from prior versions.

I also have code like that posted, to unmangle function names in
recreating import libraries for Autocad LT. With this, custom ARX
(C/C++) programs can be written for LT (an area Autodesk didn't
intend).

Basically you use the infomation you've been provided with. When
the infomation isn't available, you have to start making your own
with what ever tools are at your disposal.

Later,
Paul Kohut

Paul Kohut

unread,
Mar 19, 1999, 3:00:00 AM3/19/99
to
In article <uIJhKHJc#GA.272@cppssbbsa03>, eda...@geocities.com says...
> Paul,

>
> >Nope, re-read all the related posts and the questions / comments
> >are geared towards calling parameters. Undecorating the C++
> >names will give you the calling parameters and their return types.
>
> Yes, but how many DLLs you saw with decorated names?

>
> Functions without name are more common than ones with decorated name.

Imported or exported function in a program or DLL written
in C++ and not defined as extern "C" will show up decorated.

For the VB people all bets are off.

Later,
Paul Kohut

Michael Kaplan

unread,
Mar 20, 1999, 3:00:00 AM3/20/99
to
It is common to use a DEF file to undecorate them, and then
we are back where we started.

Michael

Paul Kohut <pko...@ibm.net> wrote in message

news:MPG.115b92eea...@enews.newsguy.com...

Reply all
Reply to author
Forward
0 new messages