XM530 iCSee camera: keeping stock drivers while adding local control (REA/Ghidra case study)

[Vittuu]

Sharing an owner-authorized embedded-device case study that used REA 6.8.0 + Ghidra 12.1.4 under WSL2/Ubuntu, with Codex assistance.

The goal was local Home Assistant control of an XM530V200 / IPG-X2-WQ-BL iCSee camera while keeping its working stock Wi-Fi, sensor, PTZ, audio, LEDs and SD recorder. We chose additions to the stock firmware rather than claiming complete OpenIPC hardware support.

Where REA/Ghidra helped: searching native Sofia command strings, following xrefs into the relevant dispatcher/handlers, and retaining selected analysis/snapshot/Evidence artifacts. Examples included OPWhiteLightControl (string 0x430027; dispatcher FUN_0018ca20 in this exact binary), OPPTZControl, and distinct white-light/day-night capability paths. These locations are binary-specific and not portable patch offsets. The scoped Ghidra readiness diagnostic passed; missing Hopper was irrelevant to this workflow.

What required separate validation: authenticated DVRIP responses/readbacks and physical checks. Both PTZ axes, white LEDs, video, microphone capture and speaker beeps were checked; static capability strings alone were not treated as hardware proof. Later work added a small C panel/API and key-only SSH, with internal boot and native WFS SD recording verified across independent restarts. A server-side H.264/Opus WebRTC viewing stream leaves the original H.265 SD recording unchanged. Exact latency improvement was not measured.

• REA/Ghidra workflow and evidence scope: https://github.com/Vittuu/icsee-localmod/blob/main/docs/REA-GHIDRA-WORKFLOW.md
• Source, tests, HA examples and limitations: https://github.com/Vittuu/icsee-localmod

This is not OpenIPC, not a full DVRIP specification and not a universal flashable image. Original additions are MIT; upstream ICSee PTZ/go2rtc/Dropbear/library work is credited. No proprietary firmware dumps, decompilation excerpts, device keys/passwords, Wi-Fi/account databases or private camera images are published. The route-removal guard is not a firewall. One hardware unit was tested; compatibility with others is unverified.

Development and writing were AI-assisted; the device owner checked the physical observations. The most useful lesson here was to keep static analysis, emulated protocol tests and real hardware/boot/recording evidence separate, and avoid promoting one into proof of the others.