Invoke is Too High Level (2018)
xlogicx.net
Invoke is Too High Level (2018)
1–8 of 8 posts
Re: Invoke is Too High Level (2018)
#2So I've never heard of invoke or high level assembly so this is interesting to hear about.
Re: Invoke is Too High Level (2018)
#3This sounds like a pretty weird thing to complain about (especially coming from the reversing direction).
Is the problem merely that they don'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?
The reason for such a macro is because it makes calling Windows functions more similar to how they are documented. I think it's still possible to use an assembler yet want such a macro for common uses (like calling Windows functions).
Re: Invoke is Too High Level (2018)
#4This sounds like a pretty weird thing to complain about (especially coming from the reversing direction). Is the problem merely that they don'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 dire…
It sounds like the real problem is that the debugger (windbg) isn't smart enough to handle inline strings. If they had used a more powerful debugger they wouldn't have been confused enough to write a blog post about it.
Re: Invoke is Too High Level (2018)
#5This sounds like a pretty weird thing to complain about (especially coming from the reversing direction). Is the problem merely that they don'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 dire…
It sounds like the real problem is that the debugger (windbg) isn't smart enough to handle inline strings. If they had used a more powerful debugger they wouldn't have been confused enough to write a blog post about it.
Do inline strings even truly exist in assembly?
Re: Invoke is Too High Level (2018)
#6Earlier quoted context omitted.
It sounds like the real problem is that the debugger (windbg) isn't smart enough to handle inline strings. If they had used a more powerful debugger they wouldn't have been confused enough to write a blog post about it.
Do inline strings even truly exist in assembly?
They're just bytes in memory and there's nothing stopping you from putting whatever you want in the code section (as long as you don't try to execute it).
Re: Invoke is Too High Level (2018)
#7This sounds like a pretty weird thing to complain about (especially coming from the reversing direction). Is the problem merely that they don'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 dire…
I thought he was honest about it and specifically said it was more of a problem due to his perspective of it.
Re: Invoke is Too High Level (2018)
#8> See our first call to 'syscalls.40201B', it'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'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.
Nasty. I love it.
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?
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.