L'écriture de shellcodes est soumise à des contraintes. En effet, un shellcode est une chaîne de caractères qui va être injectée en mémoire car elle sera en dehors de l'espace normalement alloué. Or les chaînes de caractères, dans la plupart des langages de programmation, ont l'octet nul (0x00) comme marqueur de fin. Par exemple la fonction strcpy en C arrête la copie de chaine dès qu'elle rencontre cet octet. Un shellcode ne peut donc pas contenir d'octet 0x00, sinon, il ne sera pas entièrement copié.
L'écriture d'un shellcode demande alors de n'avoir recours à aucune instruction assembleur contenant un octet nul (à l'exception du dernier). La tâche étant ardue, les concepteurs de shellcodes importants écrivent initialement un « chargeur » de shellcode servant à transformer un code assembleur (pouvant contenir des octets nuls) en un code ne contenant pas d'octet nul (le code du chargeur devant à son tour être écrit sans caractère nul). Une technique classique consiste à transformer chaque octet du code par une opération « ou exclusif » (XOR) : cette opération est simple, réversible, et on peut généralement (quoique pas à coup sûr) trouver une « clé » à appliquer au « ou exclusif » permettant d'éviter les caractères nuls.
Dans certains contextes, les contraintes sont encore plus sévères : le jeu d'octets autorisés peut être encore plus réduit. Il est possible que la chaîne envoyée au programme vulnérable ait précédemment été filtrée pour ne faire passer que des caractères alphanumériques (ayant un code ASCII compris entre 32 et 127 par exemple). On trouve un autre exemple classique sur certains systèmes fonctionnant en interne en UTF-16 (cf Unicode) : il arrive qu'une chaîne de caractères codée sur 8 bits soit d'abord « étendue » en UTF-16 (en ajoutant un 0 un octet sur deux généralement) puis traitée. Dans ce cas, les instructions qui pourront être exécutées par l'attaquant seront forcément de la forme XX00 (en hexadécimal), ce qui complique énormément la tâche du concepteur de shellcode.
Dans ces deux cas, la technique est la même que précédemment : écrire un « décodeur » avec ces contraintes qui transforme (en mémoire) le véritable code malveillant encodé précédemment. L'écriture du cœur du code malveillant (on parle de payload) est alors plus facile et indépendante du type de contraintes de la cible. Ainsi, il existe actuellement de véritables bibliothèques de construction de shellcodes permettant de l'assembler par type de fonction à réaliser et par contraintes (par "codeur" à intégrer).