Shell's Home

IM之争

Dec 2, 2007 - 1 minute read - Comments

我不记得这个Title是否已经写过了,不过无所谓,因为国际形势发生了变化。 以前是ICQ和QQ争霸中国市场。后来MSN加进来一脚,ICQ淡出了。现在Fetion跑进来了。那么未来呢? 我们先看看IM软件的发展方向吧。IM最早的远亲应当是IRC和电子邮件。不过电子邮件对于服务器需求太强大,用于实时对聊做不到。IRC虽然需求小了点,但也在不可承受的范围内。随着网络的发展,大家挂网时间越来越多。所以大家要求一种廉价有效的即时通讯手段。可以和某个人对话,而不用耗费太多的服务器成本。于是,ICQ应运而生了。ICQ可以说是最初的P2P体系者,两个人聊天的时候数据都是互相发送的,只有登录的时候才和服务器通讯。这样的好处是避免了大量的服务器开销,坏处是无法穿透防火墙。 从协议上说,IM的协议互动机制和电子邮件基本是一致的。如果不介意服务器开销的话,我们可以把IM协议构架在POP3和SMTP上。对于这种倾向,有人应该感觉熟悉。那不是MSN的离线消息么?差不多。我们定义发送逻辑为,如果可以找到对方IP就找对方IP,不可以找到对方IP就给对方发送邮件。接受的时候我们就接受邮件,如果碰到特殊格式的就解析掉当做消息处理。同时如果在线则服务器会主动推送邮件消息过来(如果不这样就要非常快的定时查询新消息,非常耗费资源)。那么我们就构成了一个跨越服务商的IM方案了,并且还支持多种客户端和离线消息。例如我们通过智能手机的终端接入进来(记得么?我们的客户端其实只是个特殊点的邮件程序),那就成了无线IM。 问题是,我们动了谁的奶酪? 服务商恐怕对此会非常不高兴。大家知道,电子邮件服务商的竞争比IM残酷多了。那么多IT公司,有多少是纯粹做电子邮件做发起来的?几乎没有。为什么呢?因为电子邮件的开放性强。开放性强是历史的产物,早在主机时代邮件协议就已经固定了,而且有了大量的实现。如果哪个ISP不遵循,那么就没有用户。但是遵循标准的结果就是谁都可以被谁替代。也许某某邮箱系统的界面好看点,某某邮箱系统的容量大点,某某邮箱的速度快点,某某邮箱的垃圾少点。但是都不是不可以替代的,属于非强用户粘着性的产品。(注意我没有使用弱这个词,因为一般人习惯用一个邮箱后也就不怎么更改了)如果邮箱服务收费,ISP会发现,几乎是立刻就没有用户了—— 然而IM则是在端点时代才发展出来的,而且始作俑者不是IETF成员,IETF也没有太关注。——这捅了大篓子。现在的IM产品,几乎一个产品和另外一个无法连接。一旦你大部分的朋友使用了某种IM,你也必须被迫使用某种IM。好比贝壳虽然不喜欢QQ(这厮没Linux版本还老封锁协议),但一帮朋友都是QQ的,难道不用?这是意味着IM是扩散用户粘着的产品! 这意味着什么呢?ISP们不用推销,只要他们拥有一定的用户了,用户就会自动扩展用户群。而且你的用户不会轻易离开你,即使你收费,也有相当的用户。如果改成开放的形式,很多大型的IM商就等着客户流失吧。因为他们有相当的客户群,因此往往会收取一定的费用或者产生较多的广告。而IETF已经开始制订IM的交互协议了,即SIMPLE协议。先不说这个协议是否先进是否安全,至少这个协议是开放的。开放的协议意味低附加值的服务,因此IM商肯定会抵制协议的推行。一般的逻辑是。如果SIMPLE协议的总客户集群无法和自己的客户群比较,则不和SIMPLE互通。这样有利于维持自己的IM群,进而取得收益。如果SIMPLE协议的总客户集群已经大大超过了自身的客户群,则和SIMPLE互通。因为可以扩大自己的群,进而扩大用户。所以SIMPLE协议应该是从新兴公司开始推广的。 因此,作为一个用户来说,我更希望大家现在开始使用带有SIMPLE特征的服务。这样更有利于促使更多IM商互通服务,而且还会减少服务的费用。 从历史上说,当今的各大IM厂商自有其来。QQ是特殊历史时期的特殊软件。开始的时候其实就是简化的ICQ中文版,除了中国制造外没有什么特长。后来中国的互联网娱乐潮起,QQ向娱乐转型,主攻大众市场,结果红的发紫。MSN则是更晚时期的产物,是MS攻占全球IM市场的拳头产品,主攻的是商务市场。Fetion是中移动今年新推出的IM产品,特点是和手机互通。 就发展趋势来预期,IM主要呈现两个特点,一个是全分布化,一个是嵌入化。 虽然IM软件的工作原理对于服务器要求不高,然而很多后续服务对于服务器却有强烈需求。我们先仅仅计算基础通讯消费吧。一个人登录的时候先认证,后回传所有好友的名单,套接字。一般登录一次开销最小也要在3K上下。一般成熟的IM软件总用户量至少是1000W以上(国内市场),峰值冗余计算为五倍。计算结果就是一天的通信最少300G,最低带宽需求是20M。这还仅仅是登录造成的通讯成本。我们再考虑持续心跳激活某个特定客户端的重复时间——那这个开销就不是某个服务器所能支持的了。现在的IM服务器端,一般都是服务器组来完成这系列的需求。当然——未来的IM软件,我们的期许绝对不是仅仅1000W用户这个级别了,至少要包含国内的上亿人,加上国际的上亿人。每个IM的有效注册用户规模可能达到数亿这种恐怖规模。加上嵌入化的发展,在线时间也会越来越长。因此服务器的规模也会随之上升,进而造成IM收费时代的到来。 如果要IM持续免费,则我们就必定要发展分布式IM。简单来说,用户登录,持续心跳等等都不以服务器为中心,而以分布网络为中心。服务器只辅之以用户入口和统一的模糊查询的功能。这样会大大减轻服务器的负担,但是也会带来几个问题。 首先是用户的注册,没有用户数据库了。不过不难解决,可以让用户不需要注册。因为没有一个统一的服务器,因此用户注册只需要生成一个UUID,生成一对公私密钥,就算完成了。登录的时候即是告知别人自己的UUID,公钥和套接字即可。需要寻找一个好友的时候,可以使用UUID查询此人的套接字,具体方法请看DHT,Kademila,我上面有写的。 其次是大规模块内容的传输,简单来说其实就是传文件。这些数据如果可以直接传输则没有问题,但是在无根分布系统中,间接数据传输是要过中间机的。这样会造成中间机的网络开销。这个还要看人家乐意不乐意呢。这个没有什么好的解决方法。 最后则是安全问题。这倒不难解决,发送内容用私钥和对方公钥各加密一遍,接受用对方公钥和私钥解密就好了。第一次发送一个统一加密块,后面就用这个块加密,定时更换。兼顾了安全和效率。 IM的另外一个特点就是嵌入化,简单来说就是移植向手机上。中国的移动运营是特殊状态,不过世界的发展大致都是一样的。就是将手机发展为网络终端,然后尽量用软件解决问题。那么中国移动现在的短信优势还能持续多久就是一个非常大的问题了。当然不排除短信优势消灭前飞信拥有了新的特性的可能。

网络银行安全性的理论分析

Nov 28, 2007 - 1 minute read - Comments

最近好像用网银的人比较多阿,贝壳就做件好事,简单介绍下密码学体系。让大家了解下网银安全性的方方面面。 我们说,银行系统的安全性和易用性往往是一个磁石的南北极,不大可能出现在一个地方的。从易用性角度来说,输入用户名和取款密码直接操作的网银是最方便的。可惜,你的钱被偷的概率也是最高的。因为你和银行间的通讯过程需要流经无数节点,任何一个地方都可以轻易拿到你的登录密码。那么重复这个过程就可以登录并且操作你的钱。所以,任何一家银行都不会提供直接的登录手段。 一般来说,银行在设计网银的时候,往往会提防以下的攻击手段。社会工程学,嗅探,重复发送,钓鱼,中间人钓鱼,猜解,内部盗窃。我们先来大致了解下这些攻击手段的方法和实施条件,然后再说银行的对应手段。 社会工程学攻击是成功率最高的,技术要求最低的攻击。其要决就是一个字,“骗”!社会工程学攻击主体上就是各种骗术,例如把机器塞上,旁边写一个处理电话。等你打电话的时候,就过来一个“工作人员”。然后弄出你的卡来,说要验明你是否是卡主,问你密码。等确认好了身份,你拿到的就不是自己的卡了,那个工作人员也就拿了钱跑了。诸如此类的攻击核心要点就是骗取客户信任。所以社会工程学的对应手段只有让客户提高警惕,其他没别的好办法。 嗅探指的是从登录的机器上或者附近符合一定条件的机器上(具体是哪些需要一定的专业知识),窃取登录过程数据,并且从中还原出用户密码的手段。这种攻击往往和重复发送一起使用。无法还原密码的情况下,将原先登录的包重新发送一次。对应嗅探攻击的方法很简单,就是挑战-回应方法(Challenge-Responses)。现代加密算法有专门对应已知明文攻击的,用于对抗已经知道明文和密文情况下反解密码。服务器发送一个随机数过来,客户端加密后发送回去。服务器端核验客户端的加密结果和服务器端的加密结果,就知道客户端是否通过认证了。而嗅探者需要相当数目的明密文对才能知道密码。所以相对安全程度更高。 钓鱼是一种社会工程攻击。一般是通过邮件或者其他手段引导你到某个网站上,看上去和网银很像。等你登录想用的时候,会发现上面说网银现在正在调整。如果当时没有在意,等下次登录的时候帐户里面的钱就没了。由于窃取的是密码本身,所以挑战-回应方法无法解决这个问题。这种情况下就必须使用挑战-回应方法的变形,例如零知识验证。大致上看起来就是这样的,银行给你本很长的书,里面写什么你也不知道。然后银行问你,第512页三行15个字是啥?钓鱼收集到这个知识就没用了。但是中间人攻击还是有效的。中间人和钓鱼看起来很像,只是中间人不是窃取密码,而是窃取会话。当你以为登录到银行的时候,其实是登录到了一个中间服务器。一切你的操作其实是通过中间服务器代理上去的。当你退出的时候,中间服务器就会替换你的操作,实施一次转帐和退出。要屏蔽中间人攻击,就必须使用签名证书系统来认证服务器地址。 猜解和内部盗窃是通过对主人情况的了解来猜测或者偷窃密码/密码设备的攻击。目前没有啥好办法,只有想点自己都想不到的东西作为密码才行。生日,电话,车牌,名字,都不可以直接作为密码。当然,做一些基础变形后作为弱密码还是可以的。例如将生日倒过来作为查询密码。 目前网银的认证系统有以下几种,密码直接验证,文件证书验证,密码卡认证,手机动态认证,硬件设备认证。 密码直接认证一般使用了SSL技术来防止嗅探,但是对于钓鱼,中间人,猜解,内部盗窃都没有防护能力。一般都是各个网银的最差防护状态,为某些对安全不在意的人设计的。只是使用方便而已。 文件证书验证是利用密码和文件数字证书来验证身份的方法,对于钓鱼,中间人有比较好的防护手段。可以防止猜解,但是无法防止内部盗窃。因为文件证书为了方便起见都是存放在电脑内部的,所以文件证书的安全就又成了问题。即使是存放在U盘上,也会在使用的瞬间被复制。电脑中木马,文件或者U盘被盗拷,都是产生不安全的原因。 密码卡是某种零知识验证的变形。差不多就是给你张密码卡,刮一次能上一次。对于钓鱼有一定防护能力,但是对于中间人攻击无能为力。可以防止猜解,但是无法防止内部盗窃。 手机动态认证是通过手机收取临时动态验证码来确认客户的身份。如果要窃取客户的身份,就必须同时得到用户手机卡和用户密码。所以,也是防嗅探,钓鱼,猜解,但是不防中间人和内部盗窃。注意这里有种特殊形式,大家也许不知道,手机发送的短信是可以被特殊设备截获破解的—— 硬件设备认证则是将密钥和计算放入了特殊硬件内。银行发送挑战数到硬件上,硬件设备返回数据到银行。如果要窃取身份,就必须获得设备和密码。因此,也是防嗅探,钓鱼,猜解,但是不防中间人和内部盗窃。一般就是指银行的U盾设备,但是要注意区分U盾究竟是用来计算呢,还是用来存放密钥。后者的安全级别和文件证书一致。 我们对比各种攻击之前,先去掉两个特殊选项,社会工程和中间人攻击。社会工程某种意义上是无法防御的,你说你要把东西交给别人,银行怎么防范?拿你的生物特征?那就太麻烦了。中间人则是因为可以用CA证书验证地址有效性,因此现在很少成功。当然,也有先欺骗DNS服务器的。碰上这种蓄意的中间人攻击,差不多就和碰上人强奸一样——反抗是没意义的。这两种方法,只要是有心算无心,基本都可以成功。因此我们先去掉这两个成功么未必成功,防范么没法防范的选项。 SSL技术是网银登录的基础技术,没有的话请记得早日离开这家银行。文件证书使用方便,但是电脑一旦中木马就立刻危险。密码卡看似安全,其实对于精心设计的钓鱼还是没用的。而且使用麻烦,不如趁早不用。手机动态验证的安全性是非常高啦,可是要记得手机的安全就是帐户的安全。所以手机卡千万看住,别被人复制了。(手机卡是可以复制的,然后就可以用这个号码打电话了。当然这种事情发生概率很小,一般倒是用在一卡多号上比较多)还有手机信号问题,找个深山老林上网吧。 硬件设备认证是比较硬的方法,一般是比较完美的。可惜价格太贵。 综合下来,偷懒的可以用手机。怕事的还是用硬件。

Google Calender

Nov 26, 2007 - 1 minute read - Comments

Google有很多产品,Google Calender就是其中之一,这个东西主要的目的就是管理日历。 其实从常规角度考虑,这是最不适合bs的产品。日历的要点就是随身,谁会高兴为了看个日历找宽带上网阿。可不能不感慨Google的水平,凭着各种技术的支持,这么一个产品居然还真让我觉得好用。 Google Calender的两个核心思想就是同步和共享,同步用的是iCalender标准,共享也很类似。Google Calender的管理中,允许在多种客户端内同步Google Calender的日程。这样Google Calender就从一个不适合的产品一下变成了多个日程工具的平台标准。贝壳现在是利用他同步多个机器上的多个软件,主要的产品包括Sunbird/Lighting,raincalender,部分的手机日历,相信很多人也会做这个应用。贝壳用的就是其中的Sunbird,这个软件是Mozilla的产品之一。(贝壳现在是Mozilla的忠实用户,FireFox,Thunderbird,Sunbird三件套常备,都做了跨系统共享)不加载Provider for Google Calendar的情况下,可以读取iCalender格式的远程日历。加载插件后会多出一个Google日历的选项,用Google中的个人xml链接,保存入个人的用户名和密码(个人的gmail,带域名),然后就可以双向同步gcal了。 至于共享,在管理的时候应该可以看到和谁共享。做项目的时候,拉组员进来共享。或者没有gmail的可以用全可见加给html链接的方式。这样就可以给组员看他们的工作状态,别人的工作状态,将来的项目安排。如果组员可信任,可以给予写权限。这样他们会自动更新进度,可谓超级省事。 最后,Google Calender可以被结合入iGoogle里面,成为标准平台的一部分。

开blog宣言

Nov 26, 2007 - 1 minute read - Comments

blog供应商更改,发个新的纪念下。 msn的blog已经用了好几年了,期间也没有出过什么大问题。只是最近在Linux下面写的东西无法提交,windows下也没有格式。问了几个朋友都正常,莫非是贝壳人品问题?算了,不搞这么复杂了,听说google的产品也不错,换了算了。 就这样。

Linux和windows共享邮件

Nov 4, 2007 - 1 minute read - Comments

总算能发正常的文章了,前面发出来的老是不会断行。庆祝一下。 很多人像贝壳一样使用双系统,Linux加windows。贝壳的Linux用的是Debian,最近其中的xfce4出现一些问题。使用的时候老是死机,这日子没法过了。所以贝壳就稍微下了点功夫,先弄个好用的windows凑合一下。 windows下最难办的恐怕就是邮件了,到不是说不能收。只是windows下一个邮件状况,Linux下一个。未免讨厌了点。就算有导入导出可以转换,你想转换多少次呢? 下面贝壳就说一种方法来对付这种状况。 首先你的系统盘应当是ntfs,否则这方法不能用。然后在windows下安装ext2ifs来读取linux的home目录,假定是d:\username.mozilla-thunderbird。windows下安装类似版本的thunderbird,然后看看你的C:\Document and Setting\username\Application Data\Thunderbird下面,是否有一个profile.ini?有就对了。删除这个目录(我没说错),然后去下一个叫做junction的软件,微软出的。这个软件可以将ntfs的某个目录映射到一个目标上去,对这个目录的访问就等同于对这个目标的访问,就好像linux下面的符号链接一样。下面知道我要做什么了么? junction "C:\Document and Setting\username\Application Data\Thunderbird" d:\username\.mozilla-thunderbird 然后启动thunderbird,他首先会检查你系统中插件的版本可用性。然后你的Linux下邮件就可以用了。 简单吧?

关于程序的一点想法

Oct 13, 2007 - 1 minute read - Comments

以下内容六牙四皂小姐可以看看,至于看的懂看不懂不负责。 程序届有个说法,只有你想不到的,没有我做不到的。当然,程序是基于数学的。如果违反了数学的基础理论,程序还是无法实现的。可程序又不同于数学。说穿了,程序有一个时间,成本和环境的限制,有的时候还有法律问题。理论上说,任何一个水平足够的人都可以写一个windows出来。但是,首先是一个人写需要多少时间。其次是这些时间,还有其他投资(例如电脑)所造成的成本。然后是这个windows所能运用的环境。当然windows也许没有这个问题,可如果是程序就必须考虑适用系统(Windows,*nix),字长(32bits,64bits)等等限制。最后,一个和windows一样的系统是否会侵犯了微软的版权? 对于程序员来说,可能这些都不是问题。程序员面对的是明确的目标,环境,解决方法和框架。他们要解决的是按照构思来实现功能,并且按照算法来构建代码。例如一个播放器,对程序员来说可能就是一个确定的接口,向里面写入固定格式的数据。或者引用某种算法读取压缩数据,解压为通用数据进行播放。或者是实现解码器的注册和管理。这些都是已经被严格确定了的目标。程序员有一个固定的环境,一个统一的框架。解决方法或者是被说明的,或者是不言而喻的。 可是由一个抽象的需求来获得一个明确的目标,并且确定环境和实现方法由谁来做呢?一般这些人被称为需求分析师和系统构架师。需求分析师的工作在于帮助用户确定需求,分析需求的可能性产出(例如播放器中是否需要一个屏保屏蔽功能),分析系统的目标环境。这些任务更多的是出于用户角度考虑的,主要是我需要做什么(what, why)。系统构架师则是一个对称的职务。其主要职能在于确定如何使用目标环境中的各种技术实现目标需求,使用这些技术完成目标需要多少时间,多少成本,是否引发法律问题。等等等等。这些问题更倾向于从程序员角度考虑,主要是怎么做(how, when)。 当然可能没有这种职位,但不可能没有这种职能。有的时候分析和构架是由项目经理兼任的,有的时候是由客户驱动的(尤其是外包的时候)。至于完全没有的时候,就只有将需求分解为零散的问题,对问题求工具了。理论上说这是一种很好的方法,强大的bash语言体系其实就是由一堆解决细节问题的工具组成的。问题是,这种情况下,对于工具的使用者就提出了很高要求。往往会把工具的使用者变成另外门语言的使用者。例如我们看电影,一般用户只是点开就看而已。如果是针对问题求解,可能我们会出现一个播放容器,一个编码分析器,一个视频解码管理系统,一个音频解码管理系统。最后还需要一个注册器来关联适当属性的播放容器和某种文件类型。从软件结构角度,这样的软件有利于构架和编写。可从用户的角度,这是最差劲的播放器。事实上,mplayer就属于这种播放器。我们用起来觉得简单是因为一些高手制作了一些预先设定的包,将所有组件关联起来。 我们回到原本的问题上来。如果用户驱动了系统的构架,那问题自然不大。只需要制作方评估系统规模,然后按照规模给出成本和时间。双方讨论一个可以接受的成本和时间,东西就可以做了。至于客户变更了系统,那自然有相关的人员会重新评价,给出新的成本和时间。问题是如果约定不清晰,可能会造成比较大的麻烦。例如客户认为他们给出的解决中必须实现某个东西,而程序这里认为是最好实现某个东西。那就扯不清楚了。因此一般建议编程人员向客户要求一份详细的制式计划书,然后双方签字确认。根据合同法规定,如果制式合同中出现纠纷,应当被解读为不利于提供方的方式。倒过来显然是不行的,既不能指望编程人员提供计划书,也不能指望客户不会对计划书随便解释。 如果是由非客户的分析和构架人员来做系统构架,那么情况就复杂了。问题实质上其实变成了五方会谈。客户方,代表客户方的需求分析师,制作方,代表制作方的系统构架师,还有程序员。看起来有点重复,但是其中都有利害关系的。客户方希望需求分析师提出尽可能多的需求,因为这样才能产生好用的软件。系统构架师则希望需求分析师提出尽可能少的需求,这个才容易制作和维护软件。制作方希望系统构架师提出尽可能高的成本和时间预算。这样有充裕的时间制作,不会制作失败,还可以多赚钱。但是客户方不会喜欢很高的成本和迟到的软件。程序员希望系统构架师给出的解决方案足够清晰,而且改动少。系统分析师总喜欢在程序员的失败中改进方案,因为简单啊。客户方希望程序员给出完整的文档和后期维护,但是程序员都不喜欢写那东西。 所以需求分析师往往会提出一堆怪怪的功能,即使这东西一般人八辈子用不到。系统构架师往往会提出高的吓人的成本和时间预算。和股指差不多吧,没几个有脑子的相信。真正的成本和时间就会在客户和制作的吵架声中被确定,并且往往成本高出正常值,时间低于正常值。程序员就在一次次的咒骂声中修改系统,并且经常忘记跟着修改文档。客户拿到手的往往是一个延期了再延期的系统。它们十有八九跑的起来,刚好可以完成预定目标。只是往往会有一些Bug,并且只有不同步的文档。系统就会在客户的抱怨声中被退回,而且客户还会追加两个需求,加上句“钱不是问题”。制作方看在孔方兄的面子上,往往也会说“保证完成任务”。系统修改的结果往往是Bug越改越多,文档越改越老,系统越改越奇怪。最后系统分析员往往会找到一个下家而跳槽,客户往往会因为钱是问题而拖帐,制作方往往会保证完不成任务,程序员往往会抱怨天天加班,唯一没问题的需求分析师往往是客户亲戚兼任的。 到底是哪里出的问题?

空之轨迹SC中文版部分攻略

Oct 12, 2007 - 1 minute read - Comments

贝壳望眼欲穿望穿秋水(好像是一个意思),总算盼望到了英雄传说SC中文版的发行。Falcom牛阿,卡卡布三部曲那么强的东西在前面,空之轨迹居然还能超越,而且一部比一部好。做到这种境界真的不容易。轩辕剑系列就有点略略的走下坡的样子。 现在讲几个解迷中比较恶心的地方。 头一个是被盗的招牌。先找钟楼背后,然后是卡佩尔里面的对话。然后是三个联在一起的烟囱,最后到地下找菲。 然后是和小女孩捉迷藏,找过所有地点(四个)后可以进入接待室。在台子的底下,别到处乱找了。 下面是玲暗语。头一个是钓师工会的标本,然后是西区的咖啡厅。下面是东区的冰激凌店,最后去空港。 再然后是消失的订婚戒指,在翡翠塔顶部。 下面是被盗的勋章。头一个地点是在导力工厂后面的花盆里面(倒置密码),第二个是协会三层的书里面(维基尼亚密码)。下一个在机场下面的铲车上,最后去教会上面的书里面。 消失的侄女那章,那位小姐就是市长小姐的女仆,关系很好的那位。看发色应该看的出吧~~ 在利贝尔方舟上面领福音的时候,选择名字赛雷斯托.D.奥赛雷斯。就是一堆晶体里面有写的那位,公主的祖先。所以要验证身份的时候只有公主能验证通过,要记得带人过来,比较麻烦。 最后是最终的大BOSS,合体后的白面。这家伙血99999,而且硬的下不去手。正常的攻击魔法都伤不到100点,还有一堆小怪在旁边消除空间。消除了的空间就会永远消失,地板会越来越少。正确的做法是经常看看这家伙的属性(一定要有情报一类的回路啦)。这家伙会轮流跳来跳去,在火土水风不防护,其余免疫上。属性对了一刀就是3000-5000。如果都是100,那用物理攻击。如果缺哪门只有死的份了。 贝壳攻略这个游戏的时间大约是50小时,其中还修改了游戏的很多关键属性(主要是钱和晶石,后期修了一堆神圣挂链和土人偶)。虽然省下不少打游戏的时间,但是还是完成了很多支线任务(有几个不知道状况的被错过了)。解迷真的很费劲阿,尤其是被盗的勋章和一个地宫的怪物。那家伙强力气绝,一个弄不好就是全灭。三五次没过去花了我两个小时,一怒干脆弄出堆神圣挂链当手信了。

三甲港游记

Oct 10, 2007 - 1 minute read - Comments

三号的时候,找了个朋友出去玩。找来找去,上海没有啥好玩地方,干脆去三甲港吧。 三甲港是浦东最早开发的旅游海港,离机场不是很远。有钱的可以坐车到龙阳路,再磁悬浮到机场,打车过去。不过一般来说,只有白痴才这么坐啦。来回路费就高达100每人,差不多够去玩的所有费用了。推荐坐地铁到陆家嘴,走到东昌路渡口。或者到外滩,摆渡过去就是。贝壳是地铁过去,在正大吃过午饭再出去的。 说到午饭,还有一桩怪事。贝壳的朋友,传说中的六牙四皂小姐,来到上海玩。她换了手机和号码,因此贝壳发的拜节短信没有收到。同时也没有贝壳的号码,所以她没法联系贝壳。所以,当天中午贝壳在正大的汉堡王吃饭,六牙四皂小姐就在旁边的松本家吃饭。NND,第二次错身而过。 三甲港的门票要38一个——是很不便宜。里面玩的东西也一般。皮艇,竹筏,骑马,乘车观海,胆子大的还可以游泳。港口本身是看不到海的,前面被很大的防波堤挡着。因此有电动车观海,还有骑马在大堤上跑的项目。至于皮艇和竹筏,好像是水边的必备项目吧。至于游泳,海水不是很干净。回头要记得冲洗,以免生病。其实还是找个游泳池来的划算,毕竟游泳池更为安全放心(呃,除了比较像下饺子)。 贝壳也没有带泳裤,所以只有划船咯。海边的风不小,还有夕晒。不撑伞会被晒伤,撑伞就会被往芦苇里面吹。要是全是臂力不足的女士们来玩,请千万带好男性同胞。贝壳就看到了两帮女士在芦苇里面没辙的场景,或者你想冒着被晒伤的风险放弃打伞? 晚上的饭就在旁边的餐厅吃的。本来里面有烧烤,可是贝壳和李定婷同志上次烧烤的经验实在太过惨烈。外面黑了,里面还带血,想想要再吃哪种东西就心寒。而且一个炉子45,要吃饱起码100多,也不合算。出去吃烧烤吧——灰太多。强烈建议三甲港的管理部门整理一下,海边这么多灰像话么?最后吃海鲜,旁边到有几个大的海鲜城。可惜看价格也不是我吃的起的。小饭店点了一个鲈鱼结束。 说道鲈鱼就丢人,本来以为海边的东西应该都新鲜的。蒸上来一看,眼睛出来的。当场就知道吃亏了。不过别的都吃到一半了,这个亏也只有认了。希望大家下次吃之前弄清楚这些问题,省得再吃这种亏。

英雄传说6空之轨迹SC修改

Oct 10, 2007 - 1 minute read - Comments

以下是空之轨迹SC的存档修改方法和部分物品代码表,六牙四皂小姐可以跳过了。 晶片数目: 0x2534C 金钱 0x25354 地 0x25358 水 0x2535C 火 0x25360 风 0x25364 行动 0x25368 EP 0x2536C 时间 个人经验: 0x1F460 艾丝蒂尔经验 0x1F514 奥利维尔经验 0x1F550 科络丝经验 0x1F604 金经验 物品代码: 01c9 最终浓缩药草茶 01c8 大麦奶酪果冻 01c7 苦味兽肉焖 01C6 每日天妇罗 01AE 提神果冻 01C4 营养果汁 019F 清凉药草茶 01B9 内陆佳肴 01BD 卡布其诺薄饼 0195 千层薄饼 01a0 红莲炖兽肉 01a6 春风螺狮面 01ba 阳光冰淇凌 01bb 月光冰淇凌 01A1 不可思议的糊 01AF 激情蛋卷 01be 终极冰淇凌 01b0 海味鲜珍 000f 火绒草杖 0014 蓝璃 001b 麒麟

骑马

Oct 8, 2007 - 1 minute read - Comments

首先请大家表误会,这个马真的是指马。 国庆前一天,公司请大家去玩,内容就是骑马。 贝壳这体重骑马,OMG,貌似有那么点点的问题。上去的时候,马一颤差点就跪下了。幸好在骑的时候问题并不大,虽然马的速度有那么一点点的折扣—— 骑马的时候需要随着马的上下颠簸而起伏,否则会被颠成白痴的。不过很可惜,贝壳的体重要颠簸是非常困难的。无论是从人的角度还是从马的角度都是种折磨。所以,贝壳为了人的健康(尤其是为了男人的健康)和马的健康,骑了两圈就逃跑了—— 还是等减肥完成再讨论吧——