Camera Hacking

Turn a requested camera capability into a source-grounded investigation, controlled implementation, and verified result. Start with the desired photographic outcome, not a firmware download. The references are dated discovery evidence, not a list of universally supported hacks. Refresh relevant upstream evidence before acting.

Scope and authorization

Support discovery, offline firmware/source analysis, patch development, build and emulator work, protocol interoperability, and explicitly authorized camera-side experiments. Name which stage the user requested. Do not stop at research when the user authorized implementation; continue through the requested deliverable.

This workflow can change external state: camera settings, calibration, boot flags, firmware, network services, cards, or physical hardware.

Confirm the target, scope, and rollback path before acting. Read-only discovery may proceed without confirmation.

Use authorization already established in the session; ask only for missing scope. A request to research a public skill does not authorize changing a personal camera. Destructive operations require an explicit directive. A reversible card loader may still change persistent camera state. Do not run an unknown tool merely to query a camera: first establish whether the command writes state or enables services.

Workflow

1. Define the outcome and deliverable. Record the feature, execution location, required shooting mode, image/output requirements, and requested stage. For a public survey, keep multiple manufacturers/models; do not require a personal camera choice. For a device operation, resolve the exact body, regional suffix, firmware and image hash when available, board revision if material, existing modifications, accessories, host platform, and ownership/authorization.
2. Find the narrowest evidence. Load the matching manufacturer reference and model/family record below. Check official capabilities and SDKs, then original project documentation, source, release artifacts and negative reports. Record URL, date, commit/release, exact tested identity and evidence level. If a brand is absent, use the evidence method and document the new model; absence is not proof that it cannot be modified.
3. Classify the mechanism. Use mechanisms and compatibility to distinguish official control, reverse-engineered protocols, host processing, RAM execution, persistent settings/calibration, firmware replacement and hardware changes. An external phone waveform is not an in-camera waveform. Shared sensor, processor, retail branding or similar firmware number does not establish support.
4. Make a bounded feasibility decision. Use the assessment template. Compare the least invasive path meeting the actual outcome. Mark feasible under stated conditions, infeasible under those conditions, or unresolved with the next evidence needed. A model roster, raw decoder, transfer driver, source directory, successful build or checksum does not prove a working photographic feature.
5. Develop and analyze offline when requested. Preserve pristine inputs, source provenance, licenses and hashes. Work on copies. Inspect project scripts and any bundled agent instructions before executing them. Define the hypothesis, target symbols/addresses and expected differences; produce a reviewable patch and build receipt rather than inventing offsets. Separate container integrity, executable behavior and complete source-to-binary reproducibility. Use existing model-specific runbooks; this skill supplies no generic flasher or universal memory-write command.
6. Prepare the device experiment. Read experiments and recovery for build, installation or hardware tasks. Resolve compatibility, conflicting mods, affected persistent state, backups and failure-specific recovery before writing. If recovery is unverified, say so; do not rename it a tested rollback. Deliver any safe offline artifacts while holding the dependent device operation for the missing evidence or explicit scope decision.
7. Execute the authorized stage and verify its outcome. Follow the pinned project procedure only for the resolved target. Capture expected/observed changes, hashes, failures and restoration results using the experiment record. Test the intended lifecycle: live view, recording, file integrity, relevant lenses, restart and restoration as applicable. Stop on identity mismatch, unexpected writes, output corruption, thermal/power faults, or loss of the recovery prerequisite.
8. Deliver the requested artifact. Provide the assessment, source/patch/build, experiment record or verified device result requested. Separate what was documented, inspected, built, emulated, maintainer-reported and independently reproduced. State unresolved limitations and the next concrete evidence, without claiming a completed installation from a script exit or a menu screenshot.

Reverse-engineering and neighboring skills

Load supporting skills by name only when their work is needed. They are optional companions, not assumed files inside this installation.

If a companion is unavailable, disclose that limitation and complete the work that can be supported; do not invent a skill, CLI backend or analysis result.

Load references on demand

For a named manufacturer, load only its row, then the relevant model evidence. Inventory files linked from manufacturer records are optional source tables for roster questions. Their gPhoto, LibRaw and vendor meanings remain distinct. For a general survey, start with scope and gaps. For refreshing or adding evidence, read provenance.

Manufacturer routing

Load the matching brand only; each includes its inventory routes and known gaps.

Fujifilm X and Ricoh GR model routing

Start with all X-series identities or all digital GR identities and editions. Load the specific lineage/body below only when it matches the task. Captured versions and project status are dated observations; resolve the current exact target before use.

Other detailed project/model records

Use these for the named model or mechanism; do not transfer their compatibility to other bodies in the manufacturer inventory.

Completion and stopping conditions

Complete when the requested deliverable exists and its evidence level, target and limits are explicit. A research request ends with a usable assessment/source record; a development request requires the requested reviewable implementation and applicable checks; a device request requires observations of the requested behavior and the current/restored state, or a precise unresolved prerequisite. Do not substitute references for an authorized implementation or a build for hardware verification. Stop dependent device work at a compatibility, authorization or recovery boundary while preserving safe completed artifacts. After three non-converging diagnostic passes, report the evidence and next decision instead of repeating writes.

When not to use

For routine vendor firmware maintenance, follow the vendor's exact update documentation. For media editing/conversion, use ffmpeg; for general photographic technique, answer that task directly. This skill does not authorize access to someone else's camera, covert capture, capture-indicator suppression, or incidental persistent debug exposure. Surveillance/industrial/phone platforms need a separately scoped investigation; do not pretend the photographic manufacturer inventory covers them.