请问下有没有办法用批处理或者命令行小程序确定系统引导分区？

秋水长天369 · 发表于 2021-1-15 18:05:01

谢谢分享

liuzhaoyzz · 发表于 2021-1-15 17:23:15

本帖最后由 liuzhaoyzz 于 2021-8-12 09:13 编辑

527104427 发表于 2021-1-13 18:27
发现之前有几处输出弄错了，搞成错误输出了，导致批处理捕捉不到任何东西，再改一下吧：

5大，我用360扫描m大的pecmd，然后找了个PECMD原始.EXE，这个不报病毒，集成你的源代码，好像不报病毒了，就是比较大，1.4MB，x86版本的。怎么你制作出来的这么小？原始文件784KB，386KB是加壳压缩了吗？
[MPRESS V2.00-V2.0X -> MATCODE Software * Sign.By.fly * 20090423]

m大的pecmd，https://www.lanzous.com/b279972/，里面有个目录是免杀版，根本不是免杀版本。

我不懂，瞎折腾的。

dos时代菜鸟 · 发表于 2021-1-15 17:22:07

本帖最后由 dos时代菜鸟于 2021-1-15 17:41 编辑

liuzhaoyzz 发表于 2021-1-15 16:29
这个版本，在一台电脑上面运行是对的。

Bcdedit 还是不准确，有问题

bcdedit 的 volume 序列与 diskpart 不一致。看来不能用 bcdedit 了

dpy.44.7z (2.35 KB, 下载次数: 20)
这个是不带 bcdedit 的，感觉，不用 aip ，着个效果已经是极限了。

liuzhaoyzz · 发表于 2021-1-15 16:29:08

dos时代菜鸟发表于 2021-1-15 15:54
确实如此，
只是考虑在脚本开始时，检测下必要的外部命令是否存在。来确保程序运行。

这个版本，在一台电脑上面运行是对的。

dos时代菜鸟 · 发表于 2021-1-15 15:54:39

本帖最后由 dos时代菜鸟于 2021-1-15 15:58 编辑

CodeHz 发表于 2021-1-15 15:30
其实没必要绕一圈，可以直接按我说的方法测试两个路径下的bcdedit那个存在就用哪个

确实如此，
只是考虑在脚本开始时，检测下必要的外部命令是否存在。来确保程序运行。

dpy.43.7z (2.67 KB, 下载次数: 11)

plusv · 发表于 2021-1-15 15:36:29

CodeHz 发表于 2021-1-15 15:17
我认为根本不用检测，直接尝试两个路径（sysnative, system32）就好了

反应一个小问题

SmartMountFirmware X64 多了一个 pdata 区段,
删了运行也正常,还省了 512 Bytes.

CodeHz · 发表于 2021-1-15 15:30:08

dos时代菜鸟发表于 2021-1-15 15:27
64位下调用 32位 cmd 可以运行
%windir%\sysnative\ 这个路径下的 bcdedit 。

其实没必要绕一圈，可以直接按我说的方法测试两个路径下的bcdedit那个存在就用哪个

dos时代菜鸟 · 发表于 2021-1-15 15:27:09

本帖最后由 dos时代菜鸟于 2021-1-15 15:50 编辑

CodeHz 发表于 2021-1-15 15:03
思考了以下你可以先尝试 %windir%\sysnative\bcdedit ，失败再尝试 %windir%\system32\bcdedit ，再不行 ...

64位下调用 32位 cmd 可以运行
%windir%\sysnative\ 这个路径下的 bcdedit 。

dir %windir%\sysnative\bcdedit.exe 也能找到

dos时代菜鸟 · 发表于 2021-1-15 15:22:43

liuzhaoyzz 发表于 2021-1-15 15:12
这个不太合适。我用32位的bcdedit在64位的系统里面，的确可以运行，但是需要加/store参数指定BCD的位置 ...

嗯嗯，那还是不能自备，就只能先这样了。
最好 64位系统，通过64位程序运行之，当然 64位系统下的32位下也能运行，只是在特定情况下可能找不到数据。

liuzhaoyzz · 发表于 2021-1-15 15:19:33

CodeHz 发表于 2021-1-15 15:09
哦，也对，不过判断架构不是可以用 PROCESSOR_ARCHITECTURE 吗（
所以先检测架构，是32位再检测WoW

用PROCESSOR_ARCHITECTURE来判断cmd的位数，是很多人的误解，正确的结果是用%PROCESSOR_IDENTIFIER%的前三位是否是x86来判断。否则在32位的文件浏览器（比如MDIE，比如qq文件管理器，网络管理器，以及一些32位的打包安装程序内嵌的安装包）就会出错。
@echo off
rem 判断64位系统和32位系统
echo %PROCESSOR_IDENTIFIER%
if /i %PROCESSOR_IDENTIFIER:~0,3%==x86 (
echo 32位操作系统
) else (
echo 64位操作系统
)
pause

%PROCESSOR_ARCHITECTURE%对于64位系统，PROCESSOR_ARCHITEW6432=AMD64，这是一个确定的值。

但是对于64位系统32位的cmd，PROCESSOR_ARCHITECTURE=x86
对于64位系统64位的cmd，PROCESSOR_ARCHITECTURE=AMD64，还有可能是安腾IA-64
这是两种结果，这两种结果对应着cmd的位数，只要是x86，就一定是32位的cmd；只要不是x86，就一定是64位的cmd，这才是我们想要判断的。

dos时代菜鸟 · 发表于 2021-1-15 15:18:21

liuzhaoyzz 发表于 2021-1-15 14:59
你这个判断不对，在XP下面运行，结果是当前环境是64位系统下的64位环境。
xp下面，%ProgramFiles%=C:\Pr ...

64位上的64 和 32位上的32 ，找文件都到一个地方就是 windows\system32 ,所以无所谓

CodeHz · 发表于 2021-1-15 15:17:29

本帖最后由 CodeHz 于 2021-1-15 15:18 编辑

dos时代菜鸟发表于 2021-1-15 15:15
这是个不错的办法，判断位数，再看看有没有特定文件夹。

另外，在查找文件这个问题上，64位上 ...

我认为根本不用检测，直接尝试两个路径（sysnative, system32）就好了

dos时代菜鸟 · 发表于 2021-1-15 15:15:51

CodeHz 发表于 2021-1-15 15:09
哦，也对，不过判断架构不是可以用 PROCESSOR_ARCHITECTURE 吗（
所以先检测架构，是32位再检测WoW

这是个不错的办法，判断位数，再看看有没有特定文件夹。

另外，在查找文件这个问题上，64位上的64 和 32位上的32 都到一个地方去找文件，就是 windows\system32 也就是没有区别的。

liuzhaoyzz · 发表于 2021-1-15 15:12:42

dos时代菜鸟发表于 2021-1-15 14:51
这里面的情况还真多。

改进了一下。

或者自备一套 bcdedit+diskpart+chcp ,但这样做体积就大了。

这个不太合适。我用32位的bcdedit在64位的系统里面，的确可以运行，但是需要加/store参数指定BCD的位置，而64位系统里面c:\windows\system32\bcdedit.exe会自动“关联”系统的那个BCD。而且感觉不同系统的bcdedit显示的结果，还有区别。如果能用系统的最好还是用系统的。

CodeHz · 发表于 2021-1-15 15:11:33

dos时代菜鸟发表于 2021-1-15 15:09
xp 下这个已经不重要了，因为 xp 下根本没有 bcdedit 也就不用考虑这个问题

不是，你这个逻辑的问题在于，纯32位的win7，8，8.1，10的ProgramFiles变量也是没x86的（

CodeHz · 发表于 2021-1-15 15:09:31

liuzhaoyzz 发表于 2021-1-15 15:06
不是考虑64位的xp啊，是32位xp下面，运行dos时代菜鸟的批处理，显示结果却是“当前环境是64位系统下的6 ...

哦，也对，不过判断架构不是可以用 PROCESSOR_ARCHITECTURE 吗（
所以先检测架构，是32位再检测WoW

dos时代菜鸟 · 发表于 2021-1-15 15:09:27

本帖最后由 dos时代菜鸟于 2021-1-15 15:10 编辑

liuzhaoyzz 发表于 2021-1-15 15:06
不是考虑64位的xp啊，是32位xp下面，运行dos时代菜鸟的批处理，显示结果却是“当前环境是64位系统下的6 ...

xp 下这个已经不重要了，因为 xp 下根本没有 bcdedit 也就不用考虑这个问题
判断版本 >=6 的，才会去判断是不是 64下的 32 ，如果是，就不找 bcdedit.
而如果 <6 的版本，直接就不会去找 bcdedit

liuzhaoyzz · 发表于 2021-1-15 15:06:56

CodeHz 发表于 2021-1-15 15:03
思考了以下你可以先尝试 %windir%\sysnative\bcdedit ，失败再尝试 %windir%\system32\bcdedit ，再不行 ...

64位 xp 根本不用考虑吧。。。这东西不兼容的地方多了

不是考虑64位的xp啊，是32位xp下面，运行dos时代菜鸟的批处理，显示结果却是“当前环境是64位系统下的64位环境”。
我没安装过64位的XP。

CodeHz · 发表于 2021-1-15 15:03:48

dos时代菜鸟发表于 2021-1-15 14:51
这里面的情况还真多。

改进了一下。

思考了以下你可以先尝试 %windir%\sysnative\bcdedit ，失败再尝试 %windir%\system32\bcdedit ，再不行就报告
应该就可以了（

liuzhaoyzz · 发表于 2021-1-15 14:59:51

dos时代菜鸟发表于 2021-1-15 14:30
先看看这个方法能不能判断出

你这个判断不对，在XP下面运行，结果是当前环境是64位系统下的64位环境。
xp下面，%ProgramFiles%=C:\Program Files

dos时代菜鸟 · 发表于 2021-1-15 14:51:37

本帖最后由 dos时代菜鸟于 2021-1-15 14:57 编辑

liuzhaoyzz 发表于 2021-1-15 14:49
确实64位操作系统里面，微软只提供了64位的bcdedit，位于c:\windows\system32\bcdedit.exe。

这里面的情况还真多。

改进了一下。

这样64位下的32位调用，就不能通过 bcdedit 来获取目标分区了，就有概率获取不到数据。
不过这总比运行不了要强一些。

或者自备一套 bcdedit+diskpart+chcp ,但这样做体积就大了。

liuzhaoyzz · 发表于 2021-1-15 14:49:39

dos时代菜鸟发表于 2021-1-15 14:41
但是 %programfiles% 就不一样，他总不至于在32位下去调用 64的程序去吧，
看这个变量，就知道了。

...

确实64位操作系统里面，微软只提供了64位的bcdedit，位于c:\windows\system32\bcdedit.exe。

32位的操作系统里面微软只提供了32位的bcdedit,位于c:\windows\system32\bcdedit.exe

liuzhaoyzz · 发表于 2021-1-15 14:44:12

dos时代菜鸟发表于 2021-1-15 14:18
可以通过判断变量 %ProgramFiles% 来判断，如果是带 (x86) ，一定是 64位下的32位cmd

哦，这个办法可行。

dos时代菜鸟 · 发表于 2021-1-15 14:41:03

本帖最后由 dos时代菜鸟于 2021-1-15 14:49 编辑

CodeHz 发表于 2021-1-15 14:13
看图就很明确了

wow64重定向就是让你看起来像是在真的32位环境跑

但是 %programfiles% 就不一样，他总不至于在32位下去调用 64的程序去吧，
看这个变量，就知道了。

dpy.42.7z (2.61 KB, 下载次数: 9)

因为 64位系统下的 sysWOW64 里面没有 32位的 bcdedit.exe
所以改进了一下

dos时代菜鸟 · 发表于 2021-1-15 14:30:09

liuzhaoyzz 发表于 2021-1-15 14:15
32位的文件管理器，很容易重现，比如你把你的批处理发给qq上面的任意一位好友，然后从qq的文件管理器里面 ...

cmd_path.7z (270 Bytes, 下载次数: 6)
先看看这个方法能不能判断出

dos时代菜鸟 · 发表于 2021-1-15 14:18:44

liuzhaoyzz 发表于 2021-1-15 14:10
我用了奇技淫巧解决32位的第三方资源管理器下面调用c:\widnows\system32\下面的程序，就是用创建软链接， ...

可以通过判断变量 %ProgramFiles% 来判断，如果是带 (x86) ，一定是 64位下的32位cmd

CodeHz · 发表于 2021-1-15 14:18:01

liuzhaoyzz 发表于 2021-1-15 14:15
32位的文件管理器，很容易重现，比如你把你的批处理发给qq上面的任意一位好友，然后从qq的文件管理器里面 ...

其实主动调用 SysWoW64 里的cmd就是跑的32位的cmd了（（可以通过ProcExp看到访问的相关目录全都是重定向的）

liuzhaoyzz · 发表于 2021-1-15 14:15:55

dos时代菜鸟发表于 2021-1-15 14:07
这是改过的

32位的文件管理器，很容易重现，比如你把你的批处理发给qq上面的任意一位好友，然后从qq的文件管理器里面双击这个批处理，这时候就是在64位系统里面调用的32位的文件管理器。在网络浏览器比如搜狗浏览器的下载窗口下载的批处理双击的时候调用的也是64位系统里面的32位的文件管理器。

BCDedit did not find BCD_VOL！不知道是不是正常的？

CodeHz · 发表于 2021-1-15 14:13:56

dos时代菜鸟发表于 2021-1-15 14:07
这是改过的

看图就很明确了

wow64重定向就是让你看起来像是在真的32位环境跑

liuzhaoyzz · 发表于 2021-1-15 14:10:38

dos时代菜鸟发表于 2021-1-15 14:01
用你这个 32位文件管理器，打开cmd 看下他的 ComSpec 是多少？
我们可以改下路径，到cmd 的解析路径找 ...

我用了奇技淫巧解决32位的第三方资源管理器下面调用c:\widnows\system32\下面的程序，就是用创建软链接，然后修改cmd解释器的指向的办法解决问题的。创建软链接之后，ComSpec=C:\Windows\system32\cmd.exe

@echo off
rem 因为在MDIE里面双击bat/cmd文件默认调用的是32位的c:\windows\syswow64\cmd.exe，可能会导致批处理运行异常，因此优先改用64位的c:\windows\system32\cmd.exe。xp和32位系统不存在此问题，直接跳过。
ver|find " 5."&& goto :next
if /i %PROCESSOR_IDENTIFIER:~0,3%==x86 goto :next
md c:\windows\Sysnative 1>nul 2>nul
mklink c:\windows\Sysnative\cmd.exe c:\windows\System32\cmd.exe
reg add "HKCR\batfile\shell\open\command" /ve /d "C:\windows\sysnative\cmd.exe /c \"%%1\" %%*" /f
reg add "HKCR\cmdfile\shell\open\command" /ve /d "C:\windows\sysnative\cmd.exe /c \"%%1\" %%*" /f
:next

		自动登录	找回密码
密码			注册

请问下有没有办法用批处理或者命令行小程序确定系统引导分区？

点评

点评

点评

点评

点评

点评

点评

点评

点评