Incorrect lifting in MLIL, HLIL when dereferencing ptr - x

[yeggor]

Binary Ninja Version
Binary Ninja 2.4.3083-dev

Describe the bug
Consider the following C code (test.c):

#include <stdint.h>
#include <stdio.h>

int check_here(uint64_t *data) {
  printf("%llu\n", *(data - 1));
  printf("%llu\n", *(data - 2));
  return 0;
}

int main() { return 0; }

This code is built using the following command (attached binary: test.zip):

clang -O3 -arch x86_64 test.c -o test

Below is the disassembled output of the check_here function:

100003f10  int64_t _check_here(void* arg1)

int64_t __saved_rbx  {Frame offset -18}
int64_t __saved_r14  {Frame offset -10}
int64_t __saved_rbp  {Frame offset -8}
void* const __return_addr  {Frame offset 0}
void* rbx  {Register rbx}
void* arg1  {Register rdi}

100003f10  _check_here:
100003f10  55                 push    rbp {__saved_rbp}
100003f11  4889e5             mov     rbp, rsp {__saved_rbp}
100003f14  4156               push    r14 {__saved_r14}
100003f16  53                 push    rbx {__saved_rbx}
100003f17  4889fb             mov     rbx, rdi
100003f1a  488b77f8           mov     rsi, qword [rdi-0x8]
100003f1e  4c8d356f000000     lea     r14, [rel data_100003f94]  {"%llu\n"}
100003f25  4c89f7             mov     rdi, r14  {data_100003f94, "%llu\n"}
100003f28  31c0               xor     eax, eax  {0x0}
100003f2a  e835000000         call    _printf
100003f2f  488b73f0           mov     rsi, qword [rbx-0x10]
100003f33  4c89f7             mov     rdi, r14  {data_100003f94, "%llu\n"}
100003f36  31c0               xor     eax, eax  {0x0}
100003f38  e827000000         call    _printf
100003f3d  31c0               xor     eax, eax  {0x0}
100003f3f  5b                 pop     rbx {__saved_rbx}
100003f40  415e               pop     r14 {__saved_r14}
100003f42  5d                 pop     rbp {__saved_rbp}
100003f43  c3                 retn     {__return_addr}

And part of the LLIL output:

 4 @ 100003f17  rbx = rdi
 5 @ 100003f1a  rsi = [rdi - 8].q
 6 @ 100003f1e  r14 = data_100003f94  {"%llu\n"}
 7 @ 100003f25  rdi = r14
 8 @ 100003f28  eax = 0
 9 @ 100003f2a  call(_printf)
10 @ 100003f2f  rsi = [rbx - 0x10].q
11 @ 100003f33  rdi = r14
12 @ 100003f36  eax = 0
13 @ 100003f38  call(_printf)

That is, the following values are passed to the printf function as the second argument:

• [rdi - 8].q
• [rbx - 0x10].q

But the HLIL looks like this:

100003f10  int64_t _check_here(void* arg1)

100003f2a      _printf("%llu\n", *(arg1 - 1))
100003f38      _printf("%llu\n", *(arg1 - 1)) // error here
100003f43      return 0

This is wrong, the HLIL should look like this:

100003f10  int64_t _check_here(void* arg1)

100003f2a      _printf("%llu\n", *(arg1 - 1))
100003f38      _printf("%llu\n", *(arg1 - 2)) // fixed
100003f43      return 0

The MLIL output for this function is also incorrect:

     100003f10  _check_here:
 0 @ 100003f17  rbx = arg1
 1 @ 100003f1a  rsi = [arg1 - 1].q
 2 @ 100003f28  rax = 0
 3 @ 100003f2a  _printf("%llu\n", rsi)
 4 @ 100003f2f  rsi_1 = [rbx - 1].q  // error here (expected [rbx - 2].q)
 5 @ 100003f36  rax_1 = 0
 6 @ 100003f38  _printf("%llu\n", rsi_1)
 7 @ 100003f3d  rax_2 = 0
 8 @ 100003f43  return 0

Version and Platform (required):

• Binary Ninja 2.4.3083-dev
• OS: macOS Monteray
• Version: 12.0.1

Additional context

• If we change the type of arg1 (data) from void * to uint64_t *, the HLIL looks correct (but MLIL is still not there):

  100003f40  int64_t _check_here(uint64_t* arg1)
  
  100003f5a      _printf("%llu\n", arg1[-1])
  100003f68      _printf("%llu\n", arg1[-2])
  100003f73      return 0
  

• https://binaryninja.slack.com/archives/C0CVALTLN/p1634916289038700

[D0ntPanic]

Fixed in build 3090

This bug was visual only and did not impact use of the API to access instructions.