yetmorecode / ghidra-lx-loader Goto Github PK

Executable used
N/A, code issue

Ghidra
N/A, code issue

Describe the bug
Sorry if it's a naive question, I am not good with Java. I can't find byte and word ordering fields used or checked anywhere. Do you assume they are always set to little-endian? If so shouldn't you at least throw "format unsupported" error when they're non-zero?

I'm new at ghidra but have been using IDA Free for a while.

I'd like to disassemble and analyze a DOS4GW-based game. After installing this extension and opening the executable, I expect to see the starting real-mode segments, and then the protected mode 32-bit segments for the rest of the code. I'm not sure this is actually happening. Is there anything specific I need to do?

Executable used
VREDIR.386 from windows 3.11

Ghidra
10.2

Describe the bug
Doesn't load anything.

Hi! I've been working on a reversing project for a little while on an executable file that I used the lx loader to analyze. I noticed a bit of an issue where it seems like there are several bytes that are messed up in ghidra. Specifically I've noticed the issue in four different instances in the data section of the executable, although it's feasible that its affected the disassembly too.
Here's the issue in action:

As you can see, the highlighted byte is a 0x00 where it seemingly should be a 0x17. I can manually override it to be a 0x17 and it accesses the proper address:

Here's a comparison with the same bytes in a hex editor (I know the addresses appear different but I think that has to do with how they're imported in the disassembler):

Interestingly, none of them in the hex editor are 0x17

And here's the same bytes in Ida:

More details:
I'm analyzing the RGFX.exe executable from The Elder Scrolls Adventures Redguard.
I'm running Ghidra 10.0.1 with the latest release of the lx loader.

These are the four addresses where I've noticed the issue so far:

0x001a2001 : should be 0x17 but is 0x00

0x001a4001 : should be 0x17 but is 0x00

0x001a2fff : should be 0x17 but is 0x00

0x001a5fff : should be 0x18 but is 0x01

Executable used
Which EXE are you trying to load? Can it be found somewhere for testing?

Ghidra
Which Ghidra version are you using?
10.2.3
Describe the bug
What's wrong?
Something is missing and watcom is not detected

I assume this NationalSecurityAgency/ghidra#156 (comment) is the correct compiler definition, but I'm not 100% sure