本文Tags: 未知设备, 离开模式

上次导师给我用的HP的台式机原来是正版Windows Media Center（可直接升到Vista），我嫌装了一大堆HP的垃圾软件，刚拿到手就格了。后来自己找了驱动，装了一晚上的XP（听说HP的机器都不带驱动盘），网卡、显卡、声卡等等都装好了，就是多出来一个未知设备。
今天终于知道原来是“离开模式”：ARPC Devices MS ArACPI
离开模式（Away Mode）是Media Center 2005 更新汇总2新增的一种电源状态，也会在Windows Vista中提供。离开模式组件并不随Media Center 2005 更新汇总2 安装，而是由OEM（原始设备制造商）使用微软提供的AwayMode-KB902347-xxx.exe安装程序预安装在支持此技术的媒体中心电脑上。此功能并不能在普通电脑上使用，而需要OEM定制特殊的BIOS。
启用时，离开模式会替代休眠模式，也可设置为进入离开模式一段时间自动进入休眠模式以进一步节约电能。

在离开模式中：

★计算机仍然可以执行任务，如录制预定的电视或流媒体到网络上的位置
★不再输出显示信号
★系统静音
★暂停播放媒体（实时电视除外）
★可以正常使用Media Center Extender
★计算机看起来已经关闭，但实际上在运行（S0状态），处于低电源消耗状态
★当用户按下遥控器上的休眠按钮，可以立即打开显示器回到正常状态
★可以设置为阻止HID和PS/2设备输入（避免小孩和宠物搞破坏）
★当插入闪存设备（U盘、存储卡等）时，会立即唤醒回到正常状态
★当插入光盘时，会立即唤醒回到正常状态
★中央处理器和显示芯片进入低功耗但不影响功能的状态（需要硬件及驱动程序支持）
★提醒内核模式和用户模式的组件切换状态，比如显卡降频工作、即时消息软件(MSN Messenger)切换用户的状态
★OEM可以指定让电源指示灯关闭
★OEM可以指定计算机中的风扇仍然工作、放慢速度或者停止转动

微软知识库——“离开模式”说明（英文）：
http://support.microsoft.com/kb/902437
微软知识库——“离开模式”已知问题（英文）：
http://support.microsoft.com/kb/909311
HP网站关于“离开模式”的说明（英文）：
http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=bph01013#bph01013_awaybph01013_away

相关日志

• 无相关日志.

本文Tags: bug, Copy, 命令, 解决

先来看看copy的语法：

C:\Documents and Settings\Administrator>copy /?
将一份或多份文件复制到另一个位置。

COPY [/D] [/V] [/N] [/Y | /-Y] [/Z] [/A | /B ] source [/A | /B]
[+ source [/A | /B] [+ …]] [destination [/A | /B]]

source 指定要复制的文件。
/A 表示一个 ASCII 文本文件。
/B 表示一个二进位文件。
/D 允许解密要创建的目标文件
destination 为新文件指定目录和/或文件名。
/V 验证新文件写入是否正确。
/N 复制带有非 8dot3 名称的文件时，
尽可能使用短文件名。
/Y 不使用确认是否要改写现有目标文件
的提示。
/-Y 使用确认是否要改写现有目标文件
的提示。
/Z 用可重新启动模式复制已联网的文件。

命令行开关 /Y 可以在 COPYCMD 环境变量中预先设定。
这可能会被命令行上的 /-Y 替代。除非 COPY
命令是在一个批文件脚本中执行的，默认值应为
在改写时进行提示。

要附加文件，请为目标指定一个文件，为源指定
数个文件(用通配符或 file1+file2+file3 格式)。

其中，file1+file2+file3还是挺好用的，我一般拿来合并JS脚本，比如：
copy bianbian.main.js + bianbian.DOM.js + bianbian.other.js bianbian.src.js /Y
jsmin <bianbian.src.js >bianbian.js
（用jsmin来删除注释缩进等等，让代码小一点）。

不过，现在发现多文件合并有bug：
1）合并以后在文件末尾会产生一个奇怪的字符（十六进制ASCII码为”1A”），如果直接引用这个js，则任何浏览器都会报错。不过这个字符用jsmin了以后就会被删除，所以这个bug倒并不要紧

2）如果这些文件格式是UTF-8的，合并的时候不会删除每个文件的UTF-8头声明，导致解析出错。我们知道UTF-8格式的文件会用“FF FE”开头（可以看做UTF-8声明），而copy只是简单地将所有文件的ASCII码合并，所以合并后的文件正文也会有“FF FE”。这样，会导致每个源文件第一行的脚本解析出错（比如function，会解析成 ?unction，此处问号表示不认识的字符。不过这个解析目前只在Opera下发现出错）
。解决的办法是每个源文件的第一行都留空，不要写脚本。

相关日志

• [原]解决qmail+iGenus webmail中文UTF-8乱码 (2)
• [原] 也许是prototype框架的bug (0)
• [转]windows xp一些命令 (0)
• [原] 解决 libXp.so.6 找不到的问题 (1)
• [原]iframe跨域访问解决方案 (3)

本文Tags: VPN, 端口映射, 远程桌面

先看完我的测试。。。。。
先介绍一下，家里有个没有显示器的台式机连在路由上天天下BT，平时用笔记本双机互联在台式机上上网。
1) telnet挂站测试：
小百合BBS可以登录三个窗口，于是：
笔记本->远程_家里台式机 登一个；
笔记本->远程_家里台式机->VPN南大校内->远程_实验室机器 登一个；
笔记本->远程_家里台式机->公司路由端口映射->远程_公司机器 登一个
2) 连环测试：
笔记本->远程_家里台式机->公司路由端口映射->远程_公司电脑->家里路由端口映射->远程_家里台式机->远程_笔记本(xp，把自己踢了)

相关日志

• [转]帝国时代2端口映射 (0)

本文Tags: Windows, 命令

自己要用，备忘一下：
服务： services.msc
设置自动登录： rundll32 netplwiz.dll,UsersRunDll
关闭对zip文件支持： regsvr32 /u zipfldr.dll
撤消视频预览： regsvr32 /u shmedia.dll

相关日志

• [原]windows命令Copy合并多文件的bug及解决 (1)

本文Tags: ARP, ARP欺骗

今天和danny一起试了一下p2pOver（网络执法官也属于此类），一开始都觉得很奇怪：交换机不像hub，已经不广播了，怎么还能控制别的机器的流量呢。。。好玩，研究一下。用数据截取软件(wireshark)查看了一下，其他都正常，却发现狂发了N多ARP（Address Resolution Protocol、地址解析协议）包。看来问题就出在这里。
ARP欺骗原理
再仔细看了一下ARP数据包，终于恍然大悟欺骗原理。
是这样的，为了能和其他机器通讯，局域网上的各个机器都缓存了ARP列表（ARP列表可以简单理解成“一个IP地址对应一个MAC地址”）。机器要通过网关和其他机器通讯，其实是在局域网内发了查询ARP请求（可以简单理解成“网关啊，请把你的MAC地址告诉我好吗？”）；网关收到此类请求后，就会发送ARP回应报文，回应网关的MAC。这样，某个机器就会把通讯数据发到网关的MAC上。
那么运行了p2pOver之类的软件后是怎么欺骗的呢？简单起见，我们设使用了p2pOver的机器为”A”，”A”的MAC地址为”M”。
首先，”A”通过ARP查询得到真实的网关MAC，和不停地轮询局域网上其他主机（IP）及其MAC。
其次，”A”不停地给局域网上其他主机发送伪造的ARP回应报文：告诉他们网关的MAC是”M”；
同时，”A”也不停给交换机发送伪造的ARP回应报文：告诉真正的网关局域网上所有主机的MAC地址为”M”。
因为是不停地发送报文，到了最后：局域网上的其他主机以为网关就是”A”，真正的网关以为局域网上的所有通讯只来自”A”。也就是”A”变成了事实上的中转中心：不仅可以截取其他主机的流量和数据，还能随心所欲地截断网络通讯。
ARP欺骗防治
从欺骗原理，不难推出防治关键就是想办法不接收错误的ARP回应报文：
1) 使用智能交换机，绑定网内所有IP-MAC。这样也就不需要ARP查询才能知道MAC。
2) 还有一个办法，就是在网内所有机器上绑定死网关的MAC（下面适用于WinXP）：
在网络正常情况下：arp -a 网关IP（如192.168.1.1），查询到正确的网关MAC
然后绑定网关MAC：arp -s 网关IP 网关MAC
在执行arp -a，看到网关IP和MAC是静态（Static）的，就可以了：

相关日志

• 无相关日志.

本文Tags: 木马

从来不装杀毒软件，我也从来不乱装东西，乱看网页。基本上没事。不装杀毒软件是因为这个不仅会拖慢系统，而且是个马后炮，真正厉害的病毒来了大家一起挂；而且现在杀毒软件越来越像个病毒了。。。。
寒，机器被谁用了下，就被装了个木马。因为我的机器做了个代理，访问网站是有日志的。发现系统最近老是去下载某个叫816.exe的文件。感觉不对。
首先看了下任务管理器，没有奇怪的进程－－肯定注入到其他进程里了（基本上是可怜的Explorer.exe）。
用Sysinternals Process Explorer看了下，果然，Explorer.exe所有使用的DLL里有个DLMon.dll，是个奇怪的东西。google了一下，果然是个盗QQ密码的木马。
于是用Sysinternals Process Explorer杀了Explorer.exe的进程，运行cmd，cd C:\windows\system32，del DLMon.dll，居然提示没找到－－肯定又用了attrib的伎俩，那可是高中DOS时代的法宝－－于是先 attrib *Mon.dll -s -h，del DLMon.dll，这下干净了。同时system32还有一个DLMain.dll，也要删除。
再运行Explorer.exe，没有奇怪的附加DLL，基本上可以了。然后regedit，搜RunOnce，把RunOnce里和Run里莫名奇妙的一些exe启动项（包括指定的文件）给删了：
C:\windows\system32\intenet.exe （Windows正常的是internet.exe，少了个r）
C:\windows\816.exe （还有系统的temp里肯定也有）
C:\windows\Program Files\Intel\rundll32.exe （寒Intel）
OK了。如果能抓到写这些垃圾软件的，一定要大家一起动手打一顿。

相关日志

• 无相关日志.

本文Tags: bug, UltraEdit, UTF-8, 编码, 解决

我一直喜欢用UltraEdit，包括写JavaScript、HTML、python、C、JSP等等。不过UltraEdit在UTF-8的处理上有个奇怪的bug。不信你可以试一下：在记事本里输入

保存，比如test.jsp。上面是很正常的一个JSP文件，现在用UltraEdit打开，你发现什么了？
我试了各种各样版本的UltraEdit，中文都是乱码。这是怎么回事呢？
后来我想了一下，用记事本保存的文件默认是ANSI格式的，也就是我们的test.jsp实际并不是UTF-8格式的；而第一行的“charset=UTF-8”只是告诉java我们输出的是UTF-8格式。可怜的UltraEdit看了这行字以为文件也是UTF-8格式的，所以显示都是乱码。我觉得很搞笑，文件格式当然要根据实际文件存储格式来确定，怎么可以反过来呢？所以我觉得是UltraEdit的bug，并写信给UltraEdit。他们的效率真高，我第二天早上就收到回信了，并解决了我这个问题（虽然我觉得他们不默认提供这个设置真是搞笑）。冲着他们的效率，我决定以后买个正版。。。。嗯，跑题了

解决办法就是打开UltraEdit安装路径下的Uedit32.ini（如果没有这个文件，那说明你的UltraEdit版本的ini不是放在安装路径下的，得去C:\Documents and Settings\(登录用户名，默认是Administrator)\Application Data\IDMComp\UltraEdit里面找一下），在[Settings]里加上一句“Detect UTF-8 String = 0”即可（bianbian补充：在UltraEdit某版本之后，这个字符串改成了“Auto Detect UTF-8 String = 0”；你可以两个都试一下，或者都填上去），意思是禁止UltraEdit检测可能标记UTF-8的字符串，这个选项在“配置”里是没有的（不然我也不会去找他们了，呵呵）。我也建议他们以后在配置里加上这个选项，他们说会考虑，不知道现在的版本里是否已经有了，呵呵。附信件：

Dear Yuelinniao,

Thanks for your message. If you don’t want the charset declaration to be
used to determine whether or not a file is in UTF-8 format there is a
setting you can add to your uedit32.ini file to help with this. If you
open the uedit32.ini file you may add this under the [Settings] section:

Detect UTF-8 String = 0

This will prevent the referenced line from determining if a file is
recognized as being in UTF-8 format. I believe this will help.

Thanks, Troy

bianbian wrote:

> Dear support,
>
> I write to report a bug, which is making me inconvenient.
>
> When I edit a jsp file, first line is like this:
> <%@page language="java" contentType="text/html;charset=UTF-8">
> ~~~~~~
> but the file is saved on disk in ANSI format. Ultraedit maybe thinks
> the file is in UTF-8 format, and all the Chinese words of the file is
> in a state of disorder.
>
> When I take the property “Auto recognize UTF-8 format” off, the file
> is showed correctly. But when I edit another really UTF-8 format file(
> the file
> saved on disk in UTF-8 format), it is wrong again.
>
> So maybe there is a bug when Ultraedit recognizing UTF-8 format (not
> depending on the really format saved on disk)?
>
> Sorry for my poor English.
>
> Best wishes.
> Yours,
> yuelinniao

相关日志

• [原] 也许是prototype框架的bug (0)
• [原]iframe跨域访问解决方案 (3)
• [原] php读取二进制流（C语言结构体struct数据文件） (4)
• [原]C#里更改控件的显示Z顺序 (2)
• [原] PHP bug or Slackware bug? –enable-fastcgi always failed. (0)