Undocumented API Parameters 2

[jmarler]

Does anyone know of a way to get the number parameters and their types (I don't care about a param name . . . just number and type) on an API just by examining the binary file? Say for instance I run Dumpbin /Exports on Shell32.dll . . . there are several exported API with no names that need to be called by their ordinals and I am wondering if . . .

1) Is there a way to determine how many params are required and what the param types are?

2) Can this method (assuming that it exists) be summerized in an algorithm so that a programtic method can be developed that will analyze exported APIs in DLLs and list their parameters and types.



Thanks! - Jeff Marler B-)

 

[MichaelRed]

Yes,

but I cannot do it.

I know the answer, because I have seen a discussion and 'just for fun' tried the final example. After some thought, I decided that Without a huge amount of "testing" it would be difficult to figure out the point/purpose of the routines and deleted the routines from my system. Obviously, this doesn't help you DO this - hopefully it will get you to think beyond this step. If you figure out the Use of the information AND how to retrieve it, I would be interested - at least in the academic sense.

In that same discussion, I recall that one of the points made was that the un-nammed functions were (rather obviously) 'helper' functions (e.g. called from the nammed functions). Another point made was that the un-nammed functions could easily be changed in every version of the dll, and thus were not safe to use in general programming.


MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over

 

[LuckyLuke]

This might be a newb question, but could you explain me how I can retrieve the API functions from a dll, say that shell32 dll?

You say u do it with dumpbin/export, what does that mean (what is it).

This could be really usefull for me.

LuCkY

 

[jmarler]

MichaelRed,
If you know where you can across the code you mentioned, I love to see it. The purpose for retrieving the params list from the DLL itself is simple. I am currently developing a Programming Development Toolkit and part of that kit is an Advanced API management system (trust me, it does a lot more than the generic API veiwer) and one of the features that I was thinking about adding would be a API browse feature that would allow the user to at least scan through a list of all the exported APIs and their params on any DLL (similar to the way a user would use VB's object browser or OleView to scan the interfaces on COM objects). Currently, I am able to read the DLLs export directory on any DLL, but the only method that I can think of for getting the params is to scan the assembly code to see how many params are being pulled off of the stack (I was hoping for something a bit simpler and more reliable). As I said before, if you can think of where you saw the information you mentioned, please pass it my way.

LuckyLuke,

Dumpbin.exe is a command line utility that installs with MS Visual Studios and provides a wealth of information on any binary file. By using a variety of command line switches, you can get export lists (the available APIs), the import lists (the APIs that it uses and the binary dependencies), and the actual disassembly of the binary's source code. Sacn you PC for Dumpbin.exe and if you have it, go to a command prompt and type Dumpbin /? and you will see all of the options that are available.

- Jeff Marler B-)

 

[MichaelRed]

Jeff,

Completely clueless re the code source. It HAD to be somewhat simplistic, as I was able to implement it, but it was a while ago.

I MAY vaguely rember it from about the time period I was getting stuff from the PC Mag. site (Ziff Davis press?).

Really reaching at the moment, but it may have part of the process which was used to attempt to find unused (unreferenced) dll's on a hard disc. Thats one of those good ideas gone (WAY TO FAR) astray.


MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over

 

[LuckyLuke]

WOHOOOOOOOO this just made my day lol

 

[LuckyLuke]

OH yeah, once you've finished the program, I WANT IT jmarler ;-)

 

[jmarler]

Glad we could help make your day LIckyLuke . . . - Jeff Marler B-)

 

[MichaelRed]

If either of you get your projects to the production stage, I would be interested. More importantly - for me - would be understanding what use you can make of the undocumented calls in the dll's.


MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over

 

[jmarler]

LuckyLuke,
Opps! Obviously I meant LuckyLuke and not LIckyLuke . . . its a monday and I can't type! Sorry . . . - Jeff Marler B-)

 

[jmarler]

MichaelRed,
The title for this thread may be somewhat misleading . . . what I am trying to do is for all APIs, not just the undocumented one . . . as I mentioned before, this is a feature on a tool that I am designing that is intended to give information regarding any DLLs API. Of course, a developer could also look up the documented ons in an API reference book, but I am aiming for convience. In addition to access to the documented APIs, it will also display the undocumented APIs. Not all of these are useful, but some are and some are just nice to know.
As for a real use of one, check out thread792-81251 . . . here the undocumented API (ordinal #181 in Shell32.dll) was used to set up a system wide hook into the event queue.

- Jeff Marler B-)

 

[MichaelRed]

Jeff,

Thanks. I'll look it up. How do you keep track of the changes in the ordinal calls? I understand these are often different between releases (ver) of dll's.

Would you have some type of version checking? and re-do the analysis for each different ver found?



MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over