Hacking For Beginners

Intro

Since there are many beginners here, I think it would be fair to give some advice in one big post, rather than answering hundreds of questions individually.
You can find a lot of resources to use for learning in Tech Wiki. I’m trying to update it when I have time.

I will suggest two paths, both of which work, but have different approaches and end goals.

  1. The “Long way”.
  2. The “Fast and Furious” way.

Long way

The idea of the Long Way is to start from the very beginning, with the basics, namely computer science, programming, and networking.
This will take you a long time, 1, maybe 2, or maybe even all 5 years, but that’s okay, there’s no need to rush. In the long run, you will become a much better specialist than most applicants on the job market.
Of course, you can learn all this in college/university, and in fact, that would be the best option. It took me a long time to learn all this on my own, and it was difficult. Really.

The idea behind this long journey is simple:

You hack programs → programs run on computers → therefore, you need to know how both work.

Seriously, this simple idea is often overlooked because advertising wants you to think that it’s easy and that MegaCoolHackingAcademy knows some magical way to teach you all of this in 3 months.

What’s next

Okay, you’ve learned the basics, you know how computers work, you know the basics of operating systems, a little bit of assembly language, C, maybe C++. That’s pretty cool. So what’s next?

Start with the basics of binary file exploitation. Thirty years ago, people hacked binary files because literally the entire Internet consisted of only HTML + CSS and nothing else.

And don’t think it’s useless. How do you think researchers find vulnerabilities in server software?

Don’t rush, maybe another year. Maybe more, don’t worry, learn as much as you can.

And FINALLY, you can learn web application security, API security, web3, and anything else you want. Trust me, after all this, everything will be easy for you.

You will have enough knowledge to quickly gain a deep understanding of almost any topic. Your knowledge will allow you to learn anything.

Fast and Furious way

Now let’s talk about the Fast and Furious way.

I think most of you want to hack just for the money. That’s okay, I’m not judging anyone. And yes, it’s possible, it will be faster, but not too fast, don’t even think about a few months. At least 2 years.

I would advise you to start with web application security rather than penetration testing. Penetration testing is actually much more complex than it appears, because it encompasses several topics, such as web application security, API security, pivoting, and perhaps even binary exploitation.

First, participate in CTF games to get used to working outside the training ground. When you feel confident, IT’s TIME to start hacking for free…

Unfortunately, most large bug bounty programs are filled with professionals in the field. Start with VDP programs. In fact, no one else is doing them, so there is no competition. You won’t always earn money, but you will gain something more valuable than experience: reputation. Maybe someone will even invite you to join a private vulnerability program, who knows?

What’s Next

It’s the same as with the Long way. The difference lies in how difficult it will be to learn something new or perhaps switch completely to another area of cybersecurity. It will always be difficult because you will need to find answers to many questions, while the long road will give you enough knowledge to understand why something works the way it does and why it is vulnerable.

Myths we believe in

  1. “Hacker mindset” is something we born with.
    NO AND NO. Any “mindset” is just a skill, you will adopt it by time, don’t worry.

  2. “White hat” hackers have carte blanche.
    No (unfortunately). Actually 90% of what white hat hackers do, is work with bureaucratic hell. They need to follow a lot of rules.

  3. CTF games are useless.
    CTF games are perfect to learn some new skill. Especially CTF games is useful for beginners to learn work in black box scenarios.

  4. Low level hacking is dead
    Say that to IoT and kernel developers who encounter with security issues day by day

  5. Certifications makes you professional
    Sorry for the bad language, but that’s complete bullshit. I know many excellent professionals who don’t have a single certificate, but they are better hackers than most “certified” hackers.

  6. (Suggest some myth in comments :new_moon_face:)

Outro

I hope I have been of some assistance to you. Do not be afraid of new things; it is always difficult at first. It will become easier later.

I would very much like to hear your opinion in the comments. Feel free to criticize and ask questions. This will help us improve.

8 Likes

Thanks for the helpful post. Most of it I agree with but some I don’t. I’d like to know what you and others think about it. It might be a good discussion to have to see where our viewpoints differ.

I don’t really agree that learning this is necessary purely depending on your goals and interests, assuming you know them already. While it’s always “good to know” a little bit about everything, I think it’s overkill to learn or even start with this information if it’s entirely irrelevant to what you will end up doing.

If I want to specialise in web applications or cloud or infra, learning asm/C/C++ is largely, if not entirely, useless to me. Time would be better spent learning relevant languages (PHP, Java, C#, JS, etc.) and reading about networking, web applications, etc. If there comes a time where you need to audit a web application that runs on C, like those that serve the web interface on your router, then you should learn it as required, along with binary exploitation. Otherwise, it’s just too niche to be useful for the typical person.

Besides the obvious skill issues, I’ve started to come to the realisation that some people are literally not built for some things. Call it mindset, aptitude, neurotypicality, whatever. Some people cannot stare at the same piece of code for months on end. Some people cannot fathom reading disassembly. Some people don’t have the ability to think like an attacker and come up with creative ways of bypassing mitigations. Some people don’t know how to think at all. Know your strengths and play towards them.

Know your strengths and play towards them.

I think that’s the best way to carry on with infosec (or anything tbh). Know how you learn/study is crucial, because not every methodology suits to everyone.

I completely agree, which is why it’s called “The Long Way.”
I am (almost) equally knowledgeable about binary exploitation and web application security. However, there are no significant differences in testing methodologies between the two. After all, we also deal with server software, we still fuzzing, and it is still useful to know how it can be hacked outside the traditional world of web application security. Sometimes bugs from binary exploitation can provide inspiration (or perhaps just experience) that can be used in other areas, and in vice versa, experience in web applications can help when auditing binary files.
This way is mostly about to become good in security in general and do not isolate your potential.

I won’t lie, I was a complete idiot when it came to information security :melting_face: And, in my opinion, I still am.

Anyway, most people are just afraid to try something new. But there is good news: our brain is very adaptable, very adaptable. I don’t want to get too deep into science here, but in fact, our brains (of course, if your IQ is higher than the IQ of bread) can learn almost anything. Everyone just needs an approach that works for them, and of course some motivation too.

Information security is actually still a fairly new thing in history, so there is no methodology for studying it. Everyone starts with something and does it their own way. The methods I mention above are just ways that I’ve noticed most people use, and they just work, I don’t know why.

So long story short. In my opinion, everyone can learn everything if he really wants it.

I agree that testing methodology is roughly the same but the similarities in vulnerabilities are quite different. Memory corruption vulnerabilities (mostly) do not exist in the large majority of web or server applications written in memory safe languages so they are irrelevant. You could argue logic bugs are always a possibility in any application but I don’t necessarily agree that focus on them exists in nearly the same capacity. I think it’s better to spend time focusing on how specific vulnerabilities originate in their respective technology stack. It’s useless to look for memory corruption in a Java web application (ignoring things like PHP deserialisation or JS engine memory corruption attacks since those are the exception than the norm). It might be more realistic the other way around since (de)serialisation, SQLi, or path traversal could exist in C/C++ applications. But even then, it’s likely not going to play a significant role, depending on what you are auditing.

Maybe I can understand your view from a conceptual, theoretical level but in practice, it isn’t super relevant or useful?

This probably boils down to the philosophical question: given an infinite amount of time, could the average human rediscover all of current technological and scientific advancements? I don’t think they could. But maybe it’s false equivalence.

1 Like