DarkCov works at the edge of what's known. Most firms cover the obvious ground. We start where they stop. Our engagements are confidential, our approach is hands-on, and the work we do exists in spaces that don't get written about publicly._
We don't have a service menu. We have capability, and we apply it to whatever the problem actually is. The work spans multiple domains and branches simultaneously. Scope is defined by the problem, not by a package tier.
This is the core of what we do. Original research across technical domains, building tools, finding things, and turning findings into something that matters in the real world.
We find what others assume doesn't exist. The approach is adversarial, thorough, and researcher-driven. We cover the surface area most teams never get to.
For organizations that need real answers, not reports that sit on a shelf. We work with decision-makers directly to build defenses that actually reflect the threat landscape.
We map real adversaries to real systems. Attack surfaces, threat vectors, risk prioritization, grounded in current intelligence rather than generic frameworks.
Manual review. Researcher-driven. We go into the places automated tools skip over, and we come back with exploit chains, root cause, and clear remediation.
Some of the most meaningful work we've done can't be named here. That's not a limitation, that's the point. Discretion isn't a setting we turn on, it's the default state.
DarkCov wasn't built by founders who decided to start a security company. It was built by researchers who were already deep in the work. Jabr and Meshaal had results before they had a name. The firm is infrastructure for the research, not the other way around.
CVEs filed, vulnerabilities disclosed to major organizations, tooling built and released, talks given at premier security conferences. We had a track record before we had a presence. We didn't start talking until there was something real to say.
Most firms pick a lane. We naturally span multiple simultaneously, offense and defense, binary and web, hardware and software, research and deployment. That's not a positioning statement, it's just how both of us ended up working.
Confidentiality isn't a policy added on top of how we work. It's embedded in it. Clients engage with us knowing their exposure is zero. We don't reference past work. We don't need to. The people who matter already know.
We're drawn to the problems that are hard enough to be worth solving. Low-level systems, memory internals, cryptographic analysis, adversarial research across domains. We're comfortable in environments where most teams need a map just to get started.
Small team, intentionally. You talk directly to the people doing the work because they're the same ones who scoped the engagement. No account managers, no translation layer, no dilution. Just the research.
I got into vulnerability research early. By 15 I had 7+ CVEs published and had
reported 10+ critical vulnerabilities in real organizations. At 16 I presented
original exploitation techniques at Black Hat MEA, which was honestly surreal
but also just the next step from the work I was already doing.
My focus is Reverse Engineering, Vulnerability Research, and Exploit Development.
I built Jinzear to deobfuscate Lua bytecode in MiWiFi firmware because I needed it
and it didn't exist. I've run fuzzing campaigns against engines and protocols
that uncovered memory corruption bugs, several of which I can't publish yet for
obvious reasons.
DarkCov exists because the research reached a point where it needed structure
around it. So I built that too.
I started in web security, went through Hack The Box, picked up eWPTX and CWES,
spent a while deep in CTFs and placed first in a national competition in Bahrain.
That was fun, but it eventually pointed me toward what I actually wanted to work on:
binary security.
Now most of my time goes into fuzzing and manual source auditing of C/C++ codebases,
finding memory corruption bugs in real software. I've disclosed vulnerabilities to
GIMP and Git, contributed findings to the Linux kernel, and built Wendigo, an
open-source crash triage tool for automated exploitability analysis.
I also care a lot about math, which I think shows in how I approach research.
I'm still learning, still pushing into harder problems. That part doesn't really stop.
I came up through web security and never left. My focus is web application exploitation
hunting logic bugs, bypassing filters, and chaining vulnerabilities for real impact. No
scanners, no automation crutches. Everything I find comes from reading source and
understanding how systems actually behave. That approach has led to 6 CVEs so far, all
from manual analysis.
A lot of my time goes into Chromium's source code tracing cross-origin oracle behaviors,
cache partitioning mechanics, and frame lifecycle internals — then turning that research
into technical write-ups that go deeper than surface-level explanations. On the server
side, I read through the source of well-known open-source web projects, mapping how they
work under the hood to find where things break.
In CTFs I compete across web exploitation, reverse engineering, and browser exploitation.
The browser is where most of my research lives. It's the attack surface everyone uses
but few people actually understand.
██████████████████████████████████████
██████████████████████████████████████
██████████████████████████████████████
If you know, you know. If you don't, you weren't supposed to.
If the problem is sensitive, technically deep, or just unsolved, reach out. First contact is confidential. So is everything after it.
Initiate contact