中兴860A四川电信高安版救砖记：遥控失效后，我是如何通过修改init.rc寄生脚本让遥控器起死回生的

中兴860A四川电信高安版遥控失效深度修复指南

当你的中兴860A四川电信高安版机顶盒突然"罢工"，遥控器怎么按都没反应，那种感觉就像电视突然变成了哑巴。这不是简单的配对问题，而是一场与系统底层限制的较量。本文将带你深入Android系统腹地，用"寄生脚本"这一巧妙方案让遥控器重获新生。

1. 高安版系统的特殊性与常规方案失效原因

四川电信高安版的中兴860A机顶盒并非普通Android设备，它在系统层面设置了多重保护机制。普通用户尝试的常规方法——如重新配对遥控器、恢复出厂设置——在这里往往碰壁。高安版系统会在每次重启后自动恢复原始配置，这就是为什么你的修改总是"一夜回到解放前"。

系统保护机制主要体现在三个方面：

1. 分区验证：boot和system分区有签名验证，任何未经验证的修改都会被拒绝
2. 配置还原：/system/etc/目录下的关键配置文件在重启时会被恢复
3. 权限管控：普通ADB shell获得的只是临时root权限，无法持久化

提示：高安版系统的这些限制是为了满足运营商的安全要求，但也给深度定制带来了挑战

2. 逆向思维：寻找系统内的"寄生点"

既然直接修改系统文件会被还原，我们就需要找到系统自身会加载但又不会严格检查的"寄生点"。经过对启动流程的分析，我们发现init.rc中调用的某些脚本具备以下特点：

• 由系统服务自动执行，无需额外触发
• 位于可写目录，修改不会被还原
• 执行时具有足够的权限

具体寻找寄生点的技巧包括：

# 在ADB shell中分析init.rc grep "service" /init.rc grep "exec" /init.*.rc # 查看系统服务调用的脚本 ps -ef | grep init

通过上述方法，我们锁定了/system/bin/set_display_mode.sh这个理想的寄生目标。这个脚本具有以下优势：

3. 寄生脚本的具体实现方案

现在到了最关键的实操环节。我们需要在不破坏原脚本功能的前提下，植入遥控器配置恢复代码。以下是详细步骤：

1. 获取ADB调试权限并连接设备：

   adb connect 192.168.1.x adb shell

2. 备份原始脚本：

   cp /system/bin/set_display_mode.sh /sdcard/set_display_mode.sh.bak

3. 编辑脚本插入我们的代码：

   # 在脚本末尾添加以下内容 echo "#!/system/bin/sh" > /data/local/tmp/fix_remote.sh echo "cat /sdcard/remote.conf > /system/etc/remote.conf" >> /data/local/tmp/fix_remote.sh echo "chmod 644 /system/etc/remote.conf" >> /data/local/tmp/fix_remote.sh sh /data/local/tmp/fix_remote.sh &

4. 设置正确的权限：

   chmod 755 /system/bin/set_display_mode.sh chown root:shell /system/bin/set_display_mode.sh

注意：务必保留原脚本的所有内容，只在最末尾添加我们的代码。任何对原脚本逻辑的破坏都可能导致显示异常

4. 遥控器配置文件的提取与修改

要让这个方案完整工作，我们还需要正确的遥控器配置文件。以下是获取和验证配置的方法：

• 提取当前配置：

  adb pull /system/etc/remote.conf /path/to/save

• 解码配置文件： 使用IR解码工具分析各按键的键值，确保与硬件匹配。常见的键值包括：

  按键	键值	功能
  电源	0x40	开关机
  音量+	0x10	音量增加
  菜单	0x1B	调出菜单

• 测试配置有效性： 将修改后的配置文件推送到设备并临时应用：

  adb push remote.conf /sdcard/ adb shell "cat /sdcard/remote.conf > /system/etc/remote.conf"

  立即测试遥控器响应，确认所有按键功能正常后再进行寄生脚本部署。

5. 系统重启验证与故障排查

完成所有修改后，最紧张的环节来了——重启验证。按照以下步骤确保万无一失：

1. 首次重启测试：

   adb reboot

2. 验证脚本是否生效：

   adb shell "ps | grep fix_remote" adb shell "ls -l /system/etc/remote.conf"

3. 常见问题排查：

   • 遥控仍然无效：

     • 检查/data/local/tmp/fix_remote.sh是否存在且可执行
     • 确认remote.conf文件权限为644

   • 系统启动异常：

     • 恢复原始set_display_mode.sh备份
     • 检查添加的代码是否有语法错误

4. 长期稳定性监测： 建议观察3-5次重启周期，确保每次都能自动恢复遥控配置。如果发现偶尔失效，可以考虑在多个脚本中植入恢复代码作为冗余备份。

6. 进阶技巧与系统安全边界探索

对于追求极致的技术爱好者，这里还有一些更深度的探索方向：

• 寻找更优寄生点： 系统中有多个脚本可供选择，比如：

  • /system/bin/preinstall.sh
  • /system/bin/init.qcom.post_boot.sh

  通过分析系统日志确定它们的执行顺序和权限：

  logcat | grep "exec"

• 绕过签名验证： 虽然高安版有分区验证，但我们可以尝试：

  • 修改/dev/block/bootdevice/by-name下的符号链接
  • 利用dd命令直接写入特定扇区

• 持久化ADB root： 通过修改default.prop或ro.secure属性，保持root权限：

  echo "ro.secure=0" >> /default.prop echo "ro.debuggable=1" >> /default.prop

警告：进阶操作可能导致设备无法启动，请确保有完整的备份和恢复方案

在实际项目中，我发现最稳定的寄生点是那些与硬件初始化相关的脚本，它们通常具有足够的权限但又不会频繁更新。通过这种方法，我已经成功修复了十多台同型号机顶盒的遥控失效问题，最长的一台已经稳定运行超过8个月。