Manish Sharma / Independent security research
I’m a security researcher with a background in exploit development. I’m building a focused firmware security practice for embedded and IoT teams.
Personal, independent work. Scope agreed before commitment.
Understand the image. Follow the evidence.
01 / Focus
I’m exploring suitable pilot engagements and research collaborations. The work below describes the intended scope of the practice; each project starts with a feasibility discussion.
Understand what a firmware image contains and which software areas deserve closer attention. Start with one product, one accessible image, and a defined question.
Potential scope: image structure, component identification, startup configuration and selected management services.
Proposed output: a technical report with evidence, coverage limitations and prioritized next steps.
Explore a bounded security question where my exploit development background fits the target and available access.
Potential scope: review of a selected component, investigation of a suspected issue, or analysis of a documented security change.
Proposed output: technical observations, supporting evidence and a clear statement of what remains unverified.
For a system already understood, compare an agreed change or revisit a previously documented finding.
Potential scope: changes to selected components or configurations, and review of a proposed fix within the original coverage.
Proposed output: a change summary or retest note. A changed version alone does not demonstrate that a security issue is resolved.
Fit comes first. Hardware testing, secure-boot validation, live exploitation, cloud services and mobile applications require their own scope. Architecture support and assessment depth are agreed after reviewing the project requirements.
02 / Working together
The proposed engagement process keeps the decision, available access and expected evidence connected from the start.
Describe the product, the concern and the release milestone. Establish whether the request fits my current capabilities.
Set the target versions, authorization, access, deliverables, handling requirements, price and schedule in writing.
Work through the agreed checks, recording observations and uncertainty. Distinguish a possible concern from a validated finding.
Walk through the report, discuss remediation options and identify the next useful check. Agree any retesting separately.
03 / The deliverable
A useful assessment connects an observation to its evidence, explains its implications, and makes the limits of the work visible.
The outline here describes the intended reporting format. The depth of each section depends on the agreed scope and the access available.
Evidence before claims. Component versions and scanner matches can guide investigation. They do not, by themselves, prove that a device is exploitable.
My background is in exploit development and low-level security research. I’m now developing a firmware security specialty, bringing that research perspective to how embedded software is packaged, configured and reviewed.
This is a solo practice. You discuss the project directly with me, and we establish a realistic scope before agreeing to delivery.
I’m interested in conversations with embedded engineering teams, product-security teams and security consultancies looking for a focused research collaborator.
I’m preparing a self-directed firmware assessment to document my approach. A completed firmware case study and sample report are not yet published here. My existing public profiles provide context for my research background.
05 / Before we talk
A specific question about one product and a manageable firmware scope. For example: understanding an accessible image’s components and startup configuration, or investigating a selected component. An initial conversation establishes feasibility before a proposal.
Some image reviews can begin offline. Hardware behavior, runtime exposure and boot-chain properties may require a suitable test device and a separate lab scope. An offline image review cannot establish every property of a deployed device.
After the scope and inputs are understood. Image accessibility, target complexity, required validation and reporting depth affect effort. Fees, delivery dates, exclusions and retest terms are agreed before paid work begins.
A technical assessment may contribute evidence to a wider compliance programme. This practice does not offer CRA certification, legal advice or a guarantee of conformity. Any requested technical evidence needs a clearly defined scope within the customer’s broader process.
Start with a non-confidential description through LinkedIn or X. Before sharing proprietary firmware, source code or sensitive findings, agree authorization, confidentiality requirements, a transfer method and data-handling terms. This page has no firmware upload facility.
I welcome discussions about bounded research or subcontract work that fits my demonstrated skills. Responsibilities, supervision where needed, customer permissions and deliverables should be explicit before the engagement begins.
06 / Start a conversation
Bring a product, a question and a target outcome. We can establish whether a focused engagement is the right next step.
Connect on LinkedInPrefer X? Connect on X.
Keep the first message non-confidential. Agree how sensitive material will be handled before sending it.