16-bit DOS incorrect hex/disassembly about reko HOT 6 CLOSED

I noticed you uploaded the binary in question in radareorg/radare2#21669. Running reko on this binary shows that we don't have an unpacker for the binary, which explains what you were observing. I will write an unpacker script for that binary and notify you here when it's done.

from reko.

Congrats, you found a bug that affects X86 disassembly, emulation, and lifting! The string instructions cmps/lods/movs etc accept a segment override prefix like es:. Turns out Reko was dropping those prefixes on the floor. This caused the unpacker code to fail. I'm working on a fix to make my fix to the "no unpacker for PKLITE" issue work :)

Reko has support for handling int 20h, once the unpacker is stable enough you should see the recursive disassembler stop when it reaches such instructions on MS-DOS. Let's see what happens to 50 00 00... once I have the unpacker working correctly.

from reko.

Thanks for reporting this. Some comments/questions:

1. You mention that the binary is packed. If so, it's possible that Reko has recognized the packer, automatically unpacked the binary, and in that way modified the data. This is expected behaviour. Are you seeing an informational message in the diagnostics window to effect of Image packed with <PACKER-NAME>? If so, which packer is it?
2. However, Reko doesn't currently provide the user with a way to inspect the binary before unpacking happens. Is this what you were expecting? If so, how do you envision it working? Would you, perhaps, expect a first Unpack binaries stage, followed by the Scan binaries stage which is the current next stage.
3. Reko proceeds in its analysis in several stages. The first stage is loading (which includes unpacking). This is where the screenshot you are showing is at. After loading, the user has a chance to mark code fragments as code. You should be able to right-click on a byte in the memory view, right-click it, and select Mark as procedure. This corresponds to your suggestion of being able to define functions at specific address. Any suggestions on how to make this more obvious are welcome!
4. Once you've loaded the file, and optionally manually marked any procedures, you need to push the Scan binaries button on the toolbar. This prompts Reko to perform a recursive scan of the binary to find as many procedures as it can.

from reko.

Apologies for the long response, let me follow up.

@uxmal

1. Reko says the signature is that of PKLITE, however when I reviewed PKLITE there was some discrepancies between the documentation and this binary. It appears that perhaps this is a modified version of PKLITE?
2. I understand that, this is not an obstacle for me. I'm currently dumping the segments out after they are unpacked.
3. This makes sense, appreciate the help - and it's just me not knowing how to use the software.
4. I did this stage, however the binary is packed so I didn't expect it to find much.

Now to your second comment:
Reko says its the signature of PKLITE, which it may be loosely based on but its not quite. Just to clarify, I don't really need an unpacker since I have a workaround by just dumping the memory out. It's moreover an issue with the disassembly itself in the code segment that isnt packed (the unpacker).

1. The int 0x20 terminate program should likely be a noreturn so it doesn't mess up the rest of the disassembly below it.
2. I'm still a little confused how Reko made the bytes "50 00 00" -> "50 00 08", was this because it thinks its PKLite? In any event this value seemingly changes depending if I run it in DosBox-X versus DosBox. I don't care for the correct value, but I think it makes sense to not change the bytes and keep it as it was originally written (50 00 00). Of course you will likely have better input on this than me - I'm more experienced with 32/64bit RE than 16 bit.

Appreciate all the help, I'm certainly looking to using Reko in the future. Also both radare2 and Reko were able to read this, Ghidra actually completely fails on this file, and IDA requires Pro for 16bit now.

from reko.

Ouch that is certainly not good, yeah they are all dependent on the segment prefixes. I'm sure the quality of the disassembly is going to be vastly improved after the update. Since I have the unpacked code dumped, I'll compare it to what the unpacker comes up with.

from reko.

After the commits above, the resulting scan (without human assistance) is:

The 05 00 08 issue is nowhere to be seen.

Thanks again for taking the time to report the issue here.

from reko.