中国DOS联盟

到这里已经混了两年了，刚来的时候基本只会cd和del那些命令，
for都不会用（感叹号的意思我大概是 09 年之后才明白的 -_-``），
热心人的帮助 + 潜水学习 + 浓厚的兴趣使得我现在知识有了很大的提高，
各种语言都学了些，对知识的运用也更加灵活，
相比之下我更喜欢vbs脚本，因为有更多的现成的功能可以拿来用，还可以与网页中使用。

今天正好是注册两周年，于是做这么个东西来纪念一下，是用 vbs 编写的。
作为加密解密工具，自己当然要保护起来，于是就不公开源代码了，
并且把他包装成一个exe命令行工具，这样就几乎不能被破解了。

我把它叫做 “小文件加密解密器”（Small File Encoder and Decoder），
因为设计它仅仅是为了操作小的文件，尤其是文本文件，
但我没想到它真的只支持小文件，大文件非常之慢，而且无法正确解密，
我大概试了一下估计上限在25KB左右，很尴尬。。。
好在支持二进制文件且效果很好，加密后面目全非，保密性很好。

具体用法就不说了，我已经把它做成命令行的样式，
你可以像一般的命令那样去查看帮助和使用它，但是不支持 “|” 管道传参数进去。

没有万能密码，如果设置了密码并且忘掉那就没办法了。
欢迎尝试破解并提出建议，以便改进它。

题外话：
在测试的时候我新建了个文本，输入 "abcde123我草" 这几个字(不含引号)，保存之后，加密在解密，发现是乱码，于是重新看了好久的程序代码查问题，后来我发现这几个字保存之后本来就是乱码，真是折腾坏了。。。

[ Last edited by qinchun36 on 2010-4-23 at 15:01 ]

支持一下.

多谢楼主的小东东，同时请教楼主，能否说说用vbs制作命令行工具时，如何进行参数的传递，就类似bat中％1，％2那样？

唉！……

Originally posted by jarry0932 at 2010-4-26 00:32:
多谢楼主的小东东，同时请教楼主，能否说说用vbs制作命令行工具时，如何进行参数的传递，就类似bat中％1，％2那样？

一般来说用下面这种方式就足够了：

WScript.Echo "总共有 " & WScript.Arguments.Count & " 个参数。"

WScript.Echo "%0=" & WScript.ScriptFullName

WScript.Echo "%1=" & WScript.Arguments(0)

WScript.Echo "%2=" & WScript.Arguments(1)

保存为 test.vbs ，在CMD窗口中试试

cscript -nologo test.vbs 目录 %cd%

cscript -nologo test.vbs 目录 "%cd%"

我来支持一下！
没抢到沙发！

呵呵,两年的坚持,祝贺你学有所成

支持一下，我现在就在 CD. DEL 接阶段

Originally posted by qinchun36 at 2010-4-23 02:55 PM:
题外话：
在测试的时候我新建了个文本，输入 "abcde123我草" 这几个字(不含引号)
...

Win XP sp3环境测试正常，没有出现LZ说的问题

PS:qzwqzw兄的文本加解密工具也不错，加解密后的文件大小一样
CF: http://www.cn-dos.net/forum/viewthread.php?tid=31054
而楼主的加密后要大约5倍

多谢指点，再顶一下

Originally posted by radem at 2010-4-27 13:32:
PS:qzwqzw兄的文本加解密工具也不错，加解密后的文件大小一样
CF: http://www.cn-dos.net/forum/viewthread.php?tid=31054
而楼主的加密后要大约5倍

这是一个问题，之所以大这么多，是因为有一道工序采用了系统自带的BASE64算法，它编码处理之后就已经超过5倍了，然后我为了更保密，又加了一点东西，于是就那么大了。

不过我主要是看效果，没注意效率，就算你的文件只有几个字节甚至是一个字节，比如一个空格，别人都没法从加密后的文件里猜出原文，因为就算是同一个文件用同样的密码，每次加密后的结果都不一样。。。

飘然路过

很感兴趣
可惜下载试用后出错
对话框提示“0x00423214”指令引用的"0x00000000"内存。该内存不能"read"。
命令行提示“Exception EAccessViolation in module SFED.exe at 00023215.
Access violation at address 00423215 in module 'SFED.exe'. Read of address 00000
000.”

大概猜测一下原理
首先用base64将源文件转换为ascii文件
但正统的Base64编码是把3个8位字节转化为4个6位的字节
所以理论体积增大倍数为4/3，约1.3倍
而不是5倍之多
除非之前已经用其它方法将源文件ASCII化再对其进行base64

至于加密算法作者没有透露
我也不能随意猜测
但如果加解密是用同样的密码
那么就应该是对称加密算法
而这类算法里面除了使用超长字典的变态算法之外
其它算法的安全性应该都是比较差的
无法达到军用甚至商用的要求

至于同一个文件用同样的密码
每次加密后的结果都不一样
我猜是加了一些随机因子
很可能跟系统时钟有关
而且这个因子应该隐藏在密文之中
否则解密逻辑就无从判断了

另外
程序自身使用了ScriptCryptor加密
网站在这里http://www.abyssmedia.com
有兴趣的可以解解看看