Far Call should be lifted as intrinsic

[ejm9]

The binja autoanalysis puts in (what I believe are wrong) code refs for the target of far calls to different segments. I have a 32 bit x86 sample file that shows the problem. The instruction is: 00000563 9af01900006000 call far 0x19f0, 0x60 {data_1f5a} So I believe the autoanalysis thinks the target of the far call to segment 0x60, address: 0x19f0 is supposed to be 0x1f5a, so it made a code ref to 0x1f5a (which is just a random location in the data section of this binary). In some cases, autoanalysis also created a new function (incorrectly) at the false target of the call far.

I believe that the autoanalysis will not be able to know what the target of a far call will be (unless its a far call to the same code segment). So to be safe, probably far calls to a different code segment should probably not have any autoanalysis target.

[psifertex]

Yes, unfortunately memory segmentation is not currently supported and therefore far calls will not function as expected.

[ejm9]

Jordan,

That's okay that memory segmentation is not implemented.

But I was wondering if auto analysis could be fixed so that it does not attempt to create any code refs for targets of far call instructions?

So if call type == far call, do not do auto analysis.

Thanks Eric

On Wed, Jun 24, 2020, 2:20 PM Jordan [email protected] wrote:

Yes, unfortunately memory segmentation is not currently supported and therefore far calls will not function as expected.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Vector35/binaryninja-api/issues/1775#issuecomment-648986555, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG7COKYTP4SZQW5SQ7KPMG3RYI7W5ANCNFSM4OB5OAMA .

[psifertex]

That's a good suggestion. Talking it over internally now.

[plafosse]

I think it'd be best if we made far calls lift the same as an unknown indirect call, until we have support for segmented memory.