简介：Unlocker 3.0.3是一款面向VMware用户的解锁工具，专用于解决macOS系统中文件被进程锁定而无法删除、移动或重命名的麻烦。该版本经实测与VMware 15.5.1完美兼容，使用时只需先暂停VMware相关进程，应用补丁后无需重启系统即可立即生效，适合经常在macOS下管理虚拟机文件的运维人员与开发者。压缩包共收录21个文件，整体大小约15.62MB，文件类型以cmd脚本、py工具、exe程序、sh脚本和txt说明文档为主，可分别用于Windows与Linux环境下的安装、卸载、更新及测试。目前已有2056人学习下载。资源内除了可直接运行的解锁程序，还附带了Python辅助脚本与操作说明，方便使用者理解工具的解锁机制，并将其嵌入到自己的虚拟化运维流程中。对于饱受VMware文件占用困扰的用户，这套工具能显著减少操作中断，提升管理效率。
1. 这个 zip 到底是什么：给 VMware 开 macOS 后门的老牌工具
如果你是做跨平台开发、自动化测试或者搞虚拟机集群的，大概率碰过这种场景：VMware 里新建虚拟机时，操作系统列表压根没有 macOS 的选项，装个 OS X 系统得靠各种“玄学”手段。这个unlocker-master3.03.zip就是干这个用的——一套在 VMware Workstation、Fusion 乃至 ESXi 上解锁 macOS 安装能力的脚本工具，3.0.3 是发布比较久、社区验证也最多的一个版本。它能解决的核心问题有两个：一是让 VMware 识别到 Apple 硬件标识，二是把被官方隐藏的 Darwin 驱动和工具链完整放出来，最终你才能在虚拟机里正常安装、启动、增强 macOS 系统。适合谁？虚拟化运维、需要 macOS 环境做 CI 构建的开发者、还有那些想在家里 PC 上体验 macOS 硬件的折腾党。与其说它是破解，不如说它是把 VMware 里本来就存在的 Darwine 支持能力重新暴露出来，这点搞清楚之后你后面排查问题会顺手得多。
2. 解锁原理与文件结构：黑匣子是怎么被撬开的
2.1 为什么 VMware 原生不支持 macOS：硬件标识与产品化限制
VMware 的所有虚拟化产品其实都内置了 macOS 的客户机支持代码，只是对外不开放。原因并不神秘——Apple 的最终用户许可协议（EULA）明确规定 macOS 只能运行在 Apple 品牌的硬件上。VMware 作为商业公司，不可能冒着版权风险把开关直接放在 GUI 里给你点。但底层代码从来没删干净，ESXi 里甚至保留着macOS客户机操作系统类型的完整选项，只是被产品策略隐藏了。
unlocker 做的事就是把这层“产品化限制”剥掉。它不会给 VMware 打补丁去绕过权限校验，而是直接修改 VMware 的配置文件、替换掉与客户机操作系统检测相关的模块文件，让 vmx 文件里能写入smc.present = "TRUE"和board-id这类 Apple 硬件专属参数。这些参数在普通配置里是非法条目，但对 macOS 客户机来说是必需的。
2.2 压缩包里的真实布局：python 脚本与 darwin 镜像各司其职
解压之后你看到的是一堆.py、.c和.h文件，加上一个darwin子目录，里面放的是打好包的 ISO 镜像和 flp 软盘镜像。别被源码文件唬住，你真正需要执行的只有一个unlocker.py（或对应平台的.py启动入口），其他 C 源码是用于重新编译vmwarebase.dll/libvmwarebase.so这类核心库的小工具。
darwin目录里的 ISO 镜像才是精华。它包含 VMware Tools for macOS、显卡驱动、网络驱动和剪贴板共享组件。如果你发现解锁完成但装完系统后屏幕分辨率固定 1024x768，那就是 darwin 镜像没被正确加载——后面我会讲到这坑。
| 路径 | 职责 | 是否手动修改 |
|---|---|---|
unlocker.py | 主入口，打补丁与回滚 | 执行即可 |
darwin.iso | macOS 客户机增强工具 | 通过 vmx 引用 |
smc.py | 生成 smc 密钥对 | 自动执行 |
tools目录 | Windows / Linux 下的辅助脚本 | 仅在特殊场景使用 |
2.3 补丁执行的完整时序：备份、替换、重启服务
在 Windows 主机上，流程分三条线：停止 VMware 服务 → 执行解锁脚本 → 重启服务。脚本内部默认会先做一次全量备份，把原始vmwarebase.dll复制为.bak后缀文件，然后对备份应用补丁，最后用打过补丁的文件替换原文件。换句话说，它不直接修改原版文件，而是改了副本再覆盖，这为回滚留了退路。
提示：执行解锁前务必关闭所有 VMware 进程和后台服务，否则 DLL 文件被占用会直接导致替换失败，脚本会静默跳过并报“access denied”。
3. 三平台实操：Workstation / Fusion / ESXi 的解锁步骤
3.1 Windows + Workstation Pro：服务停止顺序与脚本执行
先打开服务管理器（services.msc），找到VMware Workstation Server和VMware Authorization Service，手动停止。顺序不能反，否则授权服务会自动拉起 DHCP 和 NAT 服务，导致文件解锁完又被回写。然后以管理员身份打开 PowerShell，cd 到解压目录，执行：
.\unlocker.exe如果你下载的是主版本源码包，但实际是 Windows 环境的话，需要用 Python 运行主脚本，操作方式如下：
cd .\unlocker-master3.03\ python .\unlocker.py执行完成后别急着打开 Workstation，先去检查C:\Program Files (x86)\VMware\VMware Workstation\目录下vmwarebase.dll的时间戳。如果时间接近当前时刻，说明替换成功。再启动 Workstation，新建虚拟机时操作系统类型里应该出现了Apple Mac OS X。
这里有个细节：系统类型出现后不要急着选版本，先选macOS 10.15或根据你的安装镜像选对应版本，然后进 vmx 文件手动确认。Workstation 默认生成的 vmx 里通常缺board-id.reflectHost = "TRUE"这一行，没有它你启动虚拟机时会卡在苹果 Logo 界面。
3.2 macOS 主机上的 Fusion：路径不同但套路一致
Fusion 版本的解锁脚本在 macOS 端的逻辑几乎相同，只是文件路径和 Python 解释器不同。打开终端，进入脚本目录，用sudo python3 unlocker.py执行。这里有个注意点：macOS 自带的 Python 是区分新旧版解释器的，如果系统是 Catalina 及以上且你用的是系统自带 Python3，某些模块可能与脚本不兼容，表现为脚本执行没有任何错误输出到结束，但 VMware Fusion 里依旧找不到 macOS 选项。
这时候改用 Homebrew 安装的 Python：
/opt/homebrew/bin/python3 ./unlocker.py执行完毕后需要重置权限与签名。在 Apple Silicon 机器上，由于签名验证机制不同于老 Intel，脚本会尝试调用codesign对修改后的动态库重新签名，但经常因为证书缺失而失败。此时你不能重启 Fusion，必须先执行一次sudo codesign --force --deep --sign - /Applications/VMware Fusion.app，然后再启动 Fusion 验证。忽略这一步最典型的故障就是 Fusion 打开后一直转圈，甚至直接闪退。
3.3 ESXi 主机：SSH 绕过 vSphere Client 的限制
vSphere Client 的 Web 界面在创建虚拟机时根本没有 macOS 客户机类型可选，必须在 ESXi 宿主机上操作。先开启 SSH 服务，登录 shell，上传整个 unlocker 目录，执行：
cd /tmp/unlocker python3 unlocker.pyESXi 上的解锁脚本默认会操作/vmfs/volumes下的模块文件及/etc/vmware/config，所以脚本必须用 root 权限执行。补丁完成后，还要在 vSphere Web Client 里刷新几次页面，才能看到新建虚拟机界面的“操作系统类型”中出现 Apple 相关选项。
注意：ESXi 解锁后如果你升级了 ESXi 版本（比如从 7.0 升到 8.0），所有改动会被覆盖回去。升级完成后必须重新执行解锁脚本，这是很多模拟项目X 踩过的问题。
4. 避坑指南：从启动失败到内核崩溃的排查记录
4.1 现象：解锁后新建虚拟机提示“Intel VT-x 不可用”
你按照官方教程完成了所有步骤，新建虚拟机选好 macOS 版本，启动时直接弹警告：VT-x is not available。很多人以为是 unlocker 损坏了 VMware 的虚拟化层，其实完全无关。
原因是 macOS 客户机在引导阶段会使用特定 CPU 指令集，要求宿主机必须开启硬件虚拟化嵌套。解决方法是：关闭主机 BIOS 里的 VT-x / AMD-V 设置？不对，恰恰相反——必须确认 BIOS 里Intel Virtualization Technology已开启，并且 VMware 的虚拟机设置里勾选“虚拟化 Intel VT-x/EPT”。如果你使用的是嵌套虚拟化环境（比如 VMware 装在另一台虚拟机上），则还需要在宿主的虚拟机设置中勾选“向客户机暴露硬件辅助虚拟化”。
4.2 现象：启动卡在smcReadKey或黑屏停留在引导行
补丁执行成功后，虚拟机启动时黑屏且 CPU 占用 100%，或者控制台底部反复出现smcReadKey字样。原因很明确：unlocker 给 vmx 写入了smc.present = "TRUE"，但缺少配套的密钥生成。
unlocker 包里带了一个smc.py工具，用于生成一对密钥：
python3 smc.py执行完会生产两个字符串，需要手动粘贴到 vmx 文件中。常见错误是直接复制脚本输出到 vmx 里，把密钥值两边的引号也一起贴进去。正确示例如下：
smc.version = "0" smc.present = "TRUE" smc.compat = "TRUE" smc.useTag1 = "TRUE" smc.tag1 = "你的密钥1" smc.tag2 = "你的密钥2"4.3 现象：安装完成后 macOS 无网卡、分辨率固定
这是最典型的一类问题，解锁成功、系统装完、VMware Tools 也显示已安装，但网络不可用、分辨率只有 1024x768。原因通常是 darwin 镜像版本与当前 VMware 版本不匹配，或者虚拟机配置文件里没有正确挂载 darwin.iso。
建议手动检查 vmx 文件里的 CD/DVD 挂载路径是否指向 unlocker 解压目录下的 darwin.iso，并确认引导顺序里光驱在硬盘之前。在 Windows 端，路径里如果有中文或空格，需要用引号整体包裹：
ide1:0.deviceType = "cdrom-image" ide1:0.fileName = "F:\unlocker-master3.03\darwin\darwin.iso"4.4 现象：解锁脚本执行后把所有 Windows 虚拟机都搞坏了
这是一个极其伤痛的教训。有人为了图省事，在 ESXi 或 Workstation 上对全局的 vmx 添加了board-id参数，导致所有 Windows 虚拟机启动时报Invalid configuration，因为 Windows 不支持这类 Apple 硬件标识参数。解锁脚本只应该影响新增的 macOS 虚拟机，而不是全局配置。排查方法是：检查C:\ProgramData\VMware\VMware Workstation\config.ini或 ESXi 的/etc/vmware/config，把不属于 macOS 的硬件参数全部移除。如果想后悔，直接运行 unlocker 的-r回滚参数：
python3 unlocker.py -r5. vSphere 与自动化集成：从临时解锁到静默批量部署
5.1 让 vSphere Web Client 显示 macOS 类型：刷新策略
ESXi 上解锁之后，Web Client 的虚拟机创建界面偶尔不会立刻出现 macOS 选项。这是因为 vSphere Client 有会话缓存，普通刷新解决不了。常见做法是注销当前用户重新登录，或者直接在浏览器无痕模式里打开 vSphere Client。如果仍然不行，重启vpxd服务：
/etc/init.d/vpxd restart这步会让 vCenter 短暂中断，生产环境务必谨慎操作。
5.2 自动化部署 macOS 虚拟机：使用 PowerCLI 与 vmx 模板
解锁完成后，批量创建 macOS 虚拟机没必要在 GUI 里一台台点。先把一台手动配置好的 macOS 虚拟机转为模板，导出其 vmx 文件，然后写一个 PowerCLI 脚本来批量克隆。克隆后必须修改三处：虚拟机名称、UUID、以及board-id是否保留。默认情况下克隆出来的虚拟机会继承母机的board-id.reflectHost设置，导致每台机器在 macOS 系统信息里显示同样序列号，部署到生产环境有风险。
Connect-VIServer 192.168.1.10 -User root $vm = Get-Template -Name "macos-template" for ($i=1; $i -le 5; $i++) { $cloneSpec = New-Object VMware.Vim.VirtualMachineCloneSpec $cloneSpec.Location = New-Object VMware.Vim.VirtualMachineRelocateSpec $cloneSpec.Template = $false $cloneSpec.PowerOn = $true New-VM -Name "macos-node0$i" -Template $vm -Datastore "datastore1" -VMHost "esxi01" }脚本里没有显式修改 UUID 的逻辑，但这个操作必须在克隆完成后执行。进入每台新虚拟机的 vmx 文件，删除uuid.bios与uuid.location，再添加uuid.action = "create"，这样 macOS 首次启动时会重新生成唯一的硬件 UUID。
5.3 结合 packer 构建镜像：记一次自动化踩坑
如果你用 packer 做 macOS 镜像构建，unlocker 3.0.3 不一定和最新版 packer 完全兼容。常见故障是构建过程中 VMware 的vmrest接口无法正常识别客户机操作系统类型。解决方式不是去改 unlocker 源码，而是把 packer 的vmx_data字段显式加进去：
"vmx_data": { "smc.present": "TRUE", "smc.version": "0", "board-id": "Mac-35C5E5A9F0F4A5A4", "hw.model": "MacPro6,1", "ethernet0.virtualDev": "vmxnet3" }注意board-id和hw.model必须匹配，否则 macOS 安装器会提示“此电脑无法安装 macOS”，原因属于早期硬件探测失败。
6. 进阶：自己维护 unlocker 补丁的习惯动作
用了一段时间 unlocker，你会发现 3.0.3 这个版本太老，每次 VMware Workstation 升级都要重新打补丁，同时还要面对新版模块文件格式变化的问题。我的习惯是保留一份自己维护的补丁脚本，而不是每次用现成的解锁工具。核心工作是写一个挂载签名替换逻辑：先用strings抽取出原始vmwarebase.dll里与客户机检测相关的特征字节，再用 Python 脚本把对应位置替换为 macOS 支持值。
下面是一个简化思路：
import hashlib import os def patch_vmwarebase(dll_path): with open(dll_path, 'rb') as f: data = f.read() # 定位 macOS guest 检测逻辑的特征码 pattern = bytes.fromhex('48 8b 05 00 00 00 00 0f 84') if pattern not in data: raise ValueError("特征码不存在，VMware 版本是否已变更？") # 修改跳转条件为 jmp（jump always） data = data.replace(pattern, pattern[:-1] + b'\xe9') backup = dll_path + '.bak' if not os.path.exists(backup): os.rename(dll_path, backup) with open(dll_path, 'wb') as f: f.write(data) patch_vmwarebase('D:\\VMware\\vmwarebase.dll')这个脚本的局限很明显：它只能处理单一跳转特征，如果新版 VMware 修改了指令编码，必须重新分析。因此每次升级 Workstation 后，我的流程是先解开新版本的 dll 跑一次特征比对，失败就退回 3.0.3 的官方脚本重新来。
另一个习惯是这半年才开始养成的：在任何生产环境执行解锁前，先对所有 vmx 做一次快照复制。别小看这一步，很多人在 Workstation 上直接操作，出了问题才发现根本没留回滚点，不得不重装 VMware。从那以后我每次都会先复制一份 vmx 和控制文件到备份目录，再动解锁逻辑。整个过程不超过五分钟，但能省下大半天的时间去折腾。这篇内容讲的都是实际操作里验证过的经验，希望帮到你。
本文还有配套的精品资源，点击获取
