Corelan is a security research group whose Win32 exploit writing tutorials cover stack overflows, DEP/ASLR bypasses, ROP, and shellcoding, plus a pentesting career guide.
HN commenters recommend it as a good starting point for exploit development and offer its pentester guide as a better alternative to a sponsored article.
You have a long but very interesting road before you. Infosec is huge. Lesley “hacks4pancakes” Carhart has a great series which provides an overview of what you can choose from: https://tisiphone.net/2015/10/12/starting-an-infosec-career-the-megamix-chapters-1-3/
If you're serious about infosec and not just want to run tools and call it a day, I suggest covering the basics first:
- programming: would be cool if you learn not only some language but programming “as art and mindset” in general. This includes your typical Computer Science courses, algorithms etc. Great if your school or university teaches those but you can always fall back to online education platforms.
When it comes to language, I'd recommend Python over Ruby. Granted, the latter powers Metasploit, but a lot more tools and wrappers around tools are written in Python. Once you know Python, creating Metasploit modules won't be a problem because a lot of things are handled by the Metasploit Framework.
Also, this comes from a highly subjective Python developer but suggest to learn Python 3, despite a lot of infosec tutorials and tools still using Python 2 (e.g. socket programming). It's easy to fall back to Py2 if you need but you'll have the power of latest and greatest if you go Py3 because not everything is backported. Most books contain a lot of useless material and are pretty slow-paced and I'm not a fan of “Learn Python The Hard Way” either. I personally started with “Learning Python” by Mark Lutz; after…
Now that you've got a foundation in software development we can move onto exploit-development. Well not quite first you need to bridge your knowledge from building software to breaking it. For this you need to start learning about how software works at a lower level, the CPU level. There is a good book: Computer Organization and Design. Its solid but its also a textbook and covers a lot more detail than you need (though still valuable to know). It covers MIPS and how the CPU works, you probably can skip stuff about the hardware and microcode though. MIPS is a simpler assembly language than intel's stuff so its a nice starting place though.
Intel is what you'll most often encounter though so you do need to learn x86 and x86_64.
OpenSecurityTraining.info provides a number of courses that are valuable for this bridge to breaking software.
1. Life of Binaries - http://opensecuritytraining.info/LifeOfBinaries.html - This helps you go from understanding to software to understanding the system around the software and the
context in which software runs.
2. Introductory Intel x86 - http://opensecuritytraining.info/IntroX86.html - Really boring/dry class on x86 instructions but gives you the introduction you need.
3. Introductory Intel x86-64 - http://opensecuritytraining.info/Intr
oX86-64.html - Just slides this time, good to review and get a sense of the differences between 32bit and 64bit intel
assembly.
Once you've gotten the basics its finally time to move onto learning…
Vivek Ramachandran's Exploit Research Megaprimer[1] is a good video series for the basics. Peter van Eeckhoutte's article series[2] also provide a good hands on for getting started. Vivek's doing a training course at 44Con (disclaimer: I'm one of the organisers) that covers some of this[3] and looks quite promising but if London's a bit of a stretch you should be able to find training courses at conferences closer to home.
The Shellcoder's handbook is a good starting point too but is getting a bit long in the tooth. Attacking the core is a good starter on kernel bug dev. Both should be available on Amazon.
It's also worth pointing out that if you have a local Def Con chapter it's worth going at least once or twice to see whether or not you like it. Same if there's a local BSides event - these are free events, wildly variable in quality but run by the community for the community. There's also other cons like 44Con, Brucon, Cansec, Defcon etc. if you really want to get into it but these can be quite expensive.
I'm not sure where you're based, but if you're in or near London the local Def Con chapter DC4420[4] is on tuesday downstairs at the Phoenix, Cavendish square near Oxford Circus. I'll be there and will be more than happy to have a chat with you and introduce you to people.
[1] - http://www.securitytube.net/groups?operation=view&groupId=7
[2] - http://www.corelan.be/index.php/articles/
[3] - http://44con.com/training/vivek-ramachandran-hacking-with-python/
[4] -…
Canaries and other techniques that leverage volatiles do not prevent an overflow; they just try to cope with the consequences of an overflow which has happened. (This is why they're generally lumped together as "mitigation".) The canary tries to detect the case of an overflow which overwrites the return address in a stack frame. Data Execution Prevention (DEP) takes this idea a step further, it assumes that the return address has been overwritten and followed, and it restricts the areas where execution could jump. ASLR is yet another step further: it "shuffles" the areas where execution is allowed.
More specifically, stack canaries work by modifying every function's prologue and epilogue regions to place and check a value on the stack respectively. As such, if a stack buffer is overwritten during a memory copy operation, the error is noticed before execution returns from the copy function. When this happens, an exception is raised, which is passed back up the exception handler hierarchy until it finally hits the OS's default exception handler. If you can overwrite an existing exception handler structure in the stack, you can make it point to your own code. This is a Structured Exception Handling (SEH) exploit, and it allows you to completely bypass the canary check.
DEP and NX (what OpenBSD calls W^X) mark important structures in memory as non-executable, and force hardware-level exceptions if you try to execute those memory regions. This makes normal stack buffer…
Why is this on the front page? Metasploit's msfvenom and others are well ahead of this and it looks pretty cheap.
It's incredibly easy to bypass virus scanners, did it when I thought that building malware is a cool thing (it really isn't, although DLL injection, function trampolines and ROP chains are a nice way to spend some time). After building malware, creating APTs and others, I don't see the point in it anymore. There are so many ways to make money legally and in a way that's useful for society.
Let's build something great instead of cheap obfuscator scripts.
For anyone interested in learning the real stuff, this is a good start: https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/ (it got harder in the last years - stack cookies, DEP, kernel ASLR, browser sandboxes ... make it very hard to build reliable exploits - today it's easier to just scam people, I miss the times of Flash usage).
LSM, LXC, chroot, seccomp have well defined APIs for separation. My comment was referring to ptrace.
Interposing (i.e violating API contracts) with ptrace is great for debugging or research prototypes, but the knowledge gained from that research needs to be made interoperable with existing APIs that have been battle tested. Paper said that ptrace/debug overhead is 100%, seccomp (an existing, non-debug API) reduces the need to use ptrace, halving runtime overhead.
Separately, a kernel exploit could break the "sandboxing" of ptrace or docker, hence the need for AppArmor and SE Linux. Here is a year-old Windows article about breaking out of Adobe and Chromium, principles are similar for Linux:
https://www.corelan.be/index.php/2013/03/15/blackhateu2013-day2-the-sandbox-roulette-are-you-ready-to-ramble/