This discussion is more geared towards noobs, if you consider yourself an "ok" hacker and you don't know what I'm talking about....you are not an "ok" hacker.

Listen, I don't feel like there should be an anti-disclosure mindset with exploits, but for god's sake, if you don't know how to compile them, or how to configure them to work for your needs, you aren't worthy of using them.

more over, look through code, learn to recognize the syntax of different programming languages. For example, with perl, you'll commonly see
at the beginning of the exploit. for ruby and for C/C++ files.

Learn what they do.
[list]
[*]Stack Buffer Overflow
-Can cause remote code execution[/*:m]
[*]Heap Buffer Overflow
-Can cause remote code execution[/*:m]
[*]Memory Corruption
-Can cause remote code execution[/*:m]
[*]Denial of Service
-Self explanatory[/*:m]
[*]Privilege Escalation
-All your base are belong to us[/*:m][/list:u]

Learn how they work:


Learn how the man tries to stop you from using exploits:


Last, but most importantly, learn how to develop them, some things you'll need to learn are:
-a small amount of programming (any language)
-how the memory segment works
-fuzzing
-debugging
-shellcode and how to use it and encode it



Fuzzing and Debugging are two topics that honestly need their own guides, but I will give you a brief synopsis of what these do and why they are important.
-Fuzzing-
Fuzzing is a simple concept, but a complex procedure. Fuzzing is stress testing a program/service with random, or specified input. In many cases you will have to write your own fuzzer, however there are a couple of universal ones (limited to what they can test however). If a program crashes, you can continue testing for vulnerabilities. If a program does what it's supposed to, but not how it was supposed to do it, you can continue testing. If nothing happens, you have an ineffective fuzzer(unlikely even for an unskilled programmer), or it is not vulnerable to these attacks. A good fuzzer will tell you how big the program buffer is, and what kind of conditions caused it to crash/disfunction.

-Debugging-
Debugging is disassembling a program, or looking deep down inside to the underlying low level programming behind it. Here you will need to understand what return addresses are, and the various pointers associated with a program (eip, esp, ebp, etc...etc is not a pointer). While you are fuzzing, a successful test (if you do it like everyone else) will show 0x41414141 in eip....ideally. eip is the instruction pointer, in other words a location that is guaranteed to be executed in memory. When you can overwrite eip, you now have control over what is actually executed in the program i.e. shellcode. All you have to do is fill the buffer up to where 0x41414141 is located, and replace it with the return address of your shellcode. Simple concept....complex procedure.

Some things that aren't necessary but I recommend learning:
-the difference between a compiled language and interpreted language
-the dynamics of tcp
-input validation


Remember, these are not the only kind of attacks that can be used in exploits, there are attack vectors not yet known to us. All you need to do is innovate. There is so much more to this, but if you are diligent enough to read all of it, you will be well on your way to becoming 1337. Also...if you don't use linux I suggest you atleast try it.

Three quick tips to be a successful hacker.
1. Learn how to program, you will not survive without it.
2. Learn how to read and write, you will not be respected without it.
3. Learn how to reverse, you will not make any progress without it.

m0rph