Reverse Engineering and Vulnerability Research

Vulnerability Research

Before you release your product, you need to know if it contains an undiscovered flaw. We start where an attacker would: the parts that accept external input. We combine code review with fuzzing. Until a fix is released, we share a flaw only with you and, if needed, the vendor.

Discuss Scope All Service Areas

Vulnerability scanners and patch management only address known flaws. From December 2027, the EU Cyber Resilience Act requires manufacturers selling in the EU to have a coordinated vulnerability disclosure policy. If you find a flaw first, you control the timing of the fix.

The need

When organizations need it

Before delivering a new product release to enterprise customers.
When a vulnerability is announced in an internet-facing device you use and you are unsure if the patch is sufficient.
When a researcher reports a flaw in your product and you do not yet have a response process.
When you need to establish a coordinated vulnerability disclosure policy and reporting channel for your product.

Questions

What this work answers

Do the parts of our product that accept external input contain an undiscovered flaw?
Does the released patch address the root cause, or only a known attack path?
What is the real impact of a flaw: service disruption, data access, or remote code execution?
How do we receive, assess, and respond to vulnerability reports from external sources?

Vulnerability Research

What we do

Product-Focused Vulnerability Research

We search for new vulnerabilities in a specific product or component. We first map its attack surface, then conduct deeper code review.
Fuzzing

We systematically feed unexpected input to code that processes files and protocols. This reveals crashes and memory errors. Fuzzing can be set up to run continuously in your CI/CD pipeline.
Root Cause and Patch Analysis

We identify the root cause of the flaw. We test if the released fix also prevents the same issue from being triggered in other ways.
Coordinated Vulnerability Disclosure

We report a vulnerability found in a third-party product to the vendor with full technical details. The publication timeline is agreed with the vendor.
Impact Validation

We demonstrate the real impact of a vulnerability in a controlled environment, within the defined scope. Priority is set based on this impact.
Vulnerability Disclosure Program Setup

We establish the process for receiving external vulnerability reports in accordance with ISO/IEC 29147 and ISO/IEC 30111. This includes a reporting contact, triage criteria, response times, and a publication policy.

Scope

Scope is defined by product version, components, and available time. As research time is limited, we prioritize parts that accept external input and run with the highest privileges.

How we work

First, we map the attack surface: every point accepting external input. While fuzzing these points, we manually review the riskiest code paths. For each bug, we determine its root cause and exploitability. We also search for the same pattern elsewhere in the code.

Deliverables

What you receive

A technical report that enables your developers or the vendor to reproduce the flaw. The report includes the root cause and a fix recommendation. After the fix is released, a retest demonstrates that the flaw and its variants are resolved.

NoteThere is no guarantee that a new vulnerability will be found or a CVE assigned. The code paths reviewed and methods used are documented in the report.