Warning: If you're truly determined to read this article to the end, you won't regret it, but it's highly recommended that you find yourself in a comfortable environment and have a cup of coffee nearby, as it can be quite long. Also, if you decide to continue the challenge after reading the beginning, please bookmark the article. Reading the entire thing may take you about half an hour, depending on your reading speed. In the meantime, don't forget to like the article, subscribe to the newspaper to be notified of new articles, and follow me on Medium!

I've been working in cybersecurity and blockchain security for 6 years. I've held management positions in many companies in this field. I've founded several startups and have been doing bug bounty work in my free time for years.

Are there any of you here who got spoiled by the title and came here thinking, "Yes, another 100-day series, I'm sure this time"? Yes, I see you, my dear friends. Please don't judge this article by its length; here, we're giving a summary of what we'll be doing for 100 days, and we're creating a series that we'll follow with weekly Medium articles over the next 100 days, and more importantly, one where you can improve yourselves by following along.

In this article, we will first ask ourselves some questions, then solidify your "I'm going to be a bug bounter" mindset, and finally, we will try to establish a new daily routine.

First of all, I know many of you start a series like this and then give up halfway through due to exams, ex-girlfriends or boyfriends, family, or a million other things that are really important to you. I also know that some of you have the mindset of "I'm already perfect," but are experiencing an internal imposter syndrome. My dear friends, bug bounty has left behind the "gold rush" period of 2018–2021. You may be seeing videos and articles everywhere that say, "Yes, now I'll show you how to find bugs in 15 minutes," and experiencing the disappointment of trying those techniques and finding nothing.

The good old days are gone; they mounted their fine horses and rode away, leaving behind a market where only those with a strong work ethic and mental fortitude can survive, a market that demands high-performance work, where a technical and methodological approach is essential, and where those with extensive technical knowledge, not the lucky ones, will win.

First of all, it all comes down to you. This isn't an easy field anymore; you might not earn anything for months. We're embarking on a path that will mentally mature you and give you that "gitgut" feeling you only experience in soulslike games, in real life.

Question 1: Stop and ask yourself this question, Am I psychologically prepared for the challenges I will face in this type of situation?

If your answer is no, save this article and come back here when your psychology is truly ready. This is really important; if the answer to this question you're asking yourself is truly no, instead of being here and trying this, you should first prepare your psychology and gather strength for it..

My advice to those who say yes is to be sure of this answer for the sake of their own egos. Now, my friends who say yes, the first thing I want from you is this: I want you to collectively forget about all those YouTubers, writers, and your buddies who are selling you dreams (I'll talk about those who aren't selling dreams). Forget about automated tools, one-liner payloads, and tools that are said to be incredibly effective. We will use tools in this process, but we will learn what to look for and where to look, and we will learn to use tools where and when necessary. Today, organizations eliminate simple and known vulnerabilities (low-hanging fruits) at the code generation stage thanks to automated security scanners and AI-powered defense mechanisms (WAF and RASP solutions) integrated into CI/CD (Continuous Integration/Continuous Deployment) processes. This situation has reduced the success rate of entry-level researchers who rely only on automated tools or use attack payloads copied from YouTube videos without understanding them to almost zero.

I'm not a believer in luck, and I advise you not to be either. Finding vulnerabilities in systems by scanning with automated tools is entirely a matter of luck. I'm not saying you can't find them, but you really need a high level of luck.

Think of it this way: this tool is on that GitHub page, and there are 100,000 other people following that influencer along with you. Do you think that tool has already identified existing bugs in the public hunt area of ​​your bug bouncing platform? Yes, of course it has, and some weren't even detected because this automated tool was detected by the WAF, and 90% of the requests it sent were either returned empty or directly blocked by the WAF.

Bug Bounty is about that cunning fox that resides in everyone's mind. In some people, this fox is naturally more developed than others, while in others, it needs to be nurtured.

To avoid confusion, let me elaborate on the metaphor: when you go to a shopping mall, do you simply walk through the X-ray machine and rush into the store, or do you think about how this machine works and how it can be bypassed?

This question is about how self-critical you can be; be honest, "those who lie to themselves are destined to lose." Now let's move on to our second question.

Question 2: How developed is that fox you feel deep within your mind?

The answer to your question is that if I can't quite grasp this, then it's extremely important that you start thinking this way. The common characteristic of all cybersecurity professionals is that they have different perspectives on things. Our uniqueness stems from being unconventional. We look for vulnerabilities in all systems in life; we're not just focused on computer systems.

If, from your bunker with thick walls and "no entry" signs, you answered this question with something like, "Of course, we get along very well with foxes," then you're in exactly the right place.

Now let's look at your life and observe how good you are at forming habits. Don't think of this simply as being successful as a bug bounter. The path to becoming successful individuals in life and feeling free is related to the determination to form habits. Think about your morning routine; the order you establish after waking up shouldn't be about "let's see what we'll encounter today." Another goal of this series is not to make you a bug bounter, but to make you feel like a real bug bounter. Now let's move on to our next question. Let me repeat, be honest, you may have found these questions very annoying, but you can think of it like installing a Security OS on your computer before examining a system.

Question 3: Am I good at habit formation and self-discipline?

If your answer is no, I think that's the first thing we need to address. You need to wake up at the same time every morning, sit down at your computer, and continue where you left off last night. Bug Bounty is generally extremely boring. We don't enjoy the process until we discover vulnerabilities in systems; only after pressing ENTER and seeing proof of the vulnerability do we enjoy the dozens of hours we spent. Therefore, it's necessary to continue working consistently and turn it into an obsessive habit.

If your answer is yes again, and you answered yes to this question, I think all you might need is someone to guide you. I think you need a little spark. And that's what we'll be doing throughout this series.

First of all, I think we're mentally prepared and have answered the questions in our minds. You probably see people saying that cybersecurity bug bouncing is dead. Cybersecurity or bug bouncing isn't dead and never will be; it's just that the "gold rush" era is over. Currently, attack surfaces, due to microservice architectures, complex API integrations, and the expansion of multi-cloud structures, create higher-yield opportunities than before, only for bounty hunters who can reach that level of expertise. The path to success is no longer about using tools, but about properly analyzing the target system architecture, business logic, and developer errors. We will be understanding systems during these 100 days. My request to you is this: you may think you know the topics covered on some days, but based on my experience, I can clearly say that you most likely don't know them in depth. We shouldn't approach it with the mentality of "let's learn only what's useful to us and forget the rest," like we programmers do. Cybersecurity is a kind of R&D that a person develops on their own. Even if you're 100% sure you know something, please don't let your ego get the better of you. Instead, approach the topic with the mindset of, "What else can I learn about this topic today?" Plus, you might not achieve this in 100 days. Understanding certain topics might take longer; if you feel you don't understand something, spending a few extra days studying it won't set you back, it will move you forward.

Here, I'll provide a tracking chart outlining how you can work through each day without going into too much detail. We'll then examine this in phases through articles. If you're determined to start, follow me on Medium and subscribe to my newsletter to see weekly articles. Since we'll be starting from day one, bookmark this article and check back each day. Definitely use AI tools like a teacher in your research and learning. I'd be happy to hear your suggestions in the comments; let's discuss and improve together. Let's begin.

DAYS

If you think you know the topics covered on the given days very well, you can review them and move on to the next day. However, only do this if you feel like you can speak as well as an authority on the subject or explain it to a 7-year-old. Remember, people are destined to be prisoners of simple subjects or subjects they think they know. Always write down what you've studied, not just copy and paste, and be sure to review your notes. There's something my old followers know, and that I constantly tell those around me.

Words fly away, writing remains, but even writing lasts very little.

Day 1 Network Fundamentals and Packet Analysis:

To solidify your understanding of network fundamentals, today's goal is to theoretically grasp the 7 layers of the OSI model and the TCP "Three-Way Handshake" process, followed by practical analysis using Wireshark. Install Wireshark on your computer and capture traffic from example.com, meticulously examining HTTP headers (GET, Host, User-Agent) and IP addresses. Conclude the day by running ping and tracert commands via the terminal, interpreting the outputs, and putting your theoretical knowledge into practice.

Sources: https://prepare.sh/articles/the-osi-model-a-deep-dive-into-the-seven-layers-of-network-communication https://medium.com/%40Praveen_Fernando/tcp-3-way-handshake-demo-with-wireshark-9dddce2d088e https://medium.com/%40heetmehta18125/http-protocol-with-wireshark-packet-analysis-eefb97e95306 https://www.networkacademy.io/ccna/network-fundamentals/osi-model-in-practice

Day 2 HTTP Protocol and Methods:

Today, focusing on the architecture of the HTTP protocol, I want you to schematize the Request and Response cycle, learn critical status codes (200, 403, 500, etc.), and delve into the security risks of HTTP methods. To put the theory into practice, you should use the curl tool in the terminal to both analyze the handshake process in detail (-v) and experiment with how to manipulate traffic by sending server-specific headers (e.g., changing User-Agent).

Sources: https://apichallenges.eviltester.com/tutorials/http-basics https://medium.com/%40reveni324/http-fundamentals-for-cybersecurity-4ddaf13f2fe1 https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status https://cybersecnerds.com/curl-everything-you-need-to-know

Day 3 DNS and Domain Name System:

Today you should focus on deciphering the DNS system, the internet's phone book. After understanding the DNS hierarchy (Root -> TLD -> Authoritative) and record types (A, CNAME, MX), you should reinforce this knowledge by performing real-world queries using the dig and nslookup tools in the terminal. In particular, you should analyze the logic of the "Subdomain Takeover" vulnerability, which you will frequently look for in bug bounty processes, through CNAME records, and finish the day by improving your ability to gather information about the target using the whois command.

Sources: https://adminions.ca/books/information-gathering/page/domains-dns https://neatcode.org/dns/ https://wstg.oia.ovh/configuration-and-deployment-management-testing/test-for-subdomain-takeover https://nemocyberworld.github.io/BugBountyCheckList/Reconnaissance/whois-dns/

Day 4 Introduction to Linux:

Today, you should start by analyzing the file system hierarchy (/, /etc, /var) to master the Linux terminal, then build muscle memory by practicing extensively with navigation commands like cd, ls, and mkdir. After grasping file manipulation operations (cp, mv, cat), you should conclude the day by practically solving the file permissions (chmod, chown) and authorization logic, which are the backbone of system security.

Sources: https://www.pathname.com/fhs/ https://www.geeksforgeeks.org/linux-file-commands/ https://linuxhandbook.com/basic-linux-commands/

Day 5 Let's Deepen Our Linux Skills:

Today, you should focus on improving your data processing and filtering skills in the Linux terminal. You should understand the logic of "Piping" (|) which connects command outputs, and learn how to perform detailed searches within files using grep. After organizing and cleaning data with sort and uniq, you should get started with text manipulation using powerful tools like awk and sed; you should finish the day by extracting "Error" lines from a real log file and reporting them to a new file.

Sources: https://linuxhandbook.com/awk-command-tutorial/ https://www.loggly.com/ultimate-guide/linux-logging-basics/ https://www.gnu.org/software/bash/manual/html_node/Pipelines.html

Day 6 Introduction to Bash Scripting:

Today, you'll step into the world of Bash Scripting, the backbone of cybersecurity automation. First, you'll understand the importance of the `#!/bin/bash` line (shebang) and get the "Hello World" output. Then, you'll master the logic of performing batch operations on lists using variables and loops (for loops). You should finish the day by turning the code snippets you've written into executable, real automation tools using the `chmod +x` command and testing them.

Sources: https://www.gnu.org/software/bash/manual/bash.html https://linuxcommand.org/lc3_writing_shell_scripts.php https://www.shellscript.sh/

Day 7: HTML and DOM Structure:

Today, you're going into the "kitchen" of web security. Your goal is to understand the HTML structure, which is the skeleton of web pages, and how the browser interprets this structure (DOM). After understanding the working logic of the <script> and <form> tags in particular, you should explore the power of manipulating a website in real time with Browser Developer Tools (DevTools). You should conclude the day by analyzing the data transmission methods (the difference between GET and POST) of HTML forms, where attack vectors are most frequently found.

Sources: https://developer.mozilla.org/en-US/docs/Web/HTML https://portswigger.net/web-security/html https://portswigger.net/web-security/dom-based

Days 8–9: JavaScript Fundamentals:

Today, you will directly experience the working logic of JavaScript, which is key to client-side attacks (especially XSS), in the browser console (Developer Tools). First, you should test code execution with alert(1), then analyze how critical objects such as document.cookie and window.location can be turned into weapons (session hijacking or redirection) in the hands of attackers. You should end the day by understanding how asynchronous requests are created with the Fetch API, the data carrier of the modern web.

Sources: https://portswigger.net/web-security/cross-site-scripting https://portswigger.net/web-security/cross-site-scripting/dom-based https://developer.chrome.com/docs/devtools/console/ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide

Day 10: Let's Learn Burp Suite:

You're about to fully master Burp Suite, the "Swiss Army Knife" of a bug bounty hunter. After completing the installation and setting up FoxyProxy and the CA Certificate (required to read HTTPS traffic), you must learn how to intercept traffic in mid-air and modify the data before it reaches the server. You should master the Repeater module, which allows you to repeatedly modify and send the intercepted requests, and theoretically understand the attack types (Sniper, Pitchfork, etc.) of the Intruder module used for automation attacks (fuzzing).

Sources: https://portswigger.net/burp https://portswigger.net/web-security

Day 11: Introduction to SQL Injection (SQLi):

Today, you should focus on solving one of the oldest and most critical vulnerabilities in web applications: SQL Injection (SQLi). You need to understand how database queries (SELECT * FROM…) work and how that seemingly innocent single quote (') can corrupt the query structure and turn you from a "visitor" into a "command-giver". While putting theory into practice in the PortSwigger labs, you will see how the OR 1=1 logic tells the system "Everything is fine, open the door" (Login Bypass). You should end the day by preparing a solid cheat sheet with notes of the comment line characters (-, #, /*) that are vital for different databases (MySQL, PostgreSQL, Oracle).

Sources: https://portswigger.net/web-security/sql-injection https://book.hacktricks.xyz/pentesting-web/sql-injection https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection

Day 12: SQL Injection UNION Attacks:

Today, you'll focus on UNION-based SQL Injection techniques, one of the most effective ways to leak data from a database. Your goal is to iterate through tables by appending the results of your desired query to the results of the current query. To do this, you must first determine the number of columns by trial and error (1, 2, 3…) using the ORDER BY command until you get an error, and then discover which columns display data (text) using the UNION SELECT NULL, NULL… tactic. While putting this theory into practice in PortSwigger labs, you should conclude the day by noting down payloads that reveal version information (@@version, version()) according to the database type (MySQL, PostgreSQL, etc.).

Sources: https://portswigger.net/web-security/sql-injection/union-attacks https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection#union-based https://book.hacktricks.xyz/pentesting-web/sql-injection/union-based-sqli

Day 13: SQL Injection — Data Extraction:

Today, you'll focus on data exfiltration techniques, the most critical phase of SQL injection attacks. Your goal is to map the database's internal structure (information_schema, etc.) and inject sensitive data (usernames, passwords) into the existing page content using the UNION operator. The String Concatenation technique, in particular, is a lifesaver in limited viewing areas. You should reinforce this process by noting the critical syntax differences (e.g., the difference between || and CONCAT) between Oracle, MySQL, and PostgreSQL while extracting username and password information in a single line in PortSwigger labs.

Sources: https://owasp.org/www-community/attacks/SQL_Injection https://www.sqlshack.com/sql-string-concatenation/

Day 14: Blind SQL Injection: Today, you'll be learning Blind SQL Injection techniques, the most insidious and time-consuming type of SQL Injection. The database will no longer openly display data; instead, you'll learn to gauge the system's response by asking "Yes/No" questions (Boolean-based) or delaying the answer (Time-based). In the PortSwigger labs, you'll manipulate the database and measure its responses using functions like pg_sleep() or WAITFOR DELAY; and you should conclude the day by adding the basic commands (-dbs, -tables) of sqlmap, the legendary tool that automates this arduous process, to your repertoire.

Sources: https://portswigger.net/web-security/sql-injection/blind https://book.hacktricks.xyz/pentesting-web/sql-injection/blind-sqli https://owasp.org/www-community/attacks/Blind_SQL_Injection

Day 15: Cross-Site Scripting (XSS) — Reflected: Today, you should focus on understanding Cross-Site Scripting (XSS), one of the most common and dangerous vulnerabilities in modern web security. First, you should analyze the architectural differences between Reflected, Stored, and DOM-based XSS; then, you should master techniques for executing JavaScript from within HTML attributes by bypassing filtered characters (e.g., angle brackets), starting with simple HTML context injections in the PortSwigger lab. You should conclude the day by creating your own personal XSS payload archive based on scripts, SVGs, and event handlers (onerror, onmouseover) that you can use to bypass different filters (WAFs).

Sources: https://portswigger.net/web-security/cross-site-scripting/reflected https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context https://portswigger.net/web-security/cross-site-scripting/reflected/lab-attribute-context

Day 16: Stored XSS: Today, you'll focus on Stored XSS (Persistent XSS), a "stealthy" and "persistent" version of XSS vulnerabilities. Your goal is to infect everyone who visits the page by saving the malicious code not only to yourself (Reflected) but also to the server's database. While working in the PortSwigger labs, you'll see that standard <script> tags don't work, especially in the second task (anchor href attribute); this is where you need to learn how to bypass filters using javascript: pseudo-protocol. You should conclude the day by analyzing why Stored XSS can create a mass impact without needing a "clickbait" and why it's generally considered critical at the P1/P2 level in Bug Bounty programs.

Sources: https://portswigger.net/web-security/cross-site-scripting/stored https://book.hacktricks.xyz/pentesting-web/xss-cross-site-scripting/stored-xss https://owasp.org/www-community/attacks/Stored_XSS

Days 17–18–19: DOM Based XSS: Today, the attack vector shifts entirely to the client-side; that is, we're talking about a job that ends within the browser without ever going to the server. To understand the logic of DOM XSS, you must follow the flow between the point where the data enters (Source: e.g., location.search) and the point where it is executed (Sink: e.g., document.write). In the PortSwigger labs, you will see how dangerous functions (Sinks) like document.write and innerHTML process user input uncontrollably. You should end the day by exploring DOM Invader, the built-in beast of Burp Suite, which makes it incredibly easy to detect these vulnerabilities, which are like searching for a needle in a haystack.

Sources: https://portswigger.net/web-security/cross-site-scripting/dom-based https://portswigger.net/research/dom-based-xss https://book.hacktricks.xyz/pentesting-web/xss-cross-site-scripting/dom-xss https://portswigger.net/research/dom-invader

Day 20: Cross-Site Request Forgery (CSRF): Today, you'll learn about the Cross-Site Request Forgery (CSRF) attack, which turns a user's browser into a weapon against the user themselves. The basic principle is this: When browsers make a request to a site, they automatically send the site's credentials (Session Cookie); the attacker then abuses this "trust" relationship. While testing this theory in the PortSwigger labs, you must first perform an unauthorized action (e.g., changing the email address) on an unprotected form, and then bypass the developer's "Only check tokens on POST requests" error (HTTP Method Interchange — converting POST to GET). You should conclude the day by practicing with Burp Suite's "Generate CSRF PoC" feature, which automatically generates an attack page (HTML Form) for you when you right-click.

Sources: https://portswigger.net/web-security/csrf https://book.hacktricks.xyz/pentesting-web/csrf https://developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#cross-site_request_forgery_csrf

Days 21–22: Server-Side Request Forgery (SSRF) Today, you'll focus on exploring internal networks that are inaccessible from the outside by using a web server as a "proxy": Server-Side Request Forgery (SSRF). The logic is simple; you give the server a URL, and it goes to that address on your behalf. In PortSwigger labs, you will use this mechanism to gain access first to the server itself (localhost/127.0.0.1), and then to other hidden systems on the internal network. You should end the day by understanding the importance of the 169.254.169.254 (Metadata Service) address, which is the biggest nightmare of modern cloud architectures (AWS, Google Cloud, Azure) and leaks server credentials.

Sources: https://portswigger.net/web-security/ssrf https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html https://cloud.google.com/compute/docs/metadata/overview https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service

Day 23: XML External Entity (XXE): Today, you're targeting a critical vulnerability in the data processing layer of web applications: the XML External Entity (XXE) vulnerability. The basic principle is that when the application processes XML data, it also executes malicious external entities (External Entities) that you define without question. In PortSwigger labs, you will use this mechanism to first read the server's most sensitive files (/etc/passwd or c:/windows/win.ini), and then try to infiltrate the internal network by turning this vulnerability into an SSRF attack. You should end the day by learning that even endpoints that expect JSON, not just XML, can be made vulnerable to XXE by being tricked with the Content-Type: application/xml header (Content-Type Spoofing).

Sources: https://portswigger.net/web-security/xxe https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing https://www.w3.org/TR/xml/#sec-external-ent

Day 24: OS Command Injection: Today, you'll tackle OS Command Injection, a hacker's dream vulnerability that allows you to execute code directly on a server. Your goal is to infiltrate the operating system's command line and insert your own commands using operators like ;, |, or &&. In PortSwigger labs, you'll first solve a simple scenario where you can see the output, and then a Blind scenario where you measure the system's response with ping or sleep if the result isn't displayed on the screen. You should finish the day by memorizing basic reconnaissance commands like whoami, id, and uname -a, which answer the question "Who am I and where am I?" once you've infiltrated.

Sources: https://portswigger.net/web-security/os-command-injection https://book.hacktricks.xyz/pentesting-web/command-injection https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection

Day 25: Directory Traversal (Path Traversal): Today, you'll be studying the Directory Traversal (Path Traversal) vulnerability, which aims to access sensitive files on a web server by escaping the root directory where the server has trapped you. The basic principle is to climb to a higher level in the file directory using ../ (dot-dot-slash) characters. In the PortSwigger labs, you'll start with a simple filename=../../../etc/passwd test, and then learn how to bypass filters that the application blocks by using an absolute path (e.g., /etc/passwd) or URL encoding (%2e%2e%2f) encryption.

Sources: https://portswigger.net/web-security/file-path-traversal https://book.hacktricks.xyz/pentesting-web/file-inclusion/path-traversal https://owasp.org/www-community/attacks/Path_Traversal

Day 26: Access Control & IDOR — 1: Today, you'll be introduced to IDOR (Insecure Direct Object Reference), one of the most "profitable" and common vulnerabilities in the Bug Bounty world. Your goal is to identify the flaw where the application asks only "What data do you want?" instead of "Who are you?". After theoretically understanding the differences between Horizontal (another user's data) and Vertical (admin privileges) privilege escalation, you will attempt to bypass access controls in PortSwigger labs by changing id=123 values ​​in URLs or parameters to id=124. You should end the day by ingraining the motto "Every ID you see is a candidate for manipulation" in your mind.

Sources: https://portswigger.net/web-security/access-control/idor https://owasp.org/www-community/attacks/Insecure_Direct_Object_Reference https://book.hacktricks.xyz/pentesting-web/access-control/idor

Day 27: Access Control & IDOR — 2: Today, you'll focus on bypassing access controls not just by changing parameters, but by exploiting loopholes in the server's logic (Logic Flaws). Your goal is to force-broke paths like /admin that are hidden in the interface but open in the background (Force Browsing) and to break the illusion that the server only protects certain methods (POST) by using HTTP Verb Tampering (converting to GET) to escalate privileges. You should end the day by installing and optimizing the legendary Burp Authorize plugin, which will save you the tediousness of manual testing and constantly ask "What would happen if this request was made by an unauthorized user?" in the background.

Sources: https://portswigger.net/blog/burp-authorize-plugin https://portswigger.net/web-security/access-control/lab-force-browsing

Day 28: Authentication Errors: Today, you'll focus on challenging the Authentication mechanisms, the most critical gateway to web security. Your goal is to identify valid usernames (enumeration) and expand your attack surface by using subtle clues the system gives you (different error messages or response times). While putting this knowledge into practice in the PortSwigger labs, you'll see how seemingly secure 2FA (Two-Factor Authentication) systems can be disabled through simple logical errors. You should conclude the day by analyzing vulnerabilities in password reset processes, the most common method of account takeover.

Sources: https://portswigger.net/web-security/authentication https://owasp.org/www-community/attacks/Authentication_Cheat_Sheet https://book.hacktricks.xyz/pentesting-web/authentication-bypass

Day 29: File Upload Vulnerabilities: Today, you'll focus on file upload vulnerabilities, one of the quickest ways to completely take over a server (RCE — Remote Code Execution). Your goal is to transform an innocent "profile picture upload" area into a command center (web shell) from which you can remotely control the server. In the PortSwigger labs, you will first install a PHP shell on an unprotected area and execute commands, then learn how to bypass the server's "I only accept image files" (Content-Type Validation) restriction by manipulating traffic with Burp Proxy. You should end the day by writing the simplest but most effective backdoor code (<?php system(…) ?>) with your own hands.

Sources: https://portswigger.net/web-security/file-upload https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html https://book.hacktricks.xyz/pentesting-web/file-upload

Day 30: Business Logic Errors — 1: Today, you'll focus on Business Logic errors that disprove the developer's "nobody would do that" assumption, rather than just a technical bug. You'll see how logic flaws in operation can be exploited, even when the code works flawlessly; especially in client-side systems, how you can buy a $1000 jacket for $1 with Burp Suite. While practicing price manipulation in PortSwigger labs, you should conclude the day by analyzing scenarios that abuse "business intelligence," such as entering negative values ​​(-1) into e-commerce carts to zero out or reduce the total amount.

Sources: https://portswigger.net/web-security/business-logic https://portswigger.net/web-security/business-logic/lab-price-manipulation

Day 31: Business Logic Errors — 2: Today, you're chasing so-called "impossible" errors by manipulating the mathematical limits and processing order of the system. Your goal is to go beyond a simple logic error and test numerical limits (e.g., going from a negative to a positive balance) with low-level vulnerabilities like Integer Overflow, and analyze how the system locks up with unexpected inputs (Exceptional Input).

Sources: https://portswigger.net/burp/documentation/desktop/tools/repeater https://book.hacktricks.xyz/pentesting-web/business-logic-flaws

Day 32: Information Disclosure: Today, you'll focus on Information Disclosure vulnerabilities, where you'll gather secrets that systems "let slip." Your goal is to analyze version information, database errors, or file paths hidden within seemingly innocent error messages. Then, you'll attempt to access source code by finding backup files with .bak, .old, or ~ extensions that developers have forgotten on the server. You should conclude the day by discovering a critical .git folder vulnerability that exposes a project's entire history and potential secrets (hardcoded credentials), and the git-dumper tool that exploits it.

Sources: https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure https://github.com/arthaud/git-dumper https://www.google.com/search?q=https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Information%2520Disclosure

Day 33: Completing and Reinforcing Labs: Today we will focus all our time on solving the labs we haven't completed at PortSwigger Academy. For the first 30 days, you should write a checklist of what you've learned so far. This will allow you to progress by asking yourself how permanent your learning is. You need to reread the material to address any gaps in your knowledge.

Day 34: Passive Reconnaissance and OSINT: Today is Passive Reconnaissance (OSINT) day, where you gather information without sending a single packet to your target. You begin the operation by mapping your target's digital footprint, the ASN (Autonomous System Number), and its IP blocks via bgp.he.net. Then, you must hunt for forgotten files or open directories by turning Google into a hacking tool (ext:pdf, intitle:"index of); and you must finish the day by analyzing your target's unprotected services and open ports on Shodan, which tracks every device connected to the internet.

Sources: https://bgpview.io/ https://www.shodan.io/ https://www.exploit-db.com/google-hacking-database

Day 35: Subdomain Discovery Today, you'll focus on Passive Subdomain Discovery, the quietest and safest way to map the target organization's attack surface. Your goal is to scan the internet's "memory" using tools like subfinders and amass, without directly sending packets to systems and waking up firewalls (WAF/IPS). Especially when you manually examine Certificate Transparency (CT) logs (crt.sh) where SSL/TLS certificates are recorded, you'll see how critical subdomains like dev, staging, or internal, which developers thought "nobody knows about," are clearly exposed. Today, it's time to make some noise to hunt down "ghost" subdomains that passive scanning misses: Active DNS Discovery. Your goal is to install high-speed resolvers like puredns or shuffledns and bombard the target server with SecLists' legendary subdomains-top1million list. Only by using this brute force method can you uncover private development environments (dev, staging, test-01) that have left no trace in passive sources (SSL logs, etc.) and are known only to company employees.

Sources: https://crt.sh/ https://github.com/projectdiscovery/subfinder https://github.com/owasp-amass/amass https://chaos.projectdiscovery.io/ https://github.com/vortexau/dnsvalidator

Day 36: HTTP Probing, Visual Recon, Github Scanning: Today is the day to process your raw address list (DNS data) to identify which ones actually have a web service running behind them (HTTP Service). You may have obtained thousands of subdomains from yesterday's scans, but many of them may be dead, redirected, or only running on the internal network. This "liveness check" with httpx will allow you to spend your time only on targets that are the attack surface. Today, instead of going through thousands of lines of URLs one by one, you will use the human brain's most powerful ability: Visual Processing. The "200 OK" message in the terminal doesn't tell you what the page looks like; however, a screenshot will instantly reveal whether that page is an abandoned test environment or a critical admin panel. Tools like aquatone or gowitness don't just take photos; they analyze the HTML structure (DOM) and cluster similar pages. So if 500 subdomains lead to the same "Default IIS Page," the tool shows them as a single group, and instead of looking at them 500 times, you can filter them all out in one go. Today is the day to do detective work in GitHub, the massive library where developers store their code, instead of sending packages to live systems. Your goal is to find API keys, database connection strings, and private tokens that developers have carelessly forgotten deep within publicly available projects. Remember, developers often think they've noticed the mistake and deleted the password; however, Git technology keeps track of every commit. Something you can't find in manual searches (org:target "password") can be found by tools like Trufflehog by going back to a 3-year-old version of the project (Commit History Analysis). Finding an AWS key (AKIA…) can sometimes yield more critical results than a months-long penetration test.

Sources: https://blog.projectdiscovery.io/httpx-the-all-in-one-http-toolkit/ https://github.com/michenriksen/aquatone https://github.com/sensepost/gowitness https://github.com/trufflesecurity/trufflehog https://github.com/gitleaks/gitleaks

Day 37: Directory and File Scanning (Fuzzing): Today is the day to find the hidden rooms, forgotten corridors, and locked safes (admin panels, configuration files) inside a web application that appears like a "closed box" from the outside. Fuzzing is one of the most fundamental building blocks of web security because developers often fall into the trap of "If I don't link, nobody can find it" (Security by Obscurity). The ffuf tool uses wordlists like a machine gun to uncover these hidden files in seconds. But beware: the biggest enemy when fuzzing is "false positive" results (pages that don't actually exist but are returned as if they do). Therefore, you should learn not only how to scan, but also how to mute the noise using ffuf's filtering features (-fc, -fs) and focus only on the real treasures.

Sources: https://github.com/ffuf/ffuf https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content https://wfuzz.readthedocs.io/en/latest/ https://www.hackerone.com/blog/guide-to-fuzzing

Day 38: JavaScript File Analysis — 1: Today, you're getting to the heart of modern web applications (especially SPAs — Single Page Applications). Many logic, routes, and configurations that are thought to be hidden on the server side are actually explicitly written in client-side JavaScript files. These files are like a map of the site for an attacker. The files you collect with subjs are usually compressed (minified); that is, thousands of lines of code are reduced to a single line and are unreadable. The "Pretty Print" process breaks this compressed code down into readable blocks. LinkFinder then hunts for URL patterns like /api/…, /graphql…, or /admin/… using Regex (Regular Expressions) among these code chunks. These endpoints can be "backdoors" that developers have forgotten about and often lack access control, which you can't find by clicking any button on the site.

Sources: https://github.com/lc/subjs https://github.com/m4ll0k/SecretFinder https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Methodology%20and%20Resources/Reverse%20Engineering%20JavaScript

Day 39: JavaScript File Analysis — 2: Today is the day to move beyond simply asking "which pages are there?" and hunt for digital keys and vulnerabilities embedded in the developer's code. Even though a JavaScript file may appear compressed (minified) and complex, when scanned with the correct Regex patterns, it can reveal AWS keys, Google Maps API keys, or private authorization tokens. You'll now apply the DOM XSS logic you learned in the PortSwigger labs to the real world. You need to manually track within the code whether points that retrieve data from the user, such as location.search or location.hash (Source), are passing unfiltered into dangerous functions like innerHTML or document.write (Sink). You should finish the day by gaining speed with the Mantra plugin, which automatically scans for these dangerous patterns and secrets in the background while you browse your browser.

Sources https://github.com/owasp/Mantra https://github.com/ozamora/googlemaps-api-checker https://portswigger.net/burp/documentation/desktop/tools/dom-invader

Day 40: Parameter Discovery: Today is the day to hunt down the "invisible" inputs of a web application, that is, the hidden parameters that developers left for testing or debugging but forgot to delete. A URL might look like https://target.com/index.php; however, in the background it might actually be waiting for commands like index.php?debug=true or index.php?admin=1. Tools like Arjun send thousands of possible parameter names (admin, id, user, test, source) to the server in a series and analyze the length or structure of the returned responses (Anomaly Detection) to identify those that respond "differently". ParamSpider, on the other hand, scans web archives (Wayback Machine) to find parameters that have been used in the past. Every hidden parameter you find is a potential XSS, SQLi, or SSRF gateway; because developers often leave these inputs unfiltered under the misconception that "no one can attack an invisible parameter".

Sources: https://github.com/s0md3v/Arjun https://github.com/PortSwigger/param-miner

Day 41: Wayback Machine (Archive Scanning): Today is the day to examine not only the current state of the target, but also its 10-year history. The internet never forgets; developers often forget. The goal is to find "zombie" files that are thought to be removed from the site but are still alive on the server, using tools like waybackurls or gau (Get All Urls) that scan massive archives like the Wayback Machine, AlienVault, and Common Crawl. These tools will give you thousands, perhaps millions, of URLs. This is where Tomnomnom's legendary tool gf (Grep Fuzz) comes in. This tool uses predefined Regex patterns to find the needle in the haystack. For example, the gf xss command will filter and present parameters (q=, search=, id=) that are susceptible to XSS attacks in seconds. You should finish the day by filtering and simplifying (deduping) this massive dataset to create a manageable attack surface.

Sources: https://github.com/tomnomnom/waybackurls

Day 42: Port Scanning: Today is the day you're directly interacting not with the web application itself, but with the server infrastructure it runs on. Port scanning is the art of forcing open every door and window on the exterior of a building, determining which ones are open, who is inside (which service/version), and the brand of the door lock (banner grabbing). Nmap (Network Mapper) is the Swiss Army knife for this job. While you run the default discovery scenarios with -sC (Script Scan), you read the service's ID card with -sV (Version Detection). Scanning port 65,535 requires patience; that's why professionals usually use faster tools like Masscan or Rustscan to find open ports first, and then use Nmap to delve deeper into those ports.

Sources: https://stationx.net/nmap-cheat-sheet/ https://github.com/projectdiscovery/naabu https://book.hacktricks.xyz/network-services-pentesting

Day 43: Fingerprinting: Today is Fingerprinting day, where instead of blindly attacking your target, you decipher the architecture of your opponent's structure like an X-ray. Knowing whether a door is made of wood or steel is as crucial as knowing whether your target is using PHP or ASP.NET. Wappalyzer will whisper "jQuery 3.0 and Nginx are used here" while you passively browse your browser. However, WhatWeb, your terminal power, can perform much more aggressive scans (-a 3), detecting even version numbers from header information, cookie names, and even the HTML code structure (DOM) that the server tries to hide.

Sources: https://cheatsheetseries.owasp.org/cheatsheets/Fingerprint_Web_Server_Cheat_Sheet.html https://github.com/urbanadventurer/WhatWeb https://www.wappalyzer.com/

Day 44: Template-Based Scanning (Nuclei): Today, you'll be introduced to Nuclei, known as the "Swiss Army Knife" of the modern Bug Bounty world, powered by community strength. Your goal is to complete checks that would take days manually (e.g., searching for Log4j or a specific configuration error across thousands of subdomains) in minutes using pre-written YAML templates.

Sources: https://github.com/projectdiscovery/nuclei

Day 45: Data Management: Today our goal is to create a real data management system. For this, you can create a dashboard on Notion or Obsidian. The biggest problem for a bug bounter is having trouble classifying the data they collect properly. Classify your data properly and try to determine what your own bug bounty methodology is.

Day 46 Build Your Own TODO App: Today, our goal is to learn the basic uses of a hacking language like Python, Rust, or Go. If you don't know a programming language, you can extend this process to 10 days. Try writing a TODO application without using an AI tool, and then look for any security vulnerabilities you may have created in that application.

Day 47: Cloud Recon: Today is the day to hunt for forgotten data and misconfigurations in Cloud Buckets, considered the "external hard drive" of the modern internet. The goal is to find sensitive customer data, backups, or source code in S3 buckets that developers have left public, thinking "no one can guess the URL anyway." While tools like S3Scanner or GrayhatWarfare provide automation in the AWS S3 world, Google Dorking (site:s3.amazonaws.com "password") is where you'll put your manual skills to work. But it's not just AWS; Azure Blob (*.blob.core.windows.net) and Google Cloud (storage.googleapis.com) structures also carry the same risks. You need to learn what these risks are and how to identify them. Understand in detail what developers have done wrong that allows you to access them.

Day 48 Bug Bounty Platforms: Now we're at the point where it's time to join a bug bounty community to hunt legally. You can work with systems like HackerOne, Bugcrowd, YesWeHack, or you can bounty on all of them. My advice here is to choose only one of them and proceed from there. The main reason for this is that these types of systems give you certain reputation points, and thanks to these points, you can be invited to private hunts. The reason we're only dedicating one day to this is so that you can improve your knowledge of what to look for when choosing a program, what to observe, and how to read the program's rules. Today, research the area you will hunt in, your target, and your hunting grounds, and learn the differences.

Days 49–50: Server-Side Template Injection (SSTI): Today, you're hacking the "printing press" that dynamically generates HTML pages for a web application: Server-Side Template Injection (SSTI). Your goal is to manipulate the application's template engine (e.g., Jinja2, Twig, FreeMarker) to make the server not just print the data you send, but execute it. Why {{7*7}}? Because if you see the number 49 on the screen, you've proven that the server doesn't know math, but compiles and executes the code you send. In the PortSwigger lab, you'll turn this simple math into a deadly weapon that completely takes over the server (RCE — Remote Code Execution). In the "Code Context" lab, you'll learn to break out not just into text boxes, but into unfinished lines of code written by the developer, and perform chain attacks with the correct syntax.

Sources: https://afridashamsub.medium.com/comprehensive-guide-to-server-side-template-injection-ssti-233777d12f3e https://medium.com/@nyasuru/exploit-jinja2-ssti-to-rce-633010f36894 https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-Side_Template_Injection

Days 51–52–53: Web Cache Poisoning: Today is the day to understand Web Cache Poisoning, one of the most "insidious" and difficult-to-detect attacks in the cyber world. The goal is to manipulate the caching system (Cache) that the website uses to improve performance, ensuring that a malicious response you've prepared (for example, a page containing an XSS payload) is served to other innocent visitors. The most critical concept here is the Cache Key logic. The cache usually only looks at the URL and Host header (Keyed); it ignores the remaining headers (User-Agent, Cookie, etc.) (Unkeyed). Your task is to trick the server in the background by adding headers, especially X-Forwarded-Host, to these "Ignored" (Unkeyed) fields. If your server receives the X-Forwarded-Host: evil.com header you send and reflects it in a <script src="…"> tag within the page, and the cache stores it, then anyone who visits that page from that point on will download a malicious JavaScript file from your server. Your primary goal here is not so much to understand how this attack is carried out, but rather to understand why it can be carried out.

Sources: https://portswigger.net/research/practical-web-cache-poisoning https://www.fastly.com/blog/understanding-web-cache-poisoning https://blog.assetnote.io/2020/09/18/web-cache-poisoning-google/

Day 54 HTTP Request Smuggling — 1: Today, you're entering the world of HTTP Request Smuggling, one of the most complex, mind-boggling, yet critical topics in web security. Your goal is to cause disagreements between Frontend (Load Balancer) and Backend servers regarding where a sent request ends. When one server determines the length of the request based on the Content-Length (CL) header and the other based on the Transfer-Encoding: chunked (TE) header (or vice versa), the synchronization between them breaks down. In the CL.TE lab you'll solve today, the Frontend server will believe the CL header and say "this is a single request," but the Backend server will look at the TE header and terminate the request early. The remaining "orphan" part, which the Backend thinks is "the beginning of the next request," is actually the poisoned request you've smuggled into the system. Try to understand the changes in HTTP 2.0 and HTTP 1.1, how this vulnerability occurred, and practice it in labs.

Sources: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn https://hackerone.com/reports/484403

Day 55 HTTP Request Smuggling — 2: Today, you continue to challenge your brain with the TE.CL (Transfer-Encoding . Content-Length) scenario, which is the complete opposite of yesterday's CL.TE logic and is often confusing. In this scenario, the Frontend server takes the Transfer-Encoding: chunked header into account and processes the request in chunks, while the Backend server only looks at the Content-Length header and cuts off the reading early. As a result of this mismatch, the data that the Backend considers "unreadable" (your smuggled request) hangs in the socket and gets stuck at the beginning of the next innocent user's request. While doing this manually in the PortSwigger lab, you will see how much delicate work is required to calculate the chunk sizes (in hexadecimal) and put the 0 (end chunk) character in the right place.

Sources: https://github.com/PortSwigger/turbo-intruder https://tryhackme.com/room/http-request-smuggling

Days 56–57–58 Insecure Deserialization: Today, you're about to learn about Insecure Deserialization, one of the coolest and most destructive vulnerabilities on the "OWASP Top 10" list. The basic principle is this: Applications use "packets" (serialization) to transport or store data. If the server processes the packet you send without checking its contents during deserialization, you can modify the data inside the packet to become an administrator or execute code on the server (RCE). The scenario you'll encounter in today's lab will likely be PHP-based. PHP serialization uses a unique, readable format like O:4:"User":2:… Your task is to capture this sequence, decipher its logic (for example, s:5:"admin" where s is a string and 5 is the character count), and manipulate the isAdmin value to send the packet back to the server.

Sources: https://portswigger.net/web-security/deserialization https://vickieli.dev/hacking/php-object-injection/ https://bishopfox.com/blog/java-deserialization-exploits https://davidhamann.de/2020/04/05/exploiting-python-pickle/

Days 59–60–61: OAuth 2.0 Vulnerabilities: Today, you'll be hacking the OAuth 2.0 protocol, considered the "passport control" of modern web applications and the one behind "Sign in with Google" buttons. Your goal is to break the delicate chain of trust between the user, application, and provider (Google, Facebook, etc.). In the theory part, you'll realize how critical the redirect_uri parameter is when drawing the Authorization Code Flow (the most secure flow) diagram. If you, as an attacker, can redirect this address to your own server (evil.com), you can steal the victim's login key (Authorization Code). In the afternoon lab, you'll attempt to manipulate the insecure Implicit Flow structure, where the token is transmitted directly from the browser address bar (#access_token=…) instead of from behind the server, and gain access to someone else's account (Account Takeover) by simply changing the username.

Sources: https://book.hacktricks.xyz/pentesting-web/oauth-2-0#redirect_uri-bypass-techniques https://auth0.com/docs/secure/attack-protection/state-parameters https://www.nds.ruhr-uni-bochum.de/media/ei/veroeffentlichungen/2014/10/20/oauth-sec.pdf

Days 62–63: JWT (JSON Web Token) Attacks: Today is the day to manipulate the JWT (JSON Web Token) structure, the most common authentication method for modern web applications (especially APIs). The goal is to hack this "digital wristband" (token) given to you by the server by changing the claim on it and making the server believe that this fake wristband is valid (Signature Bypass).

Sources: https://portswigger.net/web-security/jwt https://book.hacktricks.xyz/pentesting-web/proxy-token-and-service-tokens/jwt-black-box-testing#none-algorithm https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

Days 64–65–66: Race Conditions: Today, you're about to delve into one of the most adrenaline-pumping topics in cybersecurity, where wins and losses are measured in "thousandths of a second": Race Conditions. Your goal is to capture that microscopic time gap (Time-of-Check to Time-of-Use — TOCTOU) in the server's logical operation to use a single-use coupon 50 times or transfer money you don't have in your balance. Normally, Burp Intruder sends requests sequentially, giving the server enough time to update its database. However, Turbo Intruder, developed by James Kettle, uses a special HTTP stack to queue requests at the server's door and sends them all in with a single trigger in the same millisecond. By the time the server processes the first request and writes "Coupon used" to the database, the other 20 requests will have already received the "Coupon valid" confirmation and been processed.

Sources: https://portswigger.net/web-security/race-conditions https://medium.com/@vickieli/race-conditions-explained-75ee6f53ef0b https://blog.projectdiscovery.io/race-condition-in-web-applications/ https://github.com/PortSwigger/turbo-intruder

Days 67–68: Prototype Pollution:

Today is the day to hack one of JavaScript's deepest and most complex structures, the "DNA" of objects: Prototype Pollution. This vulnerability poisons not just a single object, but the underlying "ancestor" object (Object Prototype) of the application, causing all objects created from that point onwards to carry this poison (malicious code). The logic is this: In JavaScript, every object inherits its properties from the prototype above it. If you access the top-level Object.prototype using the __proto__ property and add a property like `isAdmin: true` or `transport_url: 'evil.com'`, all objects in the application will start behaving as if they have that property.

Sources: https://portswigger.net/web-security/prototype-pollution https://snyk.io/blog/prototype-pollution/ https://github.com/kleiton0x00/ppscan

Day 69 API Security — Introduction: Today, you're entering the invisible engine room of the modern internet (mobile applications, SPAs, IoT devices), namely the world of APIs (Application Programming Interfaces). On classic websites, you click buttons; with APIs, you access data directly, in its raw form (JSON/XML). Therefore, APIs are often the points where security measures are weakest and the most critical data is exposed.

Sources: https://salt.security/api-security-guide https://cloud.google.com/blog/products/identity-security/api-security-best-practices https://escape.tech/blog/logic-flaws-in-apis/

Day 70–71 API — BOLA / IDOR: Today is the day to confront BOLA (Broken Object Level Authorization), the undisputed leader in API security and number one on the "OWASP API Security Top 10" list. This vulnerability, formerly known as IDOR (Insecure Direct Object References), doesn't require complex hacking techniques; it only requires attention and error hunting. The logic is simple: The server forgets to check, "Is the person requesting this data (User A) the owner of this data (User B)?". If you intercept the /api/v1/receipts/1001 request and change the final ID to 1002, and the server shows you someone else's invoice, congratulations; you've found a critical BOLA vulnerability. Your Docker experience will make the crAPI (Completely Ridiculous API) setup this afternoon much easier. But remember, in the real world, IDs don't always go in the order 1, 2, 3, etc. You might encounter complex UUIDs (550e8400-e29b…). The real skill lies in leaking these complex IDs from other parts of the application (Leaked IDs) and using them in an attack.

Sources: https://www.wallarm.com/what-is/broken-object-level-authorization-bola-idor https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ https://github.com/OWASP/crAPI

Days 72–73: API — Mass Assignment: Today is the day to explore how the "convenience" provided by modern software frameworks to developers turns into a critical security vulnerability: Mass Assignment. When developers write code, they often automatically bind the incoming JSON data to the database object. So when you register, you only send the username and password; however, the model in the background also has fields such as role, is_admin, or balance. If the developer hasn't blacklisted these fields, it accepts the extra data you send and writes it to the database.

Sources: https://portswigger.net/web-security/api-testing#exploiting-mass-assignment-vulnerabilities https://snyk.io/blog/mass-assignment-vulnerability/ https://www.homestarrunner.com/mass-assignment-github/

Day 74: API — Rate Limiting Today is the day to play cat and mouse with the "Traffic Police" of APIs. Rate Limiting is a barrier that developers put in place to protect the server from DDoS attacks or to prevent hackers like you from brute-force password attempts. Your goal is to overcome or circumvent this barrier. When an API returns a 429 Too Many Requests error, it doesn't mean the game is over; it just means the rules have changed. Most basic Rate Limiting mechanisms identify the client by IP Address. However, servers running behind cloud systems and load balancers rely on HTTP headers to see the actual IP. This is where the vulnerability begins: If the server reads the IP address not directly from the TCP connection, but from headers like X-Forwarded-For or X-Client-IP that you can manipulate; By writing a random IP address in the header of each request (IP Spoofing), you can trick the server into thinking you're a different person. Burp Intruder automatically changes these headers, so even if you send thousands of requests per second, the server can still mistake each one for a new user.

Sources: https://portswigger.net/web-security/authentication/password-brute-force#bypassing-rate-limiting-using-http-headers https://thehackerblog.com/cracking-instagram-account-passwords-via-a-rate-limit-bypass/

Day 75–76: GraphQL Exploration Today, you're introduced to the "buffet" of the API world: GraphQL. While REST APIs have hundreds of different endpoints, GraphQL typically has only one entry point (/graphql), and you decide what you'll eat (what data you'll pull) once you're inside. Today's most critical topic is the Introspection feature. This is a convenience for developers, but a treasure trove for you. When you ask the server, "Tell me what you know" (Introspection Query), the server delivers the entire database schema, all existing queries, and data modification commands (mutations) in a single JSON file. It's like getting hold of the target system's user manual. However, the game isn't over if Introspection is off. That's where the InQL plugin (Scanner) comes in; it visualizes the open schema and helps you make guesses (Brute Force) if it's off. Examining mutation (data insertion/modification) areas in particular is often where the most critical vulnerabilities (IDOR, Broken Access Control) are located.

Sources: https://portswigger.net/web-security/graphql https://book.hacktricks.xyz/pentesting-web/graphql https://blog.assetnote.io/2021/08/29/exploiting-graphql/

Day 77: GraphQL Attacks Today, polite queries are giving way to aggressive manipulations. Yesterday you extracted the schema (map); today you will use the hidden fields in that map and test the server's processing capacity by overwhelming it (DoS). The vulnerability you will see in the PortSwigger lab is the "Field Level Security" mistake that developers most frequently make. The interface may only require the title and content; but if a password or private_key is defined in the schema and you add it to your query, the server will provide it without objection. Your DoS exercise this afternoon turns GraphQL's flexible structure into a weapon. If there is a circular relationship in relational databases that goes "Author's Posts -> Author of the Post -> Author's Posts…", you can lock up the server by sending a single query that repeats thousands of times. This is called a "Recursive Query Attack".

Sources: https://medium.com/@mohamed.daher/finding-hidden-graphql-endpoints-and-queries-7f61b0a5015b https://www.apollographql.com/blog/community/security/securing-your-graphql-api-from-malicious-queries/ https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/GraphQL#dos-with-aliases

Day 78: Mobile Security — Setup (Android): Today you're closing your web browser and stepping inside the spy in your pocket: the world of Mobile Application Security. While you examine HTML/JS on the web, here you'll be operating on APK (Android Package Kit) files. Just as the "F12" key is crucial in the web world, ADB (Android Debug Bridge) is crucial in the Android world. The emulator is your laboratory, and ADB is your scalpel. With the adb shell command, you descend into the phone's Linux kernel and explore the file system. But remember; a standard Android Studio emulator doesn't grant "Root" privileges. To delve deep like a real hacker (for example, reading hidden databases in the /data/data/ folder), you'll need to "Root" the emulator or use tools like RootAVD. An APK file is essentially just a ZIP file with a modified extension. However, the AndroidManifest.xml (the application's ID and permissions) inside is unreadable (Binary XML). Apktool decompiles this file, making it readable and showing you which permissions the application requests and which hidden activities it performs.

Sources: https://mas.owasp.org/MASTG/ https://book.hacktricks.xyz/mobile-pentesting/android-app-pentesting https://github.com/newbit1/rootAVD https://www.android-recovery-adapter.com/resource/android-file-system-structure.html https://github.com/payatu/diva-android

Day 79–80: Android Static Analysis Today is the day for Static Analysis, where you'll peel back the skin of your APK file (i.e., the application) and examine the underlying musculoskeletal system. You'll search for backdoors and bugs left by the developer by reading the code without running the application (static). Jadx-gui is a magical tool that decompiles compiled and unreadable "Dalvik Bytecode" (DEX) files back into Java code that you can understand. While reading the code, you'll find yourself in the middle of a complex puzzle rather than a novel. The most critical point of the day is the AndroidManifest.xml file. This file is the application's identity. The most dangerous word to look for here is: android:exported="true". If an Activity or Content Provider is marked "exported" and there is no permission protection, this means that a malicious application you wrote could trigger that activity from the outside (Authentication Bypass). When navigating through code (Strings.xml and Java classes), you'll have to rely on developers' "forgetfulness." Often, AWS keys, Google Maps API keys, or test server passwords are forgotten because they're embedded (hardcoded) within the code.

Sources: https://github.com/skylot/jadx https://source.android.com/docs/core/runtime/dalvik-executable https://github.com/B3nac/Android-Pentest-Checklist https://www.freecodecamp.org/news/how-to-extract-api-keys-from-android-apps/ https://medium.com/@ayush_sharma/exploiting-exported-activities-in-android-apps-786016c09b9f

Day 81–82: Android Dynamic Analysis & SSL Pinning Today is the day to revive that "dead" APK file you laid out yesterday and listen to the data flowing through its veins (network traffic), i.e., the whispers between the application and the server: Dynamic Analysis. But this time, there's a huge wall in the way called "SSL Pinning." Installing the Burp certificate in the web browser is enough to see the traffic; however, modern Android applications (especially banking and finance) are paranoid. They don't just say "HTTPS," they say "The fingerprint of the server's certificate must be exactly THIS" (Pinning). When Burp Suite intervenes, the application recognizes your fake certificate and cuts off communication, saying "Connection Not Secure." This is where Frida comes in, your "God Mode." It infiltrates the running application's memory (RAM), finds the checkCertificate() function, and forcibly changes its result to return true (Secure). Objection is Frida's ready-made package that can be used without writing any code. With a single command (android sslpinning disable), you can disable the application's complex security checks.

Sources: https://portswigger.net/burp/documentation/desktop/mobile/config-android-device https://learnfrida.info/ https://medium.com/@ayush_sharma/hacking-android-apps-using-objection-6da904604550 https://book.hacktricks.xyz/mobile-pentesting/android-app-pentesting/ssl-pinning-bypass

Note: We won't be discussing iOS security for now. In most cases, this requires having a jailbreakable iOS device, which would be discouraging for those who don't have one, so I'm not going into that. I will cover the details and a separate plan regarding what can be done with MobSF in a separate article.

Day 83–84 The Art of Report Writing: Today we're leaving aside coding and focusing on "storytelling"; because even if you find the world's most critical vulnerability, if you can't sell it to the other party, that report is worthless. Instead of reinventing the wheel in the first half of the day, start by going to HackerOne's "Hacktivity" section and reading award-winning, accepted reports; analyze how these guys titled their reports, numbered their steps (PoC), and translated that aggressive hacker language into corporate politeness. In the afternoon, you'll focus on the most lucrative part of the job: "Impact Analysis"; there's a difference of thousands of dollars between describing a vulnerability as "I found an XSS vulnerability, alert(1) was triggered" and describing it as "Thanks to this vulnerability, I can steal the admin session and take over the entire system," so you need to learn how to turn a technical finding into business impact risks such as "Company Reputation" and "KVKK/GDPR Violation." At the end of the day, to avoid wasting time writing reports from scratch every time, create a professional Markdown template for yourself. Save this English template (template.md) containing the headings "Summary," "Reproduction Steps," "Impact," and "Recommended Solution," and by simply filling in the blanks whenever you find a vulnerability, you'll not only look professional but also make the triagers' (report readers') job easier and speed up your reward process. Remember, a good report is one that can make the company say, "Thank you for hacking me."

Sources: https://www.hackerone.com/blog/how-to-write-quality-bug-reports https://www.bugcrowd.com/blog/how-to-write-a-great-proof-of-concept/ https://github.com/djadmin/awesome-bug-bounty-report-templates

Day 85 "Secure Code Review" Philosophy and Introduction Your main task today will be to grasp the "Source-to-Sink" analysis logic, a code reviewer's greatest weapon; that is, you will learn to track the journey (propagation) of "dirty" data (Source) from the user within the code, like a detective, to see if it reaches a dangerous function (Sink) without undergoing any cleaning process. To reinforce this philosophy, you should strategically review the introduction and injection sections of the OWASP Code Review Guide and create a checklist for yourself.

Sources: https://owasp.org/www-project-code-review-guide/ https://checkmarx.com/blog/what-is-taint-analysis/ https://semgrep.dev/ https://github.com/wireghoul/graudit

Day 86 Static Analysis Tools (SAST): Today, as part of Static Analysis Tools (SAST), you'll focus on Semgrep. As a first step, you'll install Semgrep in your environment and understand its basic working principles. Since Semgrep is one of the most preferred SAST tools, especially for bug bounty and quick source code reviews, it's important to understand its CLI usage, how it works on the project directory, and its default scanning behavior during installation. After installation, you'll examine the Semgrep Registry in detail and review the ready-made security rules. Here, you'll focus on reading and understanding the rules written for different languages ​​(JavaScript, Python, Java, etc.) and different vulnerability categories (hardcoded secrets, injection, auth issues). Then, for practice, you'll try writing your own Semgrep rule to detect a simple hardcoded password. The goal at this stage is to understand how the pattern, metavariable, and message fields work. Finally, you'll move on to the practical part, download the OWASP Juice Shop source code from GitHub, and scan the project with Semgrep. You analyze which vulnerabilities are detected in the scan using pre-prepared rules, and try to identify false positives. If you have time, you test whether the hardcoded password rule you wrote produces results on Juice Shop and try to improve your rule accordingly.

Sources: https://semgrep.dev/docs/getting-started/ https://semgrep.dev/docs/writing-rules/examples/#finding-hardcoded-secrets https://github.com/juice-shop/juice-shop https://blog.trailofbits.com/2020/07/09/semgrep-a-static-analyzer-for-the-rest-of-us/ https://blog.projectdiscovery.io/semgrep-for-cloud-secrets/

Day 87 Static Analysis Tools (SAST) — CodeQL Today, as part of Static Analysis Tools (SAST), you'll focus on CodeQL and other popular tools. First, you'll explore the fundamental logic of CodeQL technology, developed by GitHub. The goal here is to understand how source code is transformed into a database, unlike classic regex or pattern-based scanning, and how vulnerabilities are detected by running queries on this database. You'll focus on understanding why CodeQL is powerful in large and complex projects and how it differs from Semgrep. Then, you'll examine alternative tools in the SAST world. You'll review the security and code quality checks that can be performed in the free version of SonarQube, which is widely used, especially in the enterprise sector. Similarly, you'll evaluate the free features that Snyk offers for open-source projects, the differences between SAST and dependency scanning, and how useful it can be from a bug bounty perspective. At this stage, you'll look for answers to the question of "which tool is more logical in which scenario?". Finally, you'll focus on secret scanning. To identify sensitive information like forgotten API keys, tokens, and private keys in code, you choose a tool like TruffleHog or Gitleaks and run it on an open-source project. You analyze whether the discovered secrets are real or false positives, trying to understand how such leaks can turn into critical vulnerabilities in real life. This step aims to develop reflexes, especially for bug bounty and GitHub-based hunting.

Sources: https://codeql.github.com/docs/writing-codeql-queries/about-codeql-queries/ https://securitylab.github.com/tools/codeql/ https://medium.com/@ayush_sharma/exploiting-leaked-api-keys-for-fun-and-profit-7b3b3e8e1f5

Day 88 Language-Based Analysis — PHP: Today, as part of our language-based analysis, you'll focus on PHP; a classic language that you still frequently encounter in the field. First, you'll study the most frequently abused and dangerous functions in PHP that can directly lead to remote code execution or serious privilege breaches. Specifically, you'll examine and memorize, through code examples, the scenarios in which functions like `system`, `exec`, `shell_exec`, `passthru`, `eval`, and `unserialize` become risky, and how they can be exploited when combined with user input. Next, you'll focus on PHP-specific and often overlooked Type Juggling vulnerabilities. You'll analyze why the difference between `==` and `===` is critical from a security perspective, and how it can be bypassed in authentication, token validation, or authorization controls using loose comparison. Specifically, you'll try to understand how instances of `0`, `0`, `false`, `null`, and `magic hash` (0e…) can lead to dangerous consequences in code. Finally, you'll reinforce your understanding through practice. You download the source code of an old WordPress plugin and find a known vulnerability reported in a CVE database related to that plugin. Then, by matching the CVE description with the code, you analyze exactly where, why, and how the vulnerability occurred. At this stage, you aim to both improve your PHP code reading speed and understand the logic behind real-world reported vulnerabilities.

Sources: https://owasp.org/www-project-vulnerable-web-applications-directory/ https://medium.com/@tristan_91040/php-type-juggling-vulnerabilities-3e9a4e40e67d https://vickieli.dev/hacking/php-object-injection/

Day 89: Language-Based Analysis — JavaScript & Node.js (Modern Web): Today, as part of our language-based analysis, you'll focus on JavaScript and Node.js, the backbone of modern web applications. First, you'll examine the dangerous sinks that are most frequently encountered in the Node.js ecosystem and can directly lead to remote code execution risks. You'll analyze the code flow to understand when functions like eval(), Function(), child_process.exec(), execSync(), spawn(), and spawnSync() become risky and how they can be exploited when combined with user input. At this stage, you'll particularly aim to clarify the input → processing → sink chain in your mind. Then, you'll focus on Prototype Pollution, one of the most insidious vulnerabilities in the JavaScript world. You'll investigate how this vulnerability typically manifests in source code through functions like recursive merge, Object.assign, lodash.merge, and deepExtend. Specifically, you're trying to understand how global objects can be poisoned in scenarios where the __proto__, constructor.prototype, and prototype switches aren't checked.

Sources: https://blog.appsecco.com/node-js-command-injection-101-7299042b4b4b https://pwnisher.gitlab.io/nodejs/sandbox/2019/02/21/nodejs-vm-sandbox-escape.html https://securitylab.github.com/research/prototype-pollution-tutorial-github-security-lab/

Day 90 Language-Based Analysis — Java and Deserialization: Today, as part of our language-based analysis, you'll focus on Java and deserialization. First, you'll explore what the Serializable interface in Java does, how an object is converted to a byte stream, and how the readObject() method works when converting it back to an object. You'll focus on understanding why this mechanism is the root cause of Insecure Deserialization vulnerabilities, how malicious payloads can be triggered, and the fundamentals of gadget chain logic. The goal here is to internalize Java's working logic rather than rote memorization. Afterwards, you'll move on to common errors at the framework level and examine security vulnerabilities frequently seen in applications using Spring Boot. You'll investigate how open Actuator endpoints can lead to information leakage or system control, and which code patterns lead to SpEL (Spring Expression Language) Injection vulnerabilities. The goal at this stage is to help you understand how configuration errors and code-level vulnerabilities combine to create a critical impact.

Sources: https://www.synopsys.com/blogs/software-security/understanding-java-deserialization-vulnerabilities.html https://blog.sonarsource.com/spring-spel-injection/ https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet

Day 91: Zero Day Philosophy and Vulnerability Lifecycle: Today, you'll focus on understanding the Zero Day philosophy and the end-to-end lifecycle of a vulnerability. First, you'll examine what the "Zero Day" concept means and why it's so valuable and dangerous. You'll go step-by-step through the process from the initial discovery of a vulnerability to its exploitation, responsibly reporting it to the manufacturer, public disclosure, and finally, patching. At this stage, you'll focus less on technical details and more on understanding the balance and ethical dimension between the researcher, vendor, and user. Then, to broaden your perspective, you'll visit the Google Project Zero blog. The articles here are written by the world's top security researchers and can be heavy and complex; the goal isn't to understand every line. You'll read a technical analysis and try to familiarize yourself with the terminology, thought process, and approach used. Even asking yourself, "What am I not understanding here?" is a gain for today. Finally, you'll move on to the industry side and examine the Zero Day Initiative (ZDI) program. You will learn how ZDI acknowledges vulnerabilities, what types of exploits are purchased, how the reporting process works, and the criteria used to determine its reward policies. The goal of this section is to understand that the zero-day world is not only a technical but also an economic and operational ecosystem, and to see how professional researchers position themselves within this field.

Sources: https://www.mandiant.com/resources/blog/zero-day-vulnerability-explained https://googleprojectzero.blogspot.com/ https://googleprojectzero.blogspot.com/2022/04/the-realities-of-in-the-wild-zero-day.html https://www.zerodayinitiative.com/about/ https://www.technologyreview.com/2021/09/29/1036335/inside-the-zero-day-market/

Day 92: Patch Diffing 1: Today you'll delve into the fundamentals of patch diffing, focusing particularly on understanding the logic behind 1-day exploits. The first step involves examining how technical details of vulnerabilities are indirectly revealed after a manufacturer releases a security patch. You'll explore why systems that haven't yet updated are most vulnerable during this period, how attackers reconstruct vulnerabilities by analyzing the patch, and the difference between zero-day and 1-day exploits. The goal here is to understand why the perception that "if a patch is released, the job is done" is incorrect. Next, you'll move on to tools and focus on how to perform patch diffing on closed-source software. Specifically, you'll investigate the functions of BinDiff and its open-source alternative, Diaphora, and how to compare differences between two different versions at the binary level. You'll also try to understand how to identify where vulnerabilities have been patched, even without access to the source code, through function changes, newly added controls, or removed flows. At this stage, it's crucial to understand why reverse engineering and patch diffing are intertwined. In the final part of the day, you practice with source code. You find a fix commit for a known CVE on GitHub and carefully examine the changed lines. You analyze exactly what the developer changed, why, and how an added condition, input validation, or removed function call closed the vulnerability. The goal of this analysis is to reach a level where you can reflexively answer the question, "What does a patch tell me?"

Sources: https://www.sentinelone.com/blog/from-patch-to-zero-day-how-attackers-reverse-engineer-security-updates/ https://blog.reversinglabs.com/blog/patch-diffing-for-vulnerability-research https://github.com/joxeankoret/diaphora

Day 93: Patch Diffing 2: Today you'll put your patch diffing knowledge into practice. As a first step, you choose a well-known and widely used CMS; WordPress, Joomla, or a similar system will do. You download the older, vulnerable version of this CMS and the patched version with the security vulnerabilities fixed, and prepare them in separate directories. The goal here is to test the patch diffing logic you learned in theory on a real and large codebase. Then you start comparing the two versions using a diff tool. You scan for file-based changes with WinMerge, Meld, or VS Code's compare feature, focusing especially on files that appear to be security-related. Changed functions, added conditions, new input validation controls, removed risky calls, or tightened authorization controls become your main targets. During the analysis, you look for answers not just to "what has changed," but to "why it has changed." You're trying to figure out which attack scenario the developer was trying to prevent with this change, whether the root cause of the vulnerability is lack of control, incorrect assumptions, or an unsafe flow. Ultimately, the goal is to develop the reflex to automatically ask "could an exploit be extracted from this?" when looking at a patch, and to turn patch diffing into a true vulnerability hunting technique.

Sources: https://blog.sonarsource.com/wordpress-core-vulnerability-research/ https://blog.sucuri.net/2015/12/joomla-remote-code-execution-the-details.html

Day 94: Introduction to Fuzzing: Today you'll be introduced to fuzzing and focus on understanding the fundamental philosophy behind this technique. First, you'll explore what fuzzing is and how it bombards an application with unexpected or nonsensical inputs, leading to errors, crashes, or unexpected behavior. At this stage, you'll try to understand the differences between dumb fuzzing (sending completely random data) and smart fuzzing, especially coverage-guided fuzzing. The logic behind measuring which code paths are running and generating inputs to trigger new paths is the main takeaway today. Then you'll move on to the tools side. You'll explore what AFL++ (American Fuzzy Lop) and LibFuzzer are, which languages ​​and projects they are best suited for, and the key differences between them. You'll focus on understanding whether they operate at the binary or source level, their instrumentation logic, and what types of vulnerabilities (buffer overflow, crashes, memory corruption) they are generally strong at uncovering. The goal here is to be able to instinctively answer the question, "Which fuzzer for which scenario?"

Sources: https://fuzzing.info/ https://blog.reversinglabs.com/blog/introduction-to-fuzzing https://www.fuzzingbook.org/ https://securitylab.github.com/research/fuzzing-software-vulnerabilities/

Day 95: Fuzzing with a Simple Goal: Today you begin applying your fuzzing knowledge to a concrete goal. As a first step, you find a small, as isolated as possible file parser project written in C or C++ on GitHub. Simple projects that parse JSON, XML, CSV, or similar formats are ideal for this. The goal here is not to get lost in a huge codebase; it's to clearly see how the input enters the program, which functions it passes through, and where it is processed. Then you dedicate most of the day to practicing fuzzing with AFL++. You try to make your chosen parser compatible with AFL++, and if necessary, you examine how instrumentation is done during the compilation phase. In this process, you try writing a harness; that is, you create a small bridge code that takes the input produced by the fuzzer and feeds it properly to the parser function. Realizing how the harness's role directly affects fuzzing success is the key point of today.

Sources: https://aflplus.plus/docs/tutorials/libfuzzer_harness/ https://blog.reversinglabs.com/blog/fuzzing-harnesses-101

Day 96: CVE Analysis and Replication: Today, your focus is on CVE analysis and replication; that is, you'll be trying to truly understand and exploit a critical vulnerability discovered by others. First, you choose a critical web vulnerability that has been published within the last year and whose technical details are publicly available. Log4Shell, Spring4Shell, or similar vulnerabilities that have had a significant impact are good candidates here. When making your selection, focus on carefully reading the CVE description, the affected components, and why the vulnerability is considered "critical." Then you move on to the most instructive part and set up the vulnerable environment locally. Usually using Docker, you create a controlled lab environment by deploying the vulnerable version. By running the PoC (Proof of Concept) code shared online, you see with your own eyes that the vulnerability is actually triggered. At this stage, the goal is not just to say "it worked"; it's to observe the request-response flow, logs, and system behavior.

Sources: https://github.com/vulhub/vulhub https://www.lunasec.io/docs/blog/log4j-zero-day/ https://www.assetnote.io/resources/research/citrix-bleed-leveraging-uninitialized-memory-for-session-hijacking

Day 97 Reverse Engineering Introduction: Today you are officially entering the world of reverse engineering. First, you will focus on understanding the fundamentals of assembly language. You will explore how programs work on x86 and x64 architectures, what the CPU uses registers for, the roles of stack and heap structures in memory, and how function calls occur in the background. The goal at this stage is not to write assembly; it's to avoid panicking when you encounter disassembly and to be able to understand the basic flow. Then you move on to the tools part. You download and install Ghidra (a free and very powerful reverse engineering tool developed by the NSA) or the free version of IDA Pro. You familiarize yourself with the interface, import the binary, and discover how the analysis process works, how functions are automatically named, and what the decompiler output means. At this point, the goal is not to expect miracles from the tool, but to learn what it offers you.

Sources: https://pwn.college/assembly-crash-course/ http://phrack.org/issues/49/14.html https://ghidra-re.org/ https://beginners.re/

Day 98 Reverse Engineering — Fundamentals of Flow Analysis and Anti-Analysis: Today you'll delve deeper into reverse engineering and focus not just on "where is the password," but on how the program makes decisions. First, you'll study control flow at the assembly level. You'll examine how instructions like cmp, test, je/jne, jg/jl, call, and ret manage the program's decision-making process. Specifically, you'll try to understand how if-else, loop, and switch structures appear in assembly, aiming to develop a "there's a branch here" reflex when reading disassemblies.

Sources: https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Mips/control.html https://www.sentinelone.com/blog/reverse-engineering-101-recognizing-c-constructs-in-assembly/ https://github.com/ufrisk/anti-re https://unprotect.it/

Day 99: Reverse Engineering, Debugging, and Runtime Manipulation: Today, you're shifting your focus from static analysis to runtime behavior. First, you'll understand why a debugger is essential for reverse engineering. Understanding how the program behaves in memory, how registers change instantaneously, and why the actual control flow can sometimes differ from what you see in static analysis is the foundation of today's session. Then, you'll move on to using a debugger. On Windows, you'll use x64dbg, and on Linux, gdb, to run a CrackMe or small binary. You'll learn how to set breakpoints, proceed step-in/step-over, and examine register values ​​at critical comparison points. Specifically, you'll pause at points where cmp or string comparisons are made and observe live which value the program considers "correct." The goal here isn't to guess the password, but to see what the program expects from you at runtime. Finally, you'll get to the most enjoyable part of the day: runtime manipulation. You try to force conditional branch switching or make a failed check appear as a successful one by modifying register values ​​through the debugger. If necessary, you alter the program's flow by NOPing instructions or applying small patches. The most important thing you realize at this stage is that many protections are not protections at all if they can be manipulated during runtime. Ultimately, your goal isn't to write exploits; it's to gain a sense of "I'm in control" and clearly see how a program's fate can be changed at runtime.

Sources: https://reverse.put.as/wp-content/uploads/2016/04/x64dbg-tutorial.pdf https://0x00sec.org/t/reverse-engineering-tutorial-modifying-program-behavior-at-runtime/ https://crackmes.one/ https://tuts4you.com/download.php?list.17

Day 100 Repetitions and Ready Check Yes, we finally made it this far. I wholeheartedly congratulate you. You may realize that what we've learned up to this point hasn't just turned you into a bug bounter. Up to this point, you've formed new habits in your life, added a different structure to your life, and started a new phase in your career. Some of you have won awards with what you've learned up to this point, and some of you have found new jobs by following this. If you share your changes with us, you will make us all very happy. What you need to do today is to erase the thought from your mind that what you've learned is enough; you should never say, "I've learned everything now." You must constantly continue to learn, create new things, and do better.

That's all from me for now. Don't forget to subscribe to the newspaper and follow me on Medium and clap so you don't miss the next article. Good hacks.