binaryninja-api icon indicating copy to clipboard operation
binaryninja-api copied to clipboard

Invalid operand size lifted as MLIL_CALL argument.

Open ek0 opened this issue 1 year ago • 2 comments

Version and Platform (required):

  • Binary Ninja Version: 4.1.5061-dev (587afcf1)
  • OS: Windows 11
  • CPU Architecture: x64

Looking at MLIL_CALL specifically, with the following prototype: uint32_t DbgPrintEx(uint32_t ComponentId, uint32_t Level, char* Format, ...). Looking at the disassembly we have the following listing:

1400857a3  mov     r15, qword [rdi+0x10 {_ARW_HELPER_OBJECT_IO::Length}]
1400857a7  mov     r9, r15
1400857aa  lea     r8, [rel `string'::[+] Name Length: 0x%X\n]  {"[+] Name Length: 0x%X\n"}
1400857b1  lea     r13d, [rbx+0x3]
1400857b5  mov     edx, r13d  {0x3}
1400857b8  lea     r12d, [rbx+0x4d]
1400857bc  mov     ecx, r12d  {0x4d}
1400857bf  call    qword [rel DbgPrintEx]

The call is lifted as follow:

   4 @ 1400857bf  DbgPrintEx(ComponentId: 0x4d, Level: 3, Format: "[+] Name Length: 0x%X\n", r9)

But all constant argument expressions are of size 8 instead of 4:

>>> current_function.mlil[4].params[0].size
8
>>> current_function.mlil[4].params[1].size
8

The value size should be 4. Looking at the LLIL:

  14 @ 1400857a3  r15 = [rdi + 0x10 {_ARW_HELPER_OBJECT_IO::Length}].q
  15 @ 1400857a7  r9 = r15
  16 @ 1400857aa  r8 = &`string'::[+] Name Length: 0x%X\n  {"[+] Name Length: 0x%X\n"}
  17 @ 1400857b1  r13d = (rbx + 3).d
  18 @ 1400857b5  edx = r13d
  19 @ 1400857b8  r12d = (rbx + 0x4d).d
  20 @ 1400857bc  ecx = r12d
  21 @ 1400857bf  call([DbgPrintEx].q)

// ...

>>> current_function.llil[21]
<LowLevelILCall: call([0x140002008].q)>
>>> current_function.llil[20].size
4
>>> current_function.llil[20]
<LowLevelILSetReg: ecx = r12d>

I seem to observe this behavior for MLIL_CALL only. The binary used is the HEVD 3.00. Assembly listing comes from CreateArbitraryReadWriteHelperObjectNonPagedPoolNx. HEVD3.00.zip

ek0 avatar Apr 04 '24 01:04 ek0

This may be intended. If you get the size of the type associated with that parameter is it as expected?

plafosse avatar Apr 09 '24 14:04 plafosse

Negative, this is the function prototype: image

ek0 avatar Apr 09 '24 14:04 ek0