Web Development

Ask something
Discussion Locked

Reverse engineering a DLL

0 helpful
16 replies

by guruofdos

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I program in VB Professional 3.0. Yes I KNOW it's 10 years old and only 16 bit, but that is precicely WHY I use it...I still have to support 16 bit platforms!

Also, with certain restrictions, VB3.0 programs run perfectly under 9x and NT4.0.

Here is my dilemma. Accessing hardware from VB is not a problem...there are plenty of 16 bit DLL's out there that allow VB3 to call functions within the DLL to talk to the outside world. I have several for ISA bus I/O, peripheral control etc and along with the DLL's I have the documentation on how to call the functions/routines within the DLL and what parameters are passed.

BUT....I have acquired a very interesting piece of hardware on an ISA card (what it does is not important) and have scoured the original software on the machine it was installed in, and found a DLL related to the card. Using QuickView allows me to see the names of the exports in the DLL but there I run out of information. I can use my knowledge of electronics to regenerate the circuit diagram of the card and find out HOW it works electronically, but I need a way of 'taking apart' the DLL to work out what the exported functions do and what parameters are passed to and from a routine (integer, single, long, arrays) etc. I know enough about assembly language to reverse engineer a *.com file, but how can I do the same for a DLL? Where can I find information on DLL structures or a tool to show the individual code chunks for each of the exports? I have used a program called Scanbin which gives me a little more info, but I need more data on DLL's themselves...preferably requiring little or no knowledge of C or Pascal!!

16 replies

by ann777

If you do a search on "reverse engineer a 16 bit dll" you'll pull up several hits as well.

The above link says it'll work with a 32-bit dll ; but it does not mention the older 16-bit dlls.

by guruofdos

Does not support 16 bit DLL's for Windows 3.1! The freeware Borg Disassembler is the closest tool I have found that will break down a DLL into raw code, but it needs a lot of tweaking to distinguish between data and code.

by guruofdos

Thanks for the answer, but I don't do 'C' and don't intend to! The article refers to DLLs that you have written...not third party DLL's and refers to their use in Visual C.

I do appreciate your thoughts and effort though!

by joseph moore

Well, I looked around also, and didn't find anything good. I found a product, PE Explorer, that does exactly what you need for 32-bit DLL files; unfortunately, it does not work for 16-bit (the web site for it states that exactly).
So, no luck there.
My only suggestion (not being a programmer, I don't know if it will be of any use) is to try and use STRINGS.EXE a free downloadable tool from Sysinternals.
Here is their description of STRINGS:

"Working on NT and Win2K means that executables and object files will many times have embedded UNICODE strings that you cannot easily see with a standard ASCII strings or grep programs. So we decided to roll our own. Strings just scans the file you pass it for UNICODE (or ASCII) strings of a default length of 3 or more UNICODE (or ASCII) characters. Note that it works under Windows 95 as well."

The download page is here:
http://www.sysinternals.com/ntw2k/source/misc.shtml

So, you could run STRINGS against the DLL you have, and see what kind of information it will gleam. Perhaps it will be useful to you.

hope this helps

by guruofdos

Restrictions include the fact that file dialogue boxes cannot handle long file names!!! Pain in the backside when bringing up file lists!!!

by guruofdos

Just for reference folks...Windows 16 bit .exe's and DLL's are in what is called NE (New Executeable) format. Win32 exe's and DLLS use the newer PE (Portable Executeable) format.

The difference? NE files have the original MS DOS Header and can actually be run in DOS...but all they do in DOS is generate a message stating 'This program requires Microsoft Windows!'. Anyway NE files still have the DOS header at offset $40h and PE's don't! This means that any disassembler or decoder for Win32 will not support NE's...unless explicitly stated on the pack!!

by thamer

You see,... 16bit (Windows 3.1) executables.
are a dying breed ... but, I believe Resource editor 6.30 as what you need as it can edit resource of EXE/DLL/etc of such execuatables ...

You can find this shareware @ http://hp.vector.co.jp/authors/VA003525/Eindex.htm

You may also want to see see what this pages has to offer ...

http://www.programmersheaven.com/zone16/cat633/index.htm

-VISUAL BASIC OFFICE 1.0 add-on: Req. Win 3.1, VB 2/3 and VBRUN300.DLL.... @
http://www.programmersheaven.com/search/download.asp?FileID=71

-EasyCODE: Reverse engineering, maintaining and documenting source code of almost any programming language using the ANSC method ... @
http://www.programmersheaven.com/zone16/cat516/3296.htm

Take care... I think you cried like me when Microsoft announced that they will not release any updates for ... Miss DOS ... leaving her to die die at the age of 21.

by guruofdos

Unfortunately, resource editors are only any good for extracting, er, resources!!! Resources are icons, bitmaps, wavs etc. The DLL I'm trying to back engineer is simply a low level library for controlling hardware on an ISA card.

The card itself is for use with a video camera to plot the X-Y position (in the video frame) of areas of the image that exceed a certain intensity. Sort of very primitive 'binary' machine vision.

The DLL is used to set parameters on the card, alter various settings and allow reading back of a memory array into Visual Basic. Basically, the video image creates a binary array of 1's and 0's in a static ram chip on the card, corresponding to areas of the picture that are above or below a user defined threshold. The DLL is effectively used to replace hardware I/O INP and OUT instructions which do not exist in Visual Basic, as well as perform status checks and configure settings for the card.

Just for information purposes...the system was originally designed for car wheel alignment where a laser is fitted to the front wheels and the camera and card plots alignment errors.

by jackofalltech

I'm not sure if this will help since it's been a few years since I did this kind of thing but...

DLLs are just glorified EXEs. If you look at the first 2 bytes, you'll see the familiar MZ. Disassembling EXEs is not quite as simple as COMs because of the relocatability but it can be done.

There is an old shareware disassembler called DIS86 (you can find it on WWW.CDROM.COM in the DOS\Programming Utilities section). It had a fairly comprehesive set of instructions and examples if I remember correctly.

Ralph

by guruofdos

A DLL is to all intents and purposes an EXE. With one major difference. An EXE can call a DLL...you cannot run a DLL directly. However, although DOS EXEs can be disassembled easily (once you understand loaders and Program Segment Prefixes).

Windows 16 bit programs (and libraries) start with the header bytes NE not MZ. The MZ is present in the DOS stub at offset $40h. Win32 files have a header starting with PE and no longer have the DOS stub. A DOS disassembler can't handle Win16 files correctly, and most EXE decompilers for Win32 don't do Win16 files because of this stub.

Thanks for the info though!

by guruofdos

IDAPro (available from Simtel.net) actually decompiled my DLL and gave me the list of exported functions.

What it didn't do, is tell me what needs to be passed and what gets returned. The raw assembly uses registers, and assembly languages (and C) use pointers, which are not explicitly supported by VB3. The VB3 Runtime Library (VBRUN300.DLL) has only one function...converts variables to pointers to allow VB to run under Windows!

So, IDAPro is the closest answer yet...but I'm still looking for a program to insert DLL in one end and get a table of calls and parameters out of the other. Perhaps this is a bit of a holy grail...like wanting a machine to insert 'sausage' and produce a live pig out of the other end.

One suggestion wasgiven to me by a friend. The original EXE files that use the DLL were written in VB3Pro. I need to get a VB3 decompiler that can recreate the .mak, .bas and .frm files. Then the DLL makes no odds....the VB code will tell me how to use it!

Thanks for trying everyone...appreciated the suggestions. All hints filed away for reference.

Thanks!

Mike

This discussion is closed to new replies.