无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站广告联系 微信:wuyouceo QQ:184822951
查看: 5832|回复: 11
打印 上一主题 下一主题

[求助] 磁盘签名的临时修改

[复制链接]
跳转到指定楼层
1#
发表于 2012-11-18 07:56:11 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
希望在启动的时候临时对硬盘mbr中的磁盘签名进行修改(只需修改1个位即可)。
目的是能够让系统认为启动盘为后来生成的虚拟盘(其磁盘签名预先设置为修改值),用于更方便的实现差分vhd-ramos。
目前研究过--in-situ参数,能够为分区临时生成mbr。但这个临时的mbr是通过代码模拟的,无法后续更改。
不知道有没有好的方法?注意不是永久修改。
2#
发表于 2012-11-18 08:44:03 | 只看该作者
不用 --in-situ,而用硬盘上的一个 IMG 映像文件来做,不就行了吗?这个 IMG 带有 MBR 和 分区表,你想怎么设计它的 MBR 和分区表都是可以的,这都是由你来决定的,每个字节都由你控制。因为它在你的 IMG 的第一扇区上,这个扇区是什么模样,仿真之后的虚拟硬盘的 MBR 就是什么模样的。

不知你为何要用 --in-situ,这个参数是给 win98 使用的,后来的 Windows 已经不支持 --in-situ 功能了。
回复

使用道具 举报

3#
 楼主| 发表于 2012-11-18 09:01:54 | 只看该作者

回复 #2 不点 的帖子

目前确实是使用img映像来实现的。想寻找更好的实现方法。
母vhd文件放在img文件中,更新起来太麻烦。
有一个类似 --in-situ的参数来临时更改mbr,可以实现更多的特殊用途。
回复

使用道具 举报

4#
发表于 2012-11-18 09:14:44 | 只看该作者
但是不止道Windows启动后是否还有G4D的代码存活?
回复

使用道具 举报

5#
 楼主| 发表于 2012-11-18 09:22:04 | 只看该作者

回复 #4 2011czmxbb52 的帖子

只要能够骗过bootmgr就行了。
回复

使用道具 举报

6#
发表于 2012-11-18 10:16:19 | 只看该作者
母vhd文件放在img文件中,更新起来太麻烦。


我认为没有多大麻烦,也许你需要寻找一个更新它的简便方法,而不是在仿真代码上动脑筋。

除了 IMG 文件的仿真以外,map 还支持把一个逻辑分区仿真为主分区,例如:

map (hd0,4)+1 (hd0)

逻辑分区之前也有一个逻辑分区表(我以前总是称之为扩展分区表)。所以,grub4dos 实际上是利用了这个逻辑分区表来实现仿真的。这个逻辑分区表被 grub4dos 仿真为主分区表(也就是虚拟化为主分区表,你明白这个意思的)。

逻辑分区表所在的那个扇区,姑且称之为逻辑引导扇区。但这个逻辑引导扇区只有逻辑分区表是存在的,其它全是 00 字节。

你用 WinHex 等 16 进制工具,可以看到逻辑分区之前确实有一个逻辑分区表。它距离逻辑分区本身的引导扇区也有 63 扇区的距离。

逻辑分区表与主分区表类似,也位于逻辑引导扇区的偏移 0x1BE 处。逻辑引导扇区中的可执行代码部分通常用 00 字节填充,但你可以修改为你想要的模样。比如,你可以修改磁盘签名的部分,你也可以为它填充上 MBR 可执行代码。操作系统不使用这些 00 字节,所以,从偏移 0 到偏移 0x1BD 的 00 字节,可以被你任意修改,你修改了它并用 map 之后,它将成为虚拟盘的 MBR。

map --hook 之后,你用 cat --hex (hd0)+1 就可以看到虚拟的 MBR 和分区表了。

-------------

既然谈到这里了,索性就把这个问题再加以引申。刚才说了,逻辑引导扇区(或者也可叫作逻辑 MBR)距离逻辑分区的开头也有 63 扇区(即,逻辑 MBR 也占用 63 扇区,即,一个磁道的长度)之遥。因此,这 63 扇区也是可以被利用的。这 63 个扇区将成为虚拟盘的 MBR 磁道。微软不使用这些扇区,所以,这些扇区几乎全都用 00 填充,只有逻辑分区表上的 64 字节加上 55 AA 标志(共 66 字节)才被微软使用。就是说,63 扇区中除逻辑分区表以外的那些 00 字节,都可以被你任意填充。填充之后,它就成为虚拟盘的 MBR 磁道了。比如说,你可以安排一个 grub4dos 的引导代码在这里,或者把 WEE 的代码放置在这里,作为虚拟盘的 MBR 引导代码。当然了,这都需要你手动操作,你还得小心,不要弄错什么,导致你的数据丢失,造成不可挽回的损失。

[ 本帖最后由 不点 于 2012-11-18 10:37 编辑 ]
回复

使用道具 举报

7#
 楼主| 发表于 2012-11-18 10:28:12 | 只看该作者

回复 #6 不点 的帖子

谢谢不点大师的指点,一直用主分区,忘了可以用逻辑分区来做文章了!
回复

使用道具 举报

8#
发表于 2012-11-18 22:31:12 | 只看该作者
需要这样的功能:
map --XXX (hd0) (hd1)
map --hook
其中XXX不是mem。
要求(hd1)的分区表可被修改,至少一个分区项(16字节)可改,但不改变(hd0)的分区表。
修改分区表的目的是获得一个仅分区表不同,其它相同的临时盘。

不知道好不好实现,或者有现成方法达到目的。如果能直接把(hd0)变为临时盘,不引入(hd1)更好。

目前--in-situ的分区表不可改,--fake-write的也改不成。

[ 本帖最后由 pseudo 于 2012-11-19 00:17 编辑 ]
回复

使用道具 举报

9#
发表于 2012-11-19 11:40:55 | 只看该作者

回复 #8 pseudo 的帖子

说说你的理由,具体的意图、用途、使用的场合。

理由要充分,要能让别人也理解,让人明白其必要性。

如果理由充分,那么实现它应该没有太大障碍。

如果理由不充分,那么还是尽量节约仿真代码空间较好,目前几乎用光了 12K 空间,如果增加的代码太多,将会超过 12K。
回复

使用道具 举报

10#
发表于 2012-11-19 13:57:50 | 只看该作者
一个直接应用是处理UltraISO的U+v2深度隐藏分区:
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=270743&extra=page%3D1

深度隐藏在把iso写入硬盘(指U盘)制作启动盘时,将分区表中隐藏分区表项清零,使grub4dos等根本不知道存在那个分区。

我试图重构分区表项,但重构的分区表不能真的写到U盘,以免破坏用户盘。

需要这样的效果:用户通过grub4dos访问U盘时,分区表内容跟真的不一样,但其它内容(海量)一样。

如果允许修改--in-situ的分区表就可以了。或者,g4d存放分区表数据的内存位置如果比较好定位,我直接改也行。

当然这个需求也不是必不可少。我现在这样处理也可凑合,只是代价稍大:
1、构造含物理盘元数据(分区表、文件分配表等)的虚拟盘
2、改虚拟盘分区表
3、g4d正常访问虚拟盘,获取盘上相关文件元数据
4、按元数据访问物理盘,获取相关文件内容
---------------------------------------------------------------------------------
这个问题先放一放吧。
我发现即使直接map --in-situ的分区表符合要求,直接map其上的iso到0xff,则0xff上的文件还是无法访问。
因为g4d访问0xff上文件,最后要转化为对hd0分区的访问,而hd0分区表项还是零,会出错。

[ 本帖最后由 pseudo 于 2012-11-19 17:09 编辑 ]
回复

使用道具 举报

11#
发表于 2012-11-19 18:04:17 | 只看该作者
我没太看明白你所说的情况。

说说我的理解,看看是否能够理解到位。

你是说,UltraISO 创建了一个隐藏分区,这个分区的分区信息抹掉了。因此,其中的所有文件(包括 ISO 文件)都无法访问了。

但是你知道分区的起始地址以及分区的总扇区数,所以,你能够重建分区表。

是这样吧?

如果确实是这样的话,根本没必要增加 grub4dos 的功能。现有的功能即可实现。

  1. map   (hd0)X+Y   (fd2)
复制代码
把那个隐藏的分区映射为软盘即可,访问软盘即可访问其中的文件。这是 grub4dos “手到擒来” 的功能,太普通了。

甚至,当你知道 ISO 文件的起始扇区 M 以及总扇区数 N 时,你还可以直接映射它:

  1. map   (hd0)M+N   (hd34)
复制代码


然后(在 map --hook 之后),访问 (hd34) 就是访问虚拟光盘。

[ 本帖最后由 不点 于 2012-11-19 18:08 编辑 ]
回复

使用道具 举报

12#
发表于 2012-11-19 23:05:31 | 只看该作者
嗯,现在不大需要折腾分区表了。
回复

使用道具 举报

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

本版积分规则

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

闽公网安备 35020302032614号

GMT+8, 2024-9-23 00:26

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

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