Securing Your Website: Cloudflare Tunnels, WAF, and Bypassing ISP Restrictions

 

 

            *Poo-Tee-Weet?*

 

Following some really great advice from someone who was kind enough to give it, I decided to devote some time to Web Application Firewalls (WAF), IP masking, and network security, particularly using Cloudflare’s free tier.


Over a year ago, as part of my course's challenge at ATEC, I launched my own website: www.kernelcoredive.org (don’t rush to open this link—it's still under construction). It was a small space where I documented low-level programming concepts, mostly focusing on Assembly and computer architecture.

As time went on, I got caught up in my internship and stopped updating the site, shifting my focus to both LinkedIn and this blog.
But as this challenge came up, I went ahead and renewed my domain name on Namecheap.

This post (and the next one) will document my process, some issues I found and the subsequent solutions. If you’ve ever wanted to host your own website, this should help you get started. It’s surprisingly easy, costs about €15/year, and might introduce you to essential networking and security concepts.

---

📌 Step 1: Registering a Domain

First things first—you will need a domain name. This was done through a domain registrar. You can pick one from providers like GoDaddy, Namecheap, or the Cloudflare Registrar.

Once you choose a name and pay a small yearly fee, the domain is yours (and will be as long as you pay up). Now, we need a web server to actually host the website.

---

📌 Step 2: Setting Up an Apache Server

I set up an Apache web server on my machine to host the website. Since I don’t want to clutter this post with step-by-step Apache setup instructions, I'll just point you to an excellent guide: Server World.

Follow that documentation, and you’ll have Apache running locally in no time.
And do take a look at the site. I found it really helpful a year ago during my Linux classes.

---

📌 Step 3: Connecting My Domain to Cloudflare

Next, I signed up for a free Cloudflare account. This gives me access to DDoS protection, caching, and security tools.

Adding my domain was pretty simple—you just have to follow Cloudflare’s setup guide, and it will automatically scan your DNS records.

At this stage, I also updated my domain registrar’s DNS settings to use Cloudflare’s nameservers (again, follow the instructions set up by Cloudflare). This ensures all traffic is routed through Cloudflare before reaching my server.

---

🫢 Step 4: Issue: My ISP Blocks All Inbound Traffic

This is where I got to metaphorically bang my head against a wall and was failing at reaching my server.

I needed to link my public IP address to my domain—something I had done in the past without issues. But this time, no matter how hard I tried, I couldn’t access my public IP.

After testing with nmap and other tools, I confirmed that my ISP was blocking all inbound traffic. My router was not allowing requests to reach my server, no matter what ports I used.

 I also couldn’t simply port-forward my way out of this. After carefully checking my ISP router settings, I found that port forwarding wasn’t available at all.

A possible solution? Creating a Cloudflare Tunnel.

---

📌 Step 4: Setting Up a Cloudflare Tunnel

A Cloudflare Tunnel allows outbound connections from my server to Cloudflare, bypassing ISP restrictions entirely.

I installed it with:

curl -fsSL https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
chmod +x cloudflared
sudo mv cloudflared /usr/local/bin/
cloudflared tunnel login

However, I ran into a DNS conflict issue. While cloudflare had created a couple of A records for my server, I needed in fact a CNAME record instead. While A records point towards an IP, a CNAME record would allow for cloudflare to route traffic through the tunnel. So, I deleted the A records and created the necessary CNAME record.

This is all done under the DNS tab on cloudflare, btw.

---

📌 Step 5: Enabling HTTPS with Free SSL

With my tunnel working, my website was now accessible over HTTP. But I wanted encryption (HTTPS), so I added a free SSL certificate from Let’s Encrypt. I had done this a year ago, and it was as simple as it was before.

Again, I won’t bore you with the step-by-step setup—Let’s Encrypt is easy to install, free, and a game-changer for web security.

Then, I went to Cloudflare > SSL/TLS > Edge Certificates and enabled:
✅ Always Use HTTPS
✅ Full (Strict) SSL mode

 

---

📌 Step 6: Configuring Apache & Cloudflare

Cloudflare was now handling HTTPS redirection, so I had to disable Apache’s HTTPS redirect to prevent a redirect loop.

I edited /etc/apache2/sites-available/kernelcoredive.conf and commented out these lines:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

And restarted Apache.

Note that these lines might not be exactly like this in your setup. Look for any lines handling redirection in your configuration file and comment them out to avoid conflicts with Cloudflare’s HTTPS enforcement.

Now, my website was fully accessible, bypassing my ISP’s filtering.

---

🔒 Step 7: Adding Security – WAF & Bot Protection

With my site running through Cloudflare, I started testing Web Application Firewall (WAF) rules.

I created two rules:
1️⃣ Blocking a specific country (e.g., blocking all traffic from a particular region).
2️⃣ Configured a CAPTCHA challenge for any requests using the python-requests User-Agent.

I tested this out with:

curl -A "python-requests" https://kernelcoredive.org

You might be a bit more refined in your tastes, and have a test that actually addresses the Captcha part. Either way, and as you can see, the logs can show us these failed communication attempts.

I also enabled Cloudflare’s basic bot fight mode, which is included in the Free Tier: 

---

📌 Step 8: Next Steps

Right now, the Cloudflare Tunnel is running manually, meaning if my machine reboots, or if I close the service, the tunnel stops.

Tomorrow, I’ll create a systemd service to keep my tunnel online 24/7 on a Raspberry Pi.
I'm also going to subscribe to the pro tier, in order to practice with these and other concepts for the next month. This stuff is fun, and gives us a ton of flexibility on what and how many tiers of protection we want to implement.I also want to explore the Cloudflare API to see what kind of automation and security controls I can implement.


Fun! There's more tomorrow.

I Dislike Soft Skills Talk—So Hear Me Out on Soft Skills.

 

                    "Where be yer low level ramblings, ye heathen?"

技 (Waza) – technique, skill, or ability

Lacking the time to properly organize my thoughts on malware and cybersecurity (or whatever strikes my fancy), I might as well put forth something else that's been dangling in my mind, persistently nagging to come out and play: the importance of soft skills in IT in general (cybersecurity included).

Being a techie myself, loving all (yeah, right) most things technical, and truly an introvert at heart, I can say without hesitation that I don't really appreciate the constant call for newcomers in both IT and cyber to focus hard on the "soft" side of their skills.

We're led to believe that these skills are oh-so-fundamental, to the point where instead of drilling into the technical basics and particulars of each profession, we get video after video, article after article, and mouthpiece after mouthpiece telling us to prioritize social aspects. I've even seen cybersecurity folks claim that if they could redo their path to cyber mastery (or whatevs), they'd go back to college and focus much more on networking (the human kind) while paying less attention to the technical side.

I take a hard stance against this.

• Our fields are highly technical in nature.

• We DO have a significant technical knowledge gap.

• Most of this knowledge takes years to grasp, master, and apply.

• These so-called soft skills are actually quite easy to learn and deploy.

Sure! You won’t become a master speaker or the next Shakespeare in a couple of months, but you don’t need to be. You just have to be able to communicate clearly—enough that those less technically inclined can understand you.

 

Where am I coming from with all this certainty about these much-hyped social skills—the so-called golden key to a successful tech career? Well, before diving into IT, even before working in math, I worked as an actor, director, screenplay writer, and acting teacher for over 15 years. So I might know a thing or two about speaking before a live audience, presenting oneself, and communicating effectively.

 

I don’t claim to be the greatest expert—far from it. But I’ve walked the walk and talked the talk, and now that I’m in IT, I can tell you: the two are not even remotely comparable.

My long-term goals in 'IT' are harsh, to put it mildly. Heck, I must have been very drunk when my brain decided that low-level code, reverse engineering, and poking at weird malware was the greatest invention since sliced bread. But even just talking about mastering the basics needed to apply with any real confidence to cyber positions—the often-mentioned triad of programming, systems, and networking—takes serious effort. To actually understand these fields, to feel comfortable discussing them, to even recognize what’s being said in a conversation? Believe me, acting is easier. Speaking in public, presenting your thoughts in a structured manner—these things are much easier.

Now, granted, you might not want to do it. You might be shy, socially averse, or a bloody introvert like me. But that doesn’t make it difficult. It just makes it uncomfortable.

So, is this blog post just an excuse to ramble against soft skills?

No, not really. Just because I dislike something—or the exaggerated emphasis placed on it—doesn’t mean it’s wrong. Quite the contrary.

Soft skills are, in fact, useful. Knowing how to write, speak, present yourself—in one word, communicate—is undeniably important.

 

Just recently, I had to coordinate a troubleshooting session remotely, where instructions had to be relayed to a team that wasn’t entirely familiar with the technical process—and let’s just say that language barriers didn’t help. Communication isn’t just about simplifying tech for upper management. Sometimes, it’s about conveying precise, critical steps to people who need to act on them immediately, without confusion.

In the end, it worked. But it was quite the ride, and I found myself pivoting, adapting and adjusting, in order to get the troubleshooting steps through and carry on with what we were doing.

So, yeah. There’s that too. Communication takes many forms, and you’ll need it sooner rather than later. Don’t just ignore it. And, to re-iterate some good and bad news: it’s much easier to learn and quicker to grasp than you might think—but that doesn’t mean you’ll enjoy it.

 

Enjoy the ride, though. If at all possible.

 

A former acting colleague once said: life is just the backstage intermezzo you take between being on stage.

 

I don’t like that statement. But he might be right.

Insert Here Joke About The 'S' In IoT: ___________

                    ─ Anne Rice

            "One moment the world is as it is. The next, it is something entirely different. Something it has never been before."


忍耐 (Nintai) – Endurance & Patience

Life has its twists, turns, tugs, and takes, right?

Lately, I’ve been (kind of) ‘forced’ to plunge into radio waves—5GHz, 2.4GHz, channel allocations, and even how certain countries restrict radio some frequencies.

"Woah, so new job and you got more free time to explore stuff?"

No. Not really.

If anything, I have less free time than ever. Firewalls, network congestion, MAC virtualization, plus remembering things I learned over a year ago, while picking up new tricks along the way. But here’s the thing—I get to manage my time better (to a point). 

Not because the workload is lighter, far from it.

The difference? I’m not buried neck-deep under tickets every minute of my working day. Instead of having problems chase me around nonstop, I carve out specific windows to troubleshoot, test, and develop strategies─tackling issues before they spiral out of control. And when the odd danger moment does come up, I can devote my time and energy to it.

A three-hour troubleshoot session? No problem. An endless stream of tickets for three hours? That drains the life out of you.

Drop by drop.

So, I decided to get my hands dirty and learn a bit about IoT hacking. Why the hell not?

I didn't get the luxury of studying computer science or electrical (or-anything-very-technical-really) engineering for 3 years in college─on the other hand, that gave me the privilege of carving out my own study program, and avoiding dumb, mandatory courses.

I started with this Defcon32 talk, which was surprisingly accessible, straight to the point, and fun. After that, I picked a target, got some basic tools, and started tinkering.

                "Nice IoT you got there, friend. T'would be a shame if something happened to it..."

It's not about going uber deep on this, it's about understanding a bit more about the field, getting our hands dirty and seeing if anything clicks. Also, you never know when any of this might come in useful.

Never in my life have I ever wanted to become a DB engineer, or backend mantainer, but I don't know how many times it has been extremely useful to know how to query a DB or create a View.

And always: The journey is the fun part.

Meanwhile, I've been chipping away at Practical Malware Analysis (yikes, he likes books!) but I'm saving that for later. I'll need some time to organize my notes and scribblings into something half-decent, before that becomes a blog post.

Honestly, I kind of envy the people who seem to have all the time in the world to write massive, in-depth blog posts. How do they do it? I guess, like anything else, it comes down to practice—it gets easier the more you do it.

I'm lucky if I manage to put out one of these out every so often.

But hey─if you're deep into your own projects, I hope you're having fun.

Wherein We Forsake: Farewell and Godspeed

棄 - 'to forsake', 'to discard', 'to renounce'

My friends are leaving.

Some were close friends; others were simply colleagues. But if you think about it, we spend so much time with our workmates that they become more than just faces we see at work—they’re part of our daily lives. For many of us, we see our colleagues more often than our families.

I sleep very little, which gives me some extra home time, but still, the reality is that I spend most of my waking hours surrounded by these people. And now, a significant number of them are gone.

I feel sorry for them and for us. I liked many of them, and from what I saw and heard, most were incredibly skilled at what they did. Their departure wasn’t their fault.

So today’s post is a tribute to them.

---

It’s been a month since I’ve written here. In that time, I’ve made a diagonal move in my career (up and to the side) into the role of network specialist. With this role comes a fair amount of autonomy to decide how to implement and secure systems. My onboarding is still ongoing, but I feel the itch to write and return to one of my passions: reverse engineering (RE).

Not today, though. My focus lately has been squarely on network security, and I’ve been wrestling with a thought that might resonate with some of you network addicts:

Network Protection vs. User Accessibility

How do you strike the right balance between keeping a network secure and ensuring it’s user-friendly?

The Freeloader Debate

When managing a network—especially one shared by multiple teams or even public users—you’re forced to ask yourself a tough question:

Do you lock it down, leave it open, or what?

Option 1: Lock It Down?

You could go full-on security mode and control every possible access point. Some options include:

• Blocking unapproved MAC addresses.
• Whitelisting only specific devices.
• Creating VLANs to isolate users and devices.

This approach keeps freeloaders and unauthorized devices off your network. But at what cost?

• Your IT team faces a constant workload managing requests and ensuring critical devices aren’t accidentally blocked.
• Field teams and guests are often frustrated when they can’t connect because their devices are blocked by default, leading to complaints and delays.

Option 2: Leave It Open?

You could take the laissez-faire approach. Just let everyone connect. No restrictions. No extra work.

But this comes with its own set of risks:

• An overloaded network, with too many devices competing for bandwidth and impacting performance for critical systems.
• A wider attack surface, as bad actors could exploit this openness to gain unauthorized access.
• Difficulty in tracing network activity, making it harder to identify devices or users when issues arise.

---

As a wise Jedi once said, “Only Sith deal in absolutes.” Neither extreme is sustainable. A locked-down network might keep freeloaders out, but it also hampers legitimate users from getting their work done. On the flip side, an open network exposes you to security risks and performance issues.

Without going into the nitty-gritty of it all, here are some alternative strategies:

1. Set Up a Guest Network
   A dedicated guest network with bandwidth throttling and basic isolation ensures that guests can connect without overwhelming critical systems.

2. Implement Role-Based Access
   Integrate with RADIUS or Active Directory to dynamically assign permissions based on roles.

3. Use Time-Based Access Policies
   Temporary users (e.g., guests or contractors) can be assigned access that automatically expires after a set period, preventing long-term freeloaders.

4. Monitor and Audit Regularly
   NetFlow or your router’s built-in logging can track activity. This helps detect anomalies before they become bigger issues.

This isn’t just about blocking bad actors—it’s about enabling legitimate users while minimizing risk. It’s a game of checks and balances, not unlike managing resources in an economy or a strategy game.

I can’t go into much detail for obvious reasons, but I wanted to share this small glimpse into a different side of cybersecurity—one that’s as much about people as it is about technology.
I know, I know, too basic: and you're right. Besides, the fun is in the little details, and the clever choices you make. Right? But today is not the day for that.

---

To My Friends

So, to my friends who weren’t freeloaders, who worked hard, and who I’ll miss:

Stay strong in the trenches, stay inspired, stay healthy, and remember—every system, like every farewell, brings its own challenges and opportunities.

Roger and out.

Wherein We Face A Lindwyrm: don't do LeetCode

 

                    The Lyndwurm. Let's face it sooner. Not later.

Before diving into LeetCode, let me tell you this post was initially going to be about my journey completing a series of 30 Assembly CTFs on pwn.college. It still is, in a way, and I highly recommend that site to anyone interested in hacking and low-level programming (check that site─totally worth it). 

But somewhere along the way, I decided to shift the focus. So, bear with me while we explore LeetCode.

Let’s start with the disclaimers:

• I’m happily employed.
• My knowledge of the hiring process is limited to my own experiences and what I’ve observed.
• Take everything I say here with a grain of salt.

---

What Are LeetCode Problems?

LeetCode-style problems are algorithmic and data structure challenges, often used in technical interviews to (supposedly) assess problem-solving skills, logic, and coding efficiency.

I’ve tried LeetCode. I even did a fair bit of it back in university while studying Python. And I’m here to tell you: it’s not for me. It's probably not for you, either.

Here are 10 reasons why I’ve left LeetCode by the wayside:

---

1. I’m not a programmer, nor do I want to be one.

I work in IT and am aiming to become a Cybersecurity professional, specifically a Reverse Engineer/Malware Analyst. In this realm, LeetCode is of very limited relevance, if any. My focus is on low-level code, systems, and security—not cranking out optimal algorithms for abstract, byte-sized, problems.

---

2. Time is sacred, and LeetCode doesn’t fit my priorities.

Mastering LeetCode takes time—lots of it. As someone who obsesses over how I spend my time, I refuse to pour hours into a skill I find doubtful in utility for my goals. Instead, I could be:

• Diving deeper into malware analysis.
• Learning more about CPU internals.
• Experimenting with Reverse Engineering tools.
• Or even doing other wholesome hobbies like: fishing, watching paint dry, or fine-tuning push-ups.

---

3. It consumes mental bandwidth I’d rather use elsewhere.

Focusing on LeetCode takes up space in my brain that I could dedicate to something more relevant or enjoyable. Cybersecurity is vast, and every moment I spend on coding puzzles is a moment I’m not spending on fun puzzles.

---

4. There are other ways to demonstrate my skills.

I maintain a public GitHub with projects I’ve built. If someone needs proof of my abilities, I can show my work or create something on demand. Writing scripts or automation tools in a real-world context is more relevant to my career than solving arbitrary LeetCode.

---

5. Secure, readable code > Clever one-liners.

LeetCode often rewards speed and brevity, which can lead to unreadable, messy solutions. Writing secure, stable, maintainable code that other humans can understand is far more valuable in real-world applications.

---

6. In cybersecurity, CTFs are the way to go.

Capture The Flag challenges (CTFs) are like games. They’re fun, align with the hacker spirit, and teach you practical skills. I’d rather do CTFs all day than grind through LeetCode puzzles.

---

7. Better ways to assess pressure and skills exist.

In addition to several other assessments, my current company included a 1.5-hour test during the hiring process that challenged me to work under pressure, adapt to new situations, conduct research, and document my process. It was hard, fun, and incredibly insightful. If they had instead asked me to solve 10 LeetCode problems, they wouldn’t have learned anything about my actual skills. No joke—this test was fantastic.

---

8. I’m not here to compete with kids who have all the time in the world.

If I have two free hours, I’ll use them to play in my malware lab—not grind Python or C snippets on Codewars. I have nothing to prove to anyone, and I’m not interested in chasing someone else’s benchmarks.

Years ago, I participated in a BJJ tournament and won (blue belt +40 years category). At the end of the tournament, all the blue belt winners were allowed to face each other in a 'free-for-all styled' match. I said no. I had nothing to prove. I knew the outcome, too─there was no point in fighting guys who had trained as long as I had but were 20 years younger and weighed 20 kilos more. 

Here's what I looked like after winning in my category:

                                                        Cute, huh? Third place didn't even get a medal. He got a broken rib and a trip to the hospital.

---

9. I’m not missing meaningful opportunities.

Sure, some companies prioritize LeetCode skills, but those are likely not the places I want to work at. I’d rather focus on preparing for roles that value my expertise in cybersecurity and low-level systems.

On the flip side, if I do receive a job offer from a company looking to assess my "cyber skills," I’ll be in a much stronger position if I’ve invested my time in honing those skills, rather than spending it on LeetCode.

---

10. Burnout is real.

Burnout is pervasive in IT. I’ve seen people so drained by their work that all they want is to clock out and forget anything technical. They crave time for hobbies, family, and friends, leaving the techie stuff for when it’s absolutely necessary. Not me. I dive into reverse engineering because I genuinely enjoy it, but I make sure to balance it with other hobbies, family time, and necessary downtime. Chasing someone else’s dream isn’t worth sacrificing my mental health.

---

Final Thoughts

For those who insist we must suffer through things we hate to secure a “dream job,” I leave you with this quote from Game of Thrones:

Wherein We Look At An ELF: Executable and Linkable Format

 

                So, this is an ELF file, huh?

Elves

For the past few days, I've been delving into ELF (Executable and Linkable Format) binaries—specifically focusing on their structure, behavior, and ways to manipulate them. If the subject matter is of any interest to you, then check this out.

What are ELF files?

They are a "common standard file format for executable files, object code, shared libraries, and core dumps, at least according to Wikipedia.

The magic number for ELF files is 0x7f 45 4C 46. Care to guess what's 45 4C and 46 in ASCII?

Let's look at (yet another) terribly simple C script and then look under the covers:

Not terribly impressive, but we're not trying to be terrible or to impress anyone.

Remember when we talked a bit about the 4-step compilation process here? Instead of directly compiling this program, let's jump to the Assembly phase and look at the object file:

So, as we can see, we have a 64-bit ELF object file... relocatable. What does it mean for this to be relocatable?
It means that it's not dependent on specific memory addresses. So this file can be moved around without breaking its code. Our code isn't yet an executable. We're still short of that objective since we've not yet passed through the linking phase, which will or might add to it other object files or libraries, and then yes, produce our executable.

Remember that, for the most part, programmers skip and don't even think about these steps. The compilation process takes care of all of this in the background, and only if something is untoward will the programmer be warned that one of these 4 steps went awry.

And notice as well that this file is 'not stripped'. What's this, you ask? It's informing us that the the file contains the symbol table and debugging information within it. This keeps information that is useful for debugging purposes, making it easier to analyze and understand what's happening, with tools like gdb or objdump. On the other hand, stripping our binary means that both symbol table and debugging info will be removed. The symbol table contains the names of functions, files, variables and other metadata useful for debugging or reverse engineering. And that extra debugging info shows the variable types and line numbers, for example.

So, stripping will reduce the file size, hide implementation details but also make debugging a bit harder.

Under the hood

Let's do it. It's pretty simple, actually. After finally creating our binary, we can strip it with:

strip --strip-all simple_adder

Here we can see the difference between the two files, through the use of the command readelf:

It's a bit rough around the edges, but if you look carefully, you can see two files, one stripped and one not stripped, and the difference is telling, even for such a small binary.

Obviously, stripping is also used as a countermeasure and obfuscation technique.

The readelf command that you see up there is a tool for analyzing and displaying information about ELF files. With it, we can inspect the internal structure of ELF files, such as executables, shared libraries, or object files. Yes, it's what that ELF lady is doing at the beginning of this blog post. I know. Genius.

Readelf comes in handy to debug linking issues or to understand how an executable or a library is laid out.

As per usual, man files are your friend here.

.text, .data, .bss and .rodata

Elf files have critical areas, like .text which contains executable instructions, .data which stores initialized global variables, .bss which holds uninitialized global variables and .rodata, which holds read-only data, such as constant strings.

We can inspect the .text section, which could be considered as the heart of the program (holding the executable code, really), with a tool like radare2 or objdump, for example:

As you can see, this is giving us Assembly code (in AT&T, no less... yuck) revealing function prologues, loops, and system calls.

Of course, recognizing these patterns is a vital skill for the Reverse Engineer.

Try this for yourself. Also remember to check .data and .bss with:

readelf -x .data your_file

readelf -x .bss your_file

But there's more ways to inspect your ELF files. Let's look at ldd which prints shared object dependencies and use readelf with '-r' to check relocation tables:

What's all of this, you say?

With ldd we can check the shared libraries within our binary. Each listed library representing a dependency. And relocation tables are essential for adjusting addresses in a dynamically loaded binary. Entries like R_X86_64_JUMP_SLOT or R_X86_64_GLOB_DAT help resolve function calls or global variables at runtime.

There's more, of course. But this stuff is much more fun to experiment with than just to talk or write about.

Go at it. Experiment with creating your own binary files and examine them with any or all of these tools (or others). Change things, check again.

No elves were harmed in the making of this blogpost. Nor any DWARF, of course.

Wherein We Pause to Reflect: Simple ASM Review and OS Security Mechanisms

 

Hey! Corny matrix-styled dojo. Why not?

Let’s kick off today’s blog post by writing a very, very simple ASM program. Since I’m reviewing ASM stuff through pwn.college’s course, why not showcase how simple ASM can be? (In a way... math is simple too, but many would argue otherwise).

Our script will be called one-oh-one.s, and our program will be called pausing—since that’s what we’ll want at the end.

Let's start with a program that starts and ends. Simple enough, right? But for that, we need to pass execution to the OS via a syscall (remember those?). To do this, we can move the value 60 into the rax register. Here's how:

Simple enough! But if we try to assemble and link this, we’ll hit an issue:

Ah, much better. Now, our previously failing program is a success... of sorts. We made sure to run with Intel syntax, which is much cleaner (at least to my eyes). We also made the _start label globally visible so that we can indicate where our program begins.

Now no more errors, and we’re ready to tackle the rest of the program. Easy peasy.

Right! While I was trying to set up a pause in my program, I ran into an issue. The syscall I thought was the right one for pausing was actually wrong. So, since I’m working on Linux with x86_64 architecture, I checked /usr/include/asm/unistd_64.h to see which syscalls I should use.

There, I found the exit syscall (60), which needs to be loaded into rax (which we’re already doing). If we want to set an exit code, we need to load it into the rdi register. Fair enough, we can do that. As for the pause syscall, we need syscall 34. I also discovered the alarm syscall (37), which sends a SIGALRM, ending the pause syscall. Without this, we'd have to ctrl+c our way out of the program. We also learned that we need to pass a parameter through rdi. Easy peasy.

Now that we have the tools, let’s create our pausing program, assemble it, link it, and run it while checking for our exit code:

Don't know about you, but I love this!

Now, let's review other concepts. For instance, in pwn.college, you can learn how to point to a specific memory value or the contents at that memory location.

Let's say there’s a memory position 12345 holding the value 42.

If we do:

mov rdi, 12345

We're making it so that rdi will hold that number 12345.

But if we do:

mov rdi, [12345]

Now rdi will hold the value at memory position 12345, which is 42, just like the value stored at that location.

I won’t dive too much into these basics because I’m sure you either already know them or want to experiment with them yourself. Just remember that the OS will have some defenses in place that may make it difficult, if not impossible, to access specific memory locations in your binary.

You can check which defenses have been enabled with a tool called checksec:

Please take your time and check what each of these items does. Here's a quick rundown:

• RELRO: A security feature that makes it harder to modify certain parts of a program, like its GOT (Global Offset Table), preventing attacks on function pointers.
• STACK CANARY: A protective value placed on the stack to detect buffer overflow attacks before they overwrite important data.
• NX: No-Execute; prevents code from running in certain areas of memory, like the stack, to stop exploits that execute malicious code.
• PIE: Position Independent Executable; allows a program to run at random memory addresses, making it harder for attackers to predict the location of code.
• RPATH: A runtime setting in executables that specifies directories to search for dynamic libraries before default system paths.
• RUNPATH: Similar to RPATH, but it is used after LD_LIBRARY_PATH to specify directories for locating shared libraries at runtime.
• Symbols: These represent function names, variable names, and other references in the program’s code, helpful for debugging or exploitation.
• FORTIFY: A set of compiler protections that enhance the safety of certain library functions, like checking buffer sizes to prevent overflows.
• Fortified: Refers to functions that have been modified with additional checks (from FORTIFY_SOURCE) to improve security against buffer overflows.
• Fortifiable: Functions that can potentially be fortified using additional checks to prevent common vulnerabilities like buffer overflows.
• FILE: Refers to the executable or object file format, containing the machine code, symbols, and metadata that the operating system uses to load and run the program.

Like I said, a quick rundown, but it’s worth spending time learning about these defenses—what they do and how to set them up to adequately inspect a binary. Also, note that this applies to ELF files.

Alrighty, another short one! Hope you had fun.