找回密码
 注册
搜索
系统gho:最纯净好用系统下载站投放广告、加入VIP会员,请联系 微信:wuyouceo
查看: 392|回复: 24

[原创] 利用GRUB4DOS实现替换注册表文件调用SNAPSHOT恢复系统

[复制链接]
发表于 昨天 13:37 | 显示全部楼层 |阅读模式
本帖最后由 天风 于 2026-7-10 16:30 编辑

本办法仅技术讨论,不做为常规使用,请注意电脑数据安全!!!


目的:利用GRUB4DOS实现替换注册表文件调用SNAPSHOT恢复系统

方法:
1、在WIN系统下运行SNAPSHOT恢复系统,实际上是在注册表中注入了SNA映像的路径,在下次启动时调用snapnative.exe进行恢复映像。

2、在WIN系统用SNAPSHOT工具恢复映像,不要重启,把windows\system32\config\目录下的system复制出来命名为system.bak备用

3、在windows\system32目录下找到snapnative.exe复制出来备用

4、附件中的grub4dos的EFI版本是咱们论坛的会员2011yfrui作品grub-2.14 单文件 GRUBX64.EFI 启动器
https://bbs.wuyou.net/forum.php?mod=viewthread&tid=449632&extra=page%3D1


使用:

1、把EFI目录放到ESP分区,bootx64.efi实际就是grub4dos的EFI版本。可以任意改名,引导时调用menu.lst实现恢复。
2、把snapnative.exe复制到正常系统windows\system32目录下
3、把system.bak复制到正常系统windows\system32\config\目录下(此处如果没看明白,请移步14楼看详细做法

4、添加EFI引导菜单项Recovery OS,引导目标设置为grub4dos(BOOTX64.EFI),就可以在需要恢复的时候引导grub4dos进行恢复系统

菜单:
=====================================

timeout 10
default 0

title [ 1 ] Recovery OS
find --set-root /Windows/system32/config/system.bak   找到注册表备份文件
dd if=()/Windows/system32/config/system.bak of=()/Windows/system32/config/system  通过DD命令覆盖替换注册表文件
reboot   重启系统,snapnative.exe会自动恢复注册表路径中的sna映像文件
=====================================
希望大家积极讨论本办法可行性。不喜勿喷。
SNAP秒还原文件架构.7z (141.13 KB, 下载次数: 13)
01.png
02.png
附件中WINDOWS目录中为空白文件,仅展示目录和文件结构。
EFI目录中的BOOTX64.EFI可以任意改名







评分

参与人数 2无忧币 +10 收起 理由
l3429900 + 5 很给力!
it323 + 5 赞一个!

查看全部评分

发表于 昨天 13:47 | 显示全部楼层
支持探索与研究。
回复

使用道具 举报

发表于 昨天 13:49 | 显示全部楼层
了解学习一下,谢谢!
回复

使用道具 举报

发表于 昨天 14:07 | 显示全部楼层
支 持 原 创
回复

使用道具 举报

发表于 昨天 14:14 | 显示全部楼层
看了楼主的文章,长见识啊
回复

使用道具 举报

发表于 昨天 14:57 | 显示全部楼层
多谢楼主经验分享,学习了!!增进不少!
回复

使用道具 举报

发表于 昨天 15:09 | 显示全部楼层
和当年雨林木风的onekey一键恢复原理很相似,区别在于onekey好像只支持MBR引导
回复

使用道具 举报

发表于 昨天 15:12 | 显示全部楼层
感谢楼主分享。
回复

使用道具 举报

发表于 昨天 15:13 | 显示全部楼层
我不知道自己有没有看懂,感觉上这个方法像是个低层替换,利用了SnapShot的 Native 还原机制。核心方向看上去对的,但实现方式比较粗暴,容易出问题。整个 SYSTEM hive 完整替换的风险很高,system.bak 里包含了当时整个系统的配置(服务、驱动顺序、CurrentControlSet 等),不只是还原触发器。替换后会把很多系统状态回滚到做 .bak 那一刻,导致某些服务、驱动大概率直接失效了。Hive 文件本身有 .LOG1/.LOG2 事务日志,直接 dd 覆盖主文件可能导致 Windows 认为 hive dirty,启动时修复失败或报错。

GRUB4DOS 的写入,这个写法:
find --set-root + dd if=()/... of=()/... 在简单单硬盘情况下OK,但多硬盘、GPT、隐藏分区、动态磁盘环境下很容易找错分区。
GRUB4DOS 的 NTFS 写入不是最明智的实现,况且菜单里没有备份当前 hive 的步骤,异常断电或写入中断文件系统直接就挂了。

Secure Boot在GRUBX64.EFI 几乎肯定没签名,必须要彻底先关掉。BitLocker完全不要想了。说实话菜单非常简陋,没有分区确认、文件存在性检查、写入后验证等。重启以后如果还原失败,系统可能卡在中间状态,需要在PE下重新手动还原。

点评

可以用dd写入bcd来避免这个问题。bcdedit有个loadoptions选项,可以给ntoskernel传递cmdline。再写个native程序解析cmdline。  详情 回复 发表于 昨天 16:38
你的理解非常正确。 1、system.bak 里包含了当时整个系统的配置(服务、驱动顺序、CurrentControlSet 等),不只是还原触发器。替换后会把很多系统状态回滚到做 .bak 那一刻,导致某些服务、驱动大概率直接失效了。  详情 回复 发表于 昨天 15:22
回复

使用道具 举报

发表于 昨天 15:13 | 显示全部楼层
谢谢分享
回复

使用道具 举报

 楼主| 发表于 昨天 15:22 | 显示全部楼层
lbw2007 发表于 2026-7-10 15:13
我不知道自己有没有看懂,感觉上这个方法像是个低层替换,利用了SnapShot的 Native 还原机制。核心方向看上 ...

你的理解非常正确。
1、system.bak 里包含了当时整个系统的配置(服务、驱动顺序、CurrentControlSet 等),不只是还原触发器。替换后会把很多系统状态回滚到做 .bak 那一刻,导致某些服务、驱动大概率直接失效了。
这句话解释一下,bak文件和当时备份系统的映像应该是完全致一样,不一样也无所谓,因为它起的作用只是告诉SnapShot的 Native 在还原时的映像路径,恢复映像以后已经回到备份时的状态。

2、GRUB4DOS 的写入,这个写法:
find --set-root + dd if=()/... of=()/... 在简单单硬盘情况下OK,但多硬盘、GPT、隐藏分区、动态磁盘环境下很容易找错分区。
GRUB4DOS 的 NTFS 写入不是最明智的实现,况且菜单里没有备份当前 hive 的步骤,异常断电或写入中断文件系统直接就挂了。
DD的写法的确有点简单粗爆,只是通过查找备份的注册表文件名称来确定分区,进行替换覆盖。

3、签名问题就不考虑了。
=======================================================
只是在考虑和大家讨论这个办法的可行性,直接在引导前实现简单恢复,不用在WINDOWS下来回折腾。

点评

我重新表述一下我的意思,你说得有道理)。我的意思是核心区别在于这个替换是“临时/过渡性”的,而不是永久性的。比如: 1、你在 Windows 里发起 SnapShot 还原(不重启)。此时 system 文件已经被工具修改,里面注  详情 回复 发表于 昨天 15:34
回复

使用道具 举报

发表于 昨天 15:34 | 显示全部楼层
天风 发表于 2026-7-10 15:22
你的理解非常正确。
1、system.bak 里包含了当时整个系统的配置(服务、驱动顺序、CurrentControlSet 等) ...

我重新表述一下我的意思,你说得有道理)。我的意思是核心区别在于这个替换是“临时/过渡性”的,而不是永久性的。比如:
1、你在 Windows 里发起 SnapShot 还原(不重启)。此时 system 文件已经被工具修改,里面注入了还原触发器 + .sna 映像路径。
2、你把这个修改后的 system 复制成 system.bak。
3、之后用 GRUB4DOS 把 system.bak 覆盖回磁盘上的 system=>重启。
这一次启动,Windows 加载的是 .bak 里的 SYSTEM hive(里面服务、驱动顺序、CurrentControlSet 等都是做 .bak 那一刻的状态)。
snapnative.exe 被触发执行,开始用 .sna 映像覆盖整个系统分区。
还原完成后系统重启(或直接进入还原后的状态),这时加载的已经是 .sna 映像里自带的注册表,而不是你之前 dd 进去的那个 .bak。

但snapnative.exe 在执行还原的早期阶段,可能依赖某些驱动或服务。如果 .bak 里的配置让这些关键驱动加载失败,snapnative.exe 可能在开始覆盖文件之前就出问题,导致还原中断。
某些早期启动组件(Session Manager、还有别的,我也忘了叫什么了)如果在 .bak 里被改得面目全非,也可能影响 snapnative.exe 的执行环境。所以你说得很对,这个 .bak 里的完整系统配置只在中间这一次启动起作用。它的主要任务就是“告诉 snapnative.exe 去哪里找 .sna 映像并执行还原”。一旦还原成功并重启,系统就回到 .sna 备份时的状态了(包括当时的注册表、服务、驱动等)。中间那次 hive 回滚带来的服务/驱动配置差异,理论上不会影响到最终还原后的系统。

结论是最终状态不会受影响。但中间那次启动的 hive 必须得“足够健康”,能让 snapnative.exe 顺利跑起来。

点评

可能我说的备份SYSTEM.BAK不够清楚,我下面详细说一下。 假定 1、 2026.7.10 14:00 这时的系统为正常工作系统,备份好的映像为001.sna。 system(001) 2、 2026.7.10 14:10 这时的系统为SNAPSHOT恢复映像完成  详情 回复 发表于 昨天 15:51
回复

使用道具 举报

 楼主| 发表于 昨天 15:51 | 显示全部楼层
本帖最后由 天风 于 2026-7-10 15:53 编辑
lbw2007 发表于 2026-7-10 15:34
我重新表述一下我的意思,你说得有道理)。我的意思是核心区别在于这个替换是“临时/过渡性”的,而不是 ...

可能我说的备份SYSTEM.BAK不够清楚,我下面详细说一下。

假定
1、 2026.7.10  14:00 这时的系统为正常工作系统,备份好的映像为001.sna。  system(001)

2、 2026.7.10  14:10  这时的系统为SNAPSHOT恢复映像完成,等待重启,此时  system(002)为所需要的system.bak

3、在PE下把2状态下的拷贝出来的system.bak,并复制到状态1的系统中,再次备份为001.sna.

完成

点评

我之前理解有偏差,你把整个准备流程说清楚后逻辑一下就顺了。  详情 回复 发表于 昨天 15:54
回复

使用道具 举报

发表于 昨天 15:54 | 显示全部楼层
天风 发表于 2026-7-10 15:51
可能我说的备份SYSTEM.BAK不够清楚,我下面详细说一下。

假定

我之前理解有偏差,你把整个准备流程说清楚后逻辑一下就顺了。
回复

使用道具 举报

发表于 昨天 16:25 | 显示全部楼层
这么曲折都能发现,太强了
回复

使用道具 举报

发表于 昨天 16:38 | 显示全部楼层
lbw2007 发表于 2026-7-10 16:13
我不知道自己有没有看懂,感觉上这个方法像是个低层替换,利用了SnapShot的 Native 还原机制。核心方向看上 ...

可以用dd写入bcd来避免这个问题。bcdedit有个loadoptions选项,可以给ntoskernel传递cmdline。再写个native程序解析cmdline。

点评

哇,大元帅来了,请帮忙考虑一下这个native恢复如何完美的利用起来,从而达到不用在WIIN下反复折腾的目的。  详情 回复 发表于 昨天 16:44
回复

使用道具 举报

 楼主| 发表于 昨天 16:44 | 显示全部楼层
wintoflash 发表于 2026-7-10 16:38
可以用dd写入bcd来避免这个问题。bcdedit有个loadoptions选项,可以给ntoskernel传递cmdline。再写个nati ...

哇,大元帅来了,请帮忙考虑一下这个native恢复如何完美的利用起来,从而达到不用在WIIN下反复折腾的目的。
回复

使用道具 举报

发表于 昨天 17:01 | 显示全部楼层
谢谢楼主分享
回复

使用道具 举报

发表于 昨天 17:04 | 显示全部楼层
了解学习一下!
回复

使用道具 举报

发表于 昨天 17:23 | 显示全部楼层
一起浇一浇,灌一灌,预祝一天心情好!
回复

使用道具 举报

发表于 昨天 18:06 | 显示全部楼层
感谢分享经验
回复

使用道具 举报

发表于 昨天 18:34 | 显示全部楼层
感谢楼主分享
回复

使用道具 举报

发表于 昨天 18:51 | 显示全部楼层
谢谢你!你发的帖子很精彩。
回复

使用道具 举报

发表于 昨天 19:34 | 显示全部楼层
学习学习
回复

使用道具 举报

发表于 昨天 21:55 | 显示全部楼层
感谢分享
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1|闽公网安备35020302032614号 )

GMT+8, 2026-7-11 05:52

Powered by Discuz! X5.0

© 2001-2026 Discuz! Team.

快速回复 返回顶部 返回列表