Shellcoding | Shellcoding utilities | Hacking library

After another look at the question, your actual question was about concatenating stuff with a runtime-variable C-string from a known address in the target system. Like sprintf(buf, '\\%s\x.dll', 0x00xxxxxx).

(Actually it turns out it's actually a known constant length and value, and you were just trying to save payload size by copying it.) Update, see below for 35 byte versions that hard-code the whole string in the payload, and a 31-byte version that builds the \\...\x.dll string around the string instead of copying.

Copying data small amounts of data is hard. x86 instructions take code-size for the opcode and for the addressing modes (register or memory) of your data, unless except for instructions with implicit operands like stos or movsb, or push. And even those still use bytes for the opcode. Repeated single-byte elements are hard to take advantage of. At a large scale, if you have room to write a decompressor, you could include run-length encoding or even Huffman coding. But when your data isn't much bigger than a few instructions, it's all just little tricks like in the last part of this answer.

But maybe efficiently hard-coding it can be small enough, without reading the 13-byte IP address from a known address (which takes at least 7 bytes to generate in a register with mov eax, imm32 / not eax to avoid 0 bytes in the immediate)

In 32-bit mode, repeated push imm32 will build up an arbitrary-length string on the stack (in reverse order, of course).

Start by pushing an xor-zeroed register to get a 0-terminated C string. Your literal string is pure text, so I don't see any reason to worry about zero bytes other than that. But if you did, pad with a filler character and overwrite it with a byte-store from your zero register.

If it's not naturally a multiple of 4 bytes, you can sometimes expand \ to \\ or \\\ or \.\ in paths. Or use push imm8 for the last character (which you push first), also pushing 3 bytes of zeros for free. (Assuming your character is 1..127 so sign-extension produces zeros instead of 0xFF). For this case specifically, WinExec splits on spaces so push ' ' can push a space + terminating 0 bytes.

And/or if 4-byte alignment of the stack isn't needed, use 4-byte push word imm16 for the last 2 bytes of data (operand-size prefix + opcode + 2 bytes of data = 4 bytes of code).

The payload-size overhead is 1 push opcode byte per 4 string bytes, plus the terminator, with the string size potentially padded up to a multiple of 4 byte.

The other main option is to include the string as literal data after the payload.