Are the 16 bit x86 segments supported? #6353
Replies: 9 comments
-
Hi, I guess you forgot two bytes in your listing copy/paste. I created a snippet from your listing:
Import in Ghidra 10.3.3 with:
I get a correct result:
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. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
I moved the code block to the begging of a new segment and all the switches are now fine. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
I believe it should! For my |
Beta Was this translation helpful? Give feedback.
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
Hi @Wall-AF would you mind sharing your |
Beta Was this translation helpful? Give feedback.
-
@hjanetzek my current version is: |
Beta Was this translation helpful? Give feedback.
-
Thanks! @Wall-AF |
Beta Was this translation helpful? Give feedback.
-
Hello there,
I'm trying to decompile an old x86 16 bit application. Ghidra doesn't reference the following code correctly:
The last line reference the byte at physical address
0x00002
instead0x03002
I tried to edit the register manually
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
switch
es are in the wrong locations.Am I doing something wrong ? Or this I found a missing feature?
Beta Was this translation helpful? Give feedback.
All reactions