When setting the bad chars for shell code, is there any downside to just assuming that you should mark \x00 and \x0a as bad?

2 Answers 2


For shellcode the only potential issue is size constraints. But assuming null bytes are bad is a bad habit. You might mistakenly think a crash is not exploitable because the only viable pop pop ret/ROP addresses start with a null byte.

Determining exact bad bytes isn't too time consuming and I always recommend doing it as it can save time if you need to troubleshoot your shellcode.

  • +1. Null bytes are not bad in every situation. It is only bad in overflowing a string input where it is treated as a terminator.
    – void_in
    Commented Jan 31, 2016 at 13:47

Not generally, since NULL and Line Feed are always bad chars. But size of your code will increase. I would not automatize this tho.

For example in IA32 Assembler you can replace the instruction

B8 01000000    MOV EAX,1          // Set the register EAX to 0x000000001


33C0           XOR EAX,EAX        // Set the register EAX to 0x000000000
40             INC EAX            // Increase EAX to 0x00000001

This even takes fewer bytes to encode, but generally it will be more tedious to replace chars as the number of bad chars increases.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .