Skip to content

ipc‐daemon

Jump to bottom
Hritik R edited this page Aug 13, 2026 · 1 revision

Notes on ipc and daemon Binaries

I compiled these notes while reverse engineering and debugging the vendor ipc and daemon executables during identity decryption and product map analysis.

Executable Binaries

I inspected two main MIPS executables extracted from the firmware rootfs:

ipc     4,662,024 bytes
daemon      8,016 bytes

Both files are ELF32 little-endian MIPS executables compiled for MIPS R3000 (MIPS32r2, o32 ABI, cpic, noreorder).

Understanding daemon

daemon is a lightweight watchdog and launcher wrapper. It does not contain product map logic or identity decryption routines.

I observed the following imported functions in daemon:

execvp
vfork
fork
waitpid
system
kill
open
ioctl
gv_log_init
gv_log_printf
gv_swdg_check
gv_swdg_rmpid

I also extracted key format strings from daemon:

Start app -> [%s]
Kill by signal=[%d]
Exit value=[%d]
Waitpid check app -> [%s] need reboot

From this layout, I confirmed how daemon operates:

  1. daemon launches @ipc as a child process.
  2. If @ipc crashes due to a signal, daemon logs Kill by signal=[...]. For example, Kill by signal=[4] indicates that @ipc suffered a SIGILL crash.
  3. If @ipc exits normally with a non-zero return code, daemon logs Exit value=[...].
  4. When daemon outputs Exit value=[-1], it means @ipc exited with return code -1, rather than an error inside daemon itself.

Understanding ipc

ipc is the main vendor application. It links the Tuya SDK, GV platform and factory logic, camera media handling, storage, networking, and helper routines in libgv_ipc.so.

I found several key imported symbols related to identity and factory parameters:

gv_decrypt_ininfo
gv_decrypt_exinfo
gv_factory_parm_get
gv_factory_mode
gv_factory_cmd_send
gv_factory_aging_test
gv_factory_info_setup
gv_factory_test_and_rm_silent_reboot_flag
gv_factory_device_info_start_broadcast
simplekv_init
simplekv_read
gv_json_rdconf
gv_json_wrconf
tuya_ipc_init_sdk
tuya_iot_init_params

I also noted key debug strings printed during startup initialization:

Dbg:Init Value.storage_path %s
Dbg:Init Value.upgrade_file_path %s
Dbg:Init Value.sd_base_path %s
Dbg:Init Value.product_key %s
Dbg:Init Value.uuid %s
Dbg:Init Value.auth_key %s
Dbg:Init Value.p2p_id %s
Dbg:Init Value.dev_sw_version %s
Dbg:Init Value.max_p2p_user %u

From the boot log of the original camera hardware, I was able find the real provisioning values.

Identity Decryption Dependency

ipc does not perform low-level hardware reads on /dev/i2c-1 directly. Instead, it imports gv_decrypt_ininfo and gv_decrypt_exinfo from libgv_ipc.so.

libgv_ipc.so reads /dev/i2c-1, loads libgv_device_id_decryption.so, calls gv_decode_id_decrypt_buffer, and parses the decrypted identity payload. The initial boot failure message [E][decrypt]Read and decrypt failed! retry times: 1 originates inside libgv_ipc.so.

Product Map Validation Logic

After identity decryption succeeds, ipc proceeds to product map validation. If validation fails, ipc prints:

factory profuct map not support
daemon Exit value=[-1]

By disassembling ipc, I located the function responsible for this check: gv_quick_factory_param_update at virtual address 0x00437378 (1,888 bytes).

This function calls gv_decrypt_ininfo, gv_decrypt_exinfo, gv_factory_parm_get, and strcmp. It inspects the memory at gv_decrypt_exinfo() + 4 and compares it directly against a table of supported product map strings.

Supported Product Map Identifiers

I extracted the 14 supported product map identifiers from .rodata inside ipc:

  1. qhjgaxmugu7yekm8
  2. w9trdd1kvf1f44vb
  3. 2u9qofq7hcl10hyg
  4. r6eugmx7f1gzeysw
  5. gomab8hmgbbgzfj0
  6. theukamgdf0mn3sw
  7. omauiwilykbajyks
  8. a7m2iyqenzgspyiw
  9. rge8zmpws26uszva
  10. pj5vh4ar7yjikuoc
  11. zs0tx1fjtbgoaiqa
  12. wqicvudkl16w12nz
  13. agmptiiac9lm07ar
  14. qvgnsde04d88gpbx

I noticed that the real Tuya product key from the boot log is not in this list.

Useful Addresses and Offsets

Here are key ELF addresses I noted during disassembly:

.text section virtual address:   0x0042b6e0
.rodata section virtual address: 0x0075c5d0

gv_quick_factory_param_update:   0x00437378

gv_decrypt_ininfo symbol:         0x0075c2d0
gv_decrypt_exinfo symbol:         0x0075be60
gv_factory_parm_get symbol:       0x0075bd50

Summary of Findings

I concluded that daemon is purely a supervisor process reporting whether ipc died by a signal or exited with a code. ipc performs product map validation by checking gv_decrypt_exinfo() + 4 against its internal table of supported product map IDs.

Because the factory product map table does not contain the Tuya product key, the identity data must supply both the GV factory product map ID expected by ipc and the Tuya credentials expected later by the Tuya SDK.

Clone this wiki locally