> Of course, half of the values in this file violate some part of the ELF standard, and it's a wonder that Linux will even consent to sneeze on it, much less give it a process ID. This is not the sort of program to which one would normally be willing to confess authorship.
> On the other hand, every single byte in this executable file can be accounted for and justified. How many executables have you created lately that you can say that about?
> To build this vector, the handler code first needs to push onto the stack any information that doesn't fit within a 64-bit value; for x86_64 this is a platform capability description (the string "x86_64") and 16 bytes of random data (to help seed user-space random number generators).
Why can't the string "x86-64" be fit in a 64-bit value? It's six characters, so shouldn't it be 48 bytes?
48-bits, you mean, right? That's also missing the null terminator, which I assume is at the end of the string, but that still wouldn't put it at above 64 bits assuming that each character is a byte
Gah, yes. The stupid thing starts with "b" as well. And yes, with the null terminator, it should come to 56 bits.
So regardless of what architecture you're on and how long its platform capability description is, it goes on the stack. This also allows for for future expansion without forever constraining the string to be 64 bits.
acuozzo presented on HN the (re)discovery of Mel's picture in 2011: