企业官网建设流程全解析

玩MTK手机刷机的朋友，对这几个词一定不陌生：BROM、DA、scatter、PGPT。很多人拿SP Flash Tool刷机时，第一步就是选一个scatter引导文件，否则工具连设备都识别不了。而当你手里只有一台分区表损坏的砖机时，能救它的，往往就剩一份完整备份的PGPT和一台能跑Python的电脑。

这篇文章我想把整个流程完整写出来，从获取MTK设备上的PGPT原始数据开始，到用Python解析分区表结构，再到自动生成可被SP Flash Tool识别的线刷引导文件。不是那种只给你一段模糊思路的科普文，而是你照着操作就能出结果、遇到报错也能自己排查的保姆级实战记录。适用于手机维修从业者、ROM定制爱好者，也包括单纯想学会Python二进制文件解析的新手，只要有耐心，都能跟完这一整条链路。

全文没用什么高深理论，核心就一个思路：GPT分区表是固定格式的二进制数据，Python能把这段二进制翻译成人话，再反过来生成刷机工具需要的文本配置。

1. 为什么MTK刷机要先搞定PGPT分区表

很多人第一次看到“PGPT”这三个字母都是一脸懵。其实它就是把GPT分区表原封不动存成一个分区，名字就叫pgpt。MTK平台的存储设备（eMMC或UFS）在出厂时被划分为几十个区域，每个区域的起始地址、大小、用途都记录在分区表里。对于刷机来说，线刷工具需要知道“哪个分区对应哪个镜像文件”“这个分区的物理地址是多少”，这些信息不会凭空出现，都要靠scatter文件提供，而scatter文件的源头就在PGPT里。

1.1 GPT结构：手机存储里的目录和书签

可以把整块手机存储想象成一本厚厚的书，书的目录就是GPT分区表。数据是正文，正文可以重新写，但目录如果丢了、乱了，整本书就再也翻不明白了。GPT分区表在磁盘上有两份，一份叫Primary GPT（主分区表，也就是我们说的PGPT），一份叫Secondary GPT（备份分区表，简称SGPT），两份互为保险。MTK平台把PGPT单独做成了一个分区，分区名就叫pgpt，后面紧跟着sgpt。这也是为什么MTK设备的scatter文件里总能看到这两个分区名的原因。

从存储的最开头数起，第0号逻辑块（LBA0）放的是保护性MBR，第1号逻辑块（LBA1）是GPT头，里面记录着“分区表区域的起始位置”“分区条目个数”“CRC32校验值”等关键信息。从LBA2开始，就是真正的分区条目数组，每一条128字节，记录一个分区的名称、起始逻辑块地址、结束逻辑块地址、类型GUID。MTK设备通常有几十个分区，所以分区条目数组会连续占用好多个逻辑块。

1.2 什么时候需要备份和重建PGPT

备份PGPT这件事，很多人觉得多此一举，直到变砖了才后悔。我刚入行的时候也一样，拿到一台MT6765的设备，手贱点了“Format All”，格式化过程走一半断电了，再开机直接黑屏，连SP Flash Tool都提示找不到设备。后来折腾了快两天，才意识到是因为分区表被清掉，线刷工具连怎么划分存储都不知道了，自然也就识别不了设备。

需要做PGPT备份和scatter生成的场景其实很明确：

• 救砖：设备分区表被破坏，或者被低格工具搞乱了，需要靠完整的分区表数据恢复存储布局。
• 定制ROM：要在原厂分区基础上调整大小、增加新分区，或者替换系统分区，就必须先搞清楚现有分区表长什么样。
• 备份固件：在给客户设备做维修前，先备份一份完整分区表，万一操作失误还能退回原状。
• 缺少scatter的刷机包：手里只有一个线刷包但没带scatter文件，或者scatter文件与设备不匹配，这时候就需要自己从设备里读出分区表再生成一个。

为什么这里非要用Python？因为手工用十六进制编辑器去翻二进制，遇到几十个分区根本翻不过来。我以前用HxD逐个对照偏移量，光解析一个分区表就花了半小时，中间还容易看错字节偏移。用Python脚本，一次解析，几十个分区两秒钟全部打印出来，还能直接生成scatter文件，这才是能长期用的方案。

2. 准备工作：先拿到设备上的PGPT原始数据

要解析PGPT，第一步得先把这份二进制数据从手机里“掏”出来。这一步卡住了很多人，因为不同的设备进刷机模式的方式不同，工具版本也五花八门。我建议把几种主流方式都学会，哪个能用就用哪个，毕竟在实际维修现场，手段越多越好。

2.1 环境准备：Windows加Python的最小配置

后面所有脚本都基于Python 3，建议装Python 3.8以上版本。安装的时候有个容易忽略的点：在安装向导第一步一定要勾选“Add Python to PATH”，否则后面在cmd里敲python会提示找不到命令。如果你已经装过了但没勾选，也可以手动把Python安装目录和Scripts目录加到环境变量里，网上相关教程很多，这里不展开。

装好之后打开命令提示符，敲一下python --version，能打印出版本号就说明环境没问题。然后顺手把后面要用的mtkclient装上，这个工具是用Python写的MTK刷机辅助程序，后面会用到：

pip install mtkclient

Python环境够用即可，不需要装什么重量级IDE。VS Code加Python插件就很好用，能直接运行脚本，也能看报错信息。要是你只是想把脚本拿来直接用，连编辑器都可以省了，把代码保存成.py文件，命令行运行就行。

2.2 让手机进BROM模式

MTK设备刷机依赖“BROM模式”，这是芯片BootROM里的一个底层下载模式。手机断电之后，插入USB数据线，系统会自动进入这个模式，这时电脑端的设备管理器里能看到一个“MediaTek USB Port”之类的COM口设备。

不同机型的触发方式有差别，最常见的是关机之后按住“音量上”或“音量下”键不松手，再插入数据线。我自己接触过的机器，红米的MTK机型一般按音量下，部分老MT6589的机器要按音量上，还有些平板设备需要短接主板上标好的测试点才能进BROM。实在试不出来的话，可以试试“闹钟法”：在正常开机的系统里设置一个一分钟后的闹钟，让它自动重启进BROM，这个方法对某些老机型很管用。

进模式之后不要急着进行下一步，先到设备管理器里确认驱动有没有装好。win10和win11系统大部分情况能免驱识别，要是看到带黄色感叹号的设备，就手动装一下MTK USB VCOM驱动，否则后面工具连接会报错。

2.3 方法A：用SP Flash Tool导出一份PGPT

SP Flash Tool是MTK官方线刷工具，大家常叫它“一线工具”。除了刷机，它的Read Back功能也能用来读设备数据。打开工具后，先加载Download Agent，也就是DA文件。DA文件一般在官方刷机包里能找到，后缀是bin，在刷机包的DA文件夹里。

切到Read Back页签，点“Add”添加一个读取任务。这里的关键是地址和长度两个参数：起始地址填0x0，长度我习惯填0x4000，也就是从存储最开头连续读16KB。这个长度已经覆盖了GPT头加分区条目数组，再往后还包含了备份分区表的一部分，足够后续解析用了。

设备进入BROM模式并连接电脑后，点击Read Back按钮，工具会列出可用COM口，选对端口开始读取。等进度条走到100%，保存成PGPT.bin，一份原始的PGPT数据就到手了。实际操作中如果SP Flash Tool版本较老，Read Back页签可能会让填“起始扇区”而不是“起始地址”，原理是一样的，还是从0开始。

2.4 方法B：用mtkclient命令行读取

SP Flash Tool读分区表有个前提，需要有匹配的DA文件。要是找不到DA，或者DA版本不匹配，就会一直卡在“连接设备”这一步。这时候第二套方案就很有用了——用mtkclient从BROM层面直接读取，它不需要额外的DA文件，很多情况下比SP Flash Tool还省事。

环境准备好之后，把手机正常开机状态关掉，插好USB线进入BROM模式，然后在命令行执行：

python mtk.py r pgpt PGPT.bin

mtkclient会自动识别设备并建立连接，然后把名为pgpt的分区内容读取到本地文件。如果你的设备固件比较特殊，分区名不是标准的pgpt，也可以直接按硬件地址读取存储最开头的16KB：

python mtk.py r --lun 0 --part 0 --start 0 --length 0x4000 PGPT.bin

不同环境下mtkclient的具体参数会有细微差别，读取之前先在当前目录执行python mtk.py --help看一下帮助信息，确认一下子命令和参数格式。我自己用的时候，就遇到过旧版mtkclient不支持--lun参数的情况，换成分区名读取反而顺利。

2.5 校验备份文件的完整性

不管用哪种方式，拿到文件之后第一件事是检查数据是否完整。用十六进制编辑器打开PGPT.bin，最前面的字节应该是00 00 00 00（保护MBR），滚动到文件偏移0x200处，如果能看到45 46 49 20 50 41 52 54这几个字符，翻译过来就是“EFI PART”，说明GPT头是完整的，文件基本没问题。

如果文件开头直接裸奔着一堆混乱字节，或者GPT头区域全是FF，大概率是读取地址不对，或者设备压根没处于BROM模式。这时候别急着往下走，先回头确认读取过程有没有报错。还要检查文件大小是不是足够的，我上面建议读16KB，如果只读了一个扇区（512字节）就停了，那只有GPT头没有分区条目，后面的脚本一样跑不通。

3. 核心：用Python解析PGPT二进制数据

拿到原始数据之后，接下来就是重头戏。解析PGPT这个过程，本质上就是按照GPT规范把二进制字段翻译成人类能看懂的表格。这个规范是公开的，不针对MTK，所以搞明白一次，以后任何用GPT分区表的设备都能用同样的方法处理。

3.1 GPT分区表格式拆解：偏移量决定一切

二进制解析最怕的就是“不知道这段数据代表什么”。GPT头从文件偏移0x200开始，长度固定为92字节。我整理了一个最常用的偏移表，照着这个表就能把关键字段全部读出来：

再往下看，分区条目区域从起始LBA乘以扇区大小得到文件偏移。MTK的eMMC设备扇区大小通常是512字节，所以分区条目区域一般在文件偏移0x400处。每一条分区条目是128字节，结构也有固定规范：

理解这个结构是后面所有脚本的灵魂。其实编程工作就三件事：定位偏移、按类型解析字节、把结果格式化输出。

3.2 编写解析脚本：从二进制到分区列表

我直接给出一个可以运行的Python脚本，保存为parse_pgpt.py，用的时候把文件路径当参数传进去就行。

import struct import zlib import sys SECTOR_SIZE = 512 def parse_guid(data: bytes) -> str: g1 = struct.unpack('<I', data[0:4])[0] g2 = struct.unpack('<H', data[4:6])[0] g3 = struct.unpack('<H', data[6:8])[0] g4 = data[8:10].hex().upper() g5 = data[10:16].hex().upper() return f'{g1:08X}-{g2:04X}-{g3:04X}-{g4}-{g5}' def read_partition_name(raw: bytes) -> str: name = raw.decode('utf-16-le', errors='ignore') return name.split('\x00')[0] def parse_gpt_file(file_path: str): with open(file_path, 'rb') as f: data = f.read() gpt_offset = SECTOR_SIZE if data[gpt_offset:gpt_offset + 8] != b'EFI PART': print('[-] 未找到有效的GPT头，请确认文件是从LBA0开始读取的完整镜像。') return header = data[gpt_offset:gpt_offset + 92] if len(header) < 92: print('[-] GPT头不完整，文件长度不足。') return stored_crc = struct.unpack('<I', header[0x10:0x14])[0] calc_crc = zlib.crc32(header[:0x10] + b'\x00\x00\x00\x00' + header[0x14:]) & 0xFFFFFFFF print(f'[i] 头部CRC：存储值=0x{stored_crc:08X} 计算值=0x{calc_crc:08X}') parts_lba = struct.unpack('<Q', header[0x38:0x40])[0] num_parts = struct.unpack('<I', header[0x50:0x54])[0] part_size = struct.unpack('<I', header[0x54:0x58])[0] entries_offset = parts_lba * SECTOR_SIZE print(f'[i] 分区条目起始LBA={parts_lba}, 分区条目个数={num_parts}, 条目大小={part_size}') print('-' * 100) for i in range(num_parts): start = entries_offset + i * part_size entry = data[start:start + part_size] if len(entry) < part_size: break part_type = parse_guid(entry[0:16]) prev_lba = struct.unpack('<Q', entry[0x20:0x28])[0] last_lba = struct.unpack('<Q', entry[0x28:0x30])[0] name = read_partition_name(entry[0x38:0x80]) if name == '' and prev_lba == 0 and last_lba == 0: continue start_addr = prev_lba * SECTOR_SIZE end_addr = (last_lba + 1) * SECTOR_SIZE size_mb = (last_lba - prev_lba + 1) * SECTOR_SIZE / (1024 * 1024) print(f'{i:3d} {name:<32} start=0x{start_addr:012X} ' f'end=0x{end_addr:012X} size={size_mb:10.2f} MB {part_type}') print('-' * 100) print(f'[+] 完成，共解析到 {num_parts} 个分区条目。') if __name__ == '__main__': if len(sys.argv) < 2: print(f'用法: python {sys.argv[0]} <PGPT文件路径>') sys.exit(1) parse_gpt_file(sys.argv[1])

运行方式特别简单：

python parse_pgpt.py PGPT.bin

脚本正常运行时，会先把GPT头的CRC校验结果列出来，再按顺序打印每个分区的序号、名称、起始物理地址、结束物理地址和大小。你可以拿这个结果和官方scatter文件做对比，只要对应分区的起始地址一致，就说明解析逻辑没问题。

3.3 CRC校验失败代表什么

很多人在解析时看到“头部CRC：存储值=0xFFFFFFFF 计算值=0x12345678”这样的输出，心里就发毛，担心是不是脚本坏了。其实这恰恰是脚本在帮你发现备份数据的问题。

GPT头的CRC32字段记录的是一个校验值，计算公式是把该字段本身置零后对整个头部做CRC32。如果磁盘上的数据没有被破坏，存储值应该等于计算值，两者一致代表这92个字节没有被动过。如果不一致，说明PGPT数据本身已经损坏，或者备份的时候没有从一个完整且未被改写过的存储区域读取。

遇到CRC不一致，先别急着用这个数据生成scatter。可以尝试读取设备的SGPT备份分区，用备份分区表交叉验证。MTK平台一般把sgpt分区放在存储的后面，如果设备还能正常进系统，也可以用固件提取工具直接从系统里抠出完整的分区表文件。我之前遇到过一台设备，用户用第三方工具乱改过分区大小，导致PGPT和SGPT不一致，解析出来甚至会出现某些分区起始地址和官方版本明显对不上，这种情况就要谨慎处理。

3.4 怎么确认解析结果可信

判断解析结果对不对，有个最笨但最有效的办法：和官方线刷包里的scatter文件对比。官方刷机包里通常自带一个scatter，你用文本编辑器打开它，对照里面的linear_start_addr字段，再看脚本输出里对应分区的start地址，两者应该完全一致。

还有几个特定分区可以作为“锚点”：preloader的起始地址在多数平台上是0x0；pgpt分区通常在存储开头附近；nvram、protect1、protect2这几个特殊分区的地址在不同平台上差异很大，不用死记，只需要确认脚本输出的地址在合理的物理范围内即可。

如果上面说的锚点分区一个都找不到，打印出来的分区名也完全不是MTK平台常见的名字，那基本可以断定读错位置了。最常见的原因是文件不是从LBA0开始读取的，而是从GPT分区条目区域开始读取，或者是从某个分区的中间读的，重新用SP Flash Tool或mtkclient读出完整数据就好。

4. 从解析结果生成可用的scatter引导文件

解析PGPT只是前半程，真正让人头疼的是生成scatter。MTK的线刷工具对scatter文件格式要求非常严格，一个标点不对，工具就会提示“Format scatter file fail”，逼得很多人只能手动改官方的scatter凑合着用。手动改一两个分区还行，要是整个分区表都要重排，非得写脚本不可。

4.1 先搞清楚scatter文件的格式

不同版本的SP Flash Tool对scatter文件的支持有差异，新版本工具能兼容旧的scatter文件，反过来就不好说了。这里我以目前最常用的V5/V6格式为例，它的分区条目长这样：

platform: MT6765 storage: EMMC - partition_index: SYS0 partition_name: preloader file_name: preloader.bin is_download: true type: SV5_BL_BIN linear_start_addr: 0x0 partition_size: 0x400000 region: EMMC_BOOT_1

文件开头两行是平台信息。platform字段要填芯片型号，比如MT6765、MT6785、MT6833这些；storage字段填存储类型，eMMC设备填EMMC，UFS设备填UFS。这个信息不需要从分区表里解析，需要你根据设备硬件自己填。

每个分区条目里，partition_index从SYS0开始依次递增；partition_name是分区名，必须和擦除镜像时的分区名一致；file_name是实际要刷入的镜像文件名，一般默认和分区名相同；is_download控制SP Flash Tool刷机时是否勾选该分区，true表示勾选，false表示不勾选；type是分区类型，这个字段对刷机工具判断镜像的加载方式很重要；linear_start_addr就是我们在3.2中计算出的起始物理地址；partition_size是分区大小；region指定分区所在存储区域，EMMC平台通常有EMMC_BOOT_1、EMMC_BOOT_2和EMMC_USER三个区域。

新手最容易犯错的地方是：抄了一个网上的老模板，把type字段填得五花八门，或者漏了region字段。轻则工具提示格式错误，重则刷机能识别但刷写时把数据写到了错误的存储区域。

4.2 Python批量生成scatter：规则与模板

生成scatter其实就是在做字符串拼接，但拼接之前要先处理几条经验规则：

• 分区名是preloader的分区，type固定为SV5_BL_BIN，region固定为EMMC_BOOT_1。
• 分区名是boot1、boot2的分区，region分别对应EMMC_BOOT_1和EMMC_BOOT_2，type填EMMC_BOOT_1或EMMC_BOOT_2。
• 分区名是nvram、nvdata、protect1、protect2这种包含用户信息的分区，建议把is_download设为false，防止误刷导致IMEI丢失或WIFI地址异常。
• 其他普通用户区分区，type填NORMAL_ROM，region填EMMC_USER。
• UFS设备的region要换成UFS_LUN0、UFS_LUN1等，不同芯片对UFS LUN的分区编号不一样，最好结合官方scatter确认。

下面这个脚本可以在你的电脑上直接运行，它会读取解析脚本输出的分区列表，并自动生成scatter文件：

import struct import zlib import sys SECTOR_SIZE = 512 DEFAULT_REGION = 'EMMC_USER' SPECIAL_TYPES = { 'preloader': ('SV5_BL_BIN', 'EMMC_BOOT_1'), 'boot1': ('EMMC_BOOT_1', 'EMMC_BOOT_1'), 'boot2': ('EMMC_BOOT_2', 'EMMC_BOOT_2'), } NO_DOWNLOAD_PARTS = { 'nvram', 'nvdata', 'protect1', 'protect2', 'seccfg', 'md1img' } def parse_gpt_parts(file_path: str): with open(file_path, 'rb') as f: data = f.read() gpt_offset = SECTOR_SIZE header = data[gpt_offset:gpt_offset + 92] parts_lba = struct.unpack('<Q', header[0x38:0x40])[0] num_parts = struct.unpack('<I', header[0x50:0x54])[0] part_size = struct.unpack('<I', header[0x54:0x58])[0] entries_offset = parts_lba * SECTOR_SIZE parts = [] for i in range(num_parts): entry = data[entries_offset + i * part_size: entries_offset + (i + 1) * part_size] if len(entry) < part_size: break name_raw = entry[0x38:0x80].decode('utf-16-le', errors='ignore') name = name_raw.split('\x00')[0] start_lba = struct.unpack('<Q', entry[0x20:0x28])[0] last_lba = struct.unpack('<Q', entry[0x28:0x30])[0] if name == '' and start_lba == 0 and last_lba == 0: continue parts.append({ 'name': name, 'linear_start_addr': start_lba * SECTOR_SIZE, 'partition_size': (last_lba - start_lba + 1) * SECTOR_SIZE, }) return parts def generate_scatter(parts, platform='MT6765', storage='EMMC'): lines = [] lines.append(f'platform: {platform}') lines.append(f'storage: {storage}') lines.append('') for idx, part in enumerate(parts): name = part['name'] if name in SPECIAL_TYPES: part_type, region = SPECIAL_TYPES[name] else: part_type = 'NORMAL_ROM' region = DEFAULT_REGION is_download = 'false' if name in NO_DOWNLOAD_PARTS else 'true' lines.append(f'- partition_index: SYS{idx}') lines.append(f' partition_name: {name}') lines.append(f' file_name: {name}.bin') lines.append(f' is_download: {is_download}') lines.append(f' type: {part_type}') lines.append(f' linear_start_addr: 0x{part["linear_start_addr"]:X}') lines.append(f' partition_size: 0x{part["partition_size"]:X}') lines.append(f' region: {region}') lines.append('') return '\n'.join(lines) if __name__ == '__main__': if len(sys.argv) < 2: print(f'用法: python {sys.argv[0]} <PGPT文件路径> [platform] [storage]') sys.exit(1) pgpt_path = sys.argv[1] platform = sys.argv[2] if len(sys.argv) > 2 else input('请输入平台型号（例如MT6765）: ').strip() storage = sys.argv[3] if len(sys.argv) > 3 else input('请输入存储类型（EMMC或UFS）: ').strip() parts = parse_gpt_parts(pgpt_path) scatter = generate_scatter(parts, platform, storage) output_path = f'{platform}_auto.scatter' with open(output_path, 'w', encoding='ascii', newline='\n') as f: f.write(scatter) print(f'[+] scatter文件已生成: {output_path}') print(f'[+] 共生成 {len(parts)} 个分区条目。')

运行方式：

python gen_scatter.py PGPT.bin MT6765 EMMC

脚本会把生成的scatter文件保存为MT6765_auto.scatter。打开看一下，分区顺序和PGPT里的顺序一致，地址也都是从0x0开始的连续地址。如果某个分区类型判断得不对，比如你的设备preloader分区名字叫preloader_a而不是preloader，你可以改一下代码里的SPECIAL_TYPES字典，把实际分区名加进去。

4.3 落地验证：把生成的scatter灌进SP Flash Tool

生成scatter只是纸上谈兵，真正行不行还要让SP Flash Tool认一次。把生成的.scatter文件和对应镜像放到同一个目录下，打开工具点“Choose”，选择这个文件，工具会解析并显示出所有分区列表。

这时候可以做个快速检查：工具显示的每个分区是否按顺序排列，地址是否连续，有没有出现地址重复或者明显跳变。如果工具直接弹窗报错“Format scatter file fail”，大概率是文件里有非法字符，最常见的原因是用记事本保存时把编码改成了UTF-8带BOM，或者文件末尾多了一个不可见符号。解决方案是用VS Code或Notepad++把文件转为ASCII编码，再保存一次。

验证通过之后，建议不要一上来就全选Download。我这里有个习惯：先只勾选preloader这一个分区，执行一次Download，确认设备能被正常识别、刷写过程和地址都是对的，然后再全选执行完整线刷。这个方法能帮你把风险控制到最低，要是preloader都能正常刷进去，剩下的普通用户分区出问题的概率就很小了。

5. 实操中常见问题与排查技巧实录

写代码、生成文件、连设备，每一步都可能踩坑。我把这些年实操过程中遇到的高频问题整理成一个速查表，方便你对照处理。

5.1 问题排查速查表

5.2 几个容易踩的坑

第一，mtkclient和SP Flash Tool不能同时打开。这两个工具在连接BROM设备时会争抢同一个COM口，我见过最诡异的情况就是在SP Flash Tool还在运行的时候启动了mtkclient，然后两个工具都提示设备离线。刷机不需要同时开两套工具，先关掉另一个再连设备。

第二，地址换算一定要搞清扇区大小。eMMC存储的扇区大小一般是512字节，但UFS存储的扇区大小可能是4096字节。GPT头里的parts_lba是逻辑块号，换算成文件偏移时必须乘上正确的扇区大小。我之前给一台UFS平板生成scatter，用512去乘，结果所有地址都偏了，盯着看了半天也没发现问题来源，最后是拿官方scatter一对比才醒悟。

第三，preloader的地址不能光看GPT的起始LBA。很多MTK平台的preloader实际跑在英特尔的bootrom映射区，GPT里记录的起始LBA可能是0x0，也可能是一个特殊偏移。生成的scatter如果不被工具接受，试着查看官方scatter是怎么定义preloader的，直接照抄。

第四，从PGPT恢复分区表时，不能只把PGPT写回LBA0。GPT规范要求磁盘末尾还要有备份分区表（SGPT），许多刷机工具在下载前会先校验主备份分区表的一致性，只恢复一半很容易刷到一半又报错。安全做法是用十六进制编辑器同时把PGPT和SGPT区域都写回，这个操作要在设备能进入底层模式的前提下做，否则很可能越弄越糟。

5.3 进阶扩展：顺手做一个小工具

既然已经有了解析和生成两段脚本，稍微改改就能变成一个更顺手的小工具。我后来把两个脚本合并成了一个，每次打开时先弹出文件选择对话框，选中PGPT文件后自动解析，再弹窗让填平台型号和存储类型，一键生成scatter。整个过程不用敲命令行，给同行用也很方便。

再进一步，你还能把脚本改造成一个MTK刷机包校验工具：加载官方scatter文件，把里面每个分区的file_name和实际目录里的镜像文件做对应，检查是不是漏了镜像、镜像文件名是不是错了。这些功能本质上都是对文本和二进制做处理，Python的灵活性在这里发挥得淋漓尽致。

写在最后

我在实际维修中最大的感触是，PGPT这份数据平时看起来只是一个藏在设备深处的二进制文件，但在关键时刻，它决定了一台砖机是能复活还是彻底报废。每次拿到新设备刷机之前，我都会顺手备份一下PGPT和SGPT，几秒钟的事，却能省下后面几十个小时的折腾。

最后再分享一个小技巧：备份出来的PGPT文件，除了原始.bin文件，我还会把它压缩一份留底，同时记录文件的SHA256值。等到哪天不小心改了分区表，或者准备恢复的时候，能通过哈希值检查这份备份有没有被意外改动过。技术这行，习惯做得越细，现场翻车的概率就越低。