Invoke is Too High Level (2018)

&gt; See our first call to &#x27;syscalls.40201B&#x27;, it&#x27;s jumping past our first string. A call normally knows how to return to where we came from by pushing the address of the next instruction to the stack. In this case though, our program doesn&#x27;t intend to return to this at all, it is using that pushed address as a side effect, as that address really is the first byte of our string, it serves as a pointer to it, and it is now on the stack conveniently as an argument.<p>Nasty. I love it.<p>What is the rationale for doing this, rather than putting the strings in the rodata section or whatever they have in PE files, and pushing addresses as immediates?<p>Do the strings end up in the instruction cache? They are never interpreted as instructions, but they will be on the same cache lines as real instructions.

This sounds like a pretty weird thing to complain about (especially coming from the reversing direction).<p>Is the problem merely that they don&#x27;t like how the strings are inlined in the code section? (Where else would you put it? Automagically putting them in the data section would also be non-obvious). Or is the problem that they think invoke should error out if the parameter is not an integral type that can be a directly pushed? Or is the problem with macro assemblers and high-level features in general?<p>The reason for such a macro is because it makes calling Windows functions more similar to how they are documented. I think it&#x27;s still possible to use an assembler yet want such a macro for common uses (like calling Windows functions).

So I&#x27;ve never heard of invoke or high level assembly so this is interesting to hear about.