企业官网建设流程全解析

简介：这是一款面向LG机型维修与调试场景的TestMode改串工具，主要解决开端口与改写参数的需求，适用于有一定手机维修基础、熟悉端口操作的进阶用户，而非零基础学习者。资源包共10个文件，压缩后约2.2MB，内部包含可执行主程序、OCX控件及其注册批处理，另有txt说明文档、cfg配置文件、doc/xls参考文档和htm结果页面，基本覆盖工具运行、参数配置、结果查看等环节。由于描述中明确未附带教程，使用者需自行掌握LG机型改串原理和操作流程，更适合维修技术人员直接调用。目前已有267人学习下载，包体小巧、结构紧凑，便于在维修场景中快速部署和查阅。

1. 为什么"LG 机型改串工具 TestMode"绕不开工程模式

搜索「LG 机型改串工具 TestMode」的人，手里多半是一台无法注册网络的老旗舰，比如 G2、G5、V20。改串在维修圈流传了多年，而所有 LG 改串教程的第一步都指向同一个入口：TestMode。但真正进到 TestMode 之后你会发现，它本身没有任何"改串"按钮——它只是一道能访问高通 DIAG 端口的工程门禁。老平台上改串成立，靠的是 IMEI 明文存在 NV/EFS 分区，而 TestMode 恰好放开了这条调试通道；新平台把身份标识移进签名保护的安全存储后，同一个入口推不动任何写入指令。下面顺着这条线索，把 TestMode 的进入方式、端口协议、写入链路和防御机制拆开讲，最后落在维修台上真正能用到的指令上。

2. 进入 LG TestMode：拨号码、DM 端口与 AT 指令门禁

2.1 Hidden Menu 与工厂测试模式的两种入口

LG 没有把 TestMode 做成一个开机阶段就能用物理按键稳定拉起的独立系统，它挂在隐藏工程菜单（Hidden Menu）后面。老一代 G2/G3/G5 系列在拨号盘输入3845#*[四位机型码]#，会进入以3845#*开头的工程菜单；G6 之后的部分机型把入口迁到了*#546368#*[四位机型码]#。机型码和型号名不是同一个数字，比如 G2(D802) 用 802，G6(H870) 用 870。号码输错或者少一位，拨号盘不会有任何反应，这是 LG 通过 USSD 掩码做的一道很基础的门禁。

进入菜单后，TestMode 相关子项通常藏在 SVC Menu 或 Port Setting/Device Test 这类目录下。不同固件版本的目录名不完全一致，有的叫 Service Menu，有的叫 Factory Test；在个别欧版固件里，它还被挪到设置里的 Engineer Mode 入口后面。常规操作顺序是：先通过拨号码进入 Hidden Menu，再在 SVC 菜单里确认 DM Port 开关打开，最后把设备插到电脑上，等待枚举出串口。

2.2 把 LG 手机切到 DM/DIAG 状态

TestMode 的 PC 侧工作流依赖高通平台的 DM（Diagnostic Monitor）端口。默认情况下，LG 手机的 USB 枚举只暴露 MTP 与 ADB，不暴露调制解调器调试口，需要到 Hidden Menu 的 Port Setting 里手动打开。

操作顺序固定为四步：

1. 拨号盘输入入口码进入 Hidden Menu，找到 Port Setting；
2. 打开 DM Port（旧固件叫 DM MODEM），关掉 Security Check 相关开关；
3. 打开 USB 调试，插线，在设备管理器里观察新出现的 COM 口；
4. 出现 "LGE Mobile USB Serial Port" 说明 DM 口已就绪，出现 "Qualcomm HSUSB QDLoader 9008" 则是掉进了紧急下载口。

第 4 步是最常见的误判点：9008 是 EDL（Emergency Download）模式，用来恢复底层固件，既不处理 AT 指令，也读不到 NV 项；TestMode 需要的是串口形式的 DM 口。大量"进不去 TestMode"的排查，最后都卡在把 9008 当成 DM 口去连。

注意：DM 口和 9008 是两个完全不同的枚举状态。连上后先在设备管理器确认设备名，再决定下一步用什么工具。

2.2.1 用设备管理器确认端口对应关系

在 Windows 上插线后，可以用 PowerShell 快速列出所有 COM 端口与硬件 ID，确认哪个口来自 LG 调制解调器：

Get-PnpDevice -Class Ports | Select-Object FriendlyName, InstanceId, Status

输出里会看到LGE Mobile USB Serial Port (COM5)这类条目；同一台机器上出现两个 COM 口时，靠枚举路径区分，不要看端口号大小。这一步能省掉后面 QPST 连错 COM 口的返工。

2.3 TestMode 下的 AT 指令回显与语义

DM 口就绪后，串口终端里最基础的验证是一组 AT 指令。LG 基带对话使用标准 3GPP 命令集加少量厂商扩展，下面是一段模拟回显：

AT OK AT+CGMR MPSS.DI.2.3.c2-00156 OK AT+CGSN 353260051234567 OK

AT+CGSN返回一长串十进制 IMEI；AT+CGMR返回基带固件版本。这两条都是只读指令，能读出 IMEI，但没有任何参数形式可以写入 IMEI。改串指令从来不走 AT 层，它走的是 QCDM 私有协议，也就是 QPST 那套工具真正操作的通道。AT 层在 TestMode 里的价值，是快速确认调制解调器活着、版本号对不对、读出来的身份码和机身标签是否一致。

常用 AT 指令见下表：

2.4 从 AT 端口到 QCDM：TestMode 的真正协议层

AT 通道之外，TestMode 的核心能力在 QCDM 层。QPST 的 Service Programming、NV Browser、Software Download 几个模块，都通过 DM 口向基带发送 QCDM 数据包。LG 没有对 QCDM 做私有加密，沿用高通默认鉴权流程，这也是当年大量维护工具能在这台机上跑通的前提。

QCDM 数据包的结构是"包头 + 长度 + 命令行 + 数据"，命令号决定操作类型，NV 读取与 NV 写入各自有独立命令号。QPST 的 NV Browser 打开后，可以直接按十进制 NV 号浏览基带参数。老高通平台的公开资料里，最常被引用的是 NV 550/551 两条：它们在高通 baseband 里以两段形式存放 IMEI。知道这个编号，和知道怎么写入是两回事，后者上面还压着 EFS 同步与鉴权，这一层在下一章展开。

3. IMEI 写入链路：TestMode 放开的 DM 口与四道安全拦截

3.1 老平台为什么能写：NV 与 EFS 的明文时代

Snapdragon 800/801 时代的 LG 机型，基带参数几乎全部落在一个文件系统化的 EFS 分区里，NV 项作为文件存在其中。改串在那个年代的实现路径是：通过 DM 口进 QPST 的 Service Programming 或 NV 编辑器，修改 NV 550/551 的数值，然后触发 EFS 同步与基带重启。能写成的前提有两个：一是 EFS 分区没有完整性校验，二是调制解调器信任来自 DM 口的写入请求。这两个前提在当年都成立，所以才有一大堆流传的改串教程，也直接解释了 TestMode 为什么被误认成一个改串工具——它只是放开了 DM 口，真正的写入动作发生在 QCDM 层。

这里要特意强调一点：即使是在老平台上，write NV 也不是无条件的。QCDM 的写入命令需要基带侧接受会话鉴权，且部分 NV 项受写保护位控制。维修圈里常说的"密码"，本质是厂商预置在调试固件里的鉴权值，正规固件一旦带上新版本就换掉了。所以老方法的时间窗口是固定的，跟固件版本严格绑定。

3.2 新平台的四层拦截：签名 firehose、Secure EFS 与 TrustZone

2016 年之后的 LG 旗舰，比如 G6、V30、G7，把身份标识的存储链整个改掉了。第一层，EFS 换成带 HMAC 完整性校验的 Secure EFS，任何绕过 QCDM 直接改分区的操作，都会在下次启动时校验失败。第二层，EDL 模式只执行带 LG 私钥签名的 firehose 镜像，公共固件包里不包含能绕过校验的写入镜像。第三层，IMEI 与型号、序列号被打包进 TrustZone 管理的安全存储区，调制解调器在启动时通过 QSEE trustlet 解析，普通权限连原始存储位置都读不到。第四层，也是容易被忽略的一层：NV 写入命令本身被基带固件加上了版本绑定，旧版工具发过来的命令格式在新固件里直接返回 unknown command。

这四层拦截的结果是，老方法在新机型上会卡在不同的失败点。DM 口写 NV 返回操作拒绝，在 EDL 里喂 firehose 报签名校验错误，想挖 trustlet 又涉及完整的漏洞利用链路。安全领域的公开研究里，新平台上披露过两三条可复现路径，随后厂商通过安全补丁逐一封堵，如今没有一条仍然适用于在售固件。工程上只需要记住判断标准：区分一台机器能不能走 NV 直写，看发布年份和基带版本就够，不用去背漏洞细节。

3.3 写入失败会留下哪些现场

改串不成功不是"没反应"这么简单。在 G5 这类半旧机型的固件上，写入 NV 失败后，调制解调器会进入降级状态，现象是 AT+CGSN 返回空串、系统设置里"状态信息"显示 IMEI 未知、驻网完全失败。更麻烦的是 Secure EFS 的 HMAC 校验拉高——如果写入过程中 EFS 同步被打断，手机可能连基带都拉不起来，开机停在工厂测试界面或反复重启。

判断一台机器是不是被折腾过，维修台上一般看三个痕迹：

adb shell getprop | grep -i imei adb shell getprop | grep -i persist.radio adb shell dumpsys telephony.registry | grep -i mState

第一行看属性层是否有 IMEI 残留，第二行看调制解调器持久化参数是否被改动，第三行看注册状态机。三条命令组合起来，能快速区分"固件级失败"和"参数级失败"，比直接刷全量包省时间。常见失败现场如下表：

3.4 厂商与运营商侧的设备保护机制

即使写入动作在技术上成功，身份码还要过两道外部关卡。运营商设备注册系统会比对 IMEI 与 SIM 卡开通资料，不一致时，数据业务会被直接限速或拒绝；厂商侧安全框架会在 OTA 检查里核对型号、序列号与 IMEI 的对应关系，任何一组不匹配都会让系统升级中断。换句话说，即便把 TestMode 的入口完整打开，这条链路也并不是"写入即生效"。多数的所谓"改完没信号"，问题都出在这两道外部关卡，而不是写入动作本身。

4. TestMode 在维修与射频校准里的实际用法

4.1 用 EFS 镜像备份守住 NV 数据

TestMode 放开的 DM 口，对维修最有价值的能力是备份。LG 的 EFS 分区保存着射频校准、蓝牙地址、MAC 等参数，这些数据一旦损坏，换基带芯片和刷全量固件都救不回来。所以真正进 TestMode 的第一件事，往往是先做 EFS 镜像备份，而不是读 NV。

对能解锁 BL 的机器，备份可以直接在 adb shell 里做：

adb root adb shell "ls -l /dev/block/platform/*/by-name/" adb shell "dd if=/dev/block/mmcblk0p21 of=/sdcard/efs_backup.img bs=4096" adb pull /sdcard/efs_backup.img ./

第一条命令确认分区表，第二条里的mmcblk0p21是部分 G 系列机型上 EFS 落位的常见编号，实际操作必须以第一条命令输出的 by-name 链接为准，不同机型绝对不要套用同一个分区号。备份文件保存两份，一份留在手机 /sdcard 下，方便基带异常时在 Recovery 里直接 dd 回去。

对不解锁的机器，备份通道走 QPST 的 NV Browser 导出功能，但它导出的只是 NV 项，不含 EFS 里的完整文件系统。这个区别要写清楚：NV 导出只能恢复参数，不能恢复损坏的 EFS 元数据。维修单上写"已备份 EFS"时，要标注用的是镜像备份还是 NV 导出。

4.2 用 QDART 校验功放状态与射频校准

TestMode 的第二个实用场景是射频诊断。基带进入 FTM 状态后，可以用 QDART 的 RF 模块发指定频段的测试信号，判断功放是否在正常功率区间。这个过程常用于排除"信号弱、通话断续"的硬件嫌疑。

流程是：DM 口连接 → QDART 里选择对应平台（比如 MSM8996）→ RF 测试界面填频段与信道 → 读回 TX Power 与 RSSI。测试值明显低于带内公称值，且所有频段一致偏低时，问题多半在 PA 供电；只在一个频段偏低，优先怀疑声表滤波器和天线匹配网络。这些判断不依赖改串，但充分利用了 TestMode 放开的底层射频通道，是同样入口下真正的工程价值。

4.3 用系统属性核对网络注册状态

拿到一台可能被折腾过的机器，先用系统属性快速体检：

adb shell getprop | grep -iE "gsm|imei|nv|telephony" adb shell dumpsys telephony.registry | grep -iE "mState|mImei"

第一行里的gsm.version.baseband能看到基带版本，persist.radio.*能看到调制解调器持久化参数；第二行看注册状态机，mState停在 IDLE 而不是 IN_SERVICE 时，说明网络侧没有接受这台设备。两条命令组合，能在不拆机的情况下判断问题属于调制解调器固件、射频链路还是身份信息，比盲目刷机省时间得多。

5. 用 AT+CGSN 与属性对比验证 TestMode 操作结果

5.1 三层验证法

操作完任何涉及 NV 的测试后，验证比操作本身更重要。验证分三层：第一层，拨号盘*#06#与AT+CGSN返回一致；第二层，系统属性里的 IMEI 相关字段与dumpsys telephony.registry的注册状态一致；第三层，备份镜像的哈希与操作前一致。

adb shell "cat /dev/block/mmcblk0p21" | md5sum md5sum efs_backup.img

跑这条命令前先确认设备当前分区与备份来源相同，得到的两个哈希逐位比对。哈希一致，说明 TestMode 会话期间没有任何物理分区变化；哈希不一致，说明 EFS 发生过写入，就需要优先排查基带固件而不是继续纠结参数。对不解锁的机器，可以用 QPST 的 NV 导出功能在操作前后各导出一份 CSV，再对两份文件做 diff，效果相同。

5.2 验证路径里最容易被跳过的两步

多数人验证时只看*#06#，这个习惯在老平台上够用，但在带 Secure EFS 的机型上不够。*#06#显示的值来自上层 HAL 的缓存，基带侧可能已经丢数据，界面上仍然能显示旧值。所以必须补上AT+CGSN直连基带这条路径，并且用插拔 SIM 卡后重新注册来确认网络侧接受度。另一个容易被跳过的动作是记录基带版本号，写入失败和固件版本强相关，维修记录里没有版本号，后续排查等于重新开始。

把*#06#、AT+CGSN、getprop、备份哈希四路结果并排贴进维修记录，是判断一台 LG 是否被碰过身份信息的最快方式，也是下次接手这台机器的人唯一能依赖的起点。

本文还有配套的精品资源，点击获取