MZloader: some MZ header shorts are now treated as unsigned

[haarlaj]

Issue: MZ header info is stored as short (signed) but the actual data is unsigned. MZ loader uses these shorts in calculations and this might lead to wrong results if the number is treated as negative number instead of unsigned.

Fix: I added Short.toUnsignedInt() to each case to ensure correct outcome.

PS. Not sure it header.e_magic() if really needs it as it should always be the same. Anyway good to be consistant.

Fix compiles with
Fedora 39 (amd64)
Gradle 7.6.4

[haarlaj]

I'm finding contradicting information about the types (uint16/int16) in the MZ header so I'm retracting this PR.

[haarlaj]

After reviewing more sources I think this pull request is correct so I'm reopening it.

I was puzzled as I stumbled upon a site defining cs and ss fields as int16 [1]. I tried to find some other source to back this up. Other sources use only WORD, word, USHORT, unsigned short to describe the fields [2-7]. Only mention about something else is from MS-DOS encyclopedia where checksum field is described as ones' complement [3].

Therefore I think all values (except the checksum which is not used in MZloader) should be converted to uint16 before use.

[1] http://justsolve.archiveteam.org/wiki/MS-DOS_EXE
[2] https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Features/Base/src/main/java/ghidra/app/util/bin/format/mz/DOSHeader.java
[3] https://archive.org/details/The_MS-DOS_Encyclopedia_Ray_Duncan/page/119/mode/2up
[4] https://archive.org/details/PC_System_Programming/page/67/mode/2up
[5] https://wiki.osdev.org/MZ
[6] https://blog.kowalczyk.info/articles/pefileformat.html
[7] http://www.delorie.com/djgpp/doc/exe/

[ryanmkurtz]

I'm finally able to take a look at this, sorry for the delay. If i recall correctly, there are certain areas of this code that expect subtraction to occur if the signed short is negative. That means that overflow still needs to happen if we use unsigned shorts. We won't get this behavior if we start using unsigned ints. I will look at some samples i have from other people's ticket submissions to see if i can find an example.

[ryanmkurtz]

Take a look at these tickets:

• Ghidra cannot load the x86 16bit binary with big segment offset #1876
• Exception thrown at loading MS-DOS EXE file if the e_CS in the MZ header is not 0 #5229

[haarlaj]

Thanks for the feedback. I had though the logic wrong in some of the calculations. Thanks for pointing that out. I'll check those files for future reference and test cases. I removed the faulty calculations from the PR.