What makes the UI inline a string?

[yrp604]

I have a basic C program

#include <stdio.h>

int main(void) {
    puts("x");
    puts("This is a long string");
}

If I compile this on linux, my HLIL looks like this:

   0 @ 00001140  puts(str: "x")
   1 @ 0000114c  puts(str: "This is a long string")
   2 @ 00001157  return 0

If I compile the same program on Windows and fix up the types I get this:

   0 @ 14000100b  puts(str: data_140017000)  {"x"}
   1 @ 140001017  puts(str: data_140017008)  {"This is a long string"}
   2 @ 140001022  return 0

In both bndb's the datatype of the pointer is char const [sz] and puts is uint64_t puts(char const* str). What makes the linux call inline the string while the Windows call does not?

[psifertex]

Given the same type information, the differences come down to one of two things, if you can double check to see which applies that would be helpful:

• First, memory permissions on the destination. That said, given that the annotation is shown at all, our guess is this probably isn't the case, but it can be a factor of some inlining which is why we're mentioning it here
• Secondly, do data variables exist at the destination of those calls?

[yrp604]

It was the former, PE's place their strings in .data as opposed to some other read only memory region by default it turns out.

[psifertex]

I think we've talked about inlining string annotations /despite/ the memory permissions in instances where we know the argument of a function call anyway. Arguably the string could change, but it's probably safer to do that than not. Whereas in normal annotations where we're just guessing that something looks like a string at a location and annotating it to the side, we don't necessarily know the type.

This is probably something we could improve the defaults on.