U+深度隐藏毫无意义
本帖最后由 hhh333 于 2013-5-4 10:23 编辑P大和Z版对这种方式似乎很推崇，近期也拜读了他们的大作，作了一些试验，U＋了不知道多少次，经验当然要分享！这里主要讨论U＋深度隐藏。因牵涉到grldr，因此还是发在这个区。
1、首先看一下U＋的几种隐藏方式有什么特点
隐藏方式U盘写入的区域是否分区及DG下可读大文件是否要求连续是否支持PXE启动能否找到外置
隐藏前端√×××
高端隐藏后端√×
深度隐藏前端×√
（这里讲不能找到外置当然是指不额外使用隐藏区挂载工具时的情况）
深度隐藏是没有分区信息的（或者说分区表被移动了），因此会产生严重的问题：
①EZB和Syslinux可以出菜单，但PE1.x启动时会提示ntdetect错误，PE3/4会提示BCD错误，实际就是说setupldr和bootmgr等根本不认这个没有分区信息的分区；
②grldr不经过处理也不能读取这个分区的文件，当然也不能启动；
目前，这种隐藏方式下用EZB和syslinux可以启动DOS映象和Slitaz Linux。
2、对grldr进行一些改造
这是pseudo解决这个问题的思路：1、找到隐藏分区的分区表项信息（第97扇区末）
2、解析分区表项，得到分区起始扇区、总扇区数等信息
3、将隐藏区映射为一个虚拟软盘
4、直接访问虚拟软盘上的文件，启动PE
核心grub4dos代码：
dd if=(hd0)96+1 of=(md)768+1 bs=1 count=8 skip=502
set /a pe=*393216 && set /a ps=*393220
map (128)%pe%+%ps% (17)
map --hook
rootnoverify (17)
#now you can load PE from (fd17)
根据这个意思，我对grldr的默认菜单进行了改写：pxe detect
configfile
default 0
timeout 1
title find /menu.lst, /boot/grub/menu.lst, /grub/menu.lst
errorcheck off
configfile /boot/grub/menu.lst
configfile /grub/menu.lst
if "%@root%"=="(ud)" && calc *0x82A0=*0x82b9&0xff
dd if=(hd0)96+1 of=(md)768+1 bs=1 count=8 skip=502
set /a pe=*393216 && set /a ps=*393220
map (hd0)%pe%+%ps% (fd3)
map --hook
rootnoverify (fd3)
if "%@root:~1,1%"=="f" && find --set-root --devices=f /menu.lst && configfile /menu.lst
find --set-root --ignore-floppies --ignore-cd /menu.lst && configfile /menu.lst
find --set-root --ignore-floppies --ignore-cd /boot/grub/menu.lst && configfile /boot/grub/menu.lst
find --set-root --ignore-floppies --ignore-cd /grub/menu.lst && configfile /grub/menu.lst
errorcheck on
commandline
title commandline
commandline
title reboot
reboot
title halt
halt为了方便阅读和提高兼容性将17改为fd3（不超过有的BIOS实际承认的软驱数），经过这么改造以后，确实多数机器可以出菜单，但我一台i3的挂了两个硬盘的机子，直接死机。出菜单以后的表现与EZB和syslinux相似，PE都不能启动，即控制权转交给setupldr和bootmgr后还是不能读文件！
后又看P大的菜单，用的是整体启动，即映射为软驱后，再将ISO映射为(0xff)，之后再启动其上的PE，失去了他原先作品的解开、整体都没有问题的特点。
3、其他两种隐藏方式除nativePE和非RAMPE不能启动外，启动其他形式的PE没有问题，特别是启动阶段加上bootpart工具后找外置也没有问题（基于这个原因我认为U＋比UD更具优势）。
通过以上的试验可以得出如下结论：
1、隐藏主要是为了保护启动文件，因此使用一般隐藏和高端隐藏就够了，没必要弄什么深度隐藏，如果只用DOS工具linux可以考虑这种方式（我个人认为一般隐藏应该兼容性更好，因为启动区在U盘前端）；
2、即使对grldr默认菜单进行改造，深度隐藏方式的兼容性也是最差的，不用说老机，就是有的较新的机器可能连菜单也出不了；
3、比较切合实际的做维护的办法还是准备2个U盘，容量大的做U＋隐藏或高端隐藏，容量小的做UD，前者对付新机，后者对付老机；
以上观点当否，请大家发表意见！
看来UD开发速度跟不上形式啦！开发者需要大大滴更新呀。不过俺还是用UD，用着方便，一个fbinsttool就能日常够用了。 hhh333 发表于 2013-5-5 11:17 static/image/common/back.gif
我这台NF3的机器反正是有问题，目前U+只能用USBHDD+方式就能正确识别为HDD，其它的任何组合如V2或隐藏等 ...
完全不是你说的那样。你只要能够启动 grldr，那就表明你没有遇到实质性的困难。
如果有实质性的困难，BIOS 故意设置障碍，让 dos、syslinux、ud、grub4dos 等无法进入，那么你根本就不能进入 grub4dos 的环境。
只要能够进入 grub4dos 的环境，那就说明，谢天谢地，这里没有根本性的问题，全都是可以解决的。虽然有某些问题，但那都属于小毛病，通过认真设置、完善，都是可以解决的。当然，前提是，你想去解决。如果你选择放弃，那当然就是无解了。
zhaohj 发表于 2013-5-4 14:03 static/image/common/back.gif
set /a pe=*393216 && set /a ps=*393220
是没有问题的，取地址的值。
(md)768，是否有问题，这块地址 ...
set /a pe=*393216
读出来的数据有可能是64位的,必须考虑这种情况.....
不点 发表于 2013-5-4 11:37 static/image/common/back.gif
你们都忽略了，不久以前在本版有讨论，说下面这句，在 grub4dos 新版下是错误的：
set /a pe=*393216 && ...
set /a pe=*393216 && set /a ps=*393220
是没有问题的，取地址的值。
(md)768，是否有问题，这块地址能随便写吗？
改成(md)0x200+1
上面地址也相应调整。 U+高端隐藏支持UEFI启动,这才是他的亮点. 你们都忽略了，不久以前在本版有讨论，说下面这句，在 grub4dos 新版下是错误的：
set /a pe=*393216 && set /a ps=*393220
所谓的“成功率不高”，估计都是由此引起的。
请用正确的写法来写以上这一行。请查找以前的讨论。
也请知道的人，给出正确的语句，避免他人继续使用错误的语句。
U+深度隐藏区感觉类似于UD扩展区，但U+启动的兼容性貌似低于UD
我用一块U盘，一块SD卡反复测试了+隐藏/高端隐藏/深度隐藏，在新机器和一台05年的老服务器上反复做过各种测试，现在选用的还是UD+手动添加末端隐藏区的方式
如果UD扩展区可以设置为一般隐藏属性就好了，这样在保留UD高启动成功率的同时可以支持UEFI 对u+隐藏无爱。。。。 于夜大一样“对u+隐藏无爱。。。。” 哇！看贴长知识呀。虽然有些听不懂… 我不同意标题的说法。“毫无意义”，这样的词汇，感情的色彩太浓厚了，不冷静。
任何技术，都有其优缺点。不能因为其缺点的存在就否认了其优点的存在，也不能因优点而抹杀缺点。
深度隐藏是开发者的一个开发实践，目的是提供不同的选择，让用户使用。这与 bean 开发 ud 技术，以及 grub2、syslinux 等等，都是平行的、一样的。
对了！要说隐藏还是Ud隐藏的更好吗？ U+深度隐藏和UD隐藏，都是抹掉分区表，所以，PE内核一定要打包，不能解开。同时都不能被未来的Uefi引导识别。所以，暂时只能算bios时代的东西。
U+深度隐藏，怎么改进代码，grub似乎兼容性都不太好，实测都能不达到万能启动，除非从grub内核改进支持U+深度隐藏。但自家的easyboot良好兼容U+深度隐藏，bootpart也可挂载U+V2-hdd深度隐藏区，但不能可挂载U+V2-zip深度隐藏区。个人感觉，对于U+深度隐藏，似乎是对新电脑而言，选用easyboot做第一引导，可以放心的深度隐藏，但功能又比grub功能差多了。
最后，个人在想，syslinux能识别并引导U+深度隐藏区，grub内核一定也要改造，让它识别引导。这才是根本。然后等bootpart解决挂载U+V2-zip深度隐藏区区问题，以后U+深度隐藏才会有真正的技术应用。 菜单以后的表现与EZB和syslinux相似，PE都不能启动，即控制权转交给setupldr和bootmgr后还是不能读文件！
nt5引导和nt6引导根本不认识这种抹掉分区的隐藏区，UD也是这个样子，你怎么叫他们读取下一个文件，真是强人所难。这种PE，内核打包成iso来map是王道，easyboot中直接run *.iso就行了.
谢谢楼主改进grub对U+深度隐藏的代码，改天测试一下。 本帖最后由 zds1210 于 2013-5-4 11:30 编辑
个人并不达到什么狂热的态度，只是希望技术上有 点进步，大家一起来努力，让U+深度隐藏在bios时代达到实用阶段。
但uefi时代来临，UD和U+深度隐藏都是末路了，因为uefi根本不可以识别引导这种抹掉分区的隐藏分区。唉。才是问题的根本。
个人现在比较推荐的是U+B+高端隐藏加uefi双启动技术，立足于bios，面向uefi时候。
额！…软件跟不上硬件的发展看来就的淘汰。不过我这些老电脑来说UD就是个宝贝。 不点 发表于 2013-5-4 11:37 static/image/common/back.gif
你们都忽略了，不久以前在本版有讨论，说下面这句，在 grub4dos 新版下是错误的：
set /a pe=*393216 && ...
是的，经测试，这段代码在新grub失效，希望P大更新。
我用老版的，弄到fd3试一下，能不能解决有一些机子的兼容性问题。 本帖最后由 zds1210 于 2013-5-4 16:07 编辑
深度隐藏的PE像U+深度隐藏和UD
优点是明显的：
1.分区信息抹掉了，最安全，最不怕病毒，最能防误删除和误格式化。
2.兼容性不错。UD+grub在一起，有良好的兼容；U+V-hdd深度隐藏引导+easyboot，基本上能在绝大部分机子 上启动，从这个意义上来说，兼容性不错。
缺点也明显的：
1.PE内核一定要打包,会带来种种未知的兼容性问题，特别是NT5PE，ud如此，U+深度隐藏也是这个样子。两者都要加map =n参数解决。
2.因隐藏区不能被uefi识别引导，不管是UD还是U+深度隐藏，不能用于未来的uefi时候，也是这种深度隐藏PE的最大短板。这也决定了它只是bios下的 产物。
3.U+深度隐藏，如果grub做分区引导，目前来看，兼容性并不好，身边好多机子都引导不
了。
目前，准备根据H大的改进代码，推出一个支持U+V2深度隐藏的统一模块，大家来测试改进。如果再不改进，等bios机子再退休了，研究U+V2深度隐藏就没有多大意思了。 支持U+B+高端隐藏加uefi双启动技术！！！ chenall 发表于 2013-5-4 15:40 static/image/common/back.gif
set /a pe=*393216
读出来的数据有可能是64位的,必须考虑这种情况.....
请C大帮助修正一下，我等菜菜有福了。 zds1210 发表于 2013-5-4 16:08 static/image/common/back.gif
请C大帮助修正一下，我等菜菜有福了。
看了下P大的代码用8个F值相与一下就可以截掉64位数据。 本帖最后由 zds1210 于 2013-5-4 16:32 编辑
hhh333 发表于 2013-5-4 16:22 static/image/common/back.gif
看了下P大的代码用8个F值相与一下就可以截掉64位数据。
我对grub代码不太通 ，都是抄人家用的，你帮我修正一下，我改天用下。
最好分老版本grub和新版本grub啊，分开写。 确实不能说是毫无意义。专业的维护人员还是多准备一些U盘和PE吧。 哇…！这话题很火呀，紧随置顶帖。有要水的没？ 本帖最后由 zhaohj 于 2013-5-5 15:00 编辑
grub4dos代码：
dd if=(hd0)96+1 of=(md)0x200+1 bs=1 count=8 skip=502
set /a pe=*0x40000&0xffffffff&& set /a ps=*0x40004&0xffffffff
map (128)%pe%+%ps% (17)
map --hook
rootnoverify (17)
#now you can load PE from (fd17)
看来大家对这个U+隐藏还是很关心，建议 楼主把标题改一下，改成“再进一步研究” 本帖最后由 zds1210 于 2013-5-4 17:28 编辑
zhaohj 发表于 2013-5-4 17:07 http://bbs.wuyou.net/static/image/common/back.gif
grub4dos代码：
dd if=(hd0)96+1 of=(md)0x200+1 bs=1 count=8 skip=502
set /a pe=*409600&0xffffffff ...
用最新版的grub，测试失败。
玩量产还是挺不错的！{:3_137:} 刚才下掉一个硬盘，原来用不起的i3的机子可以用了。 拿铁不加糖 发表于 2013-5-4 12:51 static/image/common/back.gif
U+高端隐藏支持UEFI启动,这才是他的亮点.
难道只有U+高端隐藏才支持支持UEFI启动，普通隐藏不行么 风神 发表于 2013-5-4 22:08 static/image/common/back.gif
难道只有U+高端隐藏才支持支持UEFI启动，普通隐藏不行么
U+不隐藏对uefi兼容性最好，其次是普通隐藏，再次是高端隐藏。稳定性及安全性相反。 zds1210 发表于 2013-5-4 22:10 static/image/common/back.gif
U+不隐藏对uefi兼容性最好，其次是普通隐藏，再次是高端隐藏。稳定性及安全性相反。
不知普通隐藏与高端隐藏的区别