I read an answer here which talked about becoming a PenTester. The answer said that you have to learn to break software. I posted a comment on the answer asking where do I start learning to break software, but I didn't get any replies, so I decided to ask my own question. How do I learn to break software? I am already a programmer and I know Java, C++. Also I am familiar with JavaScript, CSS, HTML, Python and C. I regularly read about security vulnerabilities, but now I want to know how do I find them.


Edit: I've done things like using the winnt.h header in C++ to change the entry points of executables, and add new sections to executables, hell I've written a whole working windows executable only with a hex editor.

Edit: Narrowing down the question: I am interested in website and webserver vulnerabilities, Operating System vulnerabilities, Vulnerabilities in computer memory like MemoryLeaks, things like viruses, etc.

  • This question seems way too broad. A start would be to describe the kind of vulnerability and software you are interested in. Buffer overflows? Web vulnerabilities? Flaws in Crypto stuff? But even if you do get more specific, this seems too broad a question. – tim Jun 19 '15 at 10:15
  • @tim I narrowed the question a little, seem ok? – nom Jun 19 '15 at 10:23
  • 1
    that still seems very broad to me. It's basically everything except hardware, physical and crypto security. I mean, what would a good answer look like? It would either be very broad (look at code, read about common vulnerabilities, then try to find them in the code; use the software and see what happens with various inputs) or very narrow (use scanner X, read tutorial Y) – tim Jun 19 '15 at 10:36
  • 1
    Agree with @tim — this question is far too broad. However, I can recommend this online course: coursera.org/course/softwaresec (It started a couple of weeks ago, but you should still have time to catch up) – r3mainer Jun 19 '15 at 10:42
  • 1
    I think the Google term you need to use is "exploit development" or "bug hunting" – schroeder Jun 19 '15 at 20:52

There is no one way to find vulnerabilities. But here are some steps you can follow.


First you need to choose a platform and a piece of software to attack. To begin I would choose something that is open source. There are several advantages to this; the main one being that you can look at the source code. You then need to pick an aspect that you would like to attack. For example, maybe you want to attack the UDP implementation of the Linux networking stack.

Performing an analysis on a closed source piece of software means you're disassembling the binary, rooting through instructions, and debugging the process. This is long and tedious. Better to get a grasp as to what breaks code with source code before you go looking for it in disassembly.

By being specific in your target allows you to systematically analyze a piece of software.


With your target in mind begin your analysis of the portion of the software you want to find vulnerabilities.

  • Determine which source code files affect your target.
  • With open source you can insert debug messages to ensure you understand the code flow. This can be extremely important. Knowing what sections of code are called, and the variables that lead to that outcome is key in understanding what is going on.
  • Run code analysis tools over the project. Depending on the project this might be a moot point, but they can be handy and catch common programming errors.
  • Enable all of the compiler build flags. Your goal is to find programming errors. What better way than to have the compiler tell you where it thinks the code is bad.

These are just a few of the things you can do to analyze the software. Build a list of possible coding errors.


Now with a list of possible coding flaws you need to determine if you can trigger them. Again, debug messages will help you. Go back to the source code and determine what exactly needs to happen for each coding flaw to break the software. You're not looking for full exploitation, you just want the code to crash, or do something unexpected. You need to determine what could trigger a coding flaw. This could be anything from affecting a length variable, tricking a function to take a path to process data incorrectly, etc. Some coding flaws just aren't triggerable, but that's the nature of vulnerability analysis.

At this point you have a list of flaws, and a list of ideas for each flaw on what might trigger it to do something unexpected.


Now you write code. Using pretty much whatever programming language is convenient for the software you're attacking. You could write Python code to throw specific packets at network devices to attempt to take down the UDP implementation of a Linux based device.

The goal is to implement your triggers, and hope that the code works the way you think. Your debug messages will be helpful here.

  • They can tell you if the code path taken is abnormal.
  • They can show you variables that you're attempting to manipulate
  • They ensure that your trigger is doing what you expect, and you can adjust it accordingly.

With any luck you're able to cause something different to happen. Maybe that can lead to code execution, maybe not. That's a horse of a different color.


Vulnerability analysis takes time. A lot of time. You're not going to spend a day analyzing software and find 10 vulnerabilities. The unofficial average for vulnerability analysis is 1 vulnerability per 3 months of analysis. You can double that time if you're analyzing a non-open source project.

| improve this answer | |
  1. This type of research is, isn't, won't be, or will be illegal depending on where you live, and may have unintended consequences. Avoid doing that with your employer's network, or, worse, with your spouse's connection.

  2. Some vulnerabilities can be located by fuzzing. Once a vulnerability has been found, you can learn how to assess them by reading proof of concepts. E.g., http://www.openwall.com/lists/oss-security/2015/01/27/9

| improve this answer | |

To explain in brief :

First of all for your understanding, understand the difference between making code and breaking code, as you are a programmer you were aware of developing the web application's login page.

Now as a vulnerability finder how you need to test is, first fit in shoes of hacker and breach as much as you can. As you are aware of website vulnerabilities, explore the web how to test the vulnerability within your application: for example I am aware there was a vulnerability SQL injection:

  • Identify the vulnerablity
  • how can I test the vulnerablity
  • categorize whether it can be manually checked or it should be detected using tools

Let me give an example:

  • vulnerablity : SQL injection
  • webpage need to be tested : login.aspx
  • tools used : crawl the login page with SQL injection
  • is it vulnerable? If yes fix it as a developer, there are ready-made tools available at market for every web application vulnerability.

In general you could verify owsap standard and the web application hacker's handbook for a start.

In summary for your question it's similar to your development.

In development: get the requirement-->develop the requirement-->test-->fix-->release.

In security: develop-->identify vulnerability-->explore vulnerability-->match vulnerability with your developed application-->test-->fix

| improve this answer | |
  • Yours is a nice answer, but most websites now prevent SQL injection by not allowing statements like OR 1==1 so you can't really use it (please correct me if I am wrong). I am talking about things more like CVE-2004-0207 Shatter Attack on windows, who could have thought about something like that? – nom Jun 19 '15 at 11:00
  • The specific example is not important - look at the process vignesh describes – Rory Alsop Jun 19 '15 at 11:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.