DEV Community: Ícaro Molinari

I Turned a Dusty 2014 Lenovo Into a Two-Brained Dev + Hacker Machine (and So Can You)

Ícaro Molinari — Thu, 20 Aug 2026 12:45:00 +0000

It was dying in a drawer and I turned it into this:

ONE LAPTOP
  │
  ├── 🐧 Fedora → coding, Docker, daily driver
  └── 🛡️ Kali   → pentest, security labs

Here's the trip: what I did, what broke, what I'd do differently.

Why bother?

Full hardware access (no VM slowdown)
Free — no new hardware needed
Old laptops deserve a second life

The plan

SSD  → Kali (small) + Fedora (big, main driver)
HDD  → just files (/dados)

Step 1 → Install Kali, partition it manually

Guided partitioning eats the whole disk. Don't use it. Go manual:

SSD
 ├── EFI   → 512 MB  → /boot/efi
 └── ext4  → rest     → /

HDD
 └── ext4  → all      → /dados

Rules that saved me:

Pick disks by model, never by name (sda can change)
Check "Use as:" on every partition before moving on
Read the final "write to disk?" screen. Every word.

Step 2 → Black screen on first boot

Scary. Almost always one simple fix:

Boot Mode: Legacy Support ❌
      ↓
Boot Mode: UEFI Only      ✅

Still black? Add nomodeset to the boot line and try again.

Step 3 → Check before you touch anything

lsblk -f
sudo fdisk -l
df -hT

My Kali partition:

Claimed: 447 GB
Used:    18 GB  (5%)

Huge safe gap → easy to shrink, zero risk to files.

Step 4 → Install Fedora next to Kali (no wipe)

In the installer:

"Use entire disk"              ❌ wipes everything
"Share disk with other OS"     ✅ this one

It offers "Reclaim space" — shrinks Kali live, no extra tools needed.

BEFORE                  AFTER
Kali: 480 GB      →     Kali:   100 GB
                         Fedora: 380 GB (encrypted, new)

Confirm screen, hit install, done in ~10 min.

Step 5 → "bad shim signature" — Kali won't boot anymore

Fedora's bootloader → trusted ✅
Kali's kernel       → not trusted ❌
      ↓
Secure Boot blocks it

Fix: turn off Secure Boot in BIOS (Security tab). Fedora doesn't care. Kali boots again.

Step 6 → Clean up the GRUB mess

Two distros + old kernels + recovery modes = 8 menu entries. Fix it in 2 moves:

1. Drop old kernels:

# Fedora
sudo dnf remove --oldinstallonly --setopt installonly_limit=2 -y

# Kali (check exact name first!)
dpkg --list | grep linux-image
sudo apt purge -y linux-image-OLD-VERSION+kali-amd64
sudo apt autoremove -y
sudo update-grub

2. Kill recovery-mode duplicates:

echo 'GRUB_DISABLE_RECOVERY="true"' | sudo tee -a /etc/default/grub
sudo update-grub

8 entries → 4 entries

Step 7 → Make it pretty + make it yours

GRUB_TIMEOUT=-1 → menu waits, no countdown race
grub2-themes → real GRUB theme in 2 commands
hostnamectl set-hostname kali → fixes your terminal prompt
Second keyboard layout, one toggle:

echo 'XKBLAYOUT="br,us"' | sudo tee -a /etc/default/keyboard
echo 'XKBOPTIONS="grp:alt_shift_toggle"' | sudo tee -a /etc/default/keyboard
sudo dpkg-reconfigure -f noninteractive keyboard-configuration

What I'd do differently

Check Secure Boot before starting, not after a scary error
Always lsblk -f first. I got this one right — kept it that way
Pick disks by model, never by name
Measure before you shrink
Read every confirm screen. Every time.

Got an old laptop doing nothing? This is a weekend project, not a wizard-level one. Go dig it out.

Open Redirect: When a Real google.com Link Turns Malicious

Ícaro Molinari — Tue, 18 Aug 2026 04:41:59 +0000

In December 2025, Check Point's researchers flagged something odd: thousands of phishing emails landing in inboxes with a real, valid google.com link inside them.

Not a lookalike domain. Not a typo-squat. The actual google.com.

Nearly 3,200 companies got hit. Over 9,300 emails, all disguised as Google voicemail or file-share notifications, all carrying a link that genuinely pointed at Google's own servers. Clicking it sent victims through a CAPTCHA (for "legitimacy") and then on to a fake Microsoft login page built to steal credentials. (SC Media)

Nobody hacked Google. Nobody forged the domain. The attackers just found a corner of Google's own infrastructure that would forward a visitor anywhere they asked, and used it as a launchpad.

That corner has a name: Open Redirect. And it's a lot more common, and a lot older, than a single 2025 headline suggests.

This Bug Has Been Everywhere

Microsoft's own security team wrote about this exact pattern back in 2021, after tracking a single campaign that used over 350 unique phishing domains, all funneled through open redirect links on trusted platforms. Their reasoning for why it works so well: people are trained to check the domain in a link, and an open redirect lets the visible domain be completely legitimate. (Microsoft Security Blog)

It's not just email providers, either. Cofense's threat intel team tracked phishing campaigns abusing .gov websites across dozens of countries, and found that almost 60% of the abused government domains shared the exact same vulnerable code path, traced back to a single Liferay CMS bug, CVE-2024-25608. (Cofense)

One bug class. One shared root cause. Reused across governments, cloud platforms, and email systems, for years.

So let's actually look at what it is, and why it keeps showing up.

The Bug, In Its Simplest Form

Open Redirect happens when your app takes a destination from the user and sends them there without checking it first.

https://example.com/login?redirect=/dashboard

Somewhere on the backend:

destination = request.query["redirect"]
return redirect(destination)

Change the parameter, and the server obeys just as happily:

https://example.com/login?redirect=https://attacker.example

HTTP/1.1 302 Found
Location: https://attacker.example

This isn't a hypothetical. In 2024, a bug bounty researcher found this exact pattern on Tumblr's own logout endpoint, where a redirect_to parameter sent users wherever the URL said, no validation attached. (writeup)

It also showed up in Expedia's login and logout flow, reported through HackerOne in 2023. (report)

It even shipped inside Ruby on Rails itself. CVE-2023-22797 was an open redirect baked into Action Pack's redirect_to helper, meaning any Rails app using it by default inherited the bug. (HackerOne)

If a framework used by hundreds of thousands of production apps can ship this by accident, "we'd never make that mistake" isn't a real defense.

The Method Doesn't Matter

A quick myth to clear up: this isn't a GET-only problem.

The destination can arrive in a POST body, a PUT payload, a JSON field, anywhere the server reads user-supplied data from. The only question that matters:

Does anything the user controls decide where the redirect goes?

If yes, and nothing validates it, you have the bug. The HTTP verb is just the delivery truck.

"Wait, Isn't This Just MITM?"

No, and this mix-up trips people up a lot.

Open Redirect: the server itself honestly generates a malicious Location header, because it trusted a parameter it shouldn't have. HTTPS does nothing to stop this, the channel was never the problem.
MITM (man-in-the-middle): someone sits between the browser and server, altering traffic in transit. This requires actual network positioning, not just a crafted URL.

If you've ever tested this in Burp Suite by editing a redirect parameter, you weren't simulating MITM. You already controlled the browser and configured the proxy yourself. That's a lab setup, not an attacker's vantage point.

The Version That Never Touches Your Server

Here's where it gets genuinely sneaky.

Everything so far assumed the server decides the redirect. But plenty of redirect logic lives entirely in JavaScript, in the browser, after the page has already loaded. When that's the case, your server logs never see the attack happen.

const destination = location.hash.substring(1);
window.location = destination;

Perfectly ordinary code. Probably built for some deep-linking feature. But it reads directly from the URL fragment and acts on it with zero validation.

https://example.com/redirect#https://attacker.example

The part after # never gets sent to the server at all, it's pure client-side. The victim's own browser reads it and redirects them. No server involved, no request log, nothing for a WAF to catch.

Why This One Is Scary: HackerOne Found It on Its Own Site

Here's the part I find genuinely funny. HackerOne, the bug bounty platform, runs one of the largest security researcher communities on earth.

Report #398054, disclosed publicly on their own platform: a DOM-based XSS vulnerability on hackerone.com itself, caused by an insecure message event listener tied to a Marketo contact form. (HackerOne)

The presentation tool reveal.js had the same class of bug (CVE-2020-8127): a postMessage handler that let a caller invoke arbitrary internal methods, turned into a working XSS chain. (writeup)

The common thread: a page listens for cross-window messages and trusts whatever arrives.

window.addEventListener("message", event => {
  process(event.data); // who sent this?
});

Anyone who can get the victim to open a popup or iframe can fire data into that handler. The fix is one line, and it's the one line that keeps getting skipped:

window.addEventListener("message", event => {
  if (event.origin !== "https://trusted-partner.com") return;
  process(event.data);
});

There's a reason location.hash in particular is a favorite for bug bounty hunters: it's never sent to the server, which means it's invisible to server logs, WAFs, and most automated scanners entirely. You can only find this class of bug by actually reading the client-side JavaScript. (dev.to writeup)

The One Question That Explains All of It

Every example above, the Tumblr redirect, the Rails CVE, the HackerOne postMessage bug, the Google Cloud phishing campaign, comes back to one question:

Where did the data come from, and where did it end up?

Security people call the origin a source and the destination a sink. Common sources:

Source	Where it shows up
`location.hash` / `location.search`	URL fragment and query string
`event.data`	Cross-window messages (`postMessage`)
`document.cookie`	Only non-`HttpOnly` cookies
`input.value`	Form fields
API responses	Anything a user or third party can influence

Common sinks:

Sink	Risk
`window.location = data`	Open Redirect
`element.innerHTML = data`	DOM XSS
`eval(data)`	Arbitrary code execution
`document.write(data)`	Unsanitized DOM injection

Neither a source nor a sink is a bug on its own. The vulnerability lives in the unguarded path between them.

A Five-Question Checklist

Next time you're staring at a piece of code and trying to decide if it's a problem:

Where did the data come from?
Can an attacker influence it?
Where does it end up?
Is there validation between the two?
What actually happens if it's abused?

That's the entire audit. No memorized vulnerability list required.

The Takeaway

Open Redirect and DOM XSS both survive because they exploit a very human habit: we check the domain, and we trust it once it looks right.

An attacker doesn't need to break into google.com, hackerone.com, or a government .gov site. They just need one endpoint that forwards a visitor without asking questions, and 350 phishing domains, or 9,300 emails, later, it's still working.

Go check your own postMessage listeners and redirect logic today. It costs one afternoon. The alternative costs a lot more.

[Boost]

Ícaro Molinari — Mon, 10 Aug 2026 20:27:40 +0000

Frontend Challenge CSS Art Submission 🍲🥧

Ícaro Molinari

Aug 10

The Best Hot Dog! CSS Interactive Art for the Comfort Food Edition Challenge

#frontendchallenge #devchallenge #css

4 min read

The Best Hot Dog! CSS Interactive Art for the Comfort Food Edition Challenge

Ícaro Molinari — Mon, 10 Aug 2026 17:37:02 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

The Brazilian hot dog (cachorro-quente) isn't just bread, sausage, ketchup and mustard... It's a whole toppings culture: quail egg, crispy potato sticks (batata-palha), corn, mashed potatoes, and the eternally controversial raisins.

My personal connection to this one is a little silly: my wife nicknamed our dog "hot dog" because she's so warm she basically doubles as a space heater in bed.

That nickname is what actually clicked something for me (we both already love hot dogs), and I realized the version I grew up with, the loaded, toppings-everywhere Brazilian one, is basically unknown outside Brazil. So this became my excuse to finally show it to the rest of the world.

I set the scene on Copacabana beach in Rio: sky, Sugarloaf and Christ the Redeemer in the background, sailboats drifting by, and a vira-lata caramelo (the "caramel mutt," one of Brazil's most-loved street dogs) sitting next to the stand, a little tribute to the real one who started this.

Clicking through the toppings became the whole interaction: each one gets a little pixel-art icon and a real fact about where in Brazil it shows up.

Demo

Live demo: https://the-best-brazilian-hot-dog-css.vercel.app/
Video walkthrough:
(if the embed doesn't render: https://youtu.be/vMl0N9eqd4E)
Source code: https://github.com/icaromol/the-best-brazilian-hot-dog-css

Journey

Every shape in the scene — the mountains, the boats, the food, the dog — is CSS: gradients, clip-path, and pixel art drawn with box-shadow (each sprite is a big list of x y color shadows, basically a matrix).

No raster images, no SVG. There's a thin layer of vanilla JavaScript (~300 lines total, no framework) for the click interactions — opening ingredient cards, the START gate, a responsive "dual-screen" layout on portrait viewports — but it's purely interaction, kept intentionally small so it stays a "sprinkle," never the thing producing the visuals.

None of that pixel art was hand-typed as box-shadow values, though — for this challenge I ended up building an entire second tool to make that possible:

free-css-sprite-generator

A local pixel-art editor with a brush/eraser, a locked color palette, and a live CSS preview, plus a CLI path for turning a reference image into pixel art automatically. Every sprite (the boats, the clouds, the dog's four walk/stand frames, the hot dog, all ten ingredient icons) was painted or imported there, saved as a pixel grid, then compiled into CSS with one generated box-shadow entry per pixel.

That's the actual source of the ~121,000 lines of pixel-art code in this repo. I'm glad I never wrote a shadow coordinate by hand.

Quick note since this is a CSS Art challenge: I wrote the styles in SCSS, but think of SCSS as a writing tool, not a runtime one — nothing SCSS-specific ever reaches the browser. Before anything ships, a compiler (sass) turns all my .scss files into one plain css/style.css file, and that's the only thing the browser ever loads and renders.

I only used SCSS to keep those ~121,000 lines of pixel-art code split into 56 organized files instead of one giant unreadable stylesheet — no clever logic, no loops, barely any variables. So when it's judged, what's actually running is 100% plain CSS.

The trickiest part was the responsive "dual-screen" mode: below a portrait ~900px breakpoint, popups dock into a dedicated panel above the scene instead of overlaying it, so nothing on a phone gets covered by its own popup.

Proudest of: the whole scene renders with zero images and zero SVG, and it still holds up scaled from a phone to a wide desktop.

What's next: probably more regional toppings, and maybe sound — though that'll be the tricky part to pull off using only CSS 😄

License: MIT

Huge thanks to the DEV community and to dev.to for such an inspiring challenge — building this in just one weekend and having it come together made me genuinely happy.

I've also been having a blast scrolling through everyone else's submissions.