简介：mstar-bin-tool-master正式版是一套面向嵌入式固件开发与维护场景的bin文件解包/打包工具，适用于需要处理MStar平台固件、调试启动镜像或定制系统分区的工程师。压缩包共44个文件，总大小约29.12MB，以16个ini配置、5个Python脚本、6个exe辅助程序及说明文档为主，另有bat批处理入口和密钥示例文件。ini配置覆盖多款电视/盒子机型，Python脚本实现密钥提取、分区打包与解包，exe中包含Python 3.6.3安装包，便于零基础环境快速搭建。通过运行批处理脚本，即可对AES/RSA加密的固件镜像执行自动化解包与重新打包，减少手工输入命令的出错风险。资源内附README和MBoot介绍文档，可帮助理解整体目录与操作逻辑。目前已有6378人学习下载，适合从事嵌入式开发、固件逆向或智能电视系统定制的中高级开发者，作为开箱即用的固件处理工具箱。

1. mstar-bin-tool-master（正式版）.rar 到底能干什么：一个被反复下载却很少用对的固件修改工具

拿到名为 mstar-bin-tool-master（正式版）.rar 的压缩包，很多人解压后都会愣一下：目录里是一堆 .py 脚本、几个 Readme 和看起来像是给小家电准备的 bin 文件，完全不知道从哪里下手。mstar-bin-tool 不是某个电视厂商发布的官方工具，而是一套在开发者社区里流传了很久的 Python 脚本集合，专门用来拆解和重打包 MStar/MediaTek 电视、显示器、部分车载屏幕的主控固件。它能把官方固件里跑在启动区、内核、开机 logo、Android 系统等不同位置的二进制分区逐个剥离开，等修改后再封装回去。适合手里有 UART 转串口线、愿意承担一定风险的人，至少能让电视开机 logo 由自己说了算，或把预装应用清理出系统分区。如果你只是想找一个双击就能刷机的软件，那这个 rar 暂时帮不上你，建议先看完全文再做判断。

2. 从 rar 到可运行的 bin-tool：解压、依赖与最小环境搭建

2.1 解压“正式版.rar”并不总是一帆风顺：伪加密、中文文件名与解压软件的选择

在拿到 mstar-bin-tool-master（正式版）.rar 后，最先撞上的往往不是固件，而是那个 rar 本身。很多转载站为了让资源显得“独有”，会在打包时把文件头里的加密标记改掉，形成 RAR 伪加密。伪加密的典型特征是：你打开压缩包时看到“需要密码”，但用 WinRAR 的“测试压缩文件”功能不会报数据错误，而且文件名列表依然完整可见。真正的强加密会连文件名一起隐藏或打乱，所以只要文件名能看得见，多半可以再往下试。

我习惯先让压缩包“说实话”，用 7-Zip 打开并执行一次测试：

7z t "mstar-bin-tool-master（正式版）.rar"

测试结果全部通过，说明这个包至少没有被强改过。如果再顺手解压到新文件夹，发现里面没有mstar_info.py这类入口脚本，就不要去搜所谓的“rar密码移除”工具强行处理——你需要的不是密码，而是另一个来源的文件。很多人把时间耗在找密码上，最后发现资源本身是坏的，这才是最冤枉的。

这里有个常被忽略的细节：压缩包里的中文括号。有些系统用 UTF-8 显示文件名，另一些用 GBK，导致解压软件在读取内部路径时把字符解析错，最后报hash mismatch或cannot create directory。解决方式也很直接，把外层 rar 重命名成纯英文名再解压：

mv "mstar-bin-tool-master（正式版）.rar" mstar_tool.rar unrar x mstar_tool.rar mstar_tool/

如果你在 Windows 上习惯用图形界面，WinRAR 和 7-Zip 对伪加密的默认处理都是要密码，反而是部分能识别伪加密标记的小工具能直接列出文件。我并不推荐碰那些来路不明的“暴力破解”工具，只建议退一步，去原作者或原发布者处找分享说明；很多写“密码为工具名”的压缩包，其实是伪加密或统一密码，根本不需要逐个碰撞。解压软件的偏好在这里体现得很明显：优先 7-Zip，其次 WinRAR，其余国产压缩软件只看兼容性，不特别推荐。

2.2 最小可运行环境：Python 解释器、三个依赖库和首次自检

解压之后，要先确认这套 Python 脚本能在当前系统里跑起来。大多数 mstar-bin-tool 的脚本并不依赖复杂的系统库，但要用到三个基础模块：

• pycryptodome：用于解析固件里的摘要与签名结构；
• pyelftools：读取内核 ELF 文件的基本信息；
• construct：按声明格式解析二进制字段。

如果这些库没装，脚本会在运行中报ModuleNotFoundError，比如No module named 'Crypto'。安装命令通常用 pip，但在 Linux 上要特别注意区分 Python 2 和 Python 3 的 pip：

# 先确认解释器版本 python --version # 再安装依赖，Python 3.6 以上通常都没问题 pip install pycryptodome pyelftools construct

装完依赖后不要急着拆固件，用工具自带的信息命令做一次“烟雾测试”：

python mstar_info.py --help

如果这条命令列出了-i, --input, -o, --output, -w, --workdir等参数，说明脚本基本语法兼容当前环境。如果看到SyntaxError: invalid syntax，大概率是 Python 3 在跑旧版 Python 2 脚本；此时试试python2 mstar_info.py --help，或者在脚本头部做语法迁移。也有一些发布者在 rar 里预置了.bat一键脚本，你可以直接执行mstar_info.bat来看到同样的帮助信息。这个自检过程非常关键，它能帮你区分“工具坏”和“固件坏”两类问题，而不是把锅都甩到固件上。

2.3 为什么第一件事不是接电视，而是先跑通工具自检

很多新手拿到工具后，第一反应是把电视拆开找 UART 口，但那是最后一步。mstar-bin-tool 最重要的能力是“识别固件”，而不是让电视马上开机。你的操作顺序应该是：先找一条能用于练习的官方固件 bin 文件，然后运行：

python mstar_info.py -i firmware.bin

如果输出里能清晰读到主控型号、DDR 容量、分区数量这些信息，说明当前工具链与固件匹配，后面拆包才有意义。如果输出只有header error，先想想是不是拿错了加密包；不要用网上那些“万能拆包”的说法碰运气，那条路走下去，大概率只会烧掉编程器或者整块 flash。我自己的习惯是把这一条命令的输出结果做成笔记，作为后续所有操作的对齐基线；这种排错方式，比后面翻车再回去查要快很多。

3. 拆包一条 MStar 固件的标准流程：用 mstar-bin-tool 提取分区并替换 logo

3.1 判别固件是不是“MStar 体系”：不在文件名，在头部特征

拿到任何以.bin结尾的文件，先不要看文件名，直接看最前面的 128 字节。MStar 常见固件头会有明显的魔数片段，uImage 内核前面则会有平台字符串。如果看到的是纯随机字节且没有固定偏移，那很大概率是加密固件，很多电视新品会把整包做 AES 加密，这种直接拆不开，需要先找同型号低版本引导或绕过认证芯片。

在 Linux 下可以一行命令快速看头部：

xxd firmware.bin | head -n 8

尾部还要留意是否为填充对齐。某些原厂固件会以0x00补齐到 64KB 边界，这条信息在重新打包时非常关键，因为工具会按头部里记录的长度切割分区，多一个字节少一个字节都会影响输出。看过头部结构后再决定要不要继续拆，比盲猜文件名要有把握得多。

3.2 执行拆包：解包命令、输出目录结构与四类分区

假设你已经有一条完好的firmware.bin，比如从电视服务商整包镜像，或者从旧机顶盒里备份出来的。接下来执行拆包：

python mstar_unpack.py -i firmware.bin -w out

-w后面跟工作目录，脚本会把解包生成的临时文件写进去。执行完成后，会在out下看到类似这样的结构：

• mboot：引导区，一般几十 KB 到几百 KB；
• logo/：存放开机 logo 及开机音乐；
• kernel/：存放 Linux 内核；
• rootfs/或system/：存放 Android 系统镜像。

这个结构在不同版本之间略有差异，但思路一致：先把完整 bin 按分区表切片，再做解压或还原。比较稳的做法是拆完先记录所有分区的大小和偏移，一边看输出目录下的文本日志，一边对着十六进制分区表核对。我第一次拆电视固件时，就是因为第二次解包时多了一个来自旧固件残留的backup分区，导致后续偏移整体错位，刷机后声音与显示设置全部乱掉。所以拆包完成后，最好立即复制一份完整输出目录，不要把原目录当成临时文件夹反复写。

3.3 替换开机 logo：格式、尺寸与回包的参数

最常被问到“能不能换开机 logo”，事实上这也是最安全的一项修改，因为它不动内核也不动系统。修改前，先从拆包结果中导出原始 logo，不同电视可能用.bmp、.ras或.rgb，不要凭空造一个 PNG 就说自己要替换。常见做法是沿用原图尺寸，生成一张同宽高、32 位深的 BMP，然后重新打包：

python mstar_pack.py -w out -o new.bin --logo mylogo.bmp

这里-w out告诉脚本沿用之前拆包产生的中间文件，--logo参数将mylogo.bmp写回对应分区，-o new.bin定义新固件文件名。有一个容易踩的坑：mstar 系列对 logo 的位深有约定，推荐输出为 32 位 BMP 且像素顺序是 BGRA，而不是普通 24 位。如果拿到的是 jpg，先在本机转换成相同宽高的 32 位 bmp 再传给脚本；否则新固件能开机，屏幕上却是花屏，或者是旧 logo 与新 logo 交替闪烁。不要小看这一步，很多人在这一条上翻车，然后误以为是芯片坏了。

3.4 替换系统分区和内置应用：分区大小是底线

当你想精简电视自带的少数预装应用时，会去改动 rootfs。做法是先将拆包得到的system.img用常规挂载工具解开，删掉对应 Android 应用后重新压缩成 ext4 镜像，再把新的system.img用mstar_pack.py装回去。这里必须强调的是：修改后的镜像大小不能超过原分区。

一般情况下我不会去动分区表，只在原有分区大小范围内做文件替换；一旦超过，工具打包时会自动把后续分区偏移往下推，结果就是内核里写死的地址全部失效，黑屏只是入门表现。压缩包里的文档如果强调“保持原大小”，那不是保守，是让你避开这条血泪经验。精简应用时优先删/system/app下的 APK 和/vendor/app下的厂商应用，不要试图删framework里的核心服务，否则系统会卡在启动动画，连 logcat 都来不及抓。

4. “正式版”和 master 分支：文件的真实来源与依赖坑

4.1 为什么压缩包叫“mstar-bin-tool-master”：从 Git 仓库导出时的原始命名

下载这个 rar 后，最里面的文件夹通常就叫mstar-bin-tool-master，这本身是一个很明确的暗示：它来自 Git 仓库的 master 分支。也就是说，资源发布者直接在某个公开代码托管地址上点了“下载 ZIP”，然后打包成 rar，并没有按正式 release 的方式生成带版本号的产物。Git 上使用master命名主分支的习惯很老，现在有不少仓库改成main，但你在下载包里会同时看到 README 和目录名-master，这种状态下的代码属于“活着的代码”，不是某个被验证过的固定版本。

我在看这类工具代码时，会根据提交结构确认它属于哪一阶段：如果出现feat/xxx这类功能分支痕迹，或者文件修改日期很新，说明功能还在迭代；此时直接拿去处理生产固件，就要承担脚本行为变化带来的适配成本。这也是为什么很多人明明下载的是同一个名字的 rar，在相同条件下跑出的结果却不一样——因为来源阶段不同。

4.2 如何确认 rar 里装的版本是否适合你的固件

在没有官方发布渠道的情况下，一个比较可靠的办法，是把包里自带conf目录下的型号列表，和你手头电视主控的型号做比对。旧版工具对新芯片型号支持差，尤其近两年的 64 位 MStar 芯片可能根本不在识别列表中，报错通常会像unsupported chip id。

推荐记录一下固件的 SHA-256，在改动前先保存原始摘要：

sha256sum firmware.bin > firmware.origin.sha256

这样不管后来用哪个版本的工具拆包，发现输出差异时，都能第一时间对比源文件是否被上一次解包脚本误改。否则版本换了，源文件又被覆盖，根本说不清是工具的问题还是自己的操作问题。所谓“正式版”在这个工具生态里，我个人的判断标准很简单：能够顺利用mstar_info.py读出完整芯片型号，且解包出来的分区结构完整，那就是当前最适合你的版本，不需要盲目追新。

4.3 Python 2 与 Python 3 的兼容性是最隐蔽的坑

不少老固件工具链的脚本还带着 Python 2 的语法，比如print "..."而不带括号，或者xrange这类写法。如果你用 Python 3 直接运行，会在中途报SyntaxError，表面上看是 rar 里的工具坏了，其实是你选的解释器不对。

对这种问题的常见做法有两条：一是安装一个独立的 Python 2.7 环境，让它配合脚本；另一个是用2to3工具做自动迁移，但不保证所有依赖库都能顺滑移植。我的建议是先在mstar_info.py这类小入口脚本上测兼容，如果连它都不能通过，就干脆换 Python 2 环境。千万记住在 Windows 下同时装两个版本时，要用py -2和py -3区分，否则 PATH 顺序一变，怎么查都像工具坏了。这是一个当时让我刷了三次固件才发现的“黑匣子”级别的问题，折腾完之后你会对“版本”两个字格外敏感。

5. 固件打包改机避坑：校验、签名、分区空间三个必查点

5.1 现象：新固件刷入后电视完全黑屏——原因：分区偏移被改变——解决：保持分区大小，用原始偏移回拷

黑屏往往是打包阶段造成的。mstar_pack.py在并入一个较大的 system 分区时，可能会自动重写头部里的偏移表，但内核或 bootloader 里写死的地址不会跟着变，于是机器从引导区跳转到内核时，去了一个空洞地址。解决方法是只允许在原有分区边界内改动，新增的文件尽量用相同大小的占位文件替换；如果必须增大，先去改引导阶段的参数表，而不是依赖打包脚本自动扩容。这也是我为什么一直强调备份原始 bin——没有原始偏移表，黑屏后仅凭记忆很难手算出来。

5.2 现象：开机 logo 色彩怪异——原因：位深与像素通道顺序不匹配——解决：转换图片时强制用 32 位 BGRA

刚换完 logo 时最容易出现的翻车，就是屏幕色彩变成蓝紫色或者偏红。说穿了就是图片压缩工具的默认输出格式，不符合主控的读取顺序。要避免这个问题，在生成 BMP 时可以加一条明确的转换命令，比如用 ImageMagick：

convert mylogo.png -resize 1920x1080 -define bmp:subtype=ARGB32 -depth 32 mylogo.bmp

如果系统提示没有convert，新版本 ImageMagick 改成了magick命令，用法一致。经过这样转换的图片，再传入mstar_pack.py，绝大多数情况下就能与原厂 logo 兼容。若还是不行，去拆包目录里找原始的logo.bmp，以它的文件头做模板，只替换像素数据区，这也是一种几乎不会翻车的做法。

5.3 现象：开机停在引导校验器并报告签名错误——原因：新电视校验 Bootloader 镜像有效签名——解决：只改 logo 和系统，不碰 bootloader

现在家电主控越来越多的安全启动特性写在一级引导里。刷入一个篡改过的mboot或全盘解包过的固件，芯片会直接拒绝启动。这种问题的解决办法，不是找什么关闭校验的补丁，而是只在用户分区上动手：logo、开机音乐、系统 APK 都算用户数据侧，正常情况下不会触发预引导完整性校验；一旦动了mboot、TZ这些带签名的部分，又没有原厂私钥，基本只能靠编程器刷回全量备份。所以最稳的边界就是：能不动引导区，就不动引导区。

5.4 现象：系统能开机，但 OTA 升级一直失败——原因：固件整体 CRC 与首部校验字段对不上——解决：回刷后停用 OTA，或只改 vendor 分区

如果你期望修改固件后继续接收官方 OTA，那很可能失败。MStar 方案的 OTA 包会计算整包 CRC 和分区摘要，改过任意分区都会导致校验失败。这里没有通用的“给工具补一个校验”的简单办法，只能在修改固件后停用 OTA 升级，或者采用 A/B 分区策略，将改动只放在不被 OTA 覆盖的 vendor 分区。想靠修改版本号伪装原厂校验，通常只会触发下一次升级时更严重的错误，不值得赌。

5.5 现象：解包过程中报错“file CRC error”或闪退——原因：压缩包伪加密后被解压软件强改过——解决：先用 7-Zip 测试压缩文件再解压

这个更像是资源文件本身的问题，而不是固件问题。很多论坛搬包重复上传时，都会先改伪加密、再改文件名，导致文件受损。因此在解压任何固件工具包之前，先执行一次压缩包完整性测试：

7z t "mstar-bin-tool-master（正式版）.rar"

如果测试结果里显示有Data Error，宁可重新下载一份，也不要强行用修复模式去解压。因为你需要的是完全一致的脚本，而不是某个被修得七零八落的损坏版本；工具目录多一个字节都不代表官方版本，反而可能让后续指令跑偏。

6. 回刷前的三项验证：不烧第二遍铁的经验

6.1 用工具自己读自己：重打包后必须再走一次 info/unpack

我给自己定的习惯是，任何新生成的new.bin，都要先再跑一次mstar_info.py和mstar_unpack.py。不是为了再次修改，而是让工具自己核对新固件的头部、分区大小和 logo 数据是否可以被完整解析。

python mstar_info.py -i new.bin python mstar_unpack.py -i new.bin -w verify_out

如果新包能被完整读出与源包相同的芯片型号，说明至少在交到引导器之前，数据是完整的。这一步每次都能救我，因为很多打包错误在生成阶段看不出来，只有让工具重新读一遍才会暴露。

6.2 备份三件套：原 bin、原分区表、串口完整日志

把原始 bin 用一个独立目录锁起来；把拆包时看到的每个分区偏移记成文本；把第一次连接电视 UART 时启动全过程的日志存下来。后两者在变砖后就是“后悔药”，能帮你直接计算应该从哪个物理偏移继续救援，而不是凭空扫闪存。

6.3 守住最小写入边界

回刷工具时，我坚持能走串口 OTA 就不拆机焊接，能写 logo 就不刷系统。每次只改一块功能区并回读验证，确认稳定后再做下一项；一次改动多个分区，出了问题都分不清是哪个引入的。经历了两次半夜在示波器前救砖之后，这个习惯就成了铁律。希望这段经验能帮你在改机路上少走几次弯路，也希望 mstar-bin-tool 这套“正式版”外壳下的老工具，能在你手里真正派上用场。

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