In position independent shellcode for 32-Bit windows what are the most commonly used techniques for storing string variables. I've been using stack based strings:

  • Adjust the ESP register
  • Store the ESP value in EBP
  • Push the required DWORD strings onto the stack.
  • Use EQU to for the offsets names of the strings within the stack space to make life easier when using the variables later on.

My understanding is that I can't use variable definitions in the .data section as the offsets are unknown. I've tried disassembling a number of metasploit payloads to see how they work, but there don't seem to use any other techniques.

Any information about other options and their pro's and con's would be great.


Any writable location in memory that you can reference reliably. You also have to worry about corruption of these strings depending upon how many instructions are in between your write and taking control of execution.

If the exploit is remote then you cannot use envp to write a string and reference in your shell code. If it is a local exploit this may be an option.

Hopefully this is enough of a response. Exploiting some vulnerabilities takes more creativity than others.

  • Thanks for the info. With respect to the strings be corrupted you mean because the program may take some time to get to the point where the shellcode is executed and during that period the program could do something which overwrites some or all of the values. i.e the shellcode is specific to the vulnerability being exploited, in as much as there may be very limited address space to write the shellcode, requiring the use of staged payloads or using an egg/omelette hunter to place the code in a location which won't be corrupted by the program before execution of the shellcode. – Mark A Apr 8 '17 at 23:36
  • If you are using the stack to contain your strings and do not pivot the stck – Joshua Gimer Apr 9 '17 at 1:42
  • If you are using the stack to contain your strings and do not pivot the stack to a new location immediately upon obtaining control of execution, regular application execution flow may modify or corrupt the strings that you place on the existing stack. As far as use of egg hunters, encoders, or stagers; your first stage, egg hunting code or decoding routines all face the same challenges for corruption if you used a memory location that is modified by the application after your write, but before execution. It is the same issue, has nothing to do with buffer size. – Joshua Gimer Apr 9 '17 at 1:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.