HLIL display and pointers into the middle of a structure

[yrp604]

I have a 0x100 byte structure defined on the stack, going from frame offset -100 to -200:
struct block_t buf1 {Frame offset -100}.

Later in this function, a pointer to the middle of this struct is created and used (MLIL):

  47 @ 0000156c  void* x1_6 = &var_1a0
  48 @ 00001570  char* x0_16 = x22
  49 @ 00001574  memcpy@4174(dst: x0_16, src: x1_6, sz: 0x20)

This generates awkward HLIL, where it looks like I'm reading uninit data:

  20 @ 00001574  var_1a0
  21 @ 00001574  memcpy@4174(dst: cleartext, src: &var_1a0, sz: 0x20)

I can change around the struct definition to have an element starting at offset +0xa0, but this doesn't change the output. This is one instance of this, but I'm pretty sure I've seen others similar. Is there some way I can clean up this output by undefining var_1a0 or defining it as an offset into buf1?

[plafosse]

This actually seems to be an issue in MLIL generation. There shouldn't be two variables here, and rather should be taking the address of the member in the middle of the structure.

[yrp604]

Should I file a bug for this? I created a new bndb to make sure I hadn't screwed something dumb up, and instead of creating a struct I just created a uint8_t buf[0x100] on the stack:

uint8_t buf2[256]  {Frame offset -200}
uint8_t buf1[256]  {Frame offset -100}

It looks like LLIL is correct:

  71 @ 00001568  x2 = 0x20
  72 @ 0000156c  x1 = sp + 0x290 {buf2[0x60]}
  73 @ 00001570  x0 = x22
  74 @ 00001574  call(memcpy@4174)

But, as you said, MLIL misses it somehow?

  47 @ 0000156c  void* x1_6 = &var_1a0
  48 @ 00001570  char* x0_16 = x22
  49 @ 00001574  memcpy@4174(x0_16, x1_6, 0x20)

Happy to provide binaries if they'd be helpful.

[yrp604]

One other thing I tried, if I create a structure that has a member that aligns to this offset, nothing changes:

struct test __packed
{
    uint8_t a[96];
    uint8_t b[160];
};

LLIL

  71 @ 00001568  x2 = 0x20
  72 @ 0000156c  x1 = sp + 0x290 {buf2.b}
  73 @ 00001570  x0 = x22
  74 @ 00001574  call(memcpy@4174)

MLIL

  47 @ 0000156c  void* x1_6 = &var_1a0
  48 @ 00001570  char* x0_16 = x22
  49 @ 00001574  memcpy@4174(x0_16, x1_6, 0x20)

[psifertex]

Sorry, yes, this should be a bug. 😛 We were actually just looking for it since we've got it slated for 2.1 and couldn't find it.

If you don't mind creating it (or I can) this is up for relatively soonish fixing.

[yrp604]

Peter already created one, the discussion just doesn’t show the link to it.

[yrp604]

#1649 tracks this.