Compiled DLL's 2

[DirtyB]

We need to change some pretty serious DLL's that were written here a while back. The original coder is no longer with us, and now we're stuck with about 50 of these mission critical DLL's and no source. Does anyone know of a way to decompile them, or i've heard that there are tools available that can show you the functions and parameters of the DLL's? Does anyone have any suggestions?

Thanks

 

[jmarler]

When you mention that you are interested in the function in the DLL, are you talking about methods/attributes on a COM interface, or are you talking about exported API calls? - Jeff Marler B-)

 

[DirtyB]

Thank you for your response. I'm not very familiar with COM and how it works, but i'll try to clarify. Basically everything that touches our database is in the DLL's. I really just need to know what stored procedures each DLL is calling, and I also need to know what parameters each DLL can recieve. Also, we think that one of the DLL's might possible have a math problem in the code, some of our numbers aren't coming out right. So, basically we need to see the code for the DLL's.

 

[jmarler]

OK, here are a few quick ideas . . .

- If the DLLs are COM/ActiveX DLLs, you can use an application that comes with Visual Studio called OLEView to view the TypeLib information. This will give you all of the publically available functions, their parameters, and their return types. In the event that you can not find or do not have this program, you could also just reference the library inside of Visual Basic and then hit F2 to bring up the object browser, but that will not give as much information.

- If you are looking at available APIs, then you could run a program (also with Visual Studio) called DumpBIN with the "/EXPORTS" switch (i.e. Dumbpin /EXPORTS C:\MyDll.dll) and this will give you all of the exports APIs with the DLL. This will not, however, give you parameters or return types . . . I'm still looking for a way around that one myself for an application that I am developing.

- If you need to know what stored procedures the DLLs are calling and you don't have the source code, the next best thing that I could think of would be to put a trace on the Database and log all of the calls that the DLLS make when they are running. That should give you a list of all Stored Procs and SQL used by the DLL.


- Finally, viewing the math used internally by the DLLs is going to be very difficult without the source code. You could, of course, just look at the disassembled code (DumpBin will disassemble code for you as will the basic Debug.com utility that ships with Windows), but if you do not know machine language/assembly, this is going to be very hard to read and follow. I think that unless you want to go really low level with this one, you are going to need the source code in order to see the math used by the DLL.If you want to use Dumpbin for the Disassmbly, use ther "/DUMPBIN" switch.



I hope that some of these ideas will help you out . . . if you need some more help, just let me know. - Jeff Marler B-)

 

[chiph]

Jeff -

I'm guessing that the old VB decompilers (from VB4 days) won't work anymore, since the default for compiling is to produce native code?

Otherwise, I think you've got the right approach. Inspect the COM interfaces, the Win32 API calls made, and watch the SQL log to see what stored procedures get called. And try and get lucky with the rest.

DirtyB -
This is a lot of work -- I think you *really* need to find that source code, and possibly contact the original coder to see if he/she kept a copy for themselves.

Chip H.

 

[jmarler]

Chip,
I have yet to see a "decompiler" that will generate good source code off of an existing VB binary. I agree that he really needs the original source code for the math problems that he is having . . . the only option he has now is to inspect the assembly code of the binary which may be more work than just rewriting the DLLs. - Jeff Marler B-)

 

[DirtyB]

You guys have been a ton of help. I really appreciate it. I'll try those solutions and if that won't answer my question, then we'll just have to re-write them. There are just SOOOOO many of them I was doing what I could to avoid a re-write. I'm going to definitely avoid the machine/assembly stuff, I avoid that like the plague. Thanks again, you've been very helpful.