4

I am attempting to reverse-engineer a 16-Bit DOS MZ executable.

The file contains many different strings, most of which are printed out to the console at various points.

IDA seems to be able to pick up the locations from which the strings are utilised, for example:

IDA String Information

Clicking on this reference shows the code that utilises the string, which I assume passes it into the function (sub 1462) which prints it out to the screen.

Code that utilises the above string

When I attempt to analyse the same code in Ghidra, it is unable to pickup the same strings. I have manually gone to the location shown in IDA, and setup the "print" (sub 1462) function in this way:

PrintString Function Definition

So I would expect the decompiler to show the string, however it doesn't seem to pick it up:

Print String Function in Ghidra Decompiler

Print String Function in Ghidra Decompiler

I'm assuming that this has something to do with the stack pointer being set (or assumed to be) an incorrect value? However, Ghidra seems to locate this string at a different location to IDA:

IDA String Location

Thanks, James.

3
  • 1
    The address in concat 541 is different from string address 501. Also check segment mapping may be you need to manually adjust bounds
    – blabb
    Apr 17, 2023 at 6:26
  • @blabb Yes, that's what confused me. The assembly references the address used by IDA for that string, however Ghidra seems to have mapped the strings to a slightly different location.
    – jttri777
    Apr 18, 2023 at 0:15
  • @blabb, that was it! Ghidra seems to have got somewhat confused when analysing the strings. I've posted an answer explaining. Thanks for your help.
    – jttri777
    Apr 18, 2023 at 0:24

1 Answer 1

3

I managed to solve this one myself thanks to @Blabb's comment (thanks again!).

The first identifiable string was MS Run-Time Library - Copyright (c) 1992, Microsoft Corp.

For some reason, this managed to throw Ghidra off, and it added just this string to a memory segment of its own. This, therefore, offset all of the other strings as they were pushed down into their own memory segment, causing the incorrect offsets.

To solve this, I used Ghidra's Memory Manager to remove the two memory segments, and then create a new one with all the strings combined.

Before: Ghidra Memory Map before changes After: Ghidra Memory Map after changes

As a result of these changes, and with the DS register set to the correct offset, the string now shows in the decompiler window.

Strings showing in the Ghidra decompilation window

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.