4、升级包制作实战：使用Python脚本制作全量升级包、使用bsdiff制作差分升级包、升级包的签名与校验。

各位工程师，欢迎来到升级包制作实战这一章。说实话，很多团队在OTA项目里踩的第一个大坑，就是升级包本身出了问题。不是包体结构不对，就是差分算法算出来的补丁打不上，再或者签名校验没通过，设备直接变砖。

我个人习惯把升级包制作看作整个OTA流程的“弹药生产线”。弹药质量不行，后面部署、回滚全是白忙活。今天咱们就把这条生产线上的三个核心工位——全量包制作、差分包制作、签名与校验——一个一个过一遍。

4.1 全量升级包制作：用Python脚本搞定

全量升级包，说白了就是把新版本的完整固件打个包，加上一些元数据信息。为什么不用zip直接压缩？因为设备端解压时需要知道固件的版本、目标分区、校验值，这些信息必须结构化地写在包头里。

我在项目中遇到过一种情况：某团队直接把bin文件重命名成.swu就丢给设备升级，结果设备解析包头失败，直接拒绝升级。嗯，这里要注意，升级包不是压缩包，它是有固定格式的。

一个标准的全量升级包结构通常包含：

• 包头（Header）：魔数、版本号、包体长度、校验算法标识。
• 元数据（Metadata）：目标设备型号、源版本、目标版本、分区表信息。
• 固件数据（Payload）：完整的系统镜像或文件系统镜像。
• 尾部校验（Footer）：对整个包的哈希值或签名。

下面是我常用的一个Python打包脚本核心片段。它不复杂，但很实用：

import struct
import hashlib
import os

def create_full_package(firmware_path, output_path, version, device_model):
    # 1. 读取固件
    with open(firmware_path, 'rb') as f:
        firmware_data = f.read()
    
    # 2. 计算固件哈希
    firmware_hash = hashlib.sha256(firmware_data).hexdigest()
    
    # 3. 构建元数据（JSON格式，方便扩展）
    metadata = {
        'device_model': device_model,
        'target_version': version,
        'payload_size': len(firmware_data),
        'payload_hash': firmware_hash,
        'hash_algorithm': 'sha256'
    }
    metadata_bytes = json.dumps(metadata).encode('utf-8')
    
    # 4. 构建包头（固定32字节）
    magic = b'OTAP'  # 魔数
    header_size = 32
    payload_offset = header_size + len(metadata_bytes)
    total_size = payload_offset + len(firmware_data)
    
    header = struct.pack('<4sIIII',
                        magic,
                        header_size,
                        len(metadata_bytes),
                        payload_offset,
                        total_size)
    
    # 5. 写入文件
    with open(output_path, 'wb') as out:
        out.write(header)
        out.write(metadata_bytes)
        out.write(firmware_data)
    
    print(f'[OK] 全量包生成: {output_path}')
    print(f'     大小: {total_size} 字节')
    print(f'     哈希: {firmware_hash[:16]}...')

4.2 差分升级包制作：bsdiff实战

全量包简单粗暴，但体积大。差分升级就是为了解决这个问题——只传输新旧版本之间的差异部分。差分算法里，bsdiff 是嵌入式领域用得最广的，没有之一。

bsdiff 的原理说起来也不复杂：它先找到旧文件和新文件之间的最长公共子序列，然后把新文件中新增或修改的部分提取出来，形成一个补丁文件。设备端拿到补丁后，用 bspatch 把旧文件还原成新文件。

为什么选bsdiff？

特性	bsdiff	xdelta3	hdiffpatch
差分率（压缩后）	极低（5%-15%）	较低（10%-25%）	中等（15%-30%）
内存消耗（制作端）	高（约旧文件8倍）	中等	低
打补丁速度	快	中等	快
适用场景	固件镜像	文件系统	通用

你看，bsdiff 在差分率上优势明显，但代价是制作时需要大量内存。我在项目中遇到过一个问题：一个 64MB 的旧固件，bsdiff 制作时居然吃掉了近 500MB 内存。如果你的打包服务器是低配虚拟机，可能会直接 OOM。

bsdiff 制作差分包的典型命令：

# 安装 bsdiff（Ubuntu/Debian）
sudo apt-get install bsdiff

# 制作差分补丁
bsdiff old_firmware.bin new_firmware.bin upgrade.patch

# 验证补丁（设备端操作）
bspatch old_firmware.bin recovered_firmware.bin upgrade.patch

# 校验恢复后的文件是否与新版一致
sha256sum new_firmware.bin recovered_firmware.bin

4.3 升级包的签名与校验

升级包做好了，但你能保证它在传输过程中没被篡改吗？不能。OTA 升级最怕的就是中间人攻击——攻击者替换了你的升级包，设备刷了恶意固件，后果不堪设想。

签名与校验，就是给升级包加一把锁。我习惯用 ECDSA（椭圆曲线数字签名算法），因为它签名短、验签快，非常适合资源受限的嵌入式设备。

签名流程（服务端）：

1. 对升级包（或包内固件数据）计算哈希值（SHA-256）。
2. 用私钥对哈希值进行签名，生成签名数据。
3. 将签名数据附加到升级包尾部，或单独作为一个签名文件下发。

校验流程（设备端）：

1. 设备收到升级包后，先提取出固件数据和签名数据。
2. 对固件数据计算哈希值。
3. 用预置的公钥解密签名，得到原始哈希值。
4. 对比两个哈希值：一致则通过，不一致则拒绝升级。

下面是一个使用 Python 的 cryptography 库进行签名的示例：

from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.asymmetric.utils import Prehashed

def sign_package(package_path, private_key_path, signature_path):
    # 1. 加载私钥
    with open(private_key_path, 'rb') as f:
        private_key = serialization.load_pem_private_key(
            f.read(),
            password=None
        )
    
    # 2. 读取升级包并计算哈希
    with open(package_path, 'rb') as f:
        package_data = f.read()
    digest = hashes.Hash(hashes.SHA256())
    digest.update(package_data)
    package_hash = digest.finalize()
    
    # 3. 签名
    signature = private_key.sign(
        package_hash,
        ec.ECDSA(Prehashed(hashes.SHA256()))
    )
    
    # 4. 保存签名
    with open(signature_path, 'wb') as f:
        f.write(signature)
    
    print(f'[OK] 签名生成: {signature_path}')
    print(f'     签名长度: {len(signature)} 字节')

4.4 本章知识体系总览

为了让你更直观地理解这三部分的关系，我画了一张流程图：

这张图把整个流程串起来了：从新旧固件出发，经过全量打包或bsdiff差分，生成升级包，再经过ECDSA签名，最后部署到设备端进行校验。每一步都环环相扣，缺一不可。

4.5 常见问题与避坑

最后，我总结几个我在实战中踩过的坑，希望能帮你少走弯路：

• 差分补丁打不上：八成是旧固件版本不对。设备端的旧固件必须和制作差分时用的旧固件完全一致，连一个字节都不能差。
• 签名校验失败：检查公钥是否匹配。我曾经遇到过开发环境和生产环境的公钥搞混了，结果所有设备都验签失败，紧急回滚才恢复。
• 升级包体积过大：全量包可以考虑压缩（gzip/zstd），差分包如果比全量包还大，建议直接放弃差分，改用全量部署。
• 打包脚本兼容性：Python 2 和 Python 3 的 struct 打包结果可能不同。建议统一使用 Python 3.6+，并固定字节序（小端）。