Embed Size (px)
Citation preview
English Shellcode
Joshua Mason, Sam SmallJohns Hopkins University
Baltimore, MD
{josh, sam}@cs.jhu.edu
Fabian MonroseUniversity of North Carolina
Chapel Hill, NC
Greg MacManusiSIGHT Partners
Washington, DC
ABSTRACTHistory indicates that the security community commonlytakes a divide-and-conquer approach to battling malwarethreats: identify the essential and inalienable componentsof an attack, then develop detection and prevention tech-niques that directly target one or more of the essential com-ponents. This abstraction is evident in much of the litera-ture for buffer overflow attacks including, for instance, stackprotection and NOP sled detection. It comes as no surprisethen that we approach shellcode detection and preventionin a similar fashion. However, the common belief that com-ponents of polymorphic shellcode (e.g., the decoder) can-not reliably be hidden suggests a more implicit and broaderassumption that continues to drive contemporary research:namely, that valid and complete representations of shellcodeare fundamentally different in structure than benign pay-loads. While the first tenet of this assumption is philosoph-ically undeniable (i.e., a string of bytes is either shellcode orit is not), truth of the latter claim is less obvious if there existencoding techniques capable of producing shellcode with fea-tures nearly indistinguishable from non-executable content.In this paper, we challenge the assumption that shellcodemust conform to superficial and discernible representations.Specifically, we demonstrate a technique for automaticallyproducing English Shellcode, transforming arbitrary shell-code into a representation that is superficially similar toEnglish prose. The shellcode is completely self-contained—i.e., it does not require an external loader and executes asvalid IA32 code)—and can typically be generated in underan hour on commodity hardware. Our primary objective inthis paper is to promote discussion and stimulate new ideasfor thinking ahead about preventive measures for tacklingevolutions in code-injection attacks.
Categories and Subject DescriptorsK.6.5 [Security and Protection]: Invasive software
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.CCS’09, November 9–13, 2009, Chicago, Illinois, USA.Copyright 2009 ACM 978-1-60558-352-5/09/11 ...$10.00.
General TermsSecurity, Experimentation
KeywordsShellcode, Natural Language, Network Emulation
1. INTRODUCTIONCode-injection attacks are perhaps one of the most com-
mon attacks on modern computer systems. These attacksare used to deliver and run arbitrary code on victims’ ma-chines, often enabling unauthorized access and control ofsystem resources, applications, and data. Typically, the vul-nerabilities being exploited arise due to some level of neglecton the part of system and application developers to properlydefine and reject invalid program input. Indeed, the canon-ical consequences of such neglect, which include buffer andheap overflow attacks, format string attacks, and (more re-cently) heap spray attacks, categorically demonstrate someof the most popular code-injection techniques.
Generally speaking, an attacker’s first objective in a code-injection attack is to gain control of a machine’s programcounter. The program counter is a special purpose ma-chine register that identifies the next instruction scheduledfor execution. By gaining control of the program counter,an attacker is able to redirect program execution and dis-rupt the intended behavior of the program. With the abil-ity to manipulate the program counter, attackers sometimesredirect a victim’s machine to execute (already present) ap-plication or system code in a manner beneficial to an at-tacker’s intent. For instance, return-to-libc attacks providea well-documented example of this kind of manipulation.In a code-injection attack, however, attackers redirect theprogram counter to execute code delivered by the attack-ers themselves. Depending on the details of the particu-lar vulnerability that an attacker is targeting, injected codecan take several forms including source code for an inter-preted scripting-language engine, intermediate byte-code, ornatively-executable machine code.
Despite differences in the style and implementation of dif-ferent exploits, e.g., buffer overflow versus format string at-tacks, all code-injection attacks share a common component:the injected code. This payload, once executed after suc-cessful manipulation of the program counter, often providesattackers with arbitrary control over a vulnerable machine.Frequently (though not always), attackers deliver a payloadthat simply launches a command shell. It is for this reasonthat many in the hacking community generically refer to the
payload portion of a code-injection attack as shellcode.Among those less familiar with code-injection attacks, there
is sometimes a subtle misconception that shellcode is nec-essarily delivered in tandem with whichever message ulti-mately exploits a vulnerability and grants an attacker con-trol of the program counter. While this assumption typ-ically holds in more traditional buffer overflow vulnerabil-ities, modern attacks demonstrate that attackers have de-veloped numerous techniques to covertly deliver (and ulti-mately store into memory) shellcode separately from andprior to triggering the exploit. For instance, if an attackercan manipulate memory at a known heap address, they maystore their shellcode there, using its address later when over-writing a return address on the stack [10]. We draw atten-tion to this distinction because our use of the term shellcodein this paper specifically denotes the injected code irrespec-tive of individual attacks or vulnerabilities.
Typically, shellcode takes the form of directly executablemachine code, and consequently, several defensive measuresthat attempt to detect its presence, or prevent its executionaltogether, have been proposed. Indeed, automated inspec-tion of user input, system memory, or network traffic forcontent that appears statistically or superficially executableare now common (e.g., [23, 1, 16, 15, 27]). However, as ex-pected, a number of techniques have been developed thatcircumvent these protective measures, or make their job farmore difficult (e.g., polymorphism [5, 7]).
Recently, it has been suggested that even polymorphicshellcode is constrained by an essential component: the de-coder. The argument is that the decoder is a necessary andexecutable companion to encoded shellcode, enabling theencoded portion of the payload to undergo an inverse trans-formation to its original and executable form. Since thedecoder must be natively executable, the prevailing thoughtis that we can detect its presence assuming that this portionof the payload will bear some identifiable features not com-mon to valid or non-executable data. It is this assumption—that shellcode is fundamentally different in structure thannon-executable payload data—that continues to drive someavenues of contemporary research (e.g., [27, 16, 15, 26]).
By challenging the assumption that shellcode must con-form to superficial and discernible representations, we ques-tion whether protective measures designed to assume oth-erwise are likely to succeed. Specifically, we demonstratea technique for automatically producing English Shellcode— that is, transforming arbitrary shellcode into a repre-sentation that is statistically similar to English prose. Byaugmenting corpora-based natural-language generation withadditional constraints uniquely dictated by each instance ofshellcode, we generate encodings complete with decoder thatremain statistically faithful to the corpus and yield identicalexecution as the original shellcode. While we in no way claimthat instantiations of this encoding are irrefutably indistin-guishable from authentic English prose—indeed, as shownlater, it is clear they are not—the expected burden associ-ated with reliably detecting English-encoded shellcode vari-ants in juxtaposition to genuine payloads at line speed raisesconcerns about current preventative approaches.
Similar to the goal of Song et al. [20], our objective inthis paper is to promote discussion and stimulate new ideasfor thinking about how to tackle evolutions in code-injectionattacks. Although most of the attacks observed today haveused relatively naıve shellcode engines [17, 26], exploit code
will likely continue to evade intrusion detection and preven-tion systems because malcode developers do not follow the“rules”. As this cat and mouse game plays on, it is clear thatthe attackers will adapt. So should we, especially as it per-tains to exploring new directions for preventative measuresagainst code-injection attacks.
2. ON THE ARMS RACEIn this paper, we focus on natively-executable shellcode
for x86 processors. In this case, machine code and shellcodeare fundamentally identical; they both adhere to the samebinary representation directly executable by the processor.
Shellcode developers are often faced with constraints thatlimit the range of byte-values accepted by a vulnerable ap-plication. For instance, many applications restrict input tocertain character-sets (e.g., printable, alphanumeric, MIME),or filter input with common library routines like isalnum
and strspn. The difficulty in overcoming these restrictionsand bypassing input filters depends on the range of accept-able input. Of course, these restrictions can be bypassedby writing shellcode that does not contain restricted byte-values (e.g., null-bytes). Although such restrictions oftenlimit the set of operations available for use in an attack,attackers have derived encodings to convert unconstrainedshellcode honoring these restrictions by building equivalencyoperations from reduced instruction sets (e.g., [25, 11]).
Of special note are the alphanumeric encoding engines [18]present in Metasploit (see www.metasploit.com). These en-gines convert arbitrary payloads to representations composedonly of letters and numerical digits. These encodings are sig-nificant for two reasons. First, alphanumeric shellcode canbe stored in atypical and otherwise unsuspected contextssuch as syntactically valid file and directory names or userpasswords [18]. Second, the alphanumeric character set issignificantly smaller than the set of characters available inUnicode and UTF-8 encodings. This means that the set of in-structions available for composing alphanumeric shellcode isrelatively small. To cope with these restrictions, patching orself-modification is often used. Since alphanumeric enginesproduce encodings automatically, a decoder is required. Thechallenge then is to develop an encoding scheme and de-coder that use only alphanumeric characters (and hence, arestricted instruction set), yet are together capable of en-coding arbitrary payloads. The top three rows in Figure 1show examples using the Metasploit framework.
ENCODING
None
PexAlphaNum
Alpha2
English
ASCII
1#SCSj#jfX######CRfh\fS##jfXPQV####...
QZVTX630VX4A0B6HH0B30BCVX2BDBH4A2AD...
7IIQZjJX0B1PABkBAZB2BA2AA0AAX8BBPux...
There is a major center of economic...
HEX
31DB5343536A ...
515A56545836 ...
374949515A6A ...
546865726520 ...
Figure 1: Example encodings of a Linux IA32 Bind Shell. ThePexAlphaNum and Alpha2 encodings were generated using theMetasploit Framework. A hash symbol in the last column repre-sents a character that is either unprintable or from the extendedASCII character set.
We note that much of the literature describing code in-jection attacks (and prevention) assumes a standard attacktemplate consisting of the basic components found tradition-ally in buffer-overflow attacks: a NOP sled, shellcode, and one
or more pointers to the shellcode [1, 12, 23, 27]. Not surpris-ingly, the natural reaction has been to develop techniquesthat detect such structure or behavior [20, 23, 16, 15, 27,14]. While emulation and static analysis have been success-ful in identifying some of the failings of advanced shellcode,in the limit, the overhead will likely make doing so improb-able. Moreover, attacks are not constrained to this layoutand so attempts at merely detecting this structure can beproblematic; infact, identifying each component has its ownunique set of challenges [1, 13], and it has been suggestedthat malicious polymorphic behavior cannot be modeled ef-fectively [20]. In support of that argument, we provide aconcrete instantiation that shows that the decoder can sharethe same properties as benign data.
3. RELATED WORKDefensive approaches against code-injection attacks tend
to fall into three broad categories. The first centers aroundtools and techniques to both limit the spoils of exploita-tion and to prevent developers from writing vulnerable code.Examples of such approaches include automatic bounds pro-tection for buffers [4] and static checking of format stringsat compile-time, utilizing “safe” versions of system libraries,and address-space layout randomization [19], etc. Whilethese techniques reduce the attack surface for code-injectionattacks, no combination of such techniques seems to system-atically eliminate the threat of code-injection [6, 21].
In light of persistent vulnerabilities, the second categoryof countermeasures focuses on preventing the execution ofinjected code. In this realm, researchers have demonstratedsome success using methods that randomize the instruction-set [22] or render portions of the stack non-executable. Al-though these approaches can be effective, instruction-setrandomization is considered too inefficient for some work-loads. Additionally, recent work by Buchanan et al. demon-strates that without better support for constraining programbehavior, execution-redirection attacks are still possible [3].
The third category for code-injection defense consists ofcontent-based input-validation techniques. These approachesare either host or network-based and are typically used ascomponents in intrusion detection systems. User-input ornetwork traffic is considered suspicious when it appears exe-cutable or anomalous as determined by heuristic, signature,or simulation.
In this area, Toth and Kruegel detect some buffer overflowexploits by interpreting network payloads as executable codeand analyzing their execution structure [23]. They dividemachine instructions into two categories separated by thosethat modify the program counter, i.e., jump instructions,and others that do not. Their experiments show that, undersome circumstances, it is possible to identify payloads withexecutable code by evaluating the maximum length of in-struction sequences that fall between jump instructions, andfind that payloads with lower maximum execution lengthsare typically benign. However, their evaluation does not in-clude an analysis of polymorphic code, and Kolesnikov et al.show that polymorphic blending attacks evade this detectionapproach [9].
Several approaches have been suggested for identifyingself-decrypting shellcode using emulation [15, 27, 2] or dy-namic taint analysis [26]. However, these detection methodsare based on a number of assumptions that do not neces-sarily need to be so. For instance, they detect decryption
routines in polymorphic code by scanning network traffic forGetPC code. Essentially, this includes any instructions thatprovide an attacker with the value of the instruction pointer(e.g., using the fstenv instruction). They reason that someform of GetPC code is necessary for determining the locationof an exploit’s encrypted payload. However, many exploitsdo not follow this convention and attackers can often deter-mine the location of their payload by simply understandinghow a particular exploit affects machine state or by manipu-lating it themselves as part of the attack. Furthermore, theseemulation techniques are incomplete because they cannotaccurately reproduce the behavior of execution candidateswithout register and flag information – information that isunavailable to network-based intrusion detection systems.
Polychronakis et al. address some of these limitationsby examining shellcode without GetPC code, coined non-self-contained polymorphic shellcode [16]. By developing anumber of behavioral heuristics, they were able to identifypolymorphic shellcode by emulating execution from data innumerous network traces. While their approach significantlyimproves upon previous detection methods, the contents ofmemory and registers are still unknown, making accurateemulation a challenge. For instance, an attacker may knowthe value of registers (e.g., EFLAGS) or memory accessiblefrom the vulnerable process prior to shellcode execution.This means that an attacker can use conditional jumps orother operations to obfuscate the execution path of the shell-code. In particular, self-modifying shellcode that is lacedwith conditional operations raises challenges for emulation-based techniques as they must execute all possible executionpaths. While path enumeration can be tractable in certainshellcode encodings where conditional statements are rare,the English letters “p” through “z” are all conditional jumps.Therefore, when it comes to English, shellcode designed intandem with the exploit makes current emulation particu-larly difficult.
Lastly, Song et al. examine popular polymorphic shell-code engines to assess their strengths and weaknesses [20].Our work supports their observations in that while today’spolymorphic engines do generate observable artifacts, theseartifacts are not intrinsically symptomatic of polymorphiccode. However, while they advise that modeling acceptablecontent or behavior may lead to a better long-term solu-tion for preventing shellcode delivery, we argue that evenmodeling acceptable content will be rife with its own set ofchallenges, as exemplified by English shellcode. Specifically,by generating malicious code that draws from a languagemodel built using only benign content, statistical measuresof intent become less accurate and the signal-to-noise ratiobetween malicious code and valid network data declines.
4. TOWARDS ENGLISH SHELLCODEShellcode, like other compiled code, is simply an ordered
list of machine instructions. At the lowest level of represen-tation, each instruction is stored as a series of bytes signify-ing a pattern of signals that instruct the CPU to manipulatedata as desired. Like machine instructions, non-executabledata is represented in byte form. Coincidentally, some char-acter strings from the ASCII character and native machineinstructions have identical byte representations. Moreover,it is even possible to find examples of this phenomenon thatparse as grammatically correct English sentences. For in-stance, ASCII representation of the phrase “Shake Shake
Shake!” is byte-equivalent to the following sequence of Intelinstructions: push %ebx; push "ake "; push %ebx; push
"ake "; push %ebx; push "ake!".However, it is unlikely that one could construct mean-
ingful code by simply concatenating English phrases thatexhibit this property. Abiding by the rules of English gram-mar simply excludes the presence of many instructions andsignificantly limits the availability and placement of others.For example, add, mov, and call instructions cannot be con-structed using this method. Therefore, while it may be pos-sible to construct some instances of shellcode with coherentobjectives in this manner, the versatility of this technique isseverely restricted by its limitations. Rather than find theseinstances, our goal is instead to develop an automated ap-proach for transforming arbitrary shellcode into an Englishrepresentation.
4.1 High-level OverviewWhat follows is a brief description of the method we have
developed for encoding arbitrary shellcode as English text.This English shellcode is completely self-contained, i.e., itdoes not require an external loader, and executes as validIA32 code. The steps depicted in Figure 3 complement thebrief overview of our approach presented below. One can en-vision a typical usage scenario (see Figure 4) where the En-glish shellcode (composed of a natively executable decoderand an encoded payload containing arbitrary shellcode) isfirst generated offline. Once the English shellcode is deliv-ered to a vulnerable machine and its vulnerability is trig-gered, execution is redirected to the English shellcode, ini-tiating the decoding process and launching the target shell-code contained in the payload.
First, a list of English-compatible instructions were com-piled and categorized loosely by behavior, i.e., whether aninstruction performs a jump, executes a boolean operation,or manipulates the stack. Some excerpts from the list areshown in Figure 2. Using this list and its categorization toguide development, a decoder was written that is capableof encoding generic payloads using only instructions fromour list. This intermediate result is similar in spirit to thealphanumeric decoders, however, our decoder is further con-strained by a guiding principle to avoid certain characterpatterns that might later make finding an English equivalentmore difficult, e.g., the string of mostly capital letters thatcompose the PexAlphaNum and Alpha2 decoders depictedin Figure 1 would likely result in poor English shellcode.
The basic idea then is to find a strings of English wordsthat mimic the execution behavior of our custom decoder.To achieve this goal, we use a smoothed n-gram languagemodel. That model is trained using a large set of Englishtext, and is used to deduce the probability of word sequences.As language generation proceeds, each instruction in the de-coder is assigned a numerical value. Intuitively, as we selectcandidate strings from the language model, each is executedunder supervision. We use the numerical values to indi-cate the strength of each candidate. If a candidate stringproduces the same net effect of the first instruction of ourdecoder when executed, we say that its score is one. If acandidate string produces the net effect of the first two in-structions, its score is two (and so on). At each stage, high-scoring candidates are kept (and used in driving the lan-guage model forward) and low-scoring candidates (or thosethat crash the simulator) are discarded. Ultimately, we tra-
ASCII HEX ASSEMBLY
" ca"" An"" jo"
20 63 6120 41 6E20 6A 6F
and 61(%ebx), %ah
and 6E(%ecx), %al
and 6F(%edx), %ch
STORAGE
ASCII HEX ASSEMBLY
p.q.r.s.t.u.v.w.x.y.z.
70 2E71 2E72 2E73 2E74 2E75 2E76 2E77 2E78 2E79 2E7A 2E
jo short $30
jno short $30
jb short $30
jnb short $30
je short $30
jnz short $30
jbe short $30
ja short $30
js short $30
jns short $30
jpe short $30
JUMPS
ASCII HEX ASSEMBLY
ABCDEFGHIJKLMNOPQRSTUVWXYZa
4142434445464748494A4B4C4D4E4F505152535455565758595A61
inc %eax
inc %edx
inc %ebx
inc %esp
inc %ebp
inc %esi
inc %edi
dec %eax
dec %ecx
dec %edx
dec %ebx
dec %esp
dec %ebp
dec %esi
dec %edi
push %eax
push %ecx
push %edx
push %ebx
push %esp
push %ebp
push %esi
push %edi
pop %eax
pop %ecx
pop %edx
popa
STACK MANIPULATION
Figure 2: Byte-values that have valid interpretations as EnglishASCII characters and Intel assembly instructions.
verse the language model using a beam search to find stringsof words that score the highest possible value and operatein an identical manner as the decoder developed by hand.
Finally, to encode the original payload, we continue tosample strings from our language model all the while gen-erating prose that is functionally equivalent to the targetshellcode when executed.
Our ApproachRecall that unlike other attack components, the decodermust reside in memory as executable code. This exposurecan make identifying the decoder a useful step in facilitatingdetection and prevention (e.g., by determining if a portionof the payload “looks” executable). Thus, from an attacker’sperspective, masking the decoder may reduce the likelihoodof detection and help to facilitate clandestine attacks.
Designing a decoder under unnatural constraints can bevery challenging, and this difficulty is not unique to Englishshellcode. Self-modification is often used to address thisproblem whereby permissible code modifies portions of thepayload such that non-compliant instructions are patched inat runtime, thereby passing any input filters. These addi-tional instructions provide an attacker with more versatilityand may make an otherwise impotent attack quite powerful.
Self-modification is particularly useful for overcoming someof the challenges unique to English shellcode. Among theEnglish-compatible instructions, for example, there is no na-tive support for loops or addition. Issues like these are rel-evant because decoding a payload without certain instruc-tions, while possible, can quickly become impractical. Forinstance, a decoder without a looping mechanism must beproportional in length to the length of its encoded payload,possibly exposing its existence by nature of its size and formon the wire.
4.2 The decoderWe are able to avoid these problems by building a self-
modifying decoder that has the form: initialization, de-
coder, encoded payload. Intuitively, the first componentbuilds an initial decoder in memory (through self-modification)which when executed, expands the working instruction set,providing the decoder with IA32 operations beyond those
English-compatible Decoder Language Model Generation Viterbi Search and Execution
1
LM
SCORE09
Write a decoder that is capable of
encoding generic payloads using
only English-compatible instructions.
Generate and train a natural
language model with a large and
diverse corpus of English text.
Using Viterbi search, traverse the
language model, executing and
scoring each candidate decoder.
STORAGE
" ca"" An"" jo"
\x00ca\x00An\x00jo
20 63 6120 41 6E
20 6A 6F00 63 61
00 41 6E00 6A 6F
AND [EBX+61],AHAND [ECX+6E],ALAND [EDX+6F],CHADD [EBX+61],AHADD [ECX+6E],ALADD [EDX+6F],CH
ASCIIHex
Assembly
2 3
Encode Target Shellcode
Continue to traverse the language
model, encoding the target shellcode
as English. Upon delivery, this code
will be decoded and executed.
4
xor %eax, ush %eax;cat a
Figure 3: Our method of generating English shellcode consists of four distinct components: developing an English-compatible decoder,constructing a large n-gram language model, scoring candidate execution, and encoding arbitrary shellcode.
provide by English prose. The decoder then decodes the nextsegment (the encoded payload), again via self-modification.
English Shellcode Vulnerable Host Compromised Machine
1 2 3
a
a
Decoder
Encoded Native
Shellcode
Figure 4: A typical usage scenario.
We build our decoder using a number of principles thathelp guide its design. First and foremost, the decoder mustuse only English-compatible instructions or the goal of cre-ating English shellcode cannot be realized. Furthermore,we are particularly interested in English-compatible instruc-tions that can be used, alone or in conjunction, to pro-duce useful instructions (via self modification) that are notEnglish-compatible. For example, our decoder uses multipleand instructions (which are English-compatible) to generateadd instructions (which are not English-compatible). Takentogether, it could be said that these first two goals also pro-vide a foundation for the design of alphanumeric decoders.However, our third design principle, which is not shared byalphanumeric shellcode engines, is to favor instructions thathave less-constrained ASCII equivalents. For instance, wewill likely favor the instruction push %eax (“P”) over push
%ecx (“Q”) when designing our decoder since the former ismore common in English text. The same guiding principleis applied when choosing literal values.1 It is important tonote that even though we followed these principles in design-ing our decoder, they are not hard requirements and thereare other capable approaches. What we provide here is aproof of concept to demonstrate our point.
Initialization. In its initialization phase, the decoder over-writes key machine registers and patches in machine in-structions that are not English compatible. After successfulexploitation of a software vulnerability, we assume that apointer to the shellcode resides in one of the general pur-pose registers or other accessible memory. As pointed outby Polychronakis et al., this is common in non-self-containedshellcode [16]. In order to execute the target shellcode, apointer to the encoded shellcode is needed. This pointermust address memory far beyond the first byte of the shell-code since one must first reserve space for the decoder.
1The term literal refers to a numerical operand in this con-text.
%esp
push ptr; push ptr;
inc %esp;
pop reg; pop reg;
inc reg; inc reg; ...
push reg;
dec %esp;
INSTRUCTION
1
2
3
[4, n - 2]
n - 1
n
STEP
x ! [P, W]
D
x ! {X, Y, Z, a}
x ! [A, G]
x ! [P, W]
L
ASCII OPTIONS
AD BA EF DE AD BA EF 6BDE 02 A4
AD BA EF DE AD BA EF 6BDE- 02 A4
AD BA EF DE AD BA EF 6BDE- 02 A4
AD BA EF DE AD BE EF 6BDE- 02 A4
AD BE EF DE AD BE EF 6BDE 02 A4
STACK
AD BE EF DE AD BE EF 6BDE- 02 A4NO STACK EFFECT
Figure 5: Leveraging the stack to increment the pointer to ourpayload. In this example, the pointer value is initially 0xDEADBAEFand is increased by 1024 to 0xDEADBEEF.
Since the register containing the address of the shellcodeis known, we can copy its pointer and add an offset to reachthe encoded payload. Using only English-compatible ASCIIcharacters, the increment instruction inc is the most obviouscandidate for increasing a register’s value. However, thisone-byte instruction will only increase the value of a registerin increments of one, yielding no space for the decoder. Usedthis way, the inc instruction is insufficient.
However, a single inc instruction can be used to increasea register value in increments of 256 after manipulating thealignment of the stack. This process is depicted in Figure 5.For instance, we can first push the shellcode pointer ontothe stack and shift the stack pointer %esp by one byte. Onceshifted, the pop instruction places the three least-significantbytes of the shellcode pointer into a register where its valueis increased using inc multiple times.2 Afterwards, the valueof this register is pushed back onto the stack and the stackis realigned. The top of the stack, which at first containedthe shellcode pointer, now contains the same value increasedby increments of 256. By popping this value into a register,we can use it to address the encoded payload.
Unpacking the decoder. To facilitate looping, instructionsthat are not English compatible (e.g., the lods and add
instructions) are needed. However, to generate these, theshellcode can manipulate its contents to patch in the re-quired instructions. For example, an and instruction canbe used to create an add instruction. The opcode for and
is equivalent to the ASCII space character (0x20), which
2Respectively, we push and pop the shellcode pointer twicein a row to avoid having an unpredictable byte (i.e., thebyte marked “-” in step 2 from Figure 5) in the register weincrement. This follows one of our more general principlesdiscussed in Section 5: avoid operations that may set flagsin an unpredictable manner.
is convenient because the space character is the most com-mon character in English. The variant used in our proof-of-concept is three bytes in length and takes the form “ANDr/m8, r8”. Its first parameter, r/m8, addresses the bytes tobe modified, while the second specifies one of the partial reg-isters. The opcode for the add operations we create is 0x00.This means that the partial register and the byte addressedby the r/m8 operand must yield a value of zero when theand operation is executed. Thus, the partial registers usedare chosen such that a zero byte is created at r/m8.
1:
2:
3:
4:
5:
6:
7:
8:
9:
top:
sub $0x20,%al
jnz decode
inc %edi
decode:
lods
add %ah,74(%edi)
jnz top
Decoder Loop
Figure 6: Example decoder loop. Blocks of English words in thepayload are read by the decoder and transformed into arbitraryexecutable machine code.
After patching, the add instructions further help build thedecoder by patching in the load string instruction, lods.The load string instruction is used to read bytes from theencoded payload. It loads into %eax four bytes from theaddress referenced by %esi (i.e., the encoded payload) andafterwards, immediately increments the address by four.
Decoding. The decoder loop, shown in Figure 6, readsblocks of English words from the encoded payload, decodingthe target shellcode byte-by-byte. For space efficiency, thetarget shellcode overwrites the encoded payload as it is de-coded. To facilitate this process, two pointers are initializedto point to the encoded payload. The first pointer, %esi, isimplicitly used to identify the current read position via thelods instruction and the other pointer, an offset from %edi,marks the output position for the next decoded byte. Asdescribed subsequently, the second pointer is also used asan accumulator.
The decoder reads data from the encoded payload in con-tiguous four-byte blocks. The first two bytes of each blockare ignored. The value of the third byte in each block isadded to the value referenced by the output pointer, whichinitially points to the first character of the encoded shell-code. If the value of the fourth byte in a block is equiv-alent to the space character, accumulation ends and theoutput pointer is advanced. This process ultimately ter-minates when accumulation yields the null character (0x00).At its conclusion, the target shellcode is completely decodedin memory, located in the same position that the encodedpayload originally resided.
The stop condition for both decoding individual bytesand the decoder loop itself are controlled by the conditionaljumps shown at lines 3 and 9 of the assembly listing in Fig-ure 6. Since the jump-if-not-zero instruction, jnz, is con-trolled by the zero-flag, the first jump is influenced by theoutcome of the subtraction in the previous line (the zero-flagis set if the difference between its two operands, 0x20 and%al, is zero). These two instructions are easily supported byEnglish-compatible characters: the subtraction instruction,
sub, has the same byte representation as a comma before aspace character (i.e., “, ”), while jnz is the English charac-ter “u”. Similarly, the second jump is influenced by the add
operation that immediately precedes it and was patched inby the decoder itself.
The decoder presented in this section is composed of bytevalues that are particularly helpful in facilitating the cre-ation of English shellcode. That said, there are many otherways to accomplish the same task using other series of in-structions. If a detection method is developed for one de-coder in particular, it can trivially be replaced with anotherthat performs the same operations using different instruc-tions.
Initializing registers. To ease the aforementioned exposi-tion, we omitted discussion on how registers are initialized.At the same time that the address of the encoded shellcodeis moved to a register (before the decoder loop executes),several other values are stored. Specifically, the popa in-struction, whose opcode is equivalent to the character “a”,allows us to set the contents of the registers used by theand instruction (to create an add instruction) and the add
instruction (to create the lods instruction). The popa in-struction pops 32 bytes from the stack into 8 registers. Theregisters’ values are set by pushing the values on the stackbefore popa executes. The two push operations we use pusheither one or four bytes onto the stack and are equivalentto the characters “j” and “h”, respectively. For example, theword, “johnboat”, first pushes “o” and then “nboa” onto thestack.
5. AUTOMATIC GENERATIONRecall that the instructions used to implement the decoder
are selected specifically because their byte-representationsmatch those of characters used commonly in English-basedASCII strings. Taken as-is, the custom decoder will havecommon English characters, but will not have the appear-ance of English text.
Intuitively, there are three general types of instructionsthat give us the freedom to position the decoder instruc-tions among English words and produce multiple variants ofEnglish shellcode from the same payload. The first type in-cludes all English-compatible instructions that produce nonet execution effect, i.e., nop. Second are operations thatmay in general affect machine state, but for our purposeswill not interfere with the operation of the decoder (or thedecoding process). The last type are those that in series mayintermediately affect machine state in an undesirable man-ner, but taken in sum, have the same net effect on machinestate as the other two types, i.e., no effect of consequence orno effect at all.
To generate an English-like decoder automatically, we usetechniques that draw heavily from the natural language pro-cessing community, augmenting a statistical language gen-eration algorithm with additional constraints. The languagegeneration architecture is influenced by statistical informa-tion about the target language, i.e., English, by observingits use in various settings. We use a corpus comprised of justover fifteen thousand Wikipedia articles and roughly 27, 000books from the Project Gutenberg (see www.gutenberg.org)to train a statistical model, termed a language model, whichcontains counts of words and word sequences observed dur-ing training.
... through the
... through the door
... through the end
door
end
night
SCORE: 12
!
"KEY
!"
Level-up
Does not crash
Crash
Assessment function
(.009)
(.005)
(.004)
if (crash) discard;
else if (pass_level) score++;
SCORE: 13
SCORE: 12
Figure 7: An English version of the decoder is found by samplingthe language model for words that contribute to the achievementof decoder operations. When sampling along a path produces aninstruction that prematurely halts execution, it is discarded infavor of other paths. As paths are assessed, top scoring samplesare kept as decoder candidates.
Paragraphs are built by sampling words from the languagemodel based on their observed frequency. Each sentence isgenerated from left to right such that words are added to asentence only when they have also been observed in the sam-ple text following the combination of words already chosenfor the sentence. Retrospection is, however, limited. Sincewe use an smoothed n-gram language model and our max-imum n-gram length is 53, a candidate word w5 will onlyfollow w1w2w3w4 if w1w2w3w4w5 exists in the training cor-pus. In more traditional language generation applications,we might perform a random walk through the model, choos-ing each candidate word at random based on its probability(e.g., if w5 follows w1w2w3w4 with a probability of 0.9, thenit would be generated with a probability of 0.9).
While sampling a string from a language model, a tra-ditional language generation application may only be in-fluenced by the probability distribution for each candidateword. Since we are also interested in a word’s contributionto execution, we seek a path through the model that max-imizes English probability and correct execution behaviorsimultaneously. To do so, we traverse the language modelusing the Viterbi algorithm [24].
Viterbi is used to reconstruct the most probable sequenceof states in a hidden Markov model. A hidden Markov model(HMM) is simply a Markov model in which each state is com-prised of known parameters (e.g., a word) and unknown pa-rameters (e.g., a word’s contribution to our execution goals).
Throughout this process, an objective assessment func-tion scores candidate execution so that we can quantitativelycompare candidates. Each decoder instruction is assigned alevel number i such that 1 ≤ i ≤ n, whereby level i denotesthe ith instruction. For each sampled string, the score thenindicates the number of desirable instructions it achieves.At the beginning of language generation, we say that the(yet to be generated) instance has a score of zero. For eachcandidate word, we concatenate it to the string along thepath of generation and then execute the string in a sandbox(see Section 6). If the string fails execution (e.g., crashes thesimulator), it is discarded. If the addition of the candidatecompletes the operation specified by the next level, its scoreis incremented. If execution does not crash or yield com-
3This value is chosen empirically and represents a trade-offbetween sampling accuracy and the speed at which samplesare generated.
pletion of the desired operation, the score does not change.Figure 7 illustrates this behavior.
We sample thousands of strings simultaneously and be-tween each round of candidates, keep only the top m sam-ples. Since we do not know the ideal relationship betweenexecution score and word probability at any intermediatestage, we use a greedy algorithm that maximizes our exe-cution goal first. In other words, we always keep the bestm(= 20, 000) candidates by highest execution score and uselanguage probability to settle ties. The process continues un-til a sample reaches the nth level, indicating that an English-based decoder has been found.4
While objectives change regularly for the duration of thegeneration process in response to the completion of priorobjectives, some conditions hold throughout. We discour-age the selection of candidates that reverse desirable effectsachieved previously, overwrite critical data, or execute privi-leged instructions (i.e., crash) at any stage. Furthermore, werefrain from selecting any candidates that use unpredictabledata or set flags unpredictably. For instance, performing anarithmetic operation with an operand whose value is un-known can alter the EFLAGS register in way that cannotbe predicted a priori. Without these constraints, we wouldwaste effort considering candidates that behave erratically,fail to decode encoded payloads, or ultimately crash.
Once a potential decoder is identified, we can encode ar-bitrary shellcode. After selecting a payload, we encode thetarget shellcode by continuing to explore the Viterbi searchthat generated the decoder. The process for encoding pay-loads is almost identical to the process we describe in Sec-tion 4.2 for finding an English decoder. Instead of mon-itoring the execution behavior of candidates at each step,the objective assessment function now observes how manytarget bytes are encoded by each candidate, favoring thosethat encode more of the payload using fewer words. Interest-ingly enough, encoding the payload places few restrictionson language generation. This is because the encoded datais non-executable and the first two bytes of each four-byteblock are unconstrained (as well as the fourth block whileaccumulation is incomplete).
LM
Language Engine
SCORE09
Scoring Engine
Candidate ScoresCandidate Decoders
SHARED MEMORY
64-bit Java
32-bit CJNI
Figure 8: Candidate decoders are produced by a language engineand stored in shared memory. Then, they are subsequently exe-cuted and evaluated by a scoring engine. As scores are returnedto the language engine, candidates are ranked, influencing futurecandidate selection.
Our implementation is divided into two distinct yet col-laborative entities: a language engine and a scoring en-
4We note, however, that finding a solution with this tech-nique is not guaranteed.
gine. The language engine was constructed in the Javaprogramming language using the LingPipe API (see http:
//alias-i.com/lingpipe/). LingPipe is a natural languageprocessing and data mining toolkit that provides an efficientimplementation of numerous algorithms and data structurescommonly used by computational linguistics applications.We use the toolkit to rapidly build, train, and query ourlanguage model.
Two tandem processes comprise the scoring engine. Thefirst process (hereafter referred to as the“executor”) executeseach candidate decoder while the second (the “watcher”) isresponsible for controlling and monitoring said execution.The monitor process evaluates candidate behavior (i.e., howit affects the state of the machine) through single-step ex-ecution and is implemented using the Linux ptrace API.Since our generation technique produces English from leftto right, the monitor process favors candidates that performoperations in approximately the same order as our hand-written decoder. This yields the natural scoring mechanismdescribed in Section 5. The scoring engine is also responsiblefor discouraging the selection of candidates that misbehave,crash, or produce undesirable effects.
The language and scoring engines communicate using sharedmemory. Communication is facilitated by the Java NativeInterface (JNI) as depicted in Figure 8. Before generationcommences, the JNI component performs a one-time initial-ization that allocates two shared memory regions: one thatholds the potential solution and one that holds its executionresults. The JNI component also launches the scoring en-gine’s monitor process. The scoring engine proceeds to eval-uate candidates provided by the language engine. The JNIcomponent signals the scoring engine when each new candi-date word has been copied into shared memory. Once thesignal is received, the scoring engine’s execution process fillsthe stack with random values (to ensure that a solution us-ing uncontrollable stack data is improbable), initializes otherregisters, and reassigns its instruction pointer to address thecandidate decoder. Afterward, the monitor process beginssingle-step evaluation for the new candidate and providesthe language engine with a report of each candidate’s score,which helps influence the ongoing Viterbi search and its rolein selecting future candidates. This feedback loop ends oncethe target shellcode has been successfully realized.
5.1 An optimized designAn obvious downside of the aforementioned architecture
is the use of ptrace to single-step the execution of eachcandidate; indeed, using this approach took 12 hours, onaverage, to generate a complete decoder. While utilizingptrace turned out to be invaluable in our quest towardsautomatic generation, its use is ultimately far more ineffi-cient than need be — primarily because it induces multiplecontext switches between kernel and user space.
One viable alternative to ptrace is emulation. That is,instead of using inter-process communication and ptrace,we instead emulate the effects of every instruction providedby English as well as the effect of each instruction createdby our framework. This is a particularly arduous task be-cause it requires understanding the effects that each Englishopcode can produce; including the effects to registers andmemory locations directly addressed by opcodes as well asthe flags register. In addition to being particularly hardto implement, emulation takes a single instruction and can
expand it to tens of instructions. Therefore, to avoid us-ing ptrace and to eliminate the bulk of the inter-processcommunication, we use a solution we call monitored directexecution.
This optimized design attempts to retain the benefits ofdirect execution while eliminating the need for ptrace. Theinformation required to guide English generation is the same,except we explore more efficient ways to obtain such infor-mation. Intuitively, what was formerly two processes is nowaccomplished by one process that performs both tasks. Thisis achieved by maintaining two sets of machine state andswitching between them to change execution roles. Essen-tially, both the watcher and the execution “programs” havetheir own registers, stack, and memory which we call theirstate. They “share” only the memory associated with stateswitching and the candidate solution.
Switching is accomplished by using two pieces of stub codethat saves the state of the watcher program and restores thestate of the execution program. Intuitively, we use threeseparate stacks to minimize the context switch penalty be-tween kernel and user space that arose in the unoptimizedcase. The first stack is the original watcher stack (indeed,the only“official” stack), the second is an intermediate stack,and the third is the execution program’s stack. The interme-diate stack houses the information necessary to restore theexecution process. The two pieces of stub code mentionedpreviously use this stack to either save or restore the execu-tor’s state. The third stack is simply a portion of memorymapped to a static location. It is saved and restored aftereach batch of executed instructions, keeping the contentsuntouched during the watcher’s execution.
To boost performance even further, we also forgo single-step execution. A key observation is that we only need infor-mation at very specific points in the execution of a candidatesolution. Specifically, we only need to know the executionpath dictated by changes to the flags register, as well aswhen memory beyond the current point of candidate execu-tion changes. As such, we pause to inspect execution on twopause conditions. The first is when the execution encoun-ters a jump where EFLAGS could be affected by a previousinstruction. We identified the conditions under which thiscould be true by enumerating all the instructions that couldchange the flags: i.e., all the arithmetic operations (e.g.,inc, dec, add, imul) and logical operations (e.g., and, or).(This analysis was made possible because of our earlier use ofptrace.) The second pause condition is set in places wherewe encounter instructions that can change memory; in ourimplementation, and and add are the only such instructions.Any operations between either of these pause conditions areexecuted without intervention.
It is important to note that before the first instructionsare executed and during each of the aforementioned pauseconditions, the watcher process examines upcoming instruc-tions to avoid either of two undesirable scenarios. Specifi-cally, the execution process cannot be allowed to execute anyinstructions that (i) may result in a crash, e.g., privilegedinstructions, or (ii) result in unpredictable machine state,e.g., by using unpredictable values from registers or mem-ory. Thankfully, we can again take advantage of our experi-ences using ptrace to enumerate and preemptively dismissany candidate solution containing either of these scenarios.
The result of these optimizations is that we can now rou-tinely generate entire solutions in less than 1 hour on com-
1 2
3
4
5
There is a major center of economic activity, such as Star Trek, including The Ed
Sullivan Show. The former Soviet Union. !International organization participation
Asian Development Bank, established in the United States Drug Enforcement
Administration, and the Palestinian territories, the International Telecommunication
Union, the first ma...
push $20736120
push %ebx
je short $63
jb short $22
68 20617320
53
74 61
72 20
push %esp
push $20657265
imul %esi,20(%ebx),$616D2061
push $6F
jb short $22
54
68 65726520
6973 20 61206D61
6A 6F
72 20
There is a major
1
h as Star
2
push %ebx
push $202E776F
push %esp
push $6F662065
jb short $6F
53
68 6F772E20
54
68 6520666F
72 6D
Show. The form
3
push %ebx
je short $63
je short $67
jnb short $22
inc %esp
jb short $77
53
74 61
74 65
73 20
44
72 75
States Dru
4
popad 61 a5
ASSEMBLY OPCODE ASCII
Skip Skip
SkipSkip
Skip Skip
Skip
Skip
Figure 9: Partial anatomy for an excerpt of an automaticallygenerated English encoding.
modity hardware with 4GB of RAM — almost a 12-foldimprovement over using ptrace.
6. EVALUATIONAs a preface, we note that given the sensitivity of this
work, we purposely do not show complete samples of En-glish shellcode. We believe that doing so would be irrespon-sible, as the risks (i.e., helping the attackers) outweigh thebenefits.
Figure 9 shows an annotated excerpt from an English-encoded sample that simply calls exit(0). Notice that theEnglish-encodings we produce generally follow the form andcadence of non-synthetic text. Since our generation engine ismerely a proof-of-concept, continued refinement may furtherreduce the prevalence of seemingly artificial phrases or sen-tences. The full text is 2054 bytes in length. The segmentsof text underneath the table with a grey background denoteportions of the shellcode that are passed over via jump in-structions (and are therefore not executed). In the table,we depict the assembly, machine code, and ASCII-characterrepresentations for the bolded (i.e., executed) segments.
Since our focus in this paper is to show that shellcodeneed not be different in structure than non-executable pay-load data, we consider assessment of the quality of the En-glish we generate outside the scope of this work.5 Instead,for pedagogical reasons, we revisit a recent approach that isbased on using spectrum analysis to detect the presence ofexecutable code in network traffic in lieu of emulation [8].The key assumption in that work is that the structure of ex-ecutable content is statistically dissimilar from the structure
5Indeed, several conferences (e.g., the International NaturalLanguage Generation Conference) are devoted almost en-tirely to that topic.
CONTENT TYPE INSTRUCTION DISTRIBUTION
Windows Bind DLL Inject
Pexfnstenvsub-encoded
PexAlphaNum-encoded
Alpha2-encoded
English-encoded (Average)
Wikipedia Entry (Average)
Arithmetic
Load/Store
Privileged
StackLogical
Transfer
Control
NOPSSE
MMXFloat
Interrupt
Other
Figure 10: Instruction spectrum for various encodings ofthe Windows Bind DLL Inject shellcode included in the Metas-ploit framework. For comparison, we also “disassembled” 500Wikipedia articles selected at random and 6 English shellocodesamples.
of non-executable data, and so argue that this can be usedto identify shellcode. By grouping opcodes into canonicalcategories (e.g, push and pop instructions might be classi-fied as stack functions while and and or might be groupedtogether with other logical operations), they posit that sim-ilar filetypes will have similar categorization patterns. Theirresults indicate that data and plaintext files have instructionspectrums that are characteristically different from those ofexecutable code6.
... the result of the collapse of large portions of the three provinces to have a syntax which can be
found in the case of Canada and the UK, for the carriage of goods were no doubt first considered
by the British, and the government, and the Soviet Union operated on the basis that they were...
... the US Navys interpretation of the state to which he was subsequently influenced by the new
government was established in 1951, when the new constitution approved it you King, he now had
the higher than that the M.G.u, and soul shouters like Diane. There's a mama maggot...
... including the major justifications that the test led to his own. This is usually prepared by the
infection of the Sinai to the back and the Star Destroyers in the parliament, by the speed of these
books and the revival of environmental problems of their new Arab states of the Arctic as a more...
... and they possess power to the effort she was especially valuable as the Union and that would
have said, as to note that the goods, which the night that if ever I rode after the word Father upon
His Church to claim that the peace that had permitted him the city are as a hand of one into...
... I thought of Mr. Crow and the Jews by the days of the C.Cs front garden which had first to St
Cyriacus. All of a theology in the setting in a human heart as the tale of this day. I have it to
friendship and the States that the way the English of the St Lawrence seven miles of an adjutant...
Source Material: Wikipedia
Source Material: Project Gutenberg
1
2
3
4
5
Figure 11: Excerpts for alternative encodings of exit(0). Theinstruction distribution are over the entire shellcode. Refer to thekey in Figure 10 for information about instruction categories.
Using the same categories, we classified each IA32 in-struction and produced instruction spectrums for the Win-
dows Bind DLL Inject shellcode supplied with the Metas-ploit framework, various encodings of the shellcode, andWikipedia articles selected at random. Figure 10 shows the
6We note that even using the same 13 instruction groupsin [8] we could not verify their results because of inconsis-tencies and ambiguous statements in their manuscript.
results after sorting each spectrum by category, highlightingthe distribution of instruction types in each file. Throughvisual observation, it is easy to see that the Pexfnstenvsub
encoding of the Metasploit shellcode is not significantly dif-ferent than the unmodified shellcode. Alternatively, bothalphanumeric encodings are unlike the aforementioned sam-ples and, additionally, have distributions that are most sim-ilar to each other.
More importantly, notice that the instruction distribu-tion of the English encoding is most like the instructiondistribution of the randomly chosen Wikipedia articles—illuminating the difficulty of distinguishing English shellcodewithout considering syntactic information. In particular, itis not clear (at least to us), how to easily mitigate this threatwithout considering the semantics of the input. We show ex-cerpts from other samples we generated in Figure 11.
7. CONCLUSIONIn this paper we revisit the assumption that shellcode need
be fundamentally different in structure than non-executabledata. Specifically, we elucidate how one can use natural lan-guage generation techniques to produce shellcode that is su-perficially similar to English prose. We argue that this newdevelopment poses significant challenges for inline payload-based inspection (and emulation) as a defensive measure,and also highlights the need for designing more efficient tech-niques for preventing shellcode injection attacks altogether.
8. ACKNOWLEDGEMENTSWe thank Bryan Hoffman, Ryan MacArthur, Scott Coull,
John McHugh, Ryan Gardner, and Charles Wright for manyinsightful discussions. Thank you also to our anonymous re-viewers for their invaluable comments and suggestions. Thiswork was funded in part by NFS grants CNS-0627611 andCNS-0852649.
9. REFERENCES[1] P. Akritidis, E. P. Markatos, M. Polychronakis, and
K. Anagnostakis. STRIDE: Polymorphic Sled Detectionthrough Instruction Sequence Analysis. In Proceedings ofthe International Information Security Conference, 2005.
[2] K. Borders, A. Prakash, and M. Zielinski. Spector:Automatically Analyzing Shell Code. Proceedings of theAnnual Computer Security Applications Conference, pages501–514, 2007.
[3] E. Buchanan, R. Roemer, H. Shacham, and S. Savage.When Good Instructions Go Bad: GeneralizingReturn-Oriented Programming to RISC. In Proceedings ofACM Conference on Computer and CommunicationsSecurity, Oct. 2008.
[4] C. Cowan, C. Pu, D. Maier, H. Hinton, P. Bakke,S. Beattie, A. Grier, P. Wagle, and Q. Zhang. Stackguard:Automatic Adaptive Detection and Prevention ofBuffer-overflow Attacks. In Proceedings of the USENIXSecurity Symposium, pages 63–78, 1998.
[5] T. Detristan, T. Ulenspiegel, Y. Malcom, and M. S. V.Underduk. Polymorphic Shellcode Engine Using SpectrumAnalysis. Phrack, 11(61), August 2003.
[6] T. Durden. Bypassing PaX ASLR Protection. Phrack,11(59), July 2002.
[7] K2. ADMmutate. Seehttp://www.ktwo.ca/c/ADMmutate-0.8.4.tar.gz.
[8] I. Kim, K. Kang, Y. Choi, D. Kim, J. Oh, and K. Han. APractical Approach for Detecting Executable Codes in
Network Traffic. In Asia-Pacific Network Operations andManagement Symposium, 2007.
[9] O. Kolesnikov, D. Dagon, and W. Lee. AdvancedPolymorphic Worms: Evading IDS by Blending in withNormal Traffic. Technical Report GIT-CC-05-09, GeorgiaInstitute of Technology, 2005.
[10] G. MacManus and M. Sutton. Punk Ode: Hiding Shellcodein Plain Sight. In Black Hat USA, 2006.
[11] Obscou. Building IA32 Unicode-Proof Shellcodes. Phrack,11(61), August 2003.
[12] A. One. Smashing The Stack For Fun And Profit. Phrack,7(49), November 1996.
[13] A. Pasupulati, J. Coit, K. Levitt, S. F. Wu, S. H. Li, R. C.Kuo, and K. P. Fan. Buttercup: on Network-basedDetection of Polymorphic Buffer Overflow Vulnerabilities.In IEEE/IFIP Network Operation and ManagementSymposium, pages 235–248, May 2004.
[14] U. Payer, P. Teufl, and M. Lamberger. Hybrid Engine forPolymorphic Shellcode Detection. In Proceedings ofDetection of Intrusions and Malware & VulnerabilityAssessment, pages 19–31, 2005.
[15] M. Polychronakis, K. G. Anagnostakis, and E. P. Markatos.Network-level Polymorphic Shellcode Detection usingEmulation. In Proceedings of Detection of Intrusions andMalware & Vulnerability Assessment, pages 54–73, 2006.
[16] M. Polychronakis, K. G. Anagnostakis, and E. P. Markatos.Emulation-based Detection of Non-self-containedPolymorphic Shellcode. In Proceedings of the InternationalSymposium on Recent Advances in Intrusion Detection,2007.
[17] M. Polychronakis, K. G. Anagnostakis, and E. P. Markatos.An Empirical Study of Real-world Polymorphic CodeInjection Attacks. In USENIX Workshop on Large-ScaleExploits and Emergent Threats, 2009.
[18] Rix. Writing IA32 Alphanumeric Shellcode. Phrack, 11(57),August 2001.
[19] H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu,and D. Boneh. On the effectiveness of address-spacerandomization. In Proceedings of ACM Conference onComputer and Communications Security, pages 298–307,Oct. 2004.
[20] Y. Song, M. E. Locasto, A. Stavrou, A. D. Keromytis, andS. J. Stolfo. On the Infeasibility of Modeling PolymorphicShellcode. In Proceedings of ACM Conference on Computerand Communications Security, pages 541–551, 2007.
[21] A. Sotirov and M. Dowd. Bypassing Browser MemoryProtections. In Black Hat USA, 2008.
[22] A. N. Sovarel, D. Evans, and N. Paul. Where’s the FEEB?On the Effectiveness of Instruction Set Randomization. InProceedings of the USENIX Security Symposium, 2005.
[23] T. Toth and C. Kruegel. Accurate Buffer OverflowDetection via Abstract Payload Execution. In Proceedingsof the International Symposium on Recent Advances inIntrusion Detection, pages 274–291, 2002.
[24] A. J. Viterbi. Error Bounds for Convolutional Codes andan Asymptotically Optimum Decoding Algorithm. IEEETransactions on Information Theory, 13(2):260–269, April1967.
[25] T. Wana. Writing UTF-8 compatible shellcodes. Phrack,11(62), July 2004.
[26] X. Wang, Y.-C. Jhi, S. Zhu, and P. Liu. STILL: ExploitCode Detection via Static Taint and InitializationAnalyses. Proceedings of the Annual Computer SecurityApplications Conference, pages 289–298, December 2008.
[27] Q. Zhang, D. S. Reeves, P. Ning, and S. P. Iyer. AnalyzingNetwork Traffic to Detect Self-decrypting Exploit Code. InProceedings of the ACM Symposium on Information,Computer and Communications Security, 2007.
