| FazBrowse Wikipedia Viewer | Main Page | | |
| Viewing: https://en.wikipedia.org/wiki/Shellcode |
| Contents |
|---|
| Types |
| Compatibility |
| Analysis |
| References |
A local shellcode attack allows an attacker to gain elevated access privilege on their computer. In some cases, exploiting a vulnerability can be achieved by causing an error such as buffer overflow. If successful, the shellcode enables access to the machine via the elevated privileges granted to the targeted process.
A remote shellcode attack targets a process running on a remote machine \u9090
The following instructions accomplish the same goal (EAX containing 1) without embedded zero bytes by first setting EAX to 0, then incrementing EAX to 1:
33C0 XOR EAX,EAX 40 INC EAXAn alphanumeric shellcode consists of only alphanumeric characters (0–9, A–Z and a–z). This type of encoding was created by hackers to obfuscate machine code inside what appears to be plain text. This can be useful to avoid detection of the code—to allow the code to pass through filters that scrub non-alphanumeric characters from strings. A similar type of encoding is called printable code and uses all printable characters (alphanumeric plus symbols like !@#%^&*). A similarly restricted variant is ECHOable code not containing any characters which are not accepted by the ECHO command. It has been shown that it is possible to create shellcode that looks like normal text in English. Writing such shellcode requires in-depth understanding of the instruction set architecture of the target machines. It has been demonstrated that it is possible to write alphanumeric code that is executable on more than one machine, thereby constituting multi-architecture executable code.
A work-around was published by Rix in Phrack 57 in which he shows that it is possible to turn any code into alphanumeric code. Often, self-modifying code is leveraged because it allows the code to have byte values that otherwise are not allowed by replacing coded values at runtime. A self-modifying decoder can be created that initially uses only allowed bytes. The main code of the shellcode is encoded, also only using bytes in the allowed range. When the output shellcode is run, the decoder modifies its code to use instructions it requires and then decodes the original shellcode. After decoding the shellcode, the decoder transfers control to it. It has been shown that it is possible to create arbitrarily complex shellcode that looks like normal English text.
Modern software uses Unicode to support Internationalization and localization. Often, input ASCII text is converted to Unicode before processing. When an ASCII (Latin-1 in general) character is transformed to UTF-16 (16-bit Unicode), a zero byte is inserted after each byte (character) of the original text. Obscou proved in Phrack 61 that it is possible to write shellcode that can run successfully after this transformation. Programs that can automatically encode any shellcode into alphanumeric UTF-16-proof shellcode exist, based on the same principle of a small self-modifying decoder that decodes the original shellcode.
Generally, shellcode is deployed as machine code since it affords relatively unprotected access to the target process. Since machine code is compatible within a relatively narrow computing context (processor, operating system and so on), a shellcode fragment has limited compatibility. Also, since a shellcode attack tends to work best when the code is small and targeting multiple exploits increases the size, typically the code targets only one exploit. None the less, a single shellcode fragment can work for multiple contexts and exploits. Versatility can be achieved by creating a single fragment that contains an implementation for multiple contexts. Common code branches to the implementation for the runtime context.
As shellcode is generally not executable on its own, in order to study what it does, it is typically loaded into a special process. A common technique is to write a small C program that contains the shellcode as data (i.e. in a byte buffer), and transfers control to the instructions encoded in the data function pointer or inline assembly code). Another technique is to use an online tool, such as shellcode_2_exe, to embed the shellcode into a pre-made executable husk which can then be analyzed in a standard debugger. Specialized shellcode analysis tools also exist, such as the iDefense sclog project (originally released in 2005 in the Malcode Analyst Pack). Sclog is designed to load external shellcode files and execute them within an API logging framework. Emulation-based shellcode analysis tools also exist such as the
| View original on Wikipedia | Back | FazBrowse Home |