Hi:

I'm trying to understand the difference between instruction displayed by disassemblers and the actual instruction shown in a DLL file (through a hex editor).

----------
DLL File(s): 16-bit MS-DOS DLL (protected mode)
----------

Scenario: Version 1 of this DLL works fine, but version 2 is crashing on a database insert (BTRIEVE). The main difference appears to be the size of the data segment that is referenced (trying to insert too much data).

When comparing disassembled versions 1 and 2 of the DLL, it appears that in the non-working version (2), the wrong data segment is being referenced and is about 4 times larger than in version 1.

In both versions of the DLL, the file hex instruction is shown as "B8 FF FF". My understanding is that this instruction is moving immediate value 65535 to register AX. However, I don't fully understand how the disassembler determines what data segment is actually being chosen.

------
Disassembled DLL: Version 1 (working)
------
Assembly:
Hex:

------
Disassembled DLL: Version 2 (non-working)
------
Assembly:
Hex:

------
DLL Hex Editor Instructions (both versions)
------
Hex:

As shown above, the disassembler shows different data segments used for both versions, but in the file through a hex editor, both versions just show "FF FF".

Question: How can I change the data segment that is being pointed to if the actual hex instruction is always "FF FF"? If the data segment chosen is determined at runtime, how would I go about doing some type of redirection? How does the program determine which segment to use?

The goal would be to try and force the program to use a different data segment in the MOV call. At least to test my theory out.

Using the above info, if data segment "35" appears to be the correct data segment, how can I tell the DLL to use segment 35 instead of 66?

Is it possible to do this?

Thanks.

This is probably a relocation place holder. The value 0xFFFF has no meaning and the actual value is placed by the OS loader at program start-up.

But if this is something else (we don't know since you never gave us any code) then you would need to look deeper and see what is really going on with a debugger.

Thanks for the reply.

I'm using IDA for disassembling but I'm having problems getting access to the IDA forums or I would have posted this there.

This is an older program that I am trying to run and don't have access to any source code. I feel thankful just to at least have a working version of the DLL (older version 1). The newer version of the DLL provides some features that I would like to have though.

I can paste a bigger snippet of the disassembled code but the DLL itself is almost a 1MB so the complete disassembled code is lengthy.

V1 (working):

V2 (non-working):

Since this is a DOS-Based 16-bit application, I've been having to run this program under DOSBox. This program also uses the PharLap extender. The only debugger that I've gotten to execute the parent EXE file is DEBUGX. DOSBox's own debugger and GRDB both crash or freeze the program. I'm still having a hard time getting a breakpoint to even stick, though.

If this is some type of relocation, any other suggestions on how to attempt changing the data that is used for B8?

That code you posted doesn't help us in any way.

If you are 100% certain that the problem is that the wrong segment is being referenced then you can alter the DLL file's relocation table to make it any segment you want.

I suspect the actual problem is elsewhere from what you think it is. It would be very unlikely that an incorrect segment is being used in this type of situation.

rytz,

You may host relevant files somewhere and post link.