原创【老骥伏枥-马年大礼包】破解/破译绿联UGOS Pro系统初探

前言

绿联云系统的UGOS发行有一段时间了。但系统设计有一个致命的缺点，所以我一直没有把破解版发给朋友们试验。因为UGOS必须连接绿联的服务器才能使用。做为一个NAS私有云，每次登录都离不开绿联的服务器，这是一个非常失败的设计。也是很多人用绿联硬件改刷其他NAS的原因之一。不懂NAS技术的小白们除外。

绿联云系统最近推出了新系统UGOS Pro。虽然它欠缺打磨，实在还不足以称其为一个好用的NAS系统。我和大多数用户体验下来的感受一样，这款产品硬件可以。担软件系统实在太差了。

第一节

回顾UGOS系统

绿联的UGOS系统，是一个非常粗糙的，基于OpenWrt系统开发出来的NAS系统。绿联产品的硬件中内置了emmc/ssd系统盘。因为绿联官方并不提供它的固件，所以如果要研究分析UGOS系统，只能从它的硬件中提取镜像。

提取镜像的方法非常简单，对于emmc机型，可以使用ddif=/dev/mmcblk0 | gzip >/tmp/mmcblk0.gz 我用这个命令备份同时压缩的保存到本地后，再分享。朋友们提供给我了一个DX4600的UGOS系统的NAS映像，我对它做了一般性的破解。但我发现，它实在是太差了，根本不值得分享给其它朋友们去体验。

为了解UGOS系统的结构，我认为有必要先回顾一下，以便比较UGOS Pro都有些什么改变。

拿到mmcblk0.gz压缩的映像后，我准备了一个QEMU虚拟机。在它上面做仿真分析这个系统。

首先要创建一个映像磁盘。我用命令：

qemu-img create -fqcow2 UGOS_SD.qcow2 32G [创建磁盘]

再用命令把映像解压恢复的磁盘上。

gzip c mmcblk0.gz> mmcblk0 [解压映像]

dd if=./mmcblk0 of=./UGOS_SD.qcow2 [复制映像]

让我们先来看看映像磁盘的分区结构：我暂时把磁盘挂载在/dev/sdb了，其实磁盘可以挂载在任何的sdX盘位，并不影响分析系统。

sdb 8:16 0 32G 0 disk

|-sdb1 8:17 0 64M 0 part (9%)

|-sdb2 8:18 0 1G 0 part (100%)

|-sdb3 8:19 0 10M 0 part (3%)

|-sdb4 8:20 0 1G 0 part

|-sdb5 8:21 0 1G 0 part

|-sdb6 8:22 0 26G 0 part (3%)

`-sdb128 259:0 0 239K 0 part

磁盘有七个分区，其中六个是格式化的分区，一个是非格式化的分区。

/dev/sdb1:SEC_TYPE="msdos" LABEL="kernel" UUID="1234-ABCD"TYPE="vfat" PARTUUID="bd74b9fa-7100-e8ee-f60f-57b565f1d001"

/dev/sdb2:TYPE="squashfs" PARTUUID="bd74b9fa-7100-e8ee-f60f-57b565f1d002"

/dev/sdb3: LABEL="factory"UUID="b89bd8c6-e263-4672-a471-5db2adf30fed" TYPE="ext4" PARTUUID="d4b34e73-bb2e-c748-8122-4df99f9a58f0"

/dev/sdb4: LABEL="rootfs2" UUID="8841f290-8db5-40c7-b8be-b712c0108f68"TYPE="ext4" PARTUUID="f40885a9-7106-b848-b60f-b77cc08c668b"

/dev/sdb5: LABEL="reserved"UUID="184b0c77-172f-4a7e-a6b8-192d7305c630" TYPE="ext4" PARTUUID="4589f2ed-5787-164b-bf3b-b0693a136240"

/dev/sdb6: LABEL="UserData" UUID="17e27785-20ff-43fd-aaa0-8cc74f8d7078"TYPE="ext4" PARTUUID="8a077d37-51e6-e84f-b4ab-92e76c5f48ab"

/dev/sdb128: PARTUUID="bd74b9fa-7100-e8ee-f60f-57b565f1d080"

该映像这是一个UEFI格式的启动盘：

第一分区是"vfat"格式化的文件系统，新的UGOS PRO系统也是同样功能。

含有boot和 efi两个目录，boot目录下有grub子目录，它里面有grub.cfg文件。该文件的内容如下：

serial --unit=0--speed=115200 --word=8 --parity=no --stop=1 --rtscts=off

terminal_inputconsole serial; terminal_output console serial

setdefault="0"

settimeout="2"

search --no-floppy--fs-uuid --set=root bd74b9fa-7100-e8ee-f60f-57b565f1d001

menuentry"UGREEN-NAS" {

linux /boot/vmlinuzroot=PARTUUID=bd74b9fa-7100-e8ee-f60f-57b565f1d002 rootwait console=tty0console=ttyS0,115200n8 overlay=/dev/mmcblk0p6 overlayfs=ext4 noinitrd

}

它非常简单，我稍微改了一下，添加了console=ttyS0,115200n8 以便我通过控制台跟踪信息。

第二分区是"squashfs"格式的根文件系统，注意:这是只读的不能改动。新的UGOS PRO系统也是同样功能。

因此系统运行时要通过overlay=/dev/mmcblk0p6中的upper目录做overlay处理一些系统运行时必须改动的文件。其实必要时"squashfs"格式也是可以做修改的，只是修改后要重新生成新的文件系统而已。

我们可以使用命令unsquashfs查看一下它的详细信息：

unsquashfs -s /dev/sdb2

Found a validSQUASHFS 4:0 superblock on /dev/sdb2

Creation or lastappend time Tue Oct 25 04:35:40 2022

Filesystem size 380619.98Kbytes (371.70 Mbytes)

Compression xz

Block size 262144

Filesystem isexportable via NFS

Inodes arecompressed

Data is compressed

Fragments arecompressed

Always-use-fragmentsoption is not specified

Xattrs are notstored

Duplicates areremoved

Number of fragments423

Number of inodes9640

Number of ids 1

第三分区是"ext4"格式的文件系统，新的UGOS PRO系统也是同样功能。

这里存放厂家的定制文件。是系统激活的必要文件。文件非常少，只有factory.tar和rootfs.md5sum两个文件。新的UGOSPRO系统又填了两个format.log和rootfs.count。

第四分区是"ext4"格式的文件系统，这是一个空的分区。新的UGOS PRO系统也是同样功能。

第五分区是"ext4"格式的文件系统，这是一个空的分区。新的UGOS PRO系统也是同样功能。

第六分区是"ext4"格式的文件系统，是旧系统的overlay分区。但新的UGOS PRO系统该变了这个分区的功能，用于存放"UGREEN-SERVICE"绿联的系统服务。旧UGOS系统的服务部分是放在根文件系统之中的。

新的UGOS PRO系统增加了第七分区做为overlay的分区。这一点与UGOS有点不同。但大致的结构并无根本性改变。

旧的UGOS破解很容易，我改了几个地方就可以轻松破解了。

1. /etc/shadow文件，用户root的密码：ugreen。修改的方法是，在overlay分区中upper目录中etc子目录中的shadow文件，把用户root的密码：改为ugreen（$1$abc$BxiGbxY.yOmCDbNurq3SH0=== > ugreen）。通过overlay在启动时覆盖根文件系统的内容。

2. /etc/rc.button/reset文件防止UGOS出错重启。也是在overlay分区中的upper目录中来实现。删除该文件中的如下两行：

echo "FACTORY RESET" >/dev/kmsg

/sbin/ugreen_factoryreset &

即可。

3. 还需要移除模块 ioports-hotplug-dx4600.ko这是绿联硬件对应的内核模块。使用QEMU虚拟机仿真时这个模块没有用。我使用简单粗暴的办法，直接修改squashfs的根文件系统。

用unsquashfs命令拆包

cd /mnt/custom [切换目录]

unsquashfs /dev/sdb2 [拆包squashfs]

拆包后会在当前目录下产生一个squashfs-root的目录。直接修改里面的文件即可。我直接删除了/lib/modules/5.10.120/ioports-hotplug-dx4600.ko的模块ko文件。

然后重新打包。使用命令：mksquashfssquashfs-root filesystem.squashfs -compxz 即可。

再将打包后的文件拷贝到第二分区。

cp /mnt/custom/filesystem.squashfs /dev/sda2 [拷贝squashfs]

这样简单的破解完成后，就可以试试了。因为绿联的启动盘在emmc/ssd盘上，用虚拟机仿真时需要使用一点点(trick)技巧。普通的VMware，VirtualBox，KVM，PVE等等图形UI的虚拟机，一般都不能虚拟仿真emmc/ssd盘。尽管有些虚拟机的底层也是用的QEMU代码。因此，我这次会直接使用QEMU虚拟机的命令脚本方式，来仿真绿联的UGOS系统。

QEMU虚拟机可以安装到各种操作系统平台上。Windows, Linux,Ubuntu, MacOS, 等等都可以安装。

虽然QEMU虚拟可以模拟emmc/ssd盘，但是这个模拟盘不能用作启动盘。那怎么办呢？我的办法是做一个辅助启动盘。为此我要为QEMU虚拟机创建如下的三个盘：

qemu-img create -fqcow2 UGOS_BIOS_BOOT.qcow2 1G [创建磁盘]

qemu-img create -fqcow2 UGOS_SD.qcow2 32G [创建磁盘]

qemu-img create -fqcow2 UGOS_DATA.qcow2 32G [创建磁盘]

UGOS _BIOS_BOOT.qcow2盘是辅助的启动盘，我做成BISO的启动盘。并且把绿联UGOS系统的第一分区中与启动有关的启动文件拷贝到辅助启动盘中。例如：grub.cfg和vmlinuz这两个文件。

UGOS_SD.qcow2盘是绿联UGOS的系统盘，是由镜像直接生成的。当然包含破解的改造。

UGOS_DATA.qcow2盘用作数据盘，目前是空的，也没有分区和格式化。

QEMU虚拟的启动命令脚本写法如下：（我是在Ubuntu系统上试验的，在其他操作系统平台上，可能稍有不同。例如文件的路径，网卡的Tap通道，等等。）

sudo qemu-system-x86_64 \

-enable-kvm \

-machinepc-i440fx-bionic,accel=kvm,usb=off,vmport=off,dump-guest-core=off \

-name guest=UGOS,debug-threads=on \

-cpu Nehalem-IBRS \

-m 1024 \

-realtime mlock=off \

-smp 2,sockets=2,cores=1,threads=1 \

-uuid 82cd2982-9a76-43ff-9c70-c4bb12984139 \

-smbiostype=0,vendor=American\ Megatrends\ International\ LLC.,version=5.27 \

-smbiostype=1,manufacturer=Ugreen,product=dx4600,version=JS0A40029,serial=*,family=Ugreen\NAS \

-no-reboot \

-devicesdhci-pci \

-device ahci,id=sata0,bus=pci.0,addr=0x6 \

-devicevirtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 \

-drivefile=./UGOS_SD.qcow2,format=qcow2,if=none,id=mydrive \

-device sd-card,drive=mydrive \

-drivefile=./UGOS_BIOS_BOOT.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 \

-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1\

-drive file=./UGOS_DATA.qcow2,format=qcow2,if=none,id=drive-sata0-0-1 \

-deviceide-hd,bus=sata0.1,drive=drive-sata0-0-1,id=sata0-0-1 \

-netdevtap,id=hostnet0,ifname=virbr1-nic,script=no \

-device e1000,netdev=hostnet0,mac=52:54:00:7e:2e:7f,bus=pci.0,addr=0x4\

-chardevsocket,id=charserial0,host=127.0.0.1,port=4555,server,nowait \

-device isa-serial,chardev=charserial0,id=serial0 \

-msg timestamp=on

这段命令中的几个关键点，让我再来解释一下。以便大家更了解仿真的过程。

-m 1024是虚拟机的内存。我用的机器是蜗牛星际矿渣机，安装的是Ubuntu18.40的系统，内存只有4G。所以没有办法给QEMU虚拟机分配更多的内存，建议在有条件的情况下，给虚拟机分配更大的内存。例如：-m 8192仿真运行起来会更快。

-smbiostype=0,vendor=American\ Megatrends\ International\ LLC.,version=5.27这是用于模拟绿联硬件的BIOS信息。因为shell在解释命令时不能有空格，所以对于每一个空格都要使用\转译符。

-smbios type=1,manufacturer=Ugreen,product=dx4600,version=JS0A40029,serial=*,family=Ugreen\NAS这也是用于模拟绿联硬件的System信息。只有一个空格要使用\转译符，也就是(family=Ugreen\ NAS)。serial=* 是因为不能泄露朋友的sn信息，我用了一个*星号代替。实际的信息应该是把绿联的sn设备序列号填写在这里。这是一个由16个字母和数字组成的。例如：serial=ABCD234XYZ56789这个设备序列号是瞎编的，不能实际使用。

注意：serial= 必须填写正确的设备序列号。这个号码可以用 dmidecode –t 0,1 命令从绿联的硬件设备中获取。当然，也可以从第三分区的factory.tar文件中得到。你也可以到网上搜一搜，有很多人把绿联的硬件刷机成其他的NAS了，这个设备序列号就废了。其实，这个sn设备序列号就仅仅对安装UGOS系统有用。

-devicesdhci-pci模拟sd卡的驱动。

-drive file=./UGOS_SD.qcow2,format=qcow2,if=none,id=mydrive模拟sd卡的盘文件。

-drivefile=./UGOS_BIOS_BOOT.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 这是BIOS启动盘文件。

-drive file=./UGOS_DATA.qcow2,format=qcow2,if=none,id=drive-sata0-0-1这是数据盘文件。

-netdevtap,id=hostnet0,ifname=virbr1-nic,script=no 网卡驱动。使用ifname=virbr1-nic是其中virbr1-nic是Tap的接口名。这个名字是自己定义的。不同的平台定义的方法也不同。使用是请修改为适合的名字。

-chardevsocket,id=charserial0,host=127.0.0.1,port=4555,server,nowait是用于跟踪ttyS0信息的。启动后可以使用：telnetlocalhost 4555监视ttyS0的输出信息。了解启动进度，等等情况。

好了，让我们启动一下破解的UGOS系统试试吧。

由于我不想联网到绿联的服务器。所以我设定了限制，只能在本地局域网内测试。不容许破解的UGOS系统连接到绿联的服务器，获取我破解系统的信息。我的破解系统打开了sshd的服务。该服务默认设定到了922端口。也可以通过http://IP:9999通过浏览器访问和设置系统。由于限制连接到绿联的服务器，浏览器界面有些东西不能执行。我没有用绿联的app做连接试验，因为我不想让接绿收集我的信息。所以只能给个ssh的本地访问截图做为证明。

给出一个通过ssh访问的截图：

以上是在Ubuntu系统上测试的结果。我知道很多朋友喜欢使用Windows系统。Windows系统上QEMU虚拟机启动脚本的写法与Ubuntu系统上稍有不同。为了方便大家做试验，我也给大家写了一个MyUGOS_DX4600.bat的例子：

@echo off

set "BOOT_DEVICE=UGOS_BIOS_BOOT.qcow2"

set "SD_DEVICE=UGOS_SD.qcow2"

set "DATA_DEVICE=UGOS_DATA.qcow2"

set "QEMU_BIN=qemu-system-x86_64.exe"

set "GUEST_NAME=UGOS"

echo "Emulate UGOS %GUEST_NAME% NAS"

rem ==================================

rem Run the virtual machine

rem ==================================

start %QEMU_BIN% ^

-name guest=%GUEST_NAME%,debug-threads=on ^

-machine pc-i440fx-6.0,usb=off,vmport=off ^

-cpu Nehalem-IBRS ^

-m 4096 ^

-smp 2,sockets=2,cores=1,threads=1 ^

-uuid d2dc4ea5-f3ec-474d-ab5c-cc3e68708579 ^

-smbios type=0,vendor="American MegatrendsInternational LLC.",version=5.27 ^

-smbiostype=1,manufacturer=UGREEN,product=dx4600,version=JS0A40029,serial=*,family="UGREENNAS" ^

-no-reboot ^

-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 ^

-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4^

-device sdhci-pci ^

-device ahci,id=sata0,bus=pci.0,addr=0x6 ^

-devicevirtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 ^

-drivefile=%SD_DEVICE%,format=qcow2,if=none,id=mydrive ^

-device sd-card,drive=mydrive ^

-drivefile=%BOOT_DEVICE%,format=qcow2,if=none,id=drive-usb-disk0 ^

-deviceusb-storage,bus=usb.0,port=3,drive=drive-usb-disk0,id=usb-disk0,bootindex=1,removable=off^

-drivefile=%DATA_DEVICE%,format=qcow2,if=none,id=drive-sata0-0-1 ^

-deviceide-hd,bus=sata0.1,drive=drive-sata0-0-1,id=sata0-0-1 ^

-netdevtap,id=hostnet0,ifname=TAP-Bridge1,script=no,downscript=no ^

-device e1000, netdev=hostnet0, mac=98:6E:E8:21:36: D9 ^

-serial telnet:localhost:4555,server=on,wait=off ^

-msg timestamp=on

大家可以与Ubuntu系统上的脚本对比着学习QEMU虚拟机的启动命令脚本的写法。

例如：我的Windows笔记本有8G内存。所以我给QEMU虚拟机分配了4G的内存，建议在有条件的情况下，给虚拟机分配更大的内存。例如：-m 8192仿真运行起来会更快。

注意：Ubuntu系统的脚本用\做空格转译符。也用\做shell的续行符。Windows系统不用\做空格转译符，只需要把含有空格的字符串用“”双引号括起来。续行符是^字符。

还有一点区别是这次我把启动盘放在了USB上，因此添加了几行USB设备的启动。大家可以根据自己的要求，定制适合自己的启动脚本，我这里的例子，只是抛砖引玉。

-netdevtap,id=hostnet0,ifname=TAP-Bridge1,script=no,downscript=no网卡驱动的ifname=TAP-Bridge1不同。

我在Windows系统定义了两个TAP-Bridge，名字可以任意选。我命名为：TAP-Bridge1，TAP-Bridge2。请看截图：

在Windows系统上用PuTTY连接UGOS的截图如下：

好了关于UGOS的回顾就讲到这里。这是2022年时我做的破解了。当时没有把文章发布到网上，只在极小的朋友圈分享了一下。因为这个绿联的UGOS系统实在太非常粗糙了，根本无法与其它的NAS系统竞争一席之地。虽然破解现在早已经过时了。但使用的工具，技术手段，破解的方法和技巧并不过时。甚至可以为破解新的UGOSPRO系统提供宝贵技术参考。

为什么要回顾一下UGOS呢？其实是有原因的。因为新的UGOS Pro系统与旧的UGOS在整体结构上并无大的改变。只是将基础的linux从OpenWrt系统，变成了DebianGNU/Linux 12 (bookworm)所以，我也会使用相同的破解的方法，工具。先回顾一下便于大家理解后续的内容。

第二节

如何获取官方的UGOSPor系统

绿联云系统最近推出了新系统UGOS Pro，据说不用通过绿联的服务器也可以离线登录了。并提供刷机用的官方ISO镜像。因此，我决定破解一下试试。刷机用的ISO镜像，根据官方的说法，它适用以下绿联NAS产品刷机：

● DH2600

● DX4600*：DX4600、DX4600+、DX4600Pro；

● DXP系列：DXP2800、DXP4800、DXP4800Plus、DXP6800Plus、DXP6800Pro、DXP8800、DXP8800Plus、DXP8800Pro、DXP480TPlus。

那么如何获取官方ISO镜像呢？官方的说法如下：

1. 联系绿联NAS官方技术支持，并提供设备序列号（SN）。

2. 根据技术支持提供的链接下载ISO镜像（链接一次有效）。

我只能提供破解的详细技术和原理，至于大家如何才能拿到绿联的设备序列号（SN），那就要靠大家“八仙过海，各显其能”了。你也可以到网上搜一搜，找朋友要个factory.tar文件等等。有很多人把绿联的硬件刷机成其他的NAS了，这个设备序列号就废了。其实，这个sn设备序列号就仅仅对安装UGOS和刷机UGOSPro系统有用。

为什么刷机前要向官方技术支持提供SN码？官方的说法如下：

答：用户联系技术支持并提供设备SN，技术支持在管理后台将该SN添加至刷机白名单并生成ISO镜像链接。该ISO镜像只对这台设备可用，其他设备无法使用这个镜像进行刷机。刷机成功后，如果再次刷机需要重新提供SN码申请。

也就是说，每一个ISO镜像只能使用一次，刷机完成后白名单就消除了。再次刷机需要重新提供SN码申请。

对于这个官方说法，根据我的破解，我要指出并强调：从官方获取的ISO镜像文件中不含有任何的用户敏感信息，其实每次用SN码申请的ISO镜像都是一样的，不同的SN码申请的ISO镜像也是一样的。所以，再次刷机时只要申请一下就可以了，不用重新下载ISO镜像。每次用SN码申请后，只是后台的数据库更新了临时的刷机白名单而已。刷机后，临时白名单消除。所以再次刷机时还要申请临时白名单而已。大家可以放心交换ISO镜像文件。不存在任何的私密信息泄露。

第三节

破解/破译ISO镜像

为了做分析研究，我从朋友那里获得了一个ISO镜像。它的文件名是: UGOSPRO-USB-1.0.0.8-1895-release.iso。这是一个已经刷机过的报废ISO镜像。通过破解，我发现这个刷机ISO镜像其实是通用的镜像。而且ISO镜像中不存在任何的私密信息。以后我在第四节中会详细解释我的发现。

让我们开始分析这个ISO文件吧。很简单，使用linix系统的file命令试试看：

root@J1900-Ubuntu18:~/UGREEN$file UGOSPRO-USB-1.0.0.8-1895-release.iso

UGOSPRO-USB-1.0.0.8-1895-release.iso: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS(0x3ff,255,63), startsector 1, 2998271 sectors, extended partition table (last)

这个结果非常令我吃惊，这根本不是一个iso格式的文件，而是一个DOS/MBR的磁盘镜像文件。把它的附加名命名为iso是别有用心的反破解技巧？还是技术人员水平太low呢？这完全违反了文件附加名的命名规则啊。一个简单的linix系统的file命令就可以轻松识破的。

既然已经知道这个ISO文件是磁盘镜像的拷贝，那就再用linix系统的fdisk命令查一查盘的分区结构吧。

root@J1900-Ubuntu18:~/UGREEN$fdisk -l UGOSPRO-USB-1.0.0.8-1895-release.iso

DiskUGOSPRO-USB-1.0.0.8-1895-release.iso: 1.4 GiB, 1535115264 bytes, 2998272sectors

Units: sectors of 1* 512 = 512 bytes

Sector size(logical/physical): 512 bytes / 512 bytes

I/O size(minimum/optimal): 512 bytes / 512 bytes

Disklabel type: gpt

Disk identifier:8453A2B8-16FB-4921-909C-6D1569A062D0

Device Start End Sectors Size Type

UGOSPRO-USB-1.0.0.8-1895-release.iso1 2048 409599 407552 199M EFI System

UGOSPRO-USB-1.0.0.8-1895-release.iso2409600 2996223 2586624 1.2G Linuxfilesystem

它是gpt格式的，有两个分区。因为它其实是一个磁盘映像文件。我们又准备使用QEMU虚拟机为工具来破解分析。那么就可以直接用qemu-img convert -f raw -O qcow2 做转换格式。把它变成一个UGOSPRO-INSTALL.qcow2启动盘吧。

root@J1900-Ubuntu18:~/UGREEN$qemu-img convert -f raw -O qcow2 UGOSPRO-USB-1.0.0.8-1895-release.isoUGOSPRO-INSTALL.qcow2

启动一个系统救援的Linux系统。把两个分区分别挂载到/mnt/floppy/目录，和/mnt/custom/目录。查看启动盘的内容：

root@J1900-Ubuntu18:~/UGREEN$ ls-l /mnt/floppy/

total 156948

drwxr-xr-x 3 root root 4096 Dec 1 2024 boot

drwxr-xr-x 3 root root 4096 Dec 1 2024 EFI

-rwxr-xr-x 1 root root 153633571Dec 1 2024 initrd.img

-rwxr-xr-x 1 root root 7066112 Dec 1 2024 vmlinuz

root@J1900-Ubuntu18:~/UGREEN$ ls-l /mnt/custom/

total 1192920

drwx------ 2 root root 16384 Dec 1 2024 lost+found

-rw-r--r-- 1 root root 1221522363Dec 1 2024 UGOSPRO_INSTALL_1.0.0.1895.img

-rw-r--r-- 1 root root 33 Dec 1 2024UGOSPRO_INSTALL_1.0.0.1895.img.md5

它的第一分区是一个UEFI的启动分区，第二分区有一个UGOSPRO_INSTALL_1.0.0.1895.img文件，以及该文件的校验md5文件。

第一分区启动后，使用initrd.img文件系统提供的安装程序，打开一个Web界面实现刷机。根据第一节回顾UGOS系统中的介绍。我试着用这个安装盘创建一个QEMU虚拟机。因为这不是本文的重点，具体细节就不一一赘述了。反正这个ISO镜像也是不能再刷机的。只是通过这个虚拟机，帮助了解一下刷机过程。如果你想直接刷机到QEMU虚拟机，可以参考第一节回顾中讲解的细节自行试验。

启动QEMU虚拟机，我做了一个截图：

截图显示网络没有连接，其实事实并不是这样。只是因为该ISO镜像是不能再刷机的。

事实是这个ISO镜像的后台处理白名单已经报废了。因为绿联的刷机程序做的非常粗糙，并不能区分显示不同的情况，统统用网络没有连接显示在主控制台上。

实际在使用绿联硬件设备时，一般用户是不会连接主控制台的。所有，也不会看到这些信息。

尽管主控制台显示网络没有连接，刷机用户仍然可以进入刷机的Web界面，也是没有问题的。请看如下截图：

通过跟踪ttyS0的控制台查询/tmp/upgrader目录下的formats.log记录文件可以知道，原因是该iso镜像已经不再能通过刷机认证了。

具体信息如下：

2025-06-0602:48:00.366 [INFO] {131f3599fe394618467a0d140d6eeac8} https://center.ugnas.com/data/cluster/device/route{

"code":200,

"data":{

"city":"Vancouver",

"cloudUrl":"https://api-us.ugnas.com",

"clusterName":"美国集群",

"continent":"NorthAmerica",

"continentCode":"NA",

"country":"Canada",

"countryCode":"CA",

"deviceRegionList":[

],

},

"msg":"SUCCESS"

}

2025-06-0602:48:00.368 [INFO] {131f3599fe394618467a0d140d6eeac8} fetchActivateKey https://api-us.ugnas.com/api/device/v2/sa/fetch/secret

2025-06-0602:48:00.685 [INFO] {131f3599fe394618467a0d140d6eeac8} response from cloud: {

"code":9092,

"msg":"设备不在秘钥拉取名单内"

}

2025-06-0602:48:00.686 [WARN] {131f3599fe394618467a0d140d6eeac8} failed to fetch prosecret: Unable to retrieve device information, please contact TechnicalSupport. sleepTime: 2

2025-06-06 02:48:02.686[INFO] {131f3599fe394618467a0d140d6eeac8} start fetch activate key

2025-06-0602:48:02.699 [INFO] {131f3599fe394618467a0d140d6eeac8} fetchActivateKey https://api-us.ugnas.com/api/device/v2/sa/fetch/secret

2025-06-0602:48:02.985 [INFO] {131f3599fe394618467a0d140d6eeac8} response from cloud: {

"code":9092,

"msg":"设备不在秘钥拉取名单内"

}

2025-06-0602:48:02.985 [WARN] {131f3599fe394618467a0d140d6eeac8} failed to fetch prosecret: Unable to retrieve device information, please contact TechnicalSupport. sleepTime: 3

2025-06-0602:48:06.001 [INFO] {131f3599fe394618467a0d140d6eeac8} start fetch activate key

2025-06-0602:48:06.056 [INFO] {131f3599fe394618467a0d140d6eeac8} fetchActivateKey https://api-us.ugnas.com/api/device/v2/sa/fetch/secret

2025-06-06 02:48:06.363[INFO] {131f3599fe394618467a0d140d6eeac8} response from cloud: {

"code":9092,

"msg":"设备不在秘钥拉取名单内"

}

2025-06-0602:48:06.363 [WARN] {131f3599fe394618467a0d140d6eeac8} failed to fetch prosecret: Unable to retrieve device information, please contact TechnicalSupport. sleepTime: 4

2025-06-0602:48:08.710 [INFO] {131f3599fe394618467a0d140d6eeac8} [reporter] report healthurl: https://api-us.ugnas.com/api/device/v1/device/health info:{"ak":"XXXXXXXXXXXXXXXX","mac":"6C:1F:F7:10:9A:70","ts":"1749149288","sign":"0611f3d5d9a4954bbb8de70d7b9b5315c49c646525ea02df66183ce2606002b5","alg":"SHA256","mac2":"6C:1F:F7:10:9A:71","ip":"192.168.122.111","port":9999,"name":"DX4600","firmwareVer":"JS0A40029","nasVer":"dx4600","hardwareVer":"5.27","remark":"ugosupgrade to pro"}

2025-06-0602:48:09.019 [WARN] {131f3599fe394618467a0d140d6eeac8} [reported] failed toreport health, cloud code: 9007, msg: 签名与认证不匹配,请检查

2025-06-0602:48:09.020 [INFO] {131f3599fe394618467a0d140d6eeac8} [reporter] request: https://api-us.ugnas.com/api/device/v1/device/health, response: {

"code":9007,

"msg":"签名与认证不匹配,请检查"

}

信息显示，显然与官方的说法一致：每一个ISO镜像只能使用一次，刷机完成后白名单就消除了。再次刷机需要重新提供SN码申请。所以，不能通过刷机认证了。

我使用的是第一节中我破解的机型是DX4600这个型号的绿联硬件的(sn) 设备序列号，显然是一个不在刷机白名单中的设备序列号。因为私密的原因，上述信息中我用XXXXXXXXXXXXXXXX隐藏了该设备的序列号。

如果你想使用ISO镜像刷机到QEMU虚拟机，从我目前的分析来看，只要用SN码申请的ISO镜像没有用过，创建QEMU虚拟机时的 -smbios参数正确无误。应当是可以的。但我只是猜测而已。我并不需要这样做。我自信可以破解或者说破译绿联的ISO镜像。

既然不能直接使用ISO镜像刷机，那我就需要继续破解ISO镜像，手工生成UGOSPro系统的启动盘吧。唯一可以下手的地方，就只有安装盘第二分区的UGOSPRO_INSTALL_1.0.0.1895.img文件。

在继续破解讲解破解/破译UGOSPRO_INSTALL_1.0.0.1895.img文件之前，做为预备知识，我要先介绍一下UGOSPro系统的启动盘结构。便于大家理解后续的对于破解的讲解。

由于NASYUN的篇幅限制，请看楼下，第四节【绿联UGOS Pro系统NAS的启动盘结构刨析】，精彩继续！

最自然的一种表达方式，即是不写赞赏语，红色赞赏按钮就在那，大家懂的。

打赏

f541883216 · 发表于 2026-1-12 01:59

第四节

绿联UGOS Pro系统NAS的启动盘结构刨析

在第一节的UGOS回顾中，我们已经了解了UGOS系统的启动盘结构是由六个分区组成的。介绍UGOS系统回顾的时候，其实我已经顺便也对比讲了一下UGOSPro系统的启动盘结构。它是由七个分区组成。我破解的UGOSPro系统启动盘结构，我使用lsblk命令列出结果如下：

root@DX4600-C3A9:~# lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS

sda 8:0 0 1G 0 disk

└─sda1 8:1 0 1023M 0 part

sdb 8:16 0 32G 0 disk

├─sdb1 8:17 0 15.3G 0 part

└─sdb2 8:18 0 16.7G 0 part

mmcblk0 179:0 0 16G 0 disk

├─mmcblk0p1 179:1 0 256M 0part /boot

├─mmcblk0p2 179:2 0 2G 0part /rom

├─mmcblk0p3 179:3 0 10M 0part /mnt/factory

├─mmcblk0p4 179:4 0 2G 0part

├─mmcblk0p5 179:5 0 2G 0part

├─mmcblk0p6 179:6 0 4G 0part /ugreen

└─mmcblk0p7 179:7 0 4.7G 0part /overlay

root@DX4600-C3A9:~#

我破解的机型是DX4600这个型号。其实绿联官方提供的ISO镜像，是可以适合第二节中列出的所有机型的。那么我为什么要用DX4600这个型号呢？原因很简单，我已经有了一个几年前破解的UGOS系统，给该系统破解升级为UGOSPro系统对我来说比较方便。不用再去找其它型号的有关绿联硬件的(sn)设备序列号等等信息了。

对比第一节讲解的关于QEMU虚拟模拟emmc/ssd盘，我这次仍然是为QEMU虚拟机创建如下的三个盘：

qemu-img create -f qcow2 UGOSPRO_BIOS_BOOT-1895.qcow21G

qemu-img create -f qcow2 UGOSPRO_SD.qcow2 16G

qemu-img create -f qcow2 UGOSPRO_DATA.qcow2 32G

其中：

/dev/sda为1G的辅助的启动盘。它只有一个分区，我把它做成BIOS legacy_boot启动盘。

/dev/sdb为32G的数据盘。它有两个分区，绿联的数据盘都是两个分区的结构。

/dev/mmcblk0 为16G的UGOSPro系统SD卡启动盘。它是QEMU虚拟机的mmcblk0设备

注意：有些绿联硬件，使用的是nvmeXn1启动盘，例如：DXP6800 Pro硬件设备。

再看它的结构：

/dev/mmcblk0p1分区为256M的vfat格式分区，内容为UEFI启动文件。启动后挂载到系统的/boot目录。

/dev/mmcblk0p2分区为2G的squashfs 格式分区，内容为根文件系统。启动后挂载到系统的/rom目录。

/dev/mmcblk0p3分区为10M的ext4 格式分区，内容为设备激活文件。启动后挂载到系统的/mnt/factory目录。

/dev/mmcblk0p4分区为2G的ext4 格式分区，内容为空。启动后不挂载，备用。

/dev/mmcblk0p5分区为2G的ext4 格式分区，内容为空。启动后不挂载，备用。

/dev/mmcblk0p6分区为4G的ext4 格式分区，内容为绿联的应用服务程序包。启动后挂载到系统的/ugreen目录。

/dev/mmcblk0p7分区为4.7G的ext4 格式的overlay分区，启动后挂载到系统的/overlay目录。

从启动盘结构看，UGOS Pro系统启动盘由三大部分组成，第一分区的UEFI启动文件，第二分区的squashfs根文件系统，和第六分区的绿联的应用服务程序包。只要能够破解/破译 UGOSPRO_INSTALL_1.0.0.1895.img文件获得这些东西。就能够破解UGOSPro系统了。

至于第三分区的设备激活文件，我可以使用以前的UGOS系统中已有的文件。第七分区的/overlay的内容，系统会随着启动，运行，自动生成和改变调整的。

接下来，就让我们继续破解/破译UGOSPRO_INSTALL_1.0.0.1895.img吧。

第五节

破解/破译UGOSPRO_INSTALL_1.0.0.1895.img文件

首先来查看UGOSPRO_INSTALL_1.0.0.1895.img的类型。依然使用file命令：

root@J1900-Ubuntu18:~/UGREEN$file UGOSPRO_INSTALL_1.0.0.1895.img

UGOSPRO_INSTALL_1.0.0.1895.img: gzip compressed data, from Unix

结果令人振奋，它是一个gzip compressed 的数据文件。根据以往的经验，猜想它是一个压缩的tar包。直接改名UGOSPRO_INSTALL_1.0.0.1895.tgz处理看看。

root@J1900-Ubuntu18:~/UGREEN$tar -tvf UGOSPRO_INSTALL_1.0.0.1895.tgz

-rw-r--r-- 0/0 42775617 2024-11-29 05:10ugospro-x86-64-usb-bios-squashfs-efi.img.gz

-rw-r----- 0/0 750682112 2024-11-28 00:49ugospro-rootfs.squashfs

-rw-r--r-- 0/0 428230296 2024-11-28 00:39 ugreen.bz2

-rw-r--r-- 0/0 49 2024-11-28 00:47 version.txt

-rw-r--r-- 0/0 33 2024-11-29 05:10 boot.md5sum

-rw-r--r-- 0/0 33 2024-11-29 05:10 rootfs.md5sum

-rw-r--r-- 0/0 33 2024-11-29 05:10 ugreen.md5sum

-rw-r----- 0/0 8 2024-11-28 00:49 rootfs.count

猜想正确！成功。

这里面有三个主要的大文件：（看来与我们上一节讲的启动盘结构是吻合的）

1. ugospro-x86-64-usb-bios-squashfs-efi.img.gz

2. ugospro-rootfs.squashfs

3. ugreen.bz2

先来分析ugospro-x86-64-usb-bios-squashfs-efi.img.gz这个文件。它的文件名有点奇怪，可能隐含一些内部技术人员约定的信息。不用去管文件名了，先用gunzip解压该文件得到：ugospro-x86-64-usb-bios-squashfs-efi.img文件，再用file命令查看文件类型。

root@J1900-Ubuntu18:~/UGREEN$file ugospro-x86-64-usb-bios-squashfs-efi.img

ugospro-x86-64-usb-bios-squashfs-efi.img: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS(0x126,230,59), startsector 1, 4719135 sectors, extended partition table (last)

这也是一个DOS/MBR的磁盘镜像文件。显然，可以断定这个文件的内容就应当是第一分区的UEFI启动分区中的文件。

再来分析ugospro-rootfs.squashfs这个文件。从文件名可以非常明显地看出来，ugospro-rootfs.squashfs文件应当是第二分区的”squashfs”格式的根文件系统。

第三个文件ugreen.bz2是什么呢？我猜想它只能是第六分区的绿联的应用服务程序包了。附加名bz2显然是个压缩文件，解压一下看看？咦，不能用bz2工具解压。用file命令查一下吧：

root@J1900-Ubuntu18:~/UGREEN$file ugreen.bz2

ugreen.bz2: XZcompressed data

噢，这个文件其实是:XZ compressed data 格式的压缩文件啊。改名：ugreen.bz2为ugreen.xz。猜想它也是一个压缩的tar包

用tar –tvf命令看看内容：

root@J1900-Ubuntu18:~/UGREEN$tar -tvf ugreen.xz

… [内容太多，删去一些无关紧要的部分]

drwxr-xr-xroot/root 0 2024-11-20 22:42./@appstore/

drwxr-xr-xroot/root 0 2024-11-28 00:30./wallpaper/

… [内容太多，删去一些无关紧要的部分]

drwxr-xr-xroot/root 0 2024-11-28 00:36./@cache/

-rw-r--r--root/root 59656498 2024-11-28 00:33./@cache/13_amd64_com.ugreen.thumb.upk

-rw-r--r--root/root 8516940 2024-11-28 00:33./@cache/12_amd64_com.ugreen.helpmgr.upk

-rw-r--r--root/root 7978434 2024-11-28 00:31./@cache/07_amd64_com.ugreen.appmgr.upk

-rw-r--r--root/root 8894109 2024-11-28 00:32./@cache/10_amd64_com.ugreen.taskmgr.upk

-rw-r--r--root/root 9853542 2024-11-28 00:32./@cache/11_amd64_com.ugreen.globalsearch.upk

-rw-r--r--root/root 33786572 2024-11-28 00:31./@cache/04_amd64_com.ugreen.desktop.upk

-rw-r--r--root/root 8297133 2024-11-28 00:30./@cache/02_amd64_com.ugreen.logmgr.upk

-rw-r--r--root/root 7261427 2024-11-28 00:32./@cache/09_amd64_com.ugreen.ctlmgr.index.upk

-rw-r--r--root/root 17014972 2024-11-28 00:32./@cache/08_amd64_com.ugreen.storagemgr.upk

-rw-r--r--root/root 5277161 2024-11-28 00:31./@cache/05_amd64_com.ugreen.wizard.upk

-rw-r--r--root/root 106449228 2024-11-28 00:34 ./@cache/01_amd64_com.ugreen.player.upk

-rw-r--r--root/root 83799861 2024-11-28 00:36./@cache/14_amd64_com.ugreen.transcode.upk

-rw-r--r--root/root 42264534 2024-11-28 00:32./@cache/03_amd64_com.ugreen.ctlmgr.upk

-rw-r--r--root/root 14812531 2024-11-28 00:31./@cache/06_amd64_com.ugreen.filemgr.upk

… [内容太多，删去一些无关紧要的部分]

这个文件从内容上看，应该是启动盘第六分区"UGREEN-SERVICE"的内容。在/@cache目录中的.upk文件是绿联的应用服务程序包。官方提供的ISO镜像中，仅仅含有最基础的14个应用服务程序包。这些upk包肯定是绿联自定义的格式，从文件附加名的命名可以认为是ugreenpackge的缩写upk吧。

下一步，就是如何制作UGOS Pro系统启动盘了。

现在我们也看到了，在ISO镜像中，没有包含用于第三分区的设备激活文件。

用破译获得的文件制作UGOS Pro系统启动盘可以有很多方法，也没有什么技术含量。大家可以使用自己熟悉的技术来制作。在下一节中讲的内容，是为小白们准备的。是众多方法之中的一种，仅供大家参考而已。并不是需要一定按我的方法，和我使用的工具来做启动盘哦。

第六节

制作UGOSPro系统启动盘

为了制作供QEMU虚拟机用的启动盘，也就是说前文提到的：UGOSPRO_BIOS_BOOT-1895. qcow2辅助的启动盘和UGOSPRO_SD.qcow2绿联UGOS Pro系统SD卡盘。让我们先使用QEMU提供的qemu-img工具创建三个空盘。

qemu-img create -f qcow2UGOSPRO_BIOS_BOOT-1895.qcow2 1G [创建磁盘]

qemu-img create -f qcow2 UGOSPRO_SD.qcow2 16G [创建磁盘]

qemu-img create -f qcow2 UGOSPRO_DATA.qcow2 32G [创建磁盘]

第一步，对前两个空盘进行分区。，数据盘UGOSPRO_DATA.qcow2不用分区，以后安装系统时，绿联系统会给它分区的。我还是用我的老办法SystemRescueCD这个linux系统救援的iso映像，用如下简单脚本启动救援系统来给这两个盘做分区。当然，也顺便给UGOSPRO_BIOS_BOOT-1895.qcow2做成grub的启动盘。

sudo qemu-system-x86_64 -enable-kvm \

-machine pc-i440fx-bionic,accel=kvm,usb=off,vmport=off,dump-guest-core=off\

-name guest=UGOSPro_Bootdisk_Creat,debug-threads=on\

-cpu Nehalem-IBRS \

-m 2048 \

-boot d \

-cdrom ./systemrescuecd-x86-4.9.0.iso \

-hda ./UGOSPRO_BIOS_BOOT-1895.qcow2 \

-hdb ./UGOSPRO_SD.qcow2

我使用fdisk工具来分区。例如：fdisk /dev/sda。然后，输入o（创建dos分区表），再输入n，根据提示输入回车，最后输入w写盘完成对UGOSPRO_BIOS_BOOT-1895.qcow2的分区。请看截图：

后来想了一下，这个盘其实不应该创建dos分区表，也应该创建gpt分区表。已经这样做了，懒得再改，反正都是可以用的。你做的时候，建议创建gpt分区表。

对UGOSPRO_SD.qcow2的分区也差不多。不过这次的命令是fdisk /dev/sdb。然后，输入g（创建gpt分区表），然后…请看截图：

因为这次要做七个分区，命令一步一步地做，截图太长了。上面就截了到第三个分区，下面再继续截图直到输入w命令写盘就完成了：

用lsblk查看一下：

两个盘的分区处理就完成了。顺便把UGOSPRO_BIOS_BOOT-1895.qcow2做成grub的启动盘。使用的命令也很简单，用mkfs.ext4 /dev/sda1先格式化分区。再把这个分区挂载到/mnt/floppy目录。

再执行命令：grub2-install--boot-directory=/mnt/floppy /dev/sda 就可以了。请看如下截图：

第二步，使用如下命令，格式化UGOSPRO_SD.qcow2磁盘的分区。第二分区因为是squashfs格式的根文件系统，所以不用格式化。命令非常简单，就不截图了。

mkfs.vfat -F 16 -n "kernel" /dev/sdb1 [格式化磁盘]

mkfs.ext4 -L "factory" /dev/sdb3 [格式化磁盘]

mkfs.ext4 -L "rootfs2" /dev/sdb4 [格式化磁盘]

mkfs.ext4 -L "reserved" /dev/sdb5 [格式化磁盘]

mkfs.ext4 -L "UGREEN-SERVICE" /dev/sdb6 [格式化磁盘]

mkfs.ext4 -L "USER-DATA" /dev/sdb7 [格式化磁盘]

做完这一步，我们需要暂时shutdown虚拟机，为下一步的操作做准备。

接下来我们要把破解/破译的文件按照绿联UGOS Pro系统启动盘的结构，安放到对应地分区中。

第三步，让我们来解决第一分区的这个ugospro-x86-64-usb-bios-squashfs-efi.img文件。

根据第四节的破解/破译分析，这是一个DOS/MBR的磁盘镜像文件。因此不能用简单的拷贝命令来处理。怎么办呢？

因为这是一个DOS/MBR的磁盘镜像文件，在绿联做映像的时候，我们并不知道它的实际映像寸。因此我用一个足够大像寸的临时盘来恢复这个映像文件。以免使用dd命令时失败。这个盘如果不够大，会出现不可预见的问题。我将暂时利用32G的已经创建数据盘UGOSPRO_DATA.qcow2充当临时盘的角色。

另外由于我使用简单的QEMU脚本启动SystemRescueCD这个linux系统救援系统，简单脚本只能支持两个盘，所有这次我把-hda./UGOSPRO_BIOS_BOOT-1895.qcow2的辅助启动盘暂时拿掉，换成了-hda ./UGOSPRO_DATA.qcow2数据盘。脚本如下：

sudo qemu-system-x86_64 -enable-kvm \

-machine pc-i440fx-bionic,accel=kvm,usb=off,vmport=off,dump-guest-core=off\

-name guest=UGOSPro_Bootdisk_Creat,debug-threads=on\

-cpu Nehalem-IBRS \

-m 2048 \

-boot d \

-cdrom ./systemrescuecd-x86-4.9.0.iso \

-hda ./UGOSPRO_DATA.qcow2\

-hdb ./UGOSPRO_SD.qcow2

重新启动救援系统后，我先把ugospro-x86-64-usb-bios-squashfs-efi.img文件上传到UGOSPRO_SD.qcow2盘的第七分区/dev/sdb7分区中。当然要先挂载第七分区/dev/sdb7到/mnt/custom目录，然后再上传文件。用完之后，还要删掉它。做临时盘角色的UGOSPRO_DATA.qcow2也要清除残余数据。最好是删除重新创建。

这里还要说明一下，因为简单脚本启动的救援系统，网络是NAT用户模式的。上传文件时只能从虚拟机侧使用scp 命令来抓取宿主机的文件。虚拟机的IP固定为10.0.2.15，宿主机IP固定为10.0.2.2。抓取宿主机文件的命令：

mount /dev/sdb7 /mnt/custom [挂载分区]

cd /mnt/custom [切换目录]

scp root@10.0.2.2:/root/UGREEN/ugospro-x86-64-usb-bios-squashfs-efi.img./ [上传文件]

因为文件比较大，建议抓取后用MD5验证一下是否与主机一致。

md5sumugospro-x86-64-usb-bios-squashfs-efi.img [MD5验证]

208606cefb4d99601d34088bf2081c46 ugospro-x86-64-usb-bios-squashfs-efi.img

再用dd命令把它复制到临时盘。

ddif=ugospro-x86-64-usb-bios-squashfs-efi.img of=/dev/sda bs=1M

然后可以用fdisk–l /dev/sda检查一下。其结果如下：

root@sysresccd /mnt/custom %fdisk -l /dev/sda

GPT PMBR size mismatch(4719135 != 33554431) will be corrected by w(rite).

The backup GPT table iscorrupt, but the primary appears OK, so that will be used.

Disk /dev/sda: 16 GiB,17179869184 bytes, 33554432 sectors

Units: sectors of 1 * 512 = 512bytes

Sector size (logical/physical):512 bytes / 512 bytes

I/O size (minimum/optimal): 512bytes / 512 bytes

Disklabel type: gpt

Disk identifier:99009E79-D999-A659-32E5-993BFB698A00

Device Start End Sectors Size Type

/dev/sda1 512 524799 524288 256M Linux filesystem

/dev/sda2 524800 4719103 4194304 2G Linux filesystem

/dev/sda128 34 511 478 239K BIOS boot

Partition table entries are notin disk order.

这次我给大家一个截图吧：

截图中可以看到，fdisk检查时发现ugospro-x86-64-usb-bios-squashfs-efi.img有些错误，不过我们可以忽略这些错误。并不影响我们获得第一分区的文件。

做完上述复制后。现在可以删去ugospro-x86-64-usb-bios-squashfs-efi.img文件了。还要卸载/dev/sdb7分区。

cd [离开挂载的目录]

umount /dev/sdb7 [才能卸载的分区]

接下来，我会挂载临时盘的第一分区/dev/sda1到/mnt/floppy目录。挂载UGOSPRO_SD.qcow2盘的第一分区/dev/sdb1到/mnt/custom目录。准备拷贝该分区的内容。

mount /dev/sda1 /mnt/floppy [挂载分区]

mount /dev/sdb1 /mnt/custom [挂载分区]

拷贝临时盘第一分区的所有文件到UGOSPRO_SD.qcow2盘的第一分区。使用如下命令：

cp -a /mnt/floppy/. /mnt/custom/ [拷贝文件]

复制完第一分区的文件后，临时盘的使命就完成了。可以卸载临时盘的第一分区了。

umount /dev/sda1 [卸载分区]

但现在还要一件非常重要的事情必须做。就是要根据UGOSPRO_SD.qcow2盘的第一分区中/EFI/debian/grub.cfg 的启动配置文件中的partuuid来修正第二分区的partuuid。因为我们创建的UGOSPRO_SD.qcow2盘第二分区的uuid是随机产生的，与grub.cfg配置文件中硬编码的uuid肯定不一致，不修改的话，启动时会找不到第二分区的” squashfs”格式的根文件系统。

查一下UGOSPRO_SD.qcow2盘第二分区的partuuid。使用命令：

root@sysresccd /root % blkid /dev/sdb2

/dev/sdb2: PARTUUID="2a2d42cc-b547-431b-9ed6-9a4a2712accb"

再查一下grub.cfg文件配置的根文件系统的partuuid。顺便也编辑修改grub.cfg文件。使用vi命令。顺便修改一下输出控制台的定位，把tty0改为ttyS0,115200n8串行口。以便以后跟踪启动输出信息。我使用vi命令：

vi /mnt/custom/EFI/debian/grub.cfg [编辑修改]

编辑修改后grub.cfg配置文件是如下样子滴：

set default="0"

set timeout="2"

menuentry "UGOSPRO-NAS"{

linux /boot/vmlinuz root=PARTUUID=99009e79-d999-a659-32e5-993bfb698a02 rootwait console=ttyS0,115200n8overlay=/dev/mmcblk0p7 overlayfs=ext4 net.ifnames=0 biosdevname=0

echo 'Loading initial ramdisk ...'

initrd /boot/initrd.img

}

我们需要做的是，要把UGOSPRO_SD.qcow2盘第二分区的partuuid="2a2d42cc-b547-431b-9ed6-9a4a2712accb"改成：partuuid="99009e79-d999-a659-32e5-993bfb698a02"才可以。

这次我们需要使用gdisk命令来修改PARTUUID：

gdisk /dev/sdb [输入gdisk /dev/sdb,按回车键]

GPT fdisk (gdisk) version 1.0.1

Partition table scan:

MBR: protective

BSD: notpresent

APM: notpresent

GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): x [输入x,按回车键]

Expert command (? for help): c [输入c,按回车键]

Partition number (1-7): 2 [输入2,按回车键]

Enter the partition's new unique GUID ('R' torandomize): 99009e79-d999-a659-32e5-993bfb698a02 [输入新的uuid值,按回车键]

New GUID is 99009E79-D999-A659-32E5-993BFB698A02

Expert command (? for help): m [输入m,按回车键]

Command (? for help): w [输入w,按回车键]

Final checks complete. About to write GPT data.THIS WILL OVERWRITE EXISTING

PARTITIONS!!

Do you want to proceed? (Y/N): y [输入y,按回车键]

OK; writing new GUID partition table (GPT) to/dev/sdb.

Warning: The kernel is still using the oldpartition table.

The new table will be used at the next reboot orafter you

run partprobe(8) or kpartx(8)

The operation has completed successfully.

可以用blkid命令检查一下，如果正确，然后就可以卸载UGOSPRO_SD.qcow2的第一分区了。

umount /dev/sdb1 [卸载分区]

到此为止，破解绿联UGOSPro系统的第一分区文件的复制改造工作全部完成了。

我们又要暂时shutdown虚拟机。恢复使用第一步的QEMU脚本启动SystemRescueCD这个linux系统救援系统。使用该脚本再次启动虚拟机。

继续解决，UGOSPRO_BIOS_BOOT-1895. qcow2辅助的启动盘，UGOSPRO_SD.qcow2的第二分区的”squashfs”格式的根文件系统复制，和UGOSPRO_SD.qcow2的第六分区绿联的应用服务程序包文件复制的问题了。

第四步，继续完成UGOSPRO_BIOS_BOOT-1895. qcow2辅助启动盘的制作。

在第一步中我们已经完成了辅助的启动盘的分区，和grub启动盘安装。我们还需要从UGOSPRO_SD.qcow2的第一分区了拷贝一些必要文件到辅助启动盘。其实就是三个文件而已。为了拷贝文件，先要挂载各自的第一分区。还是老样子吧，这次辅助启动盘的第一分区/dev/sda1到/mnt/floppy目录。挂载UGOSPRO_SD.qcow2盘的第一分区/dev/sdb1到/mnt/custom目录。

mount /dev/sda1 /mnt/floppy [挂载分区]

mount /dev/sdb1 /mnt/custom [挂载分区]

拷贝grub.cfg文件到辅助启动盘。命令如下：

cp/mnt/custom/EFI/debian/grub.cfg /mnt/floppy/grub/ [拷贝文件]

拷贝/boot/目录和它里面的initrd.img，vmlinuz两个文件到辅助启动盘。命令如下：

cp -r/mnt/custom/boot /mnt/floppy/ [拷贝文件]

好了，辅助启动盘的制作就完成了。可以卸载辅助启动盘的分区了。同时也卸载UGOSPRO_SD.qcow2盘的第一分区。

umount /dev/sda1 [卸载分区]

umount /dev/sdb1 [卸载分区]

第五步，UGOSPRO_SD.qcow2的第二分区的”squashfs”格式的根文件系统的复制

让我们再次利用UGOSPRO_SD.qcow2盘的第七分区/dev/sdb7分区做为临时存放文件的地方。与前面讲的一样，先要挂载这个分区到/mnt/custom目录。再上传”squashfs”格式的根文件系统ugospro-rootfs.squashfs文件。这个文件比较大，上传后最好用MD5验证一下是否与主机的文件一致。以免制作启动盘不成功。使用的命令大致如下：

挂载分区

mount /dev/sdb7 /mnt/custom [挂载分区]

上传文件

cd /mnt/custom [切换目录]

scp root@10.0.2.2:/root/UGREEN/ugospro-rootfs.squashfs./ [上传文件]

检验文件

md5sum ugospro-rootfs.squashfs[MD5验证]

a79e582722f5d186a7153383d61efc0e ugospro-rootfs.squashfs

接着使用dd命令把它复制到UGOSPRO_SD.qcow2盘的第二分区，使用dd命令复制不需要挂载分区。

root@sysresccd /mnt/custom % ddif=ugospro-rootfs.squashfs of=/dev/sdb2 bs=1M

715+1 records in

715+1 records out

750682112 bytes (751 MB) copied,6.83664 s, 110 MB/s

把它挂载到/mnt/floppy检查一下吧：

root@sysresccd /mnt/custom % mount /dev/sdb2/mnt/floppy [挂载分区]

root@sysresccd /mnt/custom % ls /mnt/floppy

bin etc lib lib64 media opt proc run srv tmp usr

dev home lib32 libx32 mnt overlay root sbin sys ugreen var

可以看到，已经成功复制了绿联的” squashfs”格式的根文件系统。删除上传的ugospro-rootfs.squashfs文件。我们就可以卸载相关的挂载分区了。

rm /mnt/custom/ugospro-rootfs.squashfs [删除文件]

umount /dev/sdb2 [卸载分区]

umount /dev/ sdb7 [卸载分区]

第六步，UGOSPRO_SD.qcow2的第六分区绿联的应用服务程序包文件复制

我们还是要次利用UGOSPRO_SD.qcow2盘的第七分区/dev/sdb7分区做为临时存放文件的地方。与前面讲的一样，先要挂载这个分区到/mnt/custom目录。再上传破译UGOSPRO_INSTALL_1.0.0.1895.img获得的ugreen.bz2文件，我已经把它改名为ugreen.xz了。使用的命令大致如下：

挂载分区

mount /dev/sdb7 /mnt/custom [挂载分区]

上传文件

scp root@10.0.2.2:/root/UGREEN/ugreen.xz ./ [上传文件]

接下来，挂载UGOSPRO_SD.qcow2盘的第六分区/dev/sdb6 到/mnt/floppy目录。解压ugreen.xz文件到第六分区。使用的命令大致如下：

mount /dev/sdb6 /mnt/floppy [挂载分区]

cd /mnt/floppy [切换目录]

tar –xvf /mnt/custom/ugreen.xz [解压文件]

查看一下吧：

root@sysresccd /mnt/floppy % ls -l

total 36

drwxr-xr-x 2 root root 4096 Nov 21 2024 @appstore

drwxr-xr-x 2 root root 4096 Nov 28 2024 @cache

drwxr-xr-x 2 root root 4096 Nov 21 2024 avatar

drwxr-xr-x 4 root root 4096 Nov 21 2024 factory

drwxr-xr-x 2 root root 4096 Nov 21 2024 language

drwxr-xr-x 3 root root 4096 Nov 28 2024 ssl

drwxr-xr-x 5 root root 4096 Nov 21 2024 static

drwxr-xr-x 2 root root 4096 Nov 28 2024 wallpaper

drwxr-xr-x 2 root root 4096 Nov 21 2024 www

做完后，第六分区就完成了。删除上传的文件。卸载相关的挂载分区。使用的命令大致如下：

rm /mnt/custom/ugreen.xz [删除文件]

cd [切换目录]

umount /dev/sdb6 [卸载分区]

umount /dev/sdb7 [卸载分区]

第七步，UGOSPRO_SD.qcow2的第三分区中需要复制的文件

这个分区是一个很小的分区，主要用于存放一些绿联的私密授权文件。其实就一个factory.tar包。还有跟文件系统的md5校验等等。

这个factory.tar包的内容是这个样子滴，截图如下：

可以看出，里面都是私密的敏感信息。

第三分区还需要有rootfs根文件系统的校验文件，在第四节破解/破译的 UGOSPRO_INSTALL_1.0.0.1895.img文件中是包含的。两个文件rootfs.md5sum和rootfs.count。我们需要把这两个文件上传到第三分区里。rootfs.md5sum很容易理解如何计算出来。那么这个rootfs.count是如何计算出来的呢？读了一下程序，发现它的算法也很简单。就是：rootfs.count = sizeof(ugospro-rootfs.squashfs)/512。

挂载分区

mount /dev/sdb3 /mnt/custom [挂载分区]

上传文件

cd /mnt/custom [切换目录]

scp root@10.0.2.2:/root/UGREEN/rootfs.md5sum ./ [上传文件]

scp root@10.0.2.2:/root/UGREEN/rootfs.count ./ [上传文件]

卸载分区

cd [切换目录]

umount /dev/sdb3 [卸载分区]

至于factory.tar这个文件吗，如果你有的话，是需要上传的。我使用的是2022年破解UGOS时的旧版本的factory.tar认证文件。它还是可以用作破解UGOSPRO的认证文件。

如果没有，启动盘也是可以启动的。但是通过Web界面进行系统初始化的时候，就会出错了。请看我做实验得到的截图：

但这并不表示制作的启动盘有问题。你可以保留着启动盘，等到找到一个factory.tar认证文件，把它上传到第三分区中，启动盘就能正常进行绿联UGOSPRO系统的初始化了。

后来我又仔细分析了factory.tar认证文件。发现，其实它是旧的UGOS版本的遗留物。虽然在UGOSPro系统中还会检查它的存在，但对它的内容检查已经退化了。如果你实在找不到factory.tar文件，不妨可以自行制作一个假的试试。

到此为止，我们的UGOSPRO_BIOS_BOOT-1895. qcow2辅助的启动盘和UGOSPRO_SD.qcow2绿联UGOS Pro系统SD卡盘就制作完成了。

其实，在真正使用自制的绿联UGOS Pro系统启动盘之前，还有一个可做，可不做的小窍门。

如果你非常自信，可不做这个小窍门。

绿联系统在启动过程中，如果出现致命错误，就会进入“emergency mode”模式。这是绿联开发人员留的调试接口。会在控制台提示出如下信息：

You are inemergency mode. After logging in, type "journalctl -xb" to view

system logs,"systemctl reboot" to reboot, "systemctl default" or"exit"

to boot intodefault mode.

Give root passwordfor maintenance

(or press Control-Dto continue):

当发生这种情况时，启动肯定是不能继续下去了。如果你想用工具“journalctl -xb" to view

system logs”查看，就需要“Give root password for maintenance”账号的密码。而root密码我们是不可能知道的。怎么办呢？只能是修改根文件系统中/etc目录中的shadow文件。绿联的根文系统是只读的”squashfs”格式根文件系统。但我们可以通过启动盘overlay分区，来修改它。在最初始时，启动盘的overlay分区是空的。我们需要把它挂载，和以前一样，把它挂载到/mnt/custom目录。这个修改与直接修改根文件系统中文件稍有不同。我们要先创建一个upper的目录，再创建etc子目录，然后，把根文件系统的shadow文件拷贝过来，在修改。使用的命令大致如下：

挂载分区

mount /dev/sdb2 /mnt/floppy [挂载分区]

mount /dev/sdb7 /mnt/custom [挂载分区]

创建目录

cd /mnt/custom [切换目录]

mkdir upper [创建目录]

cd upper [切换目录]

mkdir etc [创建目录]

拷贝文件

cd /mnt/custom/upper/etc [切换目录]

cp /mnt/floppy/etc/shadow ./ [复制文件]

使用vi编辑shadow文件，将root后面用::隔开的第一节中的密码改为如下密码：

: $1$abc$BxiGbxY.yOmCDbNurq3SH0: [=== > ugreen]

以上的密文字符串代表密码为：ugreen 改好后，存盘即可。

卸载分区

cd [切换目录]

umount /dev/sdb2 [卸载分区]

umount /dev/sdb7 [卸载分区]

这样的修改，使得进入“emergency mode”模式时，你可以查看和调试。来启动一下试试吧。祝大家好运！

由于NASYUN的篇幅限制，请看楼下，第七节【使用破解的UGOS Pro系统启动盘】，精彩继续！

f541883216 · 发表于 2026-1-12 01:59

第七节

使用破解的UGOSPro系统启动盘

与破解UGOS系统时一样，我们需要写一个QEMU虚拟机的启动脚本。这次我使用的QEMU虚拟的启动命令行写法如下：

sudo qemu-system-x86_64 \

-enable-kvm \

-machinepc-i440fx-bionic,accel=kvm,usb=off,vmport=off,dump-guest-core=off \

-name guest=UGOSPRO\1895,debug-threads=on \

-cpu Nehalem-IBRS \

-m 2048 \

-realtime mlock=off \

-smp2,sockets=2,cores=1,threads=1 \

-uuid 82cd2982-9a76-43ff-9c70-c4bb12984139\

-smbios type=0,vendor=American\ Megatrends\ International\LLC.,version=5.27 \

-smbiostype=1,manufacturer=UGREEN,product=dx4600,version=JS0A40029,serial=*,family=UGREEN\NAS \

-no-user-config \

-rtc base=utc,driftfix=slew \

-global kvm-pit.lost_tick_policy=delay\

-global PIIX4_PM.disable_s3=1 \

-global PIIX4_PM.disable_s4=1 \

-global isa-fdc.fdtypeA=none \

-no-hpet \

-no-reboot \

-deviceich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 \

-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5\

-device sdhci-pci \

-deviceahci,id=sata0,bus=pci.0,addr=0x6 \

-devicevirtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 \

-drive file=./UGOSPRO_SD.qcow2,format=qcow2,if=none,id=mysdcard \

-device sd-card,drive=mysdcard \

-drivefile=./UGOSPRO_DATA.qcow2,format=qcow2,if=none,id=drive-sata0-0-1 \

-deviceide-hd,bus=sata0.1,drive=drive-sata0-0-1,id=sata0-0-1 \

-drivefile=./UGOSPRO_BIOS_BOOT-1895.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 \

-deviceide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \

-netdev user,id=mynet0,net=192.168.2.0/24,dhcpstart=192.168.2.10,restrict=yes,hostfwd=tcp::9999-:9999,hostfwd=tcp::2222-:22 \

-netdev user,id=mynet1,net=192.168.2.0/24,dhcpstart=192.168.2.20,restrict=yes \

-devicee1000,netdev=mynet0,mac=98:6E:E8:21:36: D9 \

-devicee1000,netdev=mynet1,mac=98:6E:E8:21:36: DA \

-chardev socket,id=charserial0,host=127.0.0.1,port=4555,server,nowait \

-device isa-serial,chardev=charserial0,id=serial0\

-msg timestamp=on

与第一节的脚本一样。这段命令中的几个关键点，让我再来解释一下。以便大家更了解仿真启动过程。

在第一节中已经介绍过的关键点，在这里也标识为bold字体，但我就不赘述了。不明的的地方请参考第一节中的解释。这段启动脚本中用三个盘。

UGOSPRO_BIOS_BOOT-1895.qcow2 辅助启动盘

UGOSPRO_SD.qcow2 绿联系统的sd卡模拟盘

UGOSPRO_DATA.qcow2 数据盘

用于模拟绿联硬件的BIOS信息的部分，隐匿掉了serial=*不能泄露的sn信息。

这里面需要解释的是QEMU虚拟机两种网络模式。

QEMU虚拟机支持两种网络模式，用户模式，和Tap模式。第一节中我使用的是Tap模式。这次我使用的用户模式。下面简单介绍一下两种模式的区别。

第一节中用的Tap模式：

Tap 网络后端利用主机中的 Tap 网络设备。它性能出色，并且可以通过配置创建几乎任何类型的网络拓扑。遗憾的是，它需要在主机中配置该网络拓扑，而这通常因使用的操作系统而异。一般来说，它还需要您拥有root 权限。

用户网络(SLIRP)。这是默认的网络后端，通常最容易使用。它不需要 root/管理员权限。但它有以下限制：

通常，ICMP流量不起作用（因此您无法在客户机中使用 ping 命令）

在Linux 主机上，客户机内部可以使用 ping 命令，但需要root 用户进行初始设置。

客户机无法从主机或外部网络直接访问。

用户网络使用“slirp”实现，它在 QEMU 中提供了完整的 TCP/IP 协议栈，并使用该协议栈实现虚拟 NAT 网络。

典型的（默认）网络如下所示：

请注意，从客户机内部连接到“网关”IP 地址上的端口将连接到主机上的相应端口；例如，“ssh10.0.2.2”将从客户机通过SSH 连接到主机。

可以使用-netdev user 命令行选项配置用户网络。

在qemu 命令行中添加以下命令，将网络配置更改为使用 192.168.2.0/24 而不是默认的 10.0.2.0/24，并从 10（而不是 15）启动客户机 DHCP 分配。

可以使用restrict 选项将客户机与主机（以及更广泛的网络）隔离。例如，-netdev user,id=mynet0,restrict=y 或 -netdev type=user,id=mynet0,restrict=yes 会将网络连接限制在客户机和任何虚拟设备上。这可以用来阻止客户机访问互联网，同时仍然在客户机内部提供网络。宿主机可以使用 hostfwd 和 guestfwd 选项选择性地访问客户机。

再来看我的脚本就容易懂了吧：

-netdev user,id=mynet0,net=192.168.2.0/24,dhcpstart=192.168.2.10,restrict=yes,hostfwd=tcp::9999-:9999,hostfwd=tcp::2222-:22

-netdev user,id=mynet1,net=192.168.2.0/24,dhcpstart=192.168.2.20,restrict=yes

我用restrict=yes限制客户机访问互联网。也就是断开互联网的工作方式。去掉它，客户机就能联网了。

因为用户网络的客户机位于NAT之后，也就是俗话说的路由器的后面。因此，要访问就需要做端口转发。绿联NAS的默认Web服务端口是9999,这个端口需要转发。还有一个是ssh的22端口。我调试的时候常用，所以也做了转发。

hostfwd=tcp::9999-:9999,hostfwd=tcp::2222-:22

好了，脚本就解释到此。让我们运行它试试吧！

强调注意：用户网络 (SLIRP)一般只适用于调试，真正使用还是要用Tap模式。

我的断开互联网的工作方式。运行启动脚本后，宿主机会出现一个QEMU的弹窗。第一次运行的时候，我会打宿主机终端开跟踪。命令是：

telnet localhost 4555

跟踪用来监视启动流程。你可能会看到这样的信息流：

Loading initial ramdisk ...

[ 0.000000] Linux version 6.1.27(ugreen@debian) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils forDebian) 2.40) #26 SMP PREEMPT_DYNAMIC Mon Nov 11 22:20:21 CST 2024

[ 0.000000] Command line:BOOT_IMAGE=/boot/vmlinuz root=PARTUUID=4453acf2-08d6-4786-bad6-611b09d11e33rootwait console=ttyS0,115200n8 overlay=/dev/sda7 overlayfs=ext4 net.ifnames=0biosdevname=0

[ 0.000000] x86/fpu: x87 FPU will use FXSAVE

[ 0.000000] signal: max sigframe size: 1440

[ 0.000000] BIOS-provided physical RAM map:

[ 0.000000] BIOS-e820: [mem0x0000000000000000-0x000000000009ffff] usable

[ 0.000000] BIOS-e820: [mem0x0000000000100000-0x000000007e9ecfff] usable

[ 0.000000] BIOS-e820: [mem0x000000007e9ed000-0x000000007eab4fff] reserved

[ 0.000000] BIOS-e820: [mem0x000000007eab5000-0x000000007eb1afff] type 20

[ 0.000000] BIOS-e820: [mem 0x000000007eb1b000-0x000000007fb9afff]usable

[ 0.000000] BIOS-e820: [mem0x000000007fb9b000-0x000000007fbcafff] type 20

[ 0.000000] BIOS-e820: [mem0x000000007fbcb000-0x000000007fbf2fff] reserved

[ 0.000000] BIOS-e820: [mem0x000000007fbf3000-0x000000007fbfafff] ACPI data

[ 0.000000] BIOS-e820: [mem0x000000007fbfb000-0x000000007fbfefff] ACPI NVS

[ 0.000000] BIOS-e820: [mem0x000000007fbff000-0x000000007ffdffff] usable

[ 0.000000] BIOS-e820: [mem0x000000007ffe0000-0x000000007fffffff] reserved

[ 0.000000] BIOS-e820: [mem0x00000000ffe00000-0x00000000ffffffff] reserved

[ 0.000000] NX (Execute Disable) protection:active

[ 0.000000] efi: EFI v2.70 by EDK II

[…………] 我截取了一点点做为例子。

第一次运行破解制作的启动盘，可能会需要比较长的时间，因为启动过程中，绿联系统要重新初始化启动盘，还要安装预制的基本服务。

在这个过程中可能会出现一些非致命错误的信息，失败重试的信息，等等。我们可以忽略这些，只要没有出现致命错误，进入“emergencymode”模式。就能成功完成启动盘初始化。我反复试验了几次，都是成功的。没有问题。因为我使用蜗牛星际矿渣机，内存小，CPU慢，每次启动大约需要5分钟左右。只是要耐心等待就是了。如果你用更好的机器，启动会很快完成。

比较有可能出现致命错误的原因大概如下：

1. 模拟绿联硬件的BIOS信息的部分输入不正确，（sn）不正确。

2. （sn）与factory.tar中的内容不匹配。

3. 启动怕第二分区的PARTUUID与grub.cfg的内容不匹配。

所以，制作过程中一定要仔细，不要出现不必要的失误。费时费力查找原因。

在QEMU的弹窗中出现如下画面，启动就基本成功了。

跟踪窗口中出现如下信息后，就可以通过Web管理界面配置绿联UGOSPro系统了。

[………]

[ OK ] Finished sysstat-collect.s…-system activity accounting tool.

[ OK ] Started rc-local.service - /etc/rc.localCompatibility.

[ OK ] Started getty@tty1.service -Getty on tty1.

[ OK ] Startedserial-getty@ttyS0…rvice - Serial Getty on ttyS0.

[ OK ] Reached target getty.target- Login Prompts.

[ OK ] Reached targetmulti-user.target - Multi-User System.

Starting systemd-update-ut… RecordRunlevel Change in UTMP...

[ OK ] Finished systemd-update-ut…- Record Runlevel Change in UTMP.

UGOSPRO Linux DX4600-C3A9 ttyS0

[ 1151.911785] PASS, PASS, PASS,PASS, PASS

[ 1207.348859] ---start get sysinfo

DX4600-C3A9 login:

也可以从跟踪窗口登录系统噢。还记得上一节中的可做，可不做的小窍门吗？现在可以派上用场了：

DX4600-C3A9 login: root

root

Password: ugreen

Linux DX4600-C3A9 6.1.27 #26 SMPPREEMPT_DYNAMIC Mon Nov 11 22:20:21 CST 2024 x86_64

The programs included with theDebian GNU/Linux system are free software;

the exact distribution terms foreach program are described in the

individual files in/usr/share/doc/*/copyright.

Debian GNU/Linux comes withABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Thu Jun 15 11:07:41CST 2023 from 192.168.44.213 on pts/1

BusyBox v1.35.0 (Debian1:1.35.0-4+b3) built-in shell (ash)

Enter 'help' for a list ofbuilt-in commands.

root@DX4600-C3A9:~# ^[[26;21R

这时在#后面会有一些乱字符，不用去管它，因为跟踪窗口的telnet不能解释Esc控制符。就当这些字符也是控制台的提示符吧。不影响输入命令。

让我们用lsblk命令看看现在块设备的情况吧：

root@DX4600-C3A9:~# ^[[26;21Rlsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS

sda 8:0 0 128G 0 disk

sdb 8:16 0 1G 0 disk

└─sdb1 8:17 0 1023M 0 part /mnt/@usb/sdb1

mmcblk0 179:0 0 16G 0 disk

├─mmcblk0p1 179:1 0 256M 0 part /boot

├─mmcblk0p2 179:2 0 2G 0 part /rom

├─mmcblk0p3 179:3 0 10M 0 part /mnt/factory

├─mmcblk0p4 179:4 0 2G 0 part

├─mmcblk0p5 179:5 0 2G 0 part

├─mmcblk0p6 179:6 0 4G 0 part /ugreen

└─mmcblk0p7 179:7 0 5.7G 0 part /overlay

zram0 252:0 0 246M 0 disk [SWAP]

zram1 252:1 0 246M 0 disk [SWAP]

zram2 252:2 0 246M 0 disk [SWAP]

zram3 252:3 0 246M 0 disk [SWAP]

root@DX4600-C3A9:~# ^[[26;21R

打开浏览器输入：http://localhost:9999通过端口转发访问绿联的Web管理界面。

因为我是断开互联网方式的。这时会出现不能更新的出错画面

我选择不用更新，就继续前进了。

然后就出现了这个画面：

按Start按钮，继续前进。

回到登录界面：

查看一些本机信息：

我的机型是：DX4600，我没有用UGREENlink，版本是：1.0.0.1895。登录账号是：laojifuli。

第八节

关于绿联UGOSPro系统盘的映像制作

绿联官方以前一直没有发行它的固件刷机盘，或者是固件更新盘。大家往往是通过复制emmc/ssd系统盘镜像的办法对它的固件来做分析的。

这次的ISO镜像发布，让我们有机会来窥视一下绿联UGOSPro系统盘的结构。

我们现在可以发现，绿联UGOS Pro系统其实可以分为三大部分。

第一部分：既系统盘的第一分区，这是一个UEFI的启动分区。这个分区中的大部分文件其实与绿联无关，都是一些支持UEFI启动的文件。只有三个文件是绿联相关的。一个就是gurb.cfg文件，这是gurb启动的定义文件。另外两个是boot目录中的，initrd.img，vmlinuz文件。vmlinuz是DebianGNU/Linux 12 (bookworm)的linux内核。initrd.img是临时的ramfs文件系统，负责引导根文件系统的启动。

绿联ISO镜像提供的是整个第一分区的磁盘镜像，其实没有必要。我们完全可以使用命令创建启动盘，然后再复制这三个文件即可。例如，我在上面介绍的辅助启动盘的做方法。

好在这个分区并不大，只有大约250M。就算做分区镜像也不会太大。如果使用三个文件加命令来创建启动盘的话，大约只需要53.2M的数据就够了。

第二部分：是系统盘的第二分区，这个分区是绿联的”squashfs”格式的根文件系统。这是整个系统的核心部分。这个分区是一个2G的分区。但实际的rootfs.squashfs根文大约应该在750M到800M左右。它是xz压缩的只读文件。我在第一节中讲了如何对rootfs.squashfs根文拆包，与重新打包的方法。只需要使用squashfs-tools工具包就可以了。但是绿联的UGOSPro系统没有安装这个工具包。

其实我们可以用df命令来判断squashfs根文的尺寸。例如：

laojifuli@DXP4800PLUS-F2A:/$ sudo df

Filesystem 1K-blocks Used Available Use%Mounted on

udev 988364 0 988364 0% /dev

tmpfs 201872 956 200916 1% /run

/dev/mmcblk0p2 795904 795904 0 100% /rom

/dev/mmcblk0p6 4046560 2959624 860840 78% /ugreen

/dev/mmcblk0p1 261868 41944 219924 17% /boot

overlay 4727420 145288 4317276 4% /

tmpfs 1009344 2104 1007240 1% /dev/shm

tmpfs 5120 0 5120 0% /run/lock

tmpfs 1009344 88 1009256 1% /tmp

/dev/mmcblk0p7 4727420 145288 4317276 4% /overlay

/dev/mmcblk0p3 8729 15 7998 1% /mnt/factory

/dev/md0 15632312 4260080 10556360 29% /rootfs

tmpfs 1048576 0 1048576 0% /var/lib/nginx

/dev/sda1 522984 51280 471704 10% /mnt/@usb/sda1

tmpfs 201868 0 201868 0% /run/user/1002

可以看到挂载到/rom目录的第二分区，实际尺寸是1K-blocks：795904也就是说它的实际尺寸为795904K，约795M。因此，在做镜像的时候，正确的方法是不需要镜像整个2G的第二分区，而是应当按照挂载到/rom的实际尺寸来做镜像。使用的命令如下：

dd if=/dev/mmcblk0p2of=rootfs.squashfs ibs=1K count=795904

这样做的镜像既可以准确覆盖分区中的squashfs根文系统的尺寸，有不会浪费不必要的空间。特别是在恢复镜像的时候，不会出现第二分区尺寸不足的问题。我提供的例子是我调试改动过的文件尺寸，与原厂的系统可能不同。请朋友们在做镜像的时候，使用df命令先检查尺寸，再根据实际尺寸做镜像。

绿联ISO镜像提供的ugospro-rootfs.squashfs 文件就是实际尺寸的文件，用dd命令写入第二分区后，它的实际尺寸就是用df命令看到的挂载到/rom目录的尺寸。这个文件是只读的，无论系统如何运行，它都永久不变。所有，任何时间点做的镜像永远是相同的。不用担心它会改变。系统运行时对根文系统中/rom文件的变动，都是通过/overlay来实现的。而这个/overlay的第七分区是不需要镜像的。它只是运行时的动态文件。

第三部分：是系统盘的第六分区，它挂载到/ugreen目录。这是绿联开发的所有基础服务程序包。根据对绿联程序的分析。这个挂载到/ugreen目录的第六分区中，包括一些系统运行后生成的文件，在做镜像时是不需要的。最好不要把这些东西做到镜像中。它会对使用镜像产生一些不良影响。如下是绿联的厂方reset程序的摘要：

ugreen_reset() {

[…] [忽略无关的部分]

# 将系统时间设置为与服务器同步模式

timedatectlset-ntp true

touch/mnt/factory/factory_reset

# 恢复配置目录/ugreen/.config

rm -rf/ugreen/.config

mkdir/ugreen/.config

# 恢复其它后产生的目录

rm -rf/ugreen/data /ugreen/guide /ugreen/guide_icons /ugreen/script

[ -e/ugreen/wallpaper/login ] && rm -rf /ugreen/wallpaper/login

# 恢复内置服务，下次开机通过uginstall会全新初始化

foritem in `ls -1d /ugreen/@appstore/*`

do

id=$(basename$item)

uginstall-remove -id $id

done

rm -rf/ugreen/@appstore

mkdir/ugreen/@appstore

# 恢复nginx入口链接，下次开机通过uginstall会全新初始化

rm -fr/ugreen/www/*

# 清理系统产生的缓存目录（默认全是以@开头的）

for volin $(findmnt -n --output TARGET --target /volume*)

do

#清理应用中心安装的目录数据

rm-rf ${vol}/@appstore 2>/dev/null

done

}

从上述的程序我们就能知道。挂载到/ugreen目录的第六分区中的有些东西是运行后产生的，没有必要做到镜像中。下面逐一简单说明一下：

隐藏目录/ugreen/.config中的内容，完全没有必要做到镜像中。因为这个目录中还含有隐藏的文件，所有绿联的程序处理时采用，删除目录再重建的办法来恢复厂方初始设置。目录需要保留。

这五个目录 /ugreen/data； /ugreen/guide； /ugreen/guide_icons； /ugreen/script； /ugreen/wallpaper/login 完全没有必要做到镜像中。目录不需要保留。

目录/ugreen/@appstore/中的内容，完全没有必要做到镜像中。可能厂方担心会含有隐藏的文件，在删除目录中的内容后，又删除目录并重建。前面删除内容的程序就是多余的了。这段程序需要推敲优化。目录需要保留。

目录/ugreen/www/ 中的内容没有必要做到镜像中。但目录需要保留。

应当采用绿联制作ISO镜像的办法。先对/ugreen目录做手工恢复出厂设置。然后使用如下命令：

tar –czf ugreen.bz2 –C /ugreen .

-C /ugreen告诉 tar 将当前目录更改为/ugreen，然后 “.”表示“添加整个当前目录”。包括隐藏文件和子目录。

以上述方法制作的镜像，是由三个文件组成的。第一分区的镜像（或者是：gurb.cfg，initrd.img，vmlinuz三个文件）。第二分区的镜像rootfs.squashfs根文件系统的镜像。和第六分区的镜像ugreen.bz2绿联基础服务程序包文件。然后，把这些文件打包压缩成一个文件就可以了。

其中最大的是rootfs.squashfs根文件系统的镜像，大约750M左右。其次是ugreen.bz2绿联基础服务程序包文件，大约360M-420M左右。最小的是第一分区的镜像，压缩后大约 50M左右。

在上述根据绿联的ISO刷机镜像全面分析了关于绿联UGOS Pro系统的结构之后，我前些日子去绿联的官网下载了它的升级固件。我下载的是：UGOSPRO_OTA_1.1.16.2030-release.img，2025年1月的一个版本。用file命令一检查，发现它就是一个tar包。把它直接改名为：UGOSPRO_OTA_1.1.16.2030-release.tar后。用tar命令查看了一下它的内容。

root@J1900-Ubuntu18:~/UGREEN $tar -tvf UGOSPRO_OTA_1.1.16.2030-release.tar

-rw-r--r-- 0/0 12 2025-01-09 19:16 config.txt

-rw-r--r-- 0/0 6952000 2025-01-06 20:58 vmlinuz

-rw-r--r-- 0/0 34297818 2025-01-06 20:58 initrd.img

-rw-r--r-- 0/0 778 2025-01-09 19:17 md5sum.txt

-rw-r--r-- 0/0 360800308 2025-01-09 19:06 ugreen.bz2

-rwxr-xr-x 0/0 613 2024-05-29 02:59pre_ugreen_update.sh

-rwxr-xr-x 0/0 6242 2025-01-06 20:58 ugreen_update.sh

-rwxr-xr-x 0/0 1090 2024-06-12 08:16ugreen_squashfs.sh

-rwxr-xr-x 0/0 77 2024-03-19 03:45ugreen_profile.sh

-rw-r--r-- 0/0 290 2025-01-09 19:16 os-release

-rw-r--r-- 0/0 765784064 2025-01-09 19:17 ugospro-rootfs.squashfs

-rw-r----- 0/0 8 2025-01-09 19:17 rootfs.count

-rw-r--r-- 0/0 33 2025-01-09 19:17 rootfs.md5sum

-rw-r--r-- 0/0 50 2025-01-09 19:16 version.txt

-rwxr-xr-x 0/0 1951652 2024-12-19 05:35 ugupdate

-rwxr-xr-x 0/0 11004 2025-01-06 20:58ugospro-upgrade

-rw-r--r-- 0/0 589 2024-10-08 06:39photo_serv.service

-rw-r--r-- 0/0 932 2025-01-09 19:04 ugreen.txt

我惊奇地发现这个升级包里面的内容，与我对上述分析完全相符。我用红色bold标出这些东西。

这里面除了没有grub.cfg这个无关紧要的文件之外，所有构建启动盘的文件都有。当然还有一些绿联升级用的文件，但这些文件对于我们创建启动盘是没有用的。

我前些日子下载的这个绿联的升级到版本1.1.16.2030版。远比绿联ISO刷机镜像的1.0.0.1895版本高得多。于是我决定按照我对思路，创建一个1.1.16.2030版启动盘试试看。具体细节我就不赘述了，可以参考前面讲过的创建启动盘的方法。果然，成功了！不浪费时间截图了，只给出一张截图证明一下：

这个1.1.16.2030最新的版本，虽然远比绿联ISO刷机镜像的1.0.0.1895版高的多，但其实没有什么实质性的大的改变。最近我又去绿联的官网查了一下，现在（写这篇文章的时候）最新的版本已经升级到了1.5.0.2628版。但我还没有下载它，估计也没有什么实质性的大的改变吧。这只是我对猜测，有兴趣的朋友可以自行下载试试吧。我发现，绿联的版本升级很快，从1.1.16.2030版到1.5.0.2628版，仅仅几个月的时间。可以推测，可能是bug多多，正在加速打磨吧。

现在，理论上可以说对于绿联的任何版本，只要绿联发布升级包。我们就能制作该版本的启动盘了。但实际操作上，还是需要一些技巧的。

为例验证我的猜测，在发这篇文章之前，我决定还是下载1.5.0.2628版。看看我的猜测对不对。但下载后我发现，这个版本有个“DIFF”标记。绿联发布的升级包有两种形式，目前我也没有发现什么规律性。例如；“UGOSPRO_OTA_1.1.16.2030-release.img”，就可以拿来直接制作启动盘。但是“UGOSPRO_OTA_DIFF_1.5.0.2628-release.img”，也就是我写这篇文章时绿联发布的最新版升级包，就需要依赖以前的版本来做启动盘。这里边的差异就是“UGOSPRO_OTA”与“UGOSPRO_OTA_DIFF”。“UGOSPRO_OTA”里面包含一个完整的ugospro-rootfs.squashfs根文件系统。但是“UGOSPRO_OTA_DIFF” 里面仅仅含有一部分ugospro-rootfs.squashfs根文件系统的升级文件。需要依赖以前的根文件系统来升级。“UGOSPRO_OTA_DIFF”升级包比“UGOSPRO_OTA”会小很多。如果可能的话，尽量下载“UGOSPRO_OTA”升级包，这样制作启动盘比较简单。这两种形式的img升级包，都是tar包。可以使用tar命令来解包和查看内容。

那么我就再利用这个升级包再次做个启动盘试试吧。具体细节我就不赘述了，可以参考前面讲过的创建启动盘的方法。不浪费时间截图了，只再给出一张截图证明一下：

由于NASYUN的篇幅限制，请看楼下，第九节【关于绿联UGOS Pro系统的必要破解】，精彩继续！

f541883216 · 发表于 2026-1-12 01:59

第九节

关于绿联UGOSPro系统的必要破解

我在做前面的破解试验时，使用dx4600机型的facroty.tar激活信息文件，在rootfs.squashfs根文系统中恰好不含绿联对这个dx4600机型的防范内核模块。因此，我一路下来并没有遇到什么障碍和地雷需要破解。但是，后来朋友给的dxp4800plus机型的facroty.tar激活信息文件，启动时就遇到地雷出现了问题。必须通过摘除rootfs.squashfs根文系统里的地雷程序，才能正常启动。

在绿联的根文系统里，绿联其实安放了许多地雷程序的。对于有些机型，特别是高端机型。例如：DXP4800 Plus、DXP6800Plus、DXP6800Pro、DXP8800、DXP8800Plus、DXP8800Pro、DXP480TPlus。

在我做dxp4800 plus机型试验时，一个有趣的现象引起我注意。我想做为增长破解经验故事分享给大家。

在设定测试用QEMU虚拟机的-smbios参数机型时，使用的大小写字符居然会对绿联的系统判断有影响。当我使用小写：dxp4800 plus参数机型时，QEMU虚拟机仿真可以正常启动，但进入Web的初始化管理界面时，机型的图标没有了。截屏如下：

当我使用大写：DXP4800 Plus参数机型时，QEMU虚拟机仿真启动会引发加载ug_gpio_btn.ko内核模块。因为不是绿联的硬件，该模块会误测所有button都是长时间触发的。它引发/etc/acpi/actions/button.sh事件，F24reboot系统会重启哦。

这显然是绿联的前后台程序判断有问题。应当是一个bug吧。可能是绿联的开发人员没有想到，有人会通过修改-smbios参数的机型用QEMU虚拟机来仿真运行系统吧，所以没有注意到会有大小写机型参数这个问题。我也算是帮助绿联QA测试了一把它的系统吧。

从上面的现象可以看出，绿联系统中肯定有地雷需要破解。与硬件绑定的内核模块在用QEMU虚拟机来仿真时是没有用的，如果不删除的话，引发/etc/acpi/actions/button.sh事件，F24reboot系统会重启。仿真运行就不能实现。

于是，我必须用squashfs-tools 工具来拆包绿联的ugospro-rootfs.squashfs根文件系统。进行仔细的分析。squashfs-tools工具可以非常容易地安装到Debian系统。使用如下命令即可：

sudo apt-get install squashfs-tools

安装后，就可以方便地解包/打包绿联的squashfs根文件系统了。可以使用unsquashfsugospro-rootfs.squashfs命令来拆包。解包后，在当前目录下会产生一个squashfs-root的子目录。修改里面的文件就可以了。修改后可以使用mksquashfssquashfs-root rootfs.squashfs.update -comp xz -Xbcj x86命令重新打包。

在仔细研究了绿联的squashfs根文件系统后，发现了一些问题。比如：前面故事提到的，机型参数大小写的问题。我在/usr/sbin/目录中找到了相关的程序ug-load-drive.sh，我发现只要用小写字符的机型参数，就不会加载内核模块（ug_gpio_btn.ko和它的depend）。所以不用费事做任何的破解改动了。

关于/etc/acpi/actions/目录下的button.sh程序，这个是针对绿联按钮触发事件的程序。该程序在用QEMU虚拟机仿真时完全没有用途。建议破解时删除这个没用的程序。可以在重新打包绿联的squashfs根文件系统后时删除，也可以在绿联系统启动后，通过控制台删除，就不用可以在重新打包绿联的squashfs根文件系统了。但是这个删除时临时的，是通过启动时overlay覆盖的删除。

第十节

吐槽绿联UGOSPro系统的绿联应用服务程序包

绿联ISO刷机镜像中提供了14个基础应用服务程序包。这些都是绿联开发人员所做的工作。我发现，这些服务程序包有一个共同的特点，就是它的二进制执行文件都非常巨大。最小的也是几兆字节尺寸的文件。仅仅14个用于Web界面管理的基础包，压缩后的ugreen.bz2居然360M-420M以上。

根据我多年破解嵌入式Linux的经验，这种代码的风格，我猜测可能是用Golang语言开发出来的。

我粗粗查看了某些文件，基本80%可以确认绿联开发基础包用的是Go 1.23.1X的版本。还没有升级到Golang 更新的版本。

Golang比较适合做Web的后台应用开发，Golang开发的两个优势：

相比于C/C++，开发效率有所提高，对开发人员的水平要求不高，Go语言有大量的预制模块库，使编成开发效率大大提高。弄点鸡头，鱼刺，蘑菇腿这类的开发人员搭建个草台班子就能抵挡一阵子。好像绿联以前的主要产品线是硬件吧。Golang语言内置垃圾回收、异步函数、闭包等。另外，各种内置的库很容易和web端集成，很适合快速搭建大型Web系统。静态链接，做到了应用部署和OS版本完全解耦。

但使用Golang 语言开发的应用程序也有致命的缺点。它的编译工具链会全静态链接构建二进制文件，把标准库函数和第三方package 全部做了静态编译，再加上Go 二进制文件中还打包进去了runtime 和GC(Garbage Collection，垃圾回收) 模块代码，所以即使做了 strip 处理( gobuild -ldflags "-s -w" )，生成的二进制文件体积仍然很大。每一个二进制文件里面包含动辄几千个函数。运行起来极其耗费系统硬件资源。对于像NAS私有云这样的小型家用系统，用Golang语言开发基础包合适吗？绿联NAS的硬件一般都要求8M以上的内存，好在绿联以前做硬件的底子不差。这可能与使用Golang语言开发的应用服务程序包有关吧。

这里我想给出一个具体的”Hello World” 例子来对比一下C语言与Go语言编译成机器代码，并剔除标号(Stripped)的机器代码尺寸。

看到了吧，对于”Hello World”的例子。后者几乎比前者大了1000倍。对于解决简单的打印输出”HelloWorld”这类编成问题，C语言的机器代码效率几乎是Go语言的1000倍。类比绿联的应用服务程序包，它虽然不能等价于”HelloWorld”这样简单的例子，但写过Web前后台管理程序的朋友们都知道，像NAS私有云这样的小型家用NAS系统的Web管理界面，并非是什么大型复杂的Web系统。绿联的应用服务程序包选用Go语言来开发，是不是有点用牛刀杀鸡的感觉。

我也分析过其它很多的NAS系统，他们的固件包也就200M-400M左右，不像绿联的固件包。例如：绿联ISO刷机镜像有1.5G这么大。绿联的仅区区14个基础应用服务程序包，就比有些NAS系统整个固件包都大。这意味着什么呢？是功能更强大吗？非也，从用户的实践体验并没有出来啊。那么，唯一的解释就是绿联系统程序的机器代码冗长，效率低下。其实，还不仅仅是基础应用服务程序包，有些其它/usr/bin或/usr/sbin中的二进制代码，也是用Go语言写的。

如果应用服务程序包改用其它语言来开发的话，例如：php; ruby; python；c/c++等等。不但对硬件的要求可以降低，运行效率将大大提高。但需要经验丰富的开发人员团队才行。

绿联的UGOSPro系统启动起来非常慢，跟威联通有一拼。但是人家威联通加载了非常多的服务，绿联仅仅是基础服务，就如此之慢，与应用服务程序包用Go语言开发不无关系。

以上仅仅是本人的观点和偏好，不妥之处敬请批评指正。

结论与破解/破译存在的问题

这次仅仅是对绿联新推出的UGOSPro系统破解的初步探索，并为大家分享目前的进展情况。以前绿联的系统登录都离不开绿联的服务器的这个致命缺点，在新的UGOSPro系统中改掉了。可用性与安全性有了一定的提升。但是系统并没有大的结构性改进提升。对比我在第一节回顾的结构分析，可以看到UGOSPro系统除了将基础的linux内核从OpenWrt系统，变成了DebianGNU/Linux 12 (bookworm)之外，应用服务程序包开发改用Go语言了。但并没有结构性改动。” squashfs”格式的根文件系统，与overlay的结构方式也没有变化。第三分区的factory.tar设备必要私密敏感信息文件与旧系统一样。没有任何改变。

此次仅仅是初步破解，并没有对factory.tar设备必要私密敏感信息文件进行破解。因此，需要用QEMU虚拟机来模拟绿联所需的硬件的BIOS信息。如果要在实体机上运行这个破解，需要实体机能够刷写硬件的BIOS信息。主要是DMI type 1这一节的内容。

Handle 0x0001, DMI type 1, 27 bytes

System Information

Manufacturer: UGREEN

ProductName: DXP4800

Version:AD0X0190

SerialNumber: **

UUID: 6104c5c2-80f4-4d24-88f3-41ef2b416d01

Wake-upType: Power Switch

SKUNumber: Default string

Family: UGREEN NAS

包括：Manufacturer，Product Name，Version，Serial Number，Family这五个值。

现在的情况是如果你想安装测试绿联的UGOSPro系统，关键是找到一个factory.tar文件。这个文件中有所有需要的私密敏感信息。（设备名，激活码，sn序列号，网卡Mac地址关联，等等。所有QEMU启动脚本需要的信息，这里面都有）文件很小，只有8K左右。我估计应该不难找到吧。有很多人把绿联的硬件刷机成其他的NAS了，这个私密敏感信息设备序列号等也就废了。

绿联云系统最近推出了新系统UGOS Pro。虽然它欠缺打磨，实在还不足以称其为一个好用的NAS系统。依然是非常小众的NAS系统之一。所以还不足以花费时间和精力去做深入地factory.tar设备必要私密敏感信息文件的破解。

目前破解/破译存在的问题：

我在试验时发现，有的时候，在QEMU虚拟机上，ATA硬盘被系统认为是”外部存储”。以前的数据盘，卷，被认为是”外部存储池”。因此，目前的系统会出现，检测不出硬盘的问题。

这个问题当然可以通过改写启动脚本，使用硬盘直通的办法来解决。但需要占用硬件上的一块硬盘。反正，我也不会使用这个系统，仅仅是研究分析而已。这并不影响我对绿联系统发分析研究。如果你要安装使用它。目前的情况是，只能采用虚拟机硬盘直通方式。暂不能用虚拟硬盘。

通过几次试验，我发现使用硬盘直通任然无法解决检测不出硬盘的问题(brand=Intel;model=VK0300GDUQV)[Intel SSD DC S3500 Series]，可能是它不在/etc/nas_storage/disk_db.db可用磁盘列表中吧。因此暂时只能说，问题可能于ISO镜像中的第六分区绿联应用服务程序包有关系。我把upk包全部换成1150版本的旧包，就没有检测不出硬盘的问题了。但是又有一些其它不影响分析研究的小问题，因为我们只是分析研究绿联的系统结构，并不会去使用它。

后来，我又仔细分析了一下绿联的storagemgr基础包，终于发现如何解决这个问题了。原来是1150版本没有限定磁盘的/etc/nas_storage/disk_db.db，而1895版本已经有了这个限定的数据库。我没有中间的版本，不知道绿联从什么时候做的这个改动。通过修正这个disk_db.db数据库就可以解决问题了。这个修正，可以通过overlay实现，不需要改动只读的根文件系统。

此次破解/破译绿联系统时间比较仓促，从5月29日拿到朋友给的UGOSPRO-USB-1.0.0.8-1895-release.iso这个刷机ISO镜像到6月15完成这篇文章，大约用了16天时间。两个星期多一点。由于希望尽快给朋友一个结论，所以文章难免有很多不足之处。也可能存在不少错别字，没有仔细校对。请大家多提宝贵意见，对文章中的错误，敬请批评指正。

后记

根据2024年6月网上的报导，绿联的NAS正式开售仅3天，号称“开启智能存储新纪元”的绿联科技DXP系列私有云新品，在用户的一片差评声中黯然“下架”。有资深NAS（网络附属存储）用户猜测，绿联急于发布未打磨完善的产品，或许是想抢占618年中大促节点。

绿联NAS翻车始末：动机值得鼓励，但表现像个草台班子。

绿联这次dxp系列全系最低用上了n100的cpu，我对这个芯片还是很看好的，是一个功耗比较低的x86全能cpu。绿联这次使用了全新的Debian系统。

Debian系统是一个服务器常见的linux系统，之前绿联用的openwrt，这个openwrt虽然也是linux系统，但是阉割了非常多的东西，因为openwrt作为一个目标是路由器的系统，没必要加入很多不必要的应用包和组件，但是作为一个nas来说，如果想要支持安装应用、应用商店还有更深度的开发来说，Debian作为nas系统肯定更好一些。这也是为什么大家对这次绿联的系统备受期待的核心原因，换了Debian内核。

目前可以说绿联NAS还不够成熟。这种级别的负面影响几年内可能都无法扭转，未来购买绿联nas的人都会想起这天被支配的恐惧，即使口碑慢慢变好，以后去冲绿联nas新品的人也会想起曾经的恐惧。

系统不稳定

系统频繁崩溃、闪退。

多位用户反馈Docker首次安装运行异常，需重装。

SMB服务不稳定，文件传输时易断开。

Web端卡顿严重，操作反应慢。

功能缺失或失效

下载中心无法使用，资源添加后无反应。

硬盘休眠功能无效，硬盘频繁读写。

相册AI问题，导致相册路径丢失、相册识别不准确。

媒体播放功能差，4K视频播放卡顿，无法加载外挂字幕。

备份功能不可靠，手机照片备份缓慢且容易出错。

用户体验差

系统操作复杂，基本功能缺失或无法正常使用。

界面设计不合理，文件管理、相册等交互逻辑存在硬伤。

客户服务响应慢，技术支持不到位。

应用中心资源缺乏，预装应用功能不全。

绿联NAS 还出现了重大安全缺陷：竟然把私有云 TLS 证书和私钥全部公开，可能导致用户被中间人劫持从而窃取账号密码并引起 NAS 中的数据泄露。从该事件中可以看出来绿联 NAS 团队连最基本的网络安全常识都没有，将大量用户和私密数据暴露在风险中。

我在分析破解/破译绿联的系统时，也发现了诸多的问题。这里仅仅举一个小小的例子。绿联产品的序列号。在我写这篇文章的时间点，绿联官网发布的最新升级包“UGOSPRO_OTA_DIFF_1.5.0.2628-release.img”，里面居然泄露了100个产品的序列号。这些泄露是由该升级包的"/usr/ugreen/etc/.white_sn_list.txt"白名单文件给出的。我读了相关的程序，系统启动时会把机器的序列号填写到白名单文件中。这个文件是以“.”开头的隐藏文件，估计是开发团队在删除时只是使用了简单的 rm –rf * 这样的命令。遗留来该开头的隐藏文件吧。

不晓得绿联为什么给我们大家这100多绿联序列号。是怕我们做黑绿联缺少sn呢？还是没有仔细检查升级包，不小心泄露呢？只有老天爷知道！哈哈！

既然绿联这样慷慨，我就把这些序列号分析给大家吧。

游客，如果您要查看本帖隐藏内容请回复

jssk · 发表于 2026-1-13 08:42

感谢大佬的无私奉献，科普很详细，让菜鸟容易理解

cxx0233 · 发表于 2026-1-13 08:56

感谢大佬的无私奉献。。。。

naoki66 · 发表于 2026-1-13 08:57

感谢大佬学习一下很详细

茄子jun · 发表于 2026-1-13 09:12

感谢大佬的分享！感谢大佬的分享！

10467106 · 发表于 2026-1-13 09:49

啥也不说了，感谢楼主分享哇！

az101010 · 发表于 2026-1-13 11:30

辛苦了，多谢大佬分享。

原创【老骥伏枥-马年大礼包】破解/破译绿联UGOS Pro系统初探

#楼主# 2026-1-12 01:58

绿联UGOS Pro系统NAS的启动盘结构刨析

使用破解的UGOS Pro系统启动盘

关于绿联UGOS Pro系统的必要破解

NAS发烧友

技术达人

编辑能手

突出贡献

活跃会员

关于作者

楼主新帖

分享到：

个人中心