Bug report : Issue with 16-bit call instruction.

[mylifeisabug]

I raised this bug over on the CyberChef issues page, and the devs over there pointed me here.

Basically, in 16-bit code, an intra-segment direct CALL (opcode starting with 0xE8) should only be three bytes long and take a single 16-bit displacement like so: 0xE8, disp-low, disp-high

But, the two bytes following the CALL are also grouped in with the opcode, which would be correct only in 32-bit code.

Here's a disassembly of a raw hex file containing the bytes E8 00 00 90 90 using ndisasm.exe with the CPU Mode set to 16-bit:

And here's a disassembly of the same file with the CPU mode set to 32-bit:

Neither of these are output by your x86 disassembler, in this case it outputs CALL 0005 and no NOP instructions which isn't correct. This form of CALL shouldn't be five bytes long in 16-bit code, it should be three bytes long instead.

[Recoskie]

Thanks for noticing the Call instruction 0xE8, and Jump instruction 0xE9 did not adjust displacement size to the set bit mode. The two instructions had been fixed.