Are the 16 bit x86 segments supported?

[bog-dan-ro]

Hello there,

I'm trying to decompile an old x86 16 bit application. Ghidra doesn't reference the following code correctly:

1000:20e0 fa              CLI
1000:20e1 b8 00 03        MOV        AX,0x300
1000:20e4 8e d8           MOV        DS,AX
1000:20e6 8e d0           MOV        SS,AX
1000:20e8 8e c0           MOV        ES,AX
1000:20ea f6 06 02        TEST       byte ptr [0x2],0x1

The last line reference the byte at physical address 0x00002 instead 0x03002

I tried to edit the register manually

assume addrsize = 0x0 a
ssume CS = 0x1000 
assume DF = 0x0 
assume DS = 0x300 
assume ES = 0x300 
assume opsize = 0x0 
assume protectedMode = 0x0 
assume SS = 0x300

but still no joy.

The problem is even worse when it tries to decompile the code because it doesn't count the CS segment and most of the switches are in the wrong locations.

Am I doing something wrong ? Or this I found a missing feature?

[Tim---]

Hi,

I guess you forgot two bytes in your listing copy/paste.
Please make sure to include those, it makes it easier to reproduce.

I created a snippet from your listing:

echo 'fab800038ed88ed08ec0f606020001' | xxd -r -p > test.bin

Import in Ghidra 10.3.3 with:

• language: x86:LE:16:Real Mode
• base address: 1000:20e0
• then disassemble the first instruction

I get a correct result:

             assume DF = 0x0  (Default)
       1000:20e0 fa              CLI
       1000:20e1 b8 00 03        MOV        AX,0x300
       1000:20e4 8e d8           MOV        DS,AX
       1000:20e6 8e d0           MOV        SS,AX
       1000:20e8 8e c0           MOV        ES,AX
       1000:20ea f6 06 02        TEST       byte ptr [offset DAT_0000_3002],0x1
                 00 01

I guess you can try to reproduce with this small snippet to see if you have a sane behavior, then try reimporting your binary.

If it still fails, note that creating these references is the job of the "x86 Constant Reference Analyzer". Make sure that it is enabled and if it is, perhaps have a look at the application.log to see if something terrible happened during the analysis.

[bog-dan-ro]

Thanks a lot Tim for you super fast reply !

Sorry for not pasting the entire content :).

I tried again, and you're right it's slightly better (at least at first part).
Some of the references are okay, but mots of them are not:
I did the following steps:

• imported the file into ghidra 1.4 . I attached the file for you in case you want to give it a try.
• selected language: x86:LE:16:Real Mode, base address: 0000:0000. The file contains two parts: data which is loaded at phy address 0x3000 and code at phy address 0x12060. I crafted the file in order to import it at base 0000:0000. (see
  
  )
• set the entry point at 0x12060, and disassemble the first instruction (
  
  ) and (
  
  ).
• as I mentioned, first data references are quite okay, but most of them are not. e.g. open the defined strings view, select one of them (e.g. 0000:3983 Breakpoint interrupt), as you can see this string is not referenced. If you're searching for 0983 hex, you'll find that there is a PUSH instruction at 0x12ddf which should reference it (
  
  ).
• same problem with the switches, it seems that all the switches wrongly referenced. Check switchD_1000:6932::switchD which reference address 1000:0095, same switchD_1000:d19f::switchD ...

How can I tell ghidra that all the data segments are at 0x300 and the CS is at 0x1000 unless they are explicitly set to other values? Setting them at the begging doesn't help.

Is it possible to create a script which fixes all there references? If yes, where I can find the documentation for such scripts?

ioc_dbg.bin.zip

[bog-dan-ro]

I moved the code block to the begging of a new segment and all the switches are now fine.
Now the only issue I have is with data segments which defaults to 0 instead of custom value (in my case 0x0300).

[Tim---]

I looked a bit at the analyzer options and builtin scripts but unfortunately nothing seems to correspond to your problem.

It kind of makes sense. When the reference analyzer sees that you push a big value before calling a function, it assumes that it is a pointer. But it cannot know if it will be relative to CS/DS or another segment. Based on your last message, it assumes that it is relative to the current segment and creates the reference. Meh, that's a safe default.

You can try putting up a script to modify the references by adding an offset of 0x3000 starting from the ReferenceManager.
I don't know how painful it is but given that you have a lot of references it's worth a shot.

[Wall-AF]

... But it cannot know if it will be relative to CS/DS or another segment. Based on your last message, it assumes that it is relative to the current segment and creates the reference. Meh, that's a safe default.

I believe it should! For my 16-bit Protected Mode suit of apps, I modified ia.sinc to show the segment being used for all memory accesses, calls and jmps in the assembly. I just don't think that info has been passed over to the rest of Ghidra, or it isn't using it! Unfortunately, I don't know enough of the internals to fix it, sorry.

[bog-dan-ro]

I created a script which fixed most of the references to DS:ADDR . As I mentioned in my last comment the CS references where "fixed" by moving the code block to 2000:0000 instead of 1000:2060. That's fine as the code is relocatable.

The problem is that Ghidra keeps track to DS,ES,SS only if they are explicitly set (see my first post) into the current function.
If I set the DS,ES,SS registers values using Ctrl+R to the entire code block, ghidra doesn't use them when it analize the code....
What will help a lot is a way to tell Ghidra what is the default values for those regs when they can't be computed.

[hjanetzek]

Hi @Wall-AF would you mind sharing your ia.sinc ? I'm currently starting with my first 16bit disassembly project for 80186 firmware and this different interpretation of addressings give me lots of headache right now

[Wall-AF]

Hi @Wall-AF would you mind sharing your ia.sinc ? I'm currently starting with my first 16bit disassembly project for 80186 firmware and this different interpretation of addressings give me lots of headache right now

@hjanetzek my current version is:
ia.sinc.zip

[hjanetzek]

Hi @Wall-AF would you mind sharing your ia.sinc ? I'm currently starting with my first 16bit disassembly project for 80186 firmware and this different interpretation of addressings give me lots of headache right now

@hjanetzek my current version is: ia.sinc.zip

Thanks! @Wall-AF