DEV Community: Paras

You Just Got Handed a Mystery Binary. Now What?

Paras — Tue, 03 Nov 2026 07:09:29 +0000

Someone drops a file in your lap. No source code, no docs, no idea what it does. Maybe it's a CTF challenge. Maybe it's a suspicious attachment. Maybe it's a dependency you don't quite trust.

So you start the usual ritual: strings here, xxd there, objdump for the imports, another tool for the headers, a different one for the hash. Five tools, five outputs, and you're still stitching the story together by hand.

That's the exact friction hexlens was built to kill.

The problem hiding in plain sight

Binaries don't explain themselves. Every question you ask needs a different tool:

What kind of file is this? — PE, ELF, Mach-O, DEX, .NET — each with its own parser
What does it import? — and does its imphash match known malware?
What's inside? — strings, sections, headers, all scattered across outputs

For CTF players, malware triage, and forensics work, that tool-hopping is the slowest part of the job. The analysis isn't hard — getting to it is.

What hexlens does

hexlens is an open-source binary intelligence and reverse engineering framework that puts the answers in one place. Point it at a binary and get the intelligence that matters:

Format support across PE, ELF, Mach-O, DEX, and .NET — one tool, whatever you're handed
Import analysis and imphash — spot known-bad patterns fast, and compare binaries by behavior instead of bytes
Security and forensics focus — built for malware analysis and CTF forensics, not just hex dumps
A TUI — browse the binary interactively instead of drowning in terminal scrollback

Instead of five tools and a notebook, you get one view of what the binary is and what it does.

Get started

npm install hexlens

Then run hexlens against your binary and start with the imports and headers — that's where the story usually is.

Why I built it

Reverse engineering tooling is powerful but fragmented, and most of it assumes you already know what you're looking for. I wanted something that answers the first five questions about an unknown binary immediately, so you can spend your time on the actual analysis instead of the setup.

hexlens is at v0.2.0 now, with 400+ total downloads on npm. It's still early — if you throw a weird binary at it and it chokes, or there's a format you need, I'd genuinely love to hear about it.

Try it, break it, and tell me what it missed. Feedback welcome.

npm: https://www.npmjs.com/package/hexlens
GitHub: https://github.com/parasraju/hexlens

Open-source binary intelligence & reverse engineering framework. npm install hexlens

Stop Catting Your .env File

Paras — Tue, 03 Nov 2026 07:06:35 +0000

We've all done it. Something's broken, someone asks "what's in your env?", and you run:

cat .env

Then you paste the output into Slack, a GitHub issue, or a screen share — and only afterwards remember that file holds your database password, your API keys, and your production tokens. Now they're in chat history forever.

That's the exact accident environmental-peek exists to prevent.

The problem hiding in plain sight

.env files are the worst-kept secrets in software. They sit in every project, they're full of credentials, and the only way to check them is to print them in full:

Debugging in public — pasting .env output into a support thread or team chat
Screen sharing — one cat .env during a call and the whole meeting has your keys
CI logs — a stray printenv in a debug step and your secrets are in the build log

You rarely need the actual values. What you actually want to know is: which keys are set, which are missing, and is anything misspelled? That's a very different question from "show me all my secrets."

What environmental-peek does

environmental-peek lets you safely inspect your .env files without leaking secrets. It shows you the structure of your environment — what keys exist and whether they're set — while keeping the sensitive values masked.

So instead of dumping credentials to check why your app can't connect, you get answers like:

DATABASE_URL — set ✓
STRIPE_SECRET_KEY — missing ✗ (there's your bug)
API_KEY — set ✓

No values on screen. No secrets in chat history. No panic after you hit send.

Get started

npm install environmental-peek

Then run envpeek in your project and check your environment the safe way.

Why I built it

Every "don't commit your .env" guide stops at the git part. Nobody talks about the dozen other ways secrets leak — the paste, the screenshot, the shared terminal. I wanted a tool that makes the safe way also the easy way, so checking your environment stops being a security incident waiting to happen.

environmental-peek is at v0.2.0 now, with 400+ total downloads on npm. It's still early — if you try it and there's a case it doesn't cover, I'd genuinely love to hear about it.

Try it, break it, and tell me what it missed. Feedback welcome.

npm: https://www.npmjs.com/package/environmental-peek
GitHub: https://github.com/parasraju/environmental-peek

Safely inspect your .env files without leaking secrets. npm install environmental-peek

Your CI/CD Pipeline Is the Easiest Way Into Your Repo (And Nobody's Checking It)

Paras — Tue, 03 Nov 2026 06:59:29 +0000

Your CI/CD Pipeline Is the Easiest Way Into Your Repo (And Nobody's Checking It)

Your code gets reviewed. Your dependencies get scanned. But your CI/CD pipeline — the thing with access to your secrets, your deployments, and your production credentials — usually gets copy-pasted from a tutorial and never looked at again.

That's the gap plumber-linter was built for.

The problem hiding in plain sight

Here's a workflow file that looks completely normal. It's also a security incident waiting to happen:

name: CI
on: [push]

permissions: write-all

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: some-random-action/setup-node@main
      - run: |
          echo "Deploying..."
          curl -H "Authorization: Bearer AKIAIOSFODNN7EXAMPLE" https://api.example.com/deploy

Three problems, zero warnings from your CI:

permissions: write-all — the workflow can do everything: push code, read secrets, modify releases. A compromised step inherits all of it.
An unpinned action (@main) — you're running whatever the maintainer pushes next, sight unseen. If that repo gets hijacked, so does your pipeline.
A hardcoded secret in a run step — it now lives in your git history forever, and anyone with repo access can read it.

Most teams find these during an incident review. plumber-linter finds them before that.

What plumber-linter does

plumber-linter scans your CI/CD pipeline configs — GitHub Actions and GitLab CI — and flags:

Hardcoded secrets in workflow files
Overly broad permissions like write-all
Unpinned third-party actions that can change under you
Missing branch protections that let unreviewed code straight into main

And instead of cryptic rule IDs, it explains each finding in plain English — what the risk actually is, and how to fix it. So even if you're not a security person, you know exactly what to change and why.

Get started

npm install plumber-linter

Point it at your pipeline configs, fix what it flags, and your next deploy is already safer than your last one.

Why I built it

Pipeline security tools exist, but they're usually heavy, noisy, or written for security teams. I wanted something a regular developer could run in a minute and actually understand the output of. No 200-page report — just the real risks, explained like a person would explain them.

plumber-linter is at v1.1.0 now, and it's already got 800+ total downloads on npm. It's still early — if you run it on your repo and it catches something embarrassing, that's the whole point, and I'd genuinely love to hear about it.

Try it, break it, and tell me what it missed. Feedback welcome.

npm: https://www.npmjs.com/package/plumber-linter
Website: https://plumber-7dv.pages.dev/
GitHub: https://github.com/parasraju/plumber/

Built for GitHub Actions / GitLab CI. npm install plumber-linter