Manish
Sharma.
The independent researcher behind Kedloc’s software-focused firmware practice. Known in the security community as sh377c0d3.
I’m interested in what software actually does, how its assumptions can fail, and what the evidence tells us about its security.
My background is in exploit development and low-level security research. That is the foundation I’m bringing to Kedloc as I develop a focused firmware security practice.
My focus is the software inside supplied firmware images: its components, configuration and changes between releases. Kedloc does not offer hardware testing or complete IoT ecosystem assessments.
Kedloc gives that work a clear home. It connects my existing research identity with a focused way for engineering teams and security consultancies to discuss a project directly with me.
Background and direction
From low-level research
to a firmware focus.
Exploit development involves looking beyond an interface and investigating the behavior underneath it. I want to carry that attention to detail into firmware review: understanding the image, examining selected components and configuration, and explaining what can be established from the available access.
I have also shared security presentations and training material with the community. Making technical reasoning understandable is an important part of the work I want to do through Kedloc.
Firmware is a developing specialty within this practice. I’m building the supporting assessment workflow through self-directed work, starting with offline image analysis. A proposed engagement is evaluated against the skills, access and validation needed for that specific question.
Working together
One researcher.
A clearly defined brief.
When you contact Kedloc, you speak with me. I work independently, so it matters that the question, deliverable and scope are realistic for the engagement.
- Start with the decision.
- Understanding the decision your team faces helps define which checks would be useful and what the final report needs to explain.
- Keep conclusions traceable.
- I aim to connect each observation to its evidence and separate confirmed behavior from concerns that still need testing.
- Make the boundaries explicit.
- Access, assumptions, exclusions and untested areas belong in the scope and the report. They help you interpret the result correctly.
- Make the output usable.
- The intended deliverable combines technical detail with priorities, practical next steps and a discussion of remaining questions.
Where a conversation fits
Bring an image,
a component or a question.
I welcome conversations with firmware engineering teams, product-security teams and security consultancies that need a bounded piece of software research. A useful starting point is an accessible firmware image, a selected component within it or a clearly described firmware security question.
The first conversation establishes fit. For any project we agree to take forward, the target, authorization, available access, handling requirements, deliverables, fee and schedule are defined before paid work begins.
You do not need to send proprietary material to start that conversation. A non-confidential outline of the product, your question and your timeframe is enough to discuss the next step.
Discuss a project with me