If you were wondering why things have been so quiet for the past month, it’s because I’ve been spending my every waking hour learning to hack. This explains the presence of a new category here on the site, and the motivation behind some of the upcoming topics. It would be a shame to let January pass us by, so here comes an introductory post on the exciting science of shellcoding. First, some formalities:

Shellcode (sh?l’k?d)
n.

A relocatable piece of executable code used as the payload in a software exploit, typically having the purpose of providing the attacker with unauthorised access to the system at which it is directed.

v. [shellcod•ing, shellcod•er]

The process of developing shellcode and tailoring it to a particular target.
A piece of software is said to be vulnerable (to exploitation) if it contains a bug which allows a user to cause it to behave in a way unintended by the developers, by supplying appropriately crafted data to one of its normal input mechanisms. The faulty processing of this input is the vulnerability, and any operation that takes advantage of this is an exploit. The data used in such an exploit is the payload, and the executable component of this payload is the shellcode. While a distinction exists between an exploit’s payload and its shellcode, the two terms are often used interchangeably. The name ’shellcode’ derives from the fact that many Unix exploits would work toward the goal of delivering a shell to the attacker, but this is not a necessary criterion under today’s usage.

Not all exploits will require shellcode, as certain goals may be achieved without it, but we’ll primarily concern ourselves with vulnerabilities that lead to execution of arbitrary code (i.e. the shellcode), as that’s the holy grail of the hacker. While vulnerabilities can fall into many categories, there are a few of particular interest, and these are the ones I’ll concentrate on. Putting the theory into practice is the real stumbling-block, and so along the way I’ll discuss common problems the average Windows shellcoder will run into. Here’s the battle-plan:

  • Stack overflows
  • Heap overflows
  • Format-string vulnerabilities
  • String filters, shellcode-location and other technical problems
  • Non-executable stacks and stack-canaries
I appreciate that this is a lot of material to cover, and that you may be best off buying a book (The Shellcoder’s Handbook handles this vast subject magnificently), but I aim to spend as little time as possible on the bread-and-butter material that can be found just about everywhere, while putting far more focus on the practical side of things. See you next week.



http://www.ring3circus.com/rce/shellcoding-on-windows-part-i/