An Untrusted Certificate Can Still Get You Breached

We’re told the padlock means we’re safe — but what it actually confirms is that we’re talking to the right entity, the one whose name is on the certificate. HTTPS is encrypted, so whatever we send is only readable by us and whoever holds that certificate.

But encryption only protects a connection if you’re actually connected to the right server. All it takes to break that is one untrusted certificate the user clicks past — and the data in transit is still technically encrypted the whole time — it’s just encrypted to an attacker instead of the real server. The browser won’t show a padlock for a connection like that — not before the warning, and not after the user clicks past it either. It keeps marking the page as not secure for the rest of that session; clicking through only stops it from blocking the page, it doesn’t bring the padlock back.

In this lab, I position an attacker machine between a victim and a company firewall, exploit exactly that untrusted-certificate warning, and intercept a login to the firewall’s own admin dashboard — credentials and all.

This is a lab, not an invitation. Every step below was carried out against machines I own, on an isolated, host-only VMware network with no route to the internet or any production system. ARP spoofing and traffic interception against systems you don’t own or don’t have explicit written authorization to test are illegal in most jurisdictions, Morocco included. Build this to learn the mechanism and the defenses — not to point it at anything else.

How HTTPS Is Supposed to Work

During a TLS handshake, the server presents its certificate to the client. The client checks whether it’s signed by a trusted Certificate Authority, that it hasn’t expired, and that its hostname matches the site being visited. If all three check out, the connection proceeds and data flows encrypted between the two parties.

The whole system rests on that first check — trust. The client isn’t verifying the server directly; it’s trusting that a CA already did. Break that chain of trust, and the protections built on top of it stop mattering.

The Lab Setup

To simulate a real company environment, the lab uses three machines:

• Victim — a Windows machine, representing an employee
• Attacker — Kali Linux
• Server — a FortiGate firewall, specifically its web login portal

All three sit on an isolated, host-only VMware network with no bridge to any other network. The first step is just reconnaissance — confirming each machine’s IP address on that segment.

Step 1: Positioning the Attacker — ARP Spoofing

To intercept traffic between the victim and the server, the attacker first needs to sit between them. ARP spoofing poisons both machines’ ARP tables: the victim is told the attacker’s MAC address belongs to the server, and the server is told the attacker’s MAC address belongs to the victim.

sudo ettercap -T -q -i eth0 -M arp:remote /192.168.1.101// /192.168.1.100//

• -T -q — text UI, quiet output
• -i eth0 — the interface to attack from
• -M arp:remote — launch ARP poisoning, with remote enabling interception of traffic routed through a gateway
• The two /ip// arguments are the targets being poisoned against each other

Step 2: Letting Traffic Flow — IP Forwarding

ARP spoofing alone breaks the connection rather than intercepting it — by default, the kernel drops packets addressed to an IP that isn’t its own, so without this next step the victim simply loses connectivity.

echo 1 > /proc/sys/net/ipv4/ip_forward

This tells the kernel to forward packets it receives that aren’t addressed to itself, routing them to their real destination. The victim and server keep talking normally — every packet now just passes through the attacker first.

Step 3: Terminating TLS — mitmweb

Forwarding alone would just pass the victim’s traffic straight through, unmodified — still encrypted, so unreadable. To actually read HTTPS traffic, the attacker needs something that terminates TLS with the victim and opens a separate connection to the real server, relaying data between the two.

mitmweb --mode transparent --showhost --ssl-insecure

• --mode transparent — intercepts redirected traffic with no proxy configuration needed on the victim's side
• --showhost — shows the original Host header rather than the proxy's own address
• --ssl-insecure — skips verifying the real server's certificate on the upstream connection, needed here because the FortiGate's login portal ships with a self-signed certificate by default

Step 4: Redirecting the Traffic

IP forwarding alone sends traffic straight past the attacker to the real server. Before that happens, port 443 traffic needs to be redirected into mitmweb’s listening port, so it stops at the proxy first.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080

With this rule in place, TCP traffic arriving on port 443 is redirected to port 8080, where mitmweb is listening, before the kernel ever considers forwarding it onward.

The Attack, From the Victim’s Side

With everything running, the victim opens a browser and navigates to the firewall’s login IP. Because mitmweb is presenting its own certificate instead of the FortiGate’s — and that certificate isn’t trusted by the victim’s machine — the browser shows a warning page: untrusted certificate, possible wrong entity.

A user with no reason to be suspicious clicks through. From there, the login page loads normally, credentials are entered, and the dashboard opens — all while the attacker has already captured the credentials passing through the proxy, and can now log into the same firewall dashboard directly. A single login, on a connection the victim believed was secure, is enough to compromise the device meant to protect everything behind it.

Red Flags a User Could Have Caught

None of these are foolproof, and most require more attention than a routine login usually gets — but they’re worth knowing:

1. The certificate’s issuer. A proxy’s generated certificate can show telltale details, like “mitmproxy” as the issuing authority — though an attacker who clones the real certificate’s displayed fields can make this far less obvious at a glance. It won’t fix the underlying trust failure, just the field a human might read.
2. A warning on a site you’ve visited safely before. Some browsers, Firefox notably, remember a previously accepted self-signed certificate’s public key; a warning reappearing on a site that didn’t show one before can mean the certificate changed.
3. A different error than usual. If a site has always shown one kind of error — an expired cert, a hostname mismatch — and suddenly shows “untrusted certificate” instead, that’s a meaningfully different failure worth a second look.

What Actually Prevents This

Red flags rely on a human noticing something they probably won’t. Two real fixes remove the decision from the user entirely:

• Deploy a proper internal CA. When a company’s own certificate authority is installed and trusted on every host, every legitimate internal certificate verifies cleanly — and anything else is immediately flagged as untrusted, no judgment call required.
• Enable HSTS. HSTS has the server tell the browser, “only ever connect to me securely, for the next however many days.” Once a browser holds that instruction for a domain, it won’t just block plain HTTP — it refuses any HTTPS connection with certificate errors outright, no “proceed anyway” option at all. The warning dialog the victim clicked through in this lab simply never appears.

One Mistake We Made Too

The same shortcut that made this attack possible is a vulnerability in its own right. --ssl-insecure told mitmweb to ignore the real server's certificate entirely — so if a second attacker were sitting between the lab's Kali machine and the real FortiGate, mitmweb would trust that attacker's certificate just as blindly, and we'd become the victim in someone else's man-in-the-middle without knowing it.

The better practice is to download and verify the real server’s certificate once, then pin mitmweb to trust only that specific certificate:

mitmweb --mode transparent --showhost --set ssl_verify_upstream_trusted_ca=/path/to/downloaded_cert.pem

Even this isn’t airtight — if an attacker is already in the middle at the moment that certificate is downloaded, you’d be verifying their certificate instead of the real one. It’s the same trust-on-first-use weakness that shows up anywhere a credential is accepted with no independent way to confirm it. But it’s a meaningfully smaller attack surface than ignoring certificate errors by default — and a good reminder that even the tools built to demonstrate an attack can carry the same flaw they’re demonstrating.

Visit the full video at : https://youtu.be/7FYNN40fLxg

In modern web development and cybersecurity, few tools are as fundamental as the interception proxy. Whether you are a security researcher hunting for vulnerabilities, a penetration tester evaluating an enterprise platform, or a developer debugging complex API integrations, having complete visibility over HTTP and HTTPS traffic between client and server is indispensable.

Yet, despite being central to daily workflows, the software ecosystem around interception proxies has felt static for a long time. Many of the tools we rely on were designed decades ago, burdened by legacy architectures, complex interfaces, and feature sets locked behind paywalls.

I started building Aresius with a simple goal in mind: to create a modern, lightweight, and fully open-source desktop proxy that makes web inspection and security testing accessible, clean, and intuitive.

Here is an overview of what Aresius is, the philosophy behind it, and how it aims to fit into your workflow.

The Need for a Fresh Perspective

Security testing should be focused on discovery and problem-solving, not fighting your tools. Over time, practitioners have encountered common friction points in existing solutions:

1. Heavy Footprint: Traditional desktop proxies are often demanding on system resources, making multitasking or running inside virtual machines slower than it needs to be.
2. Artificial Barriers: Useful features like saving testing sessions or running automated payload tests without artificial rate limits are frequently restricted or difficult to configure.
3. Cluttered User Experience: Decades of layered features often lead to dense, overwhelming user interfaces with a steep learning curve for newcomers and students.

Aresius was born out of a desire for a clean slate — a standalone tool that provides the essential capabilities needed for everyday web testing, wrapped in a responsive, modern desktop experience.

What is Aresius?

At its core, Aresius is an HTTP/HTTPS interception proxy and testing workspace. It sits between your browser or application and the web server, allowing you to observe, inspect, tamper with, and analyze every transaction in real time.

Rather than trying to be an all-in-one kitchen sink, Aresius prioritizes speed, clarity, and the core workflows security researchers use every single day.

Key Capabilities at a Glance

1. Seamless Traffic Interception

Aresius captures outgoing requests and incoming responses on the fly. You can inspect headers, query parameters, cookies, and payloads with clarity, or pause requests in transit to modify data before it reaches the server. Certificate handling for secure HTTPS traffic is handled smoothly, getting you up and running within seconds.

2. An Intuitive Request Replayer

Testing web applications often involves minor, iterative modifications to see how an endpoint reacts. Aresius includes a dedicated Replayer that allows you to clone requests, tweak headers or body parameters, and send them repeatedly. A built-in side-by-side response comparison helps you instantly spot differences in status codes, headers, and reflected content.

3. Fuzzing & Input Testing

Automated input testing is critical when searching for edge cases, injection points, or logic flaws. Aresius provides a built-in testing engine that sends multiple variations of a request using customizable payload lists, helping you quickly identify anomalous responses without artificial slowdowns.

4. Workspace & Session Persistence

Losing your testing history at the end of a session is frustrating. Aresius allows you to save your entire workspace — including intercepted logs, replay tabs, and scope rules — into portable project files. You can close your laptop, return days later, and pick up right where you left off.

5. Focused Scope & Automation Rules

Stay organized during targeted assessments. You can define in-scope and out-of-scope targets to filter out background noise, as well as set up automatic match-and-replace rules to modify specific headers or parameters dynamically.

Built for Usability

One of the guiding principles of Aresius is that powerful security tools do not have to feel clunky.

Aresius is designed as a native cross-platform application that launches instantly and respects your system’s resources. The interface is deliberately uncluttered, making it equally welcoming to:

• Security Students & Beginners practicing in labs and capture-the-flag (CTF) environments.
• Bug Bounty Hunters & Pen Testers who want a fast, reliable tool for focused engagements.
• Developers & QA Engineers debugging API behaviors and webhook integrations.

Committed to Open Source

Aresius is 100% free and open-source under the AGPLv3 license.

Security software thrives on community trust, transparency, and collaboration. By making Aresius open-source, the project ensures that anyone can inspect the code, suggest improvements, build extensions, and contribute to its evolution.

Looking Ahead

Aresius is an active, evolving project. The roadmap includes expanding automation capabilities, visual mapping of application logic flows, and exploring an extensible plugin ecosystem so the community can build custom workflows.

Whether you’re looking for an alternative to your current proxy, a dedicated tool for your learning labs, or an open-source project to contribute to, I invite you to explore Aresius.

• Explore the Code & Releases on GitHub: github.com/0xMarik/Aresius
• Join the Discussion: r/aresius

Feedback, ideas, and contributions are always welcome!

A new integration that turns any MCP-compatible AI assistant into your personal Game Of Life planner.

For a while now, Game Of Life has helped people turn their daily grind into something structured, motivating, and actually manageable — tasks, habits, goals, all in one place. But there was always one extra step: you still had to open the app and do the planning yourself.

That changes today.

Introducing MCP Support

We’ve integrated MCP (Model Context Protocol) directly into Game Of Life. In plain terms: your AI assistant can now talk to Game Of Life the same way it talks to you — and act on your behalf inside the app.

No copy-pasting. No switching tabs. No manually building out your week task by task.

You just tell your AI assistant what you want, and it handles the rest — inside Game Of Life.

What This Looks Like in Practice

In our demo video, we show the integration doing three things end-to-end:

• Building a routine — the AI creates a structured routine with a specific schedule, slotting in the times and frequency that make sense for the goal at hand.
• Setting goals — the AI adds concrete goals directly into the app, no manual form-filling required.
• Doing it all through conversation — every step happens through natural back-and-forth with the assistant, not through menus and settings screens.

The result: a fully planned routine and goal structure, built by AI, living inside the same Game Of Life app you already use to track your progress.

Why This Matters

Productivity tools have always asked users to do two jobs: figure out what they want to achieve, and then do the tedious work of setting it all up. MCP support removes that second job entirely.

This is part of a broader shift happening across software right now — apps aren’t just being used by AI assistants, they’re being operated by them. Game Of Life is one of the first habit and productivity tools to make that real, rather than theoretical.

What’s Next

This is the first step toward making Game Of Life fully AI-native. We’re already exploring deeper integrations — from adaptive routines that adjust themselves based on your progress, to AI-suggested goals based on patterns in your existing habits.

If you want to see the MCP integration in action, check out the full demo video https://www.youtube.com/watch?v=EtVrFa3jj-A.

And if you’re curious about building with MCP yourself, or you’re an AI assistant developer looking to integrate with Game Of Life, reach out — we’d love to collaborate.

Game Of Life is available on https://gameoflife-next.vercel.app . Follow us for more updates as we continue building the AI-native future of productivity.

This meme gives an idea about today’s article: it’s about how students select their major after high school.

other one

Let be honest: choosing a part of a song in instagram is easier than choosing a major in college. the process of choosing a major in higher education is often chaotic and stressful. Many students find themselves lost in a sea of options students are less mature at the end of their hight school years, and they often lack the guidance and support needed to make informed decisions about their future. This article explores the challenges students face in selecting their majors and how these issues can lead to a sense of chaos in their educational journey.

Introduction: A Life Path in Chaos

Imagine your life path being chosen randomly, without guidance or support. After getting your bac, if you don’t hear about available schools, it’s like a whole path of life just disappears — maybe a path you could have loved. Many universities and educational services seem unaware — or maybe they just don’t care — that leaving students in this confusing period only adds more stress.

Problems Students Face

1. Confusing and inconsistent application processes
Every school posts its announcements on a different platform, demanding the same information in slightly different ways. JPEG here, PDF there, sometimes combined, sometimes separate, sometimes specific resolutions, sometimes specific sizes. Add in calculating grades and other requirements — it’s overwhelming.

2. Platforms and security risks
Some of these platforms have been hacked, leaking personal information. Imagine applying to your dream program and then having your personal data exposed. It’s terrifying and completely unnecessary.

3. Priority and fairness issues
There’s also “monopolization” — students who get 18/20 and 19/20 and occupy every spot, leaving others on waiting lists. Students end up unsure if they’ll get a chance at all.

4. Poor communication
Students often don’t even get a confirmation. Just a simple bot that says, “We hear you” would be helpful. Even better if it explains why an application was rejected — it would make things not just much less stressful but also more helpful.

5. Exam scheduling conflicts Sometimes exams for different programs are scheduled on the same day. Students are forced to sacrifice one path for another. Why can’t they give students a chance at both?

The Problem We All Know Too Well

You buy a course. You’re excited. The first few lessons? Amazing. You’re learning, you’re motivated, you’re finally going to master Python or something.

Then… life happens.

A week passes. Then two. The course sits there, mocking you from your bookmarks. You’ve completed 3 out of 30 hours. Sound familiar?

Here’s the thing: it’s not about the quality of the course. It’s not even about your interest level. The modern world has fundamentally changed how we focus, and traditional online courses haven’t caught up.

Why Finishing Courses Has Become Nearly Impossible

The problem isn’t you — it’s the format. We’re trying to consume 30-hour courses in a world optimized for 30-second videos. Our attention spans haven’t gotten worse; our environment has gotten infinitely more distracting.

But there’s another issue nobody talks about: courses don’t fit into your actual life.

Most platforms just give you a “Start Course” button and wish you luck. They don’t ask:

• When do you actually have time to learn?
• What does your typical week look like?
• Where does learning fit between work, family, and everything else?

I’ve tried everything:

• Setting reminders (ignored them)
• Blocking distracting websites (found new ones)
• Telling friends about my goals (added pressure, didn’t help)
• Downloading productivity apps (collected dust on my phone)

None of it worked because they all missed the core issue: long-form learning needs structure, accountability, and a system that works with your actual schedule, not against it.

So I Built My Own Solution

After abandoning my 5th course, I decided enough was enough. If I couldn’t find a platform that actually helped me finish courses, I’d build one.

Here’s what I created: a routine-based learning platform that transforms course completion from a test of willpower into a sustainable habit that fits your real life.

How It Works:

Weekly Scheduling That Adapts to Your Life Before you even start, the platform asks: when can you actually do this? You design your learning week based on your reality — maybe Monday and Wednesday evenings, Saturday mornings, or whatever works for you. The course fits into your life, not the other way around.

Routine-Based Learning Instead of facing a 30-hour mountain, you build a weekly learning routine. The platform tracks every scheduled session and turns consistency into your competitive advantage. You’re not trying to find time to learn; learning already has its time.

Real-Time Progress Tracking See exactly how much time you’ve invested and how you’re tracking against your own schedule. No shame, no comparison to others — just you versus your plan.

Streak System Hit your scheduled sessions? Your streak grows. Miss one? You see what’s at stake. The platform makes your progress visible and meaningful, all based on the schedule you created.

Smart Skip System Life happens — meetings run late, kids get sick, emergencies pop up. You can skip scheduled sessions, but there’s a catch: skips are earned through coins you collect by checking off completed routines. This creates a natural balance: consistency gives you the flexibility you need when life gets chaotic.

Built for Real Life

This isn’t about grinding harder or “finding” more time. It’s about being honest with yourself upfront: “I can realistically dedicate Tuesday and Thursday evenings to this.”

Then the platform holds you to that commitment while giving you the tools to adapt when necessary.

The platform doesn’t guilt you for being human. Instead, it gamifies consistency, makes progress tangible based on YOUR schedule, and gives you the flexibility to adapt without losing momentum.

The Difference

Traditional platforms: “Here’s 30 hours of content. Good luck!”

This platform: “When can you learn? Let’s build a weekly routine that actually works and track your commitment to it.”

The Result

I have completed more that 40 courses, Using the platform it helped also in my studies and my projects.

Try It Yourself

sign in with your google account and give it a shot: https://gameoflife.ma

Because finishing what you start shouldn’t require finding time you don’t have.

That’s Not a Terminal — The Truth About Linux Terminals

What if I told you… this is not a terminal?
What you’re looking at is an emulator.
And the real terminal? It used to be a physical machine.

Let me show you the real story behind what we still call ‘the terminal’ today.

let’s go back in time. In 70s,

Computers were massive, expensive mainframes that cost millions of dollars. No one could afford a personal computer, so these mainframes had to be shared between multiple users.

The solution? Terminals. A terminal was a simple device — just a keyboard, a monitor, and a serial cable connection. No CPU, no RAM, no motherboard, no hard disk. Nothing.

Just an Input from the keyboard and Output to screen

One famous example is the VT-100 terminal

It would connect via serial cable to a central mainframe computer — like a VAX-11 — and that mainframe would do all the actual computing.

These devices were called ‘terminals’ because they were the terminal point — the endpoint — where users interacted with the computer

And something else a ‘TTY’, which you’ll see everywhere in Linux, stands for ‘teletypewriter’ — those were even older machines that literally printed output on paper before monitors existed!

So the terminal was just your window into the system. As this photo show how they worked.

Even though physical terminals are obsolete today, the concept of terminals still exists in Linux. The Linux operating system has software that can communicate with terminal devices, and it offers ways to access that functionality both physically and virtually.

Let me show you what’s actually running on a Linux system right now.

[Let’s press Ctrl + Alt + F3]

This screen is called a virtual console.

I’ll enter my username and password — and this is exactly how Linux systems were used years ago: no windows, no mouse, just pure text.

If I run the command tty, it tells me which terminal I’m connected to.
As you can see, I’m on tty3.

What’s interesting is that this isn’t a separate physical device.
There’s only one keyboard and one screen —

but Linux virtually splits them into multiple independent consoles.

These virtual consoles are text-mode login sessions built directly into the Linux kernel.

You can switch between them using Ctrl + Alt + F1 through F6, and each one runs independently in the background — even while a graphical desktop is active.

Before graphical environments existed, this was Linux and it still applied in version that don’t require a graphical environment like Ubuntu server.

Now let me open what you probably use every day:
a terminal emulator.

Let’s run the same command again: tty.

This time, instead of tty3 or tty4, we get something like /dev/pts/0.

This tells us we’re no longer on a virtual console.

What you’re looking at now is a terminal emulator — a graphical application that simulates a terminal in software.

If you check the application menu on some Linux distributions, you’ll literally see it named “Terminal Emulator.”

Now you know why.

These programs are emulating the behavior of old physical terminals,
but instead of real hardware, they use pseudo-terminals.

That’s what pts stands for: Pseudo-Terminal Slave.

Each terminal window you open gets its own device file:
/dev/pts/0,1,2, and so on.

So while it looks similar to a virtual console, it’s actually a GUI program talking to the kernel through a virtual device.

So what’s the relationship between virtual consoles and terminal emulators?

They’re actually siblings — two different ways to achieve the same goal: giving you a text interface to communicate with Linux.

Virtual consoles are implemented directly in the kernel. No GUI needed. They’re your emergency backup — if your graphical desktop crashes, you can always press Ctrl+Alt+F2 and still access your system. You can see it a lot in servers version where GUI is not installed. Like Ubuntu server as we said before.

Terminal emulators in the other hand are GUI applications that run inside your desktop environment. They’re more convenient for daily use, but if your GUI crashes, they go away too.

Here’s the beautiful part: from the shell’s perspective, it doesn’t matter! Whether you’re in virtual console or terminal emulator, the shell just sees a terminal device and works exactly the same way.

There’s a well-known concept in Linux: “Everything is a file.”

That doesn’t just apply to regular files like documents or scripts — 
it also applies to devices.

Keyboards, disks, screens… and terminals are no exception.

In Linux, terminals are represented as device files.

Virtual consoles appear as: /dev/tty1, /dev/tty2, and so on.

Terminal emulators, on the other hand, use: /dev/pts/0, /dev/pts/1, etc.

This file-based design is what makes Unix-like systems so powerful — programs don’t talk to hardware directly; they just read from and write to files.

So next time you open a terminal, remember that you’re just interacting with these device files.

If you found this helpful, go subscribe to the channel https://www.youtube.com/@AsgardTech, hit the like button, and drop a comment that you came from medium, see you in the next one.

Hello everyone, have you ever wondered what these symbols — >, 2>, &>, and < — are used for in Linux and Unix-like systems?

If not, this blog is for you.

We are going to explore how these redirection operators work in the Linux terminal.

A Simple Example to Begin

Take a look at these codes:

#include<stdio.h>
int main() {
    printf("Hello, World!\n");
    return 0;
}

print("Hello, World!\n")

We all run them at least once, and most people think: “Yeah, it prints text to the terminal, right?”
Well… yes, but not exactly, because behind the scenes your program is not talking directly to the terminal, but through streams.

What Are Streams?

Before we dive into redirection, let’s understand streams. In Unix-like systems, every program has three standard streams:

0 — Standard Input (stdin)

Receives data from your keyboard or from other programs through pipes.

1 — Standard Output (stdout)

Where normal program output goes.

2 — Standard Error (stderr)

Used specifically for error messages and diagnostics.

These numbers (0, 1, 2) are called file descriptors, and they are the key to understanding redirection.

Standard Input (stdin)

In Python, you read from stdin using the input() function:

name = input()

In C, you use scanf:

scanf("%s", name);

The shell gives us two main ways to provide input:

• Pipes (|)
  Example:
  cat ./file.txt | grep "something"
  Sends the file contents to grep.
• Redirection <
  Example:
  cat < ./file.txt
  Makes cat read from the file instead of the keyboard.

Standard Output (stdout)

In Python, we use print():

print("Enter a filename")

In C, we use printf().

Standard Error (stderr)

Stderr is for errors and diagnostics.

• In Python:

import sys
print("Error happened!", file=sys.stderr)

• In C:

fprintf(stderr, "Error happened!");

The key point is: stderr is separate from stdout, so you can redirect each of them differently.

Why Streams Matter

Because they are directly connected to the symbols:

>, 2>, &>

These are redirection operators that redirect output from the terminal to a file — but not all of them redirect the same stream.

Redirection Operators Explained

1. > or 1> — Redirect stdout

command > output.txt
Redirects stdout (file descriptor 1).

2. 2> — Redirect stderr

command 2> errors.txt
Redirects stderr (file descriptor 2).

3. &> — Redirect both stdout and stderr

Redirects both streams into the same file.
Very useful for logging everything.

Example Program

#include <stdio.h>
int main () {
    printf("Enter a file name:\n");         // goes to stdout
    fprintf(stderr, "Error happened!");      // goes to stderr
    return 0;
}

Python version:

import sys

print("Enter a file name:")           # stdout
print("Error happened!", file=sys.stderr)   # stderr

This prints:

• “Enter a file name:” → stdout
• “Error happened!” → stderr

When we run the program normally, both stdout and stderr appear on the terminal.

Redirecting stdout:

Terminal shows only stderr.
File contains stdout.

Redirecting stderr:

Terminal shows only stdout.
File contains stderr.

Redirecting both:

Terminal shows nothing.
File contains both stdout and stderr.

Appending Instead of Overwriting (>>, 2>>, &>>)

There is something more to talk about: the symbols
>>, 2>>, &>>.

They do the same as the previous operators, but instead of erasing the file, they append to the existing file.

Conclusion

And that’s it!
This is all you need to know about redirecting streams in Linux.

If you found this helpful, go subscribe to the channel https://www.youtube.com/@AsgardTech, hit the like button, and drop a comment.

Imagine having a tutor available 24/7, one who adapts to your exact learning style, answers your specific questions, and never gets impatient. This isn’t science fiction — it’s AI-powered self-learning, and it’s transforming how we acquire new skills.

As someone who’s spent countless hours learning independently, I’ve experienced the frustration of hitting a wall with no one to turn to. But over the past year, AI has fundamentally changed my approach to self-education. Here’s what I’ve learned.

The Traditional Self-Learning Struggle

Let’s be honest: traditional self-learning has always been challenging.

You find a promising video tutorial or course, dive in with enthusiasm, and then hit a roadblock. Maybe the instructor explains a concept too quickly, assuming knowledge you don’t have. Perhaps they use jargon without defining it. Or they skip steps that seem “obvious” but leave you completely lost.

The old approach? Pause the video, search Google for clarification, wade through Stack Overflow threads from 2015, and hope someone asked your exact question. Sometimes you find an answer. Often, you don’t.

The core problem: Static resources can’t adapt to your unique knowledge gaps. A video designed for intermediate learners can’t magically adjust when a beginner watches it. A textbook can’t answer your specific “but why?” questions.

Enter AI: Your Adaptive Learning Partner

This is where AI tools, particularly Large Language Models (LLMs), become game-changers.

Think of traditional resources as a map — they show you the destination and the general route. AI is like a GPS that adapts to exactly where you are, recalculates when you take a wrong turn, and provides real-time guidance based on your current position. Both are valuable, but one responds to your specific situation in the moment.

What Makes AI Different

Instant, personalized answers: Unlike posting on forums and hoping for replies, AI responds immediately to your specific question at your current level.

Adaptive explanations: If the first explanation doesn’t click, ask for it differently: “Can you explain this using a cooking analogy?” or “I’m 15 years old, can you simplify this?”

No judgment zone: Ask the “stupid” questions you’re embarrassed to post publicly. AI won’t judge your knowledge gaps.

Practical Setup: AI Alongside Your Learning

Here’s how I’ve optimized my learning environment, and you can too.

The Browser Sidebar Approach

Stop switching between tabs. Modern browsers like Firefox, Edge, and Chrome now offer AI sidebars that sit alongside your learning materials.

How to set it up:

1. Open your browser settings
2. Look for “Sidebar” or “AI assistant” options
3. Choose your preferred AI tool (ChatGPT, Claude, Copilot, etc.)
4. Pin it to stay visible

For Firefox users here is how I do it

1. Active the side bar
2. Choose to open AI tab
3. Choose your preferred AI (ChatGPT, Claude, Copilot, etc.)

Why this works: When reading a PDF tutorial or watching a course video in your main window, you can instantly ask questions in the sidebar without losing your place. No context switching, no momentum lost.

Pro tip: Open PDFs directly in your browser rather than a separate PDF reader. This keeps everything in one ecosystem, making it easier to copy sections into your AI prompts for context.

The Art of Asking: Prompt Engineering Basics

Here’s the truth: AI is only as helpful as the questions you ask. Generic questions get generic answers. Precise, contextualized questions get transformative responses.

Bad Prompt vs. Good Prompt

❌ Bad: “Explain recursion”

✅ Good: “I’m learning Python and understand loops. Can you explain recursion by comparing it to loops, then show me a simple example with line-by-line comments explaining what happens?”

See the difference? The second prompt provides:

• Your current knowledge level
• A comparison framework
• The specific format you want
• Your learning style preference

The Context Game-Changer

When you’re taking a course or following a specific curriculum, give AI that context:

Example prompt structure:

I'm taking a database course where we're learning SQL. 
My professor emphasizes normalization and provided this 
definition: [paste definition]. 

I understand 1NF, but I'm confused about 2NF. Can you:
1. Explain 2NF using my professor's framework
2. Show me an example table that violates 2NF
3. Show how to fix it
4. Explain why my professor's approach differs from 
   other explanations I've seen online

This approach ensures your AI-assisted learning aligns with your coursework, which is crucial for exams and assignments.

Different Questions, Different Answers

Remember: there’s often more than one way to solve a problem or explain a concept. In academic settings, understanding your instructor’s preferred approach matters.

That’s why context is king. Tell the AI:

• What course you’re taking
• What your instructor emphasizes
• What you’ve already covered
• Where specifically you’re stuck

My Real-World AI Learning Workflow

Here’s exactly how I use AI in my daily learning:

Morning learning session:

1. Open course material in main browser window
2. Activate AI sidebar (I use Claude, but any works)
3. Start with: “I’m learning [topic] today. I’ll share concepts as I go, and I might need clarification.”

During learning:

• Highlight confusing passages → paste into AI → ask for clarification
• See unfamiliar terms → quick definitions without breaking flow
• Encounter complex diagrams → describe to AI → ask for step-by-step explanation

Pro tip for deep dives: When exploring a complex topic, start by giving AI the full context upfront: “I’m learning about [topic]. I’ll be asking you several questions about it today. Here’s what I already know: [brief summary]. Here’s what I’m trying to understand: [specific goal].” This “pin” ensures every follow-up question builds on your previous conversation, and the AI maintains awareness of your learning journey without you repeating yourself each time.

Here is an example from ClaudeAI

After learning:

• “Can you quiz me on what I just learned?”
• “What are common misconceptions about this topic?”
• “What should I learn next to build on this foundation?”

Beyond the Hype: Real Limitations to Consider

Let’s be balanced here. AI isn’t perfect, and self-learning still requires effort.

AI can occasionally be wrong: Always verify critical information, especially for topics like medicine, law, or financial advice.

It’s not a replacement for practice: AI can explain how to code, but you still need to write code yourself to learn.

Some topics need human guidance: Complex mathematics, creative arts, or hands-on skills often benefit from human mentorship alongside AI support.

Access isn’t universal: Not everyone has reliable internet, capable devices, or can afford premium AI tools. We shouldn’t pretend these barriers don’t exist.

The Learning Revolution Is Personal

We’re living through a fundamental shift in how humans acquire knowledge. For the first time in history, personalized, adaptive education isn’t limited to those who can afford private tutors or attend elite institutions.

AI doesn’t replace the discipline and effort required to truly learn something. But it removes many of the artificial barriers — the waiting for answers, the mismatched teaching styles, the isolation of learning alone.

Your path to mastering new skills is now smoother, faster, and more adapted to exactly who you are and how you learn best.

Your Turn: Start Today

If you’re currently learning something — anything — try this experiment:

1. Open your learning material
2. Activate an AI tool (most have free tiers)
3. Ask one specific, contextualized question about something you don’t fully understand
4. Notice how the personalized response differs from generic Google results

The future of self-learning isn’t about AI replacing teachers or resources. It’s about AI filling the gaps, adapting to you, and ensuring that the only limit to what you can learn is your curiosity, not the availability of the right explanation at the right level at the right time.

What will you learn first?

Have you used AI in your self-learning journey? I’d love to hear your experiences and tips in the comments below.

Sometimes, a question looks simple — but hides an impossible premise.

In the Korean movie In Our Prime, a teacher draws a right-angled triangle with two identical legs. The height is given as 6, and the hypotenuse as 10. He asks the students to find the area.

Using the common formula:

Area = 1/2 × base × height = 30

The calculation seems straightforward, but the teacher says the answer is wrong.

Why?

Because the triangle described cannot exist.

A right-angled triangle’s hypotenuse is the diameter of its circumcircle. This means the height (the perpendicular from the right angle to the hypotenuse) acts as the radius of that circle.

If the hypotenuse is 10, the radius must be 5. The height being 6 is impossible geometrically.

This example reveals a false question — not because of a calculation error, but due to an impossible premise.

The third image says: “It is impossible to get a right answer from a wrong question.”

Of course this scene was captured to teach him how to study math but it is very good example for our case

Introduction

In science and technology, precision is everything. But sometimes, the questions themselves lack precision or contain hidden assumptions, contradictions, or ambiguities. These are false questions: questions that are flawed by design, leading to confusion or unfair evaluation.

They may appear simple or straightforward, but they test not only knowledge but also the ability to spot inconsistencies.

Example from CCNA Knowledge Test: The Subnet Mask Dilemma

I recently came across a question in a CCNA (Cisco Certified Network Associate) knowledge assessment that perfectly illustrates this issue:

“A site administrator manages a network that must accommodate 126 hosts. Which subnet mask would satisfy the number of hosts requested?”

A. 255.255.255.0

B. 255.255.255.128

At first glance, both answers are technically valid:

• 255.255.255.0 supports 254 usable hosts — more than enough.
• 255.255.255.128 supports 126 usable hosts — exactly what’s required.

So what’s the right answer?

That depends on the intended goal of the question — which is not clearly stated.

• If the purpose is to test whether the student can pick the smallest subnet that fits exactly 126 hosts, then 255.255.255.128 is correct.
• But if the purpose is to test whether the student is aware that networks often require room for growth, and that you should avoid maxing out a subnet, then 255.255.255.0 is the wiser choice.

The real problem is that the question does not clarify its intent. There is no mention of:

• Planning for future hosts
• Choosing the most efficient option
• Avoiding subnet exhaustion

So a student can think carefully, defend their reasoning — and still be marked wrong based on an unstated expectation.

This transforms a good teaching opportunity into a trap question.

Why False Questions Are Harmful

• They confuse learners and penalize those who think critically.
• They promote guesswork rather than true understanding.
• They can undermine confidence in assessments and educators.
• They encourage rote memorization instead of logical analysis.

Common Characteristics of False Questions

• Ambiguous wording without clear constraints.
• Multiple correct answers without instruction to choose all that apply.
• Hidden or unstated assumptions.
• Logical or physical impossibilities within the question.
• Mixing incompatible categories or units.

How to Avoid or Fix False Questions

• Clearly define requirements and constraints.
• Avoid vague terms like “best,” “ideal,” or “suitable” without context.
• Ensure internal consistency and real-world feasibility.
• If multiple answers are valid, ask for all correct options or specify criteria.
• Peer-review questions to spot ambiguities and logical flaws.

Conclusion

Good questions lead to clarity and deeper understanding. False questions mislead, confuse, and frustrate.

Whether in geometry, networking, or any scientific discipline, precision in questioning is essential. Sometimes the best answer to a question is to recognize that the question itself is broken.

“Sometimes, the smartest answer is: This question is flawed.”

Give a look to my portfolio https://soufianeamimi.vercel.app

Security monitoring is no longer a luxury — it’s a necessity. But for many organizations, the cost and complexity of commercial SIEM solutions can be overwhelming.

That’s why I built a complete, open-source SIEM architecture using lightweight, modular, and community-supported tools: Wazuh, Fluent Bit, Graylog, and OpenSearch.

here is the documentation step by step to build this architecture
https://opensource-siem-doc.vercel.app/

🧱 The Architecture at a Glance

The flow is simple but powerful:

1. Wazuh collects logs and detects security events from endpoints.
2. Fluent Bit forwards those alerts efficiently to the next stage.
3. Graylog enriches and organizes the data.
4. OpenSearch stores everything and makes it searchable.

Each tool has a specific role and can be customized, scaled, or replaced independently.

💡 Why This Stack?

• ✅ Free & Open-Source — No licensing limits or hidden fees.
• ⚙️ Modular — Swap or update any part without breaking the system.
• 🔍 Detailed Visibility — Detect, enrich, and search logs in real time.
• 📈 Scalable — Handles large data volumes efficiently.

💭 Lessons Learned

During this project, I ran into some configuration challenges — especially around data formatting in Graylog — but the flexibility of the stack allowed me to overcome them.

The key takeaway? Keep your architecture clean, modular, and well-documented.

🔚 Final Thoughts

If you’re looking for a cost-effective and powerful SIEM solution, this stack is a great starting point. It gives you full control, strong detection capabilities, and solid performance — all without paying for a commercial license.

Whether you’re a student, a startup, or an enterprise team, open-source SIEM is more accessible than ever.

Thanks for reading. Feel free to reach out or share if you’re building something similar. 🙌