离奇死亡事件薄之CoCreate篇

“周节棍的双杰伦,砌里侉叉 …”

一阵吵杂的手机铃声将正在发呆的瓶瓶吵醒,他呆滞的眼神中蓦地闪出亮光,心想:大买卖又来了?

果不其然,又是一桩离奇案件:CoCreate在密镇莫名死亡,临终前嘴里还含糊地说了句“The file xxx failed to load. could not unpack the file xxx. Either this file is invalid, you do not have sufficient memory, or no space is left. (Error 398)” ,然后便咽气了。

密镇是凶杀案频发的地方,因其本身治案环境不好,很多案件都成了无头案。这也是为什么作为私家侦探的瓶瓶会被委托查找真凶的原因。

瓶瓶深思了一会,便开始着手重构死亡现场。这里还要多说一句,随着科技的进步,新时代的侦探们也有了更高效的破案方式方法,虽然原始的从验尸(Postmortem,Crash dump analysis)开始的福氏方式依然盛行,但越来越多的人都开始采用这种重建虚拟现场的方式,毕竟新的方法可以让你一遍一遍地推演,并在推演中不断地发现新的线索,直到真相大白。

重构虚拟现场需要相关的工具和设备才行。每位侦探都有自己偏爱的工具组合,当然也逃不脱其时代的限制与烙印。比如两位同姓宋的侦探前辈:宋慈因处宋朝,手中也只有手术刀之类的工具,纵使锋利,但作用毕竟有限;再看19世纪英国的宋戴克,他的方形绿皮箱里可谓是包罗万象,从放大镜,显微镜,到酒精灯,试剂等一应俱全,俨然福尔摩斯的化学实验室了。

但对于21世纪像瓶瓶一样的侦探们来说,一切又化繁为简,一般一台电脑足矣,有时也需要多台并加上若干互联设备。瓶瓶的书房便是充斥着各色各样的电子设备,相互间连接着的五颜六色的电缆全绞缠在一起。

瓶瓶最得心应手的工具包还是windbg,外加一根1394线,便足以对付大多数棘手的凶案。从业之初,瓶瓶用得可是debug工具包,后来经过softice,最后才用上windbg,前几年还是windbg第五代,当时用得还是串口线,现在已升级至第六代了。

不到一个小时,瓶瓶便已连接好所有设备,并设定妥了虚拟现场环境。随着“滴”的一声响,模拟系统开始启动,windbg上开始显现一串串的字符。此时,瓶瓶圆睁的双眼透过厚厚的近似镜片直盯盯地注视着快速翻滚的屏幕,生怕错过每一个细节。同时又暗自庆幸,CoCreate并没有进行反模拟手术,否则,如果像3ds max那样完全依赖log来分析地话苦头可就大了。

忽然“铛”地一声响,屏幕跳出了CoCreate的临终遗言。此次模拟相当成功,但在细致分析windbg记录之前还没找到任何明显线索,在浏览了所有记录后,也未能找到什么重要的线索。不得不又架设好procmon工具,重新又模拟了一次。procmon工具可以协助记录CoCreate死亡前的所有活动记录,及所有与他接触的相关人员等等。在procmon记录中,发现最后一个与死者接触的人是unzip。

“CoCreate死前找unzip干什么呢?”,瓶瓶陷入深思,忽然间,他想到了死者的遗言中有说 "unpack”,“难道真和unzip有关”,瓶瓶一边思考着一边努力寻找着证据。

瓶瓶打开了死者临死前正翻阅的文件,题为xxx。这是一个加密的文件,密镇定了法律为了保护所有信息,必须对各种重要文件进行加密,否则不能随便交换或传阅。瓶瓶当然知道怎么将此加密文件解密成明文,毕竟如果没有点关系,还真干不成侦探这个行当。

刚打开明文文件,瓶瓶就发现文件头竟赫然是 “504B0304”, ”504B”正是zip压缩法发明者Phil Katz的名字缩写: PK。基本可以肯定xxx文件为zip文件格式,所以CoCreate死前才会去见unzip。若如此地话,那unzip倒底做了些什么呢?

瓶瓶大感意外的是:等找到unzip时,发现unzip也离奇死亡了。难道是…连环谋杀?看来此案件内情确实不简单,搞不好会惹火上身!想到此,瓶瓶不禁觉得背后发寒。

但事已至此,由不得自己了。瓶瓶先勘察了unzip的死亡现场,但另他失望的是,unzip临死留下的遗言更让人摸不着头脑:  ”End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive…”。这倒底什么意思?进行了一番搜索后,瓶瓶发现如此死亡的案件竟有很多,只是,众多老案件至今还未结案。

多次探索均无功而返,瓶瓶决定先从模拟unzip死亡现场开始。好在unzip也是位名人,有关他的材料可谓是汗牛充栋,特别是有关他的生平传记(unzip60.zip),更是给现场模拟提供了最好的背景材料。

模拟中果然有新的发现,unzip在通过公开渠道获取的加密文件信息竟是错的。此公开渠道是_stat64调用:

int _stat64( const char path, struct __stat64 buffer );

_stat64会返回文件大小、时间戳等信息。关键的地方是:_stat64获取这些信息的方法不是通过GetFileInformationByHandle (IRP_MJ_QUERY_INFORMATION/FileStandardInformation),而是通过FindFirstFileEx (即IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY)得来的。这样操作如果在平时是没有问题的,但在密镇却会出错。

密镇会对所有文件进行过滤并加密,即便是授权的用户在用第二种办法查询文件时,所返回的文件大小与实际大小也是不相符的,因为密镇的所有文件都要附载加密信息而被增厚了。故unzip用错误的文件页码信息来校验文件时,必然会发生了意外。

这个问题当然是出在密镇身上,但令人可气的是,unzip在调用_stat64后又调用了GetFileTime (IRP_MJ_QUERY_INFORMATION/FileBasicInformation),既然都动用私人关系了,为什么不一次性到位,直接将文件大小也一并取了呢?!

案件侦测至此,案情已基本大白。只是善后工作该怎样去做,真是个让瓶瓶头痛的事情:

最彻底的办法,当然是改良密镇,虽然此方案涉及面太广。瓶瓶经过好一番努力,透过多个渠道才将此事办妥,本以为可以长舒一口气的当口,黑老大M$的代表Office Word发飙了,无论如何都反对。此事竟然黑老大也参与其中?这让瓶瓶不得其解,在没有搞清楚其中奥妙之前,也只能放弃此番所有努力而另辟奇径了,毕竟太岁头上的土动不得。

既然unzip已经死亡,那就不妨再推出个新个unzip吧。让新的unzip用新的私人渠道来获取加密文件的信息不就完了呗。

说到便做到,等将新的unzip装上设备,又进行新的一轮模拟,一切正常了。

连日的探查已让瓶瓶厚厚的镜片蒙上了一层灰尘,正好遮挡住了他更加疲惫的眼神。但无论如何,最后还是以最小的代价将善后工作完成了,瓶瓶终于能够安坐在弹簧椅上,惬意地随着电视哼起了 《游击队歌》。

密镇的电视共有200个频道,只是所有频道上都是相同的节目,而且都是红歌大比拼。红歌声中,瓶瓶淡定地等待着下一件凶杀案的发生。他知道,用不着等太久 ……

(本故事部分纯属虚构,请勿胡乱对号入座)

Continue reading » · Rating: · Written on: 12-30-11 · 7 Comments »

很有趣的视频:10分钟了解中国

Continue reading » · Rating: · Written on: 12-26-11 · No Comments »

最隐私—CSDN密码泄漏事件

如果要问,当前你最大的隐私是什么,那最直接的答案就应该是密码了。无论是手机、银行卡,甚至于门锁都是有着密码保护的,更别说你的电邮、网银、论坛、QQ或MSN及各种的博客帐号了。

然而时至今日,无论个人还是从公司都没有做出足够的努力。从这次CSDN泄漏出6,428,632个帐户的明文密码来看,安全意识还是普遍缺乏。

(一) 先从CSDN说起:

年初时SourceForge (http://www.sourceforge.net/) 曾发生黑客攻击事件,之后网站在最快的时间便向所有用户发邮件通知并在其首面显著位置公布了攻击事件及初步分析结果,并要求所有用户重置密码。虽然此举广为大家所诟病,但这是最安全的方式。

反观CSDN,直至现在我还未收到CSDN官方的邮件,在其主页上并没有明显看到相关通告,找了找才在news.csdn.net上不明显位置找到了公司通告。

        http://news.csdn.net/a/20111221/309505.html

至于相关分析更是难觅踪影,倒是金山发布了一个替员工解脱责任的申明:

        金山网络官方回应“员工涉嫌CSDN黑客事件”:  http://www.cnbeta.com/articles/166675.htm

在研究泄漏的密码数据库时,也发现了我的帐号及密码:
        cfy_matt # pop.smtp # mattwu@163.com

让我很奇怪的是,密码确是我很早以前的密码,但帐号却多了个 “cfy_”前辍。查了一下,共有10,657个用户都是有这种前辍的,但一直没能找到合理的解释。

让我很感庆幸的是,我的另外一个真正常用帐号并不在泄漏数据之中,不过二者用得是相同的邮箱,权且认为这就是为什么没收到CSDN的通知邮件的原因吧。

值得称赞的是网易在第一时间就向所有网易用户发出了警告信息。

(二)再来说说密码本身:

我是21号上午于cnbeta上得知的此事,旋即去emule上将此密码库拉了下来,很想第一时间做个分析的,但只因时间紧张才拖至今日。今天发现,和我持有相同兴趣的人已做了不少分析了,呵呵:

        CSDN泄漏数据完整分析: http://www.cnbeta.com/articles/166576.htm
        分析CSDN泄漏数据信息的一些数据: http://www.cnbeta.com/articles/166529.htm
        统计CSDN用户都喜欢哪些密码: http://www.cnbeta.com/articles/166527.htm

1,先看看大家最喜欢什么密码:

D:\>gawk -F# '{print $2}'  www.csdn.net.sql | sort -r | uniq -c |  sort -r –n > passwds
D:\>head -n 10 passwds
235012  123456789
212749  12345678
  76346  11111111
  46053  dearbook
  34952  00000000
  19986  123123123
  17790  1234567890
  15033  88888888
   6995  111111111
   5965  147258369

再次证明,越是简单越有生命力的道理!数字、重复字母还是大家的最爱。让我最意外的是4.6万的人用了 "dearbook”。

2,看看都是谁在 “loveyou” 或 “爱你”

D:\>grep -i loveyou passwds | more
   3080  iloveyou
    119  ILOVEYOU
     93  iloveyou1314
     63  Iloveyou
     55  iloveyou123
     40  loveyou1314

D:\>grep -i aini passwds | more
   1003  woaini1314
    708  woaini123
    649  woainima
    561  woaini520
    321  woaini521
    278  aini1314
    211  woainiwoaini

  1314 == 一生一世 !

3,又是谁在说赃话:

D:\>grep -i fuck passwds | more
     65  fuckfuck
     56  fuckyou123
     34  fuckyou1
     28  fuckcsdn
     26  ifuckyou
     23  fuckyou
     21  fuckshit
     21  fuck1234
     20  fuckyoufuckyou
     16  fuck2007
     14  fuckyouall
     10  shitfuck
    10  fuckyouyou
          …… 
     5  fuckfuckyou
     2 fuckyoudead

         2 fuckyouverymuch

D:\>grep -i caonima passwds
    565  wocaonima
    137  caonima123
    128  caonimabi

哈哈,从"fuckyou” "fuckfuckyou” 或 "fuckyoufuckyou” 到 "fuckyouverymuch”,直至 "fuckyoudead”,其仇恨程度各有高低。

另外呢,28位使用 "fuckcsdn”的先知用户还是有正当理由的。

4,用 ”password”当密码的人有多少呢”

D:\>grep -i pass passwds
   3501  password
    264  passw0rd
     97  Passw0rd
     91  PASSWORD
     87  password888
     82  password123
     76  passpass

5,密码与用户名一样的呢?密码用email帐号的?

D:\>gawk -F# '{ if (sprintf(" %s", $1) == $2) {print $1}}' www.csdn.net.sql | wc
 292661 292662 3589154

如果忽略大小写地话:

D:\>gawk -F# '{ if (tolower(sprintf(" %s", $1)) == tolower($2)) {print $1}}' www
.csdn.net.sql | wc
 307465  307466 3769498

D:\>gawk -F# '{ if (sprintf("%s ", $3) == $2) {print $1}}' www.csdn.net.sql | wc
   2854    2854   31678

CSDN上注册的用户多是计算机从业者或开发者,竟然还有30万人会犯如些低级的错误,实在是不应该。CSDN官方应该在用户注册时就否决此类弱智密码,包括第一部分的简单密码之内应该全部拒绝。

由此推想,中国的几亿网民的安全意识又将如何呢?

6,密码长度统计:

D:\>gawk -F# '{print $2}' www.csdn.net.sql | gawk -F' ' '{print length($1)}' | sort -r | uniq -c | sort -r -n
2337404 8
1550353 9
929647 10
627512 11
368342 12
167143 13
154356 14
  84444 6
  74784 15
  49014 16
  34060 5
  19042 7
   7657 4
   6949 17
   5841 18
   4974 20
   2262 19
   1594 3
   1485 2
   1060 0
    709 1

前7名都是8位及8位以上的,毕竟大部分都是开发人员。

7,CSDN用户都喜欢用什么邮箱 ?

D:\>gawk -F@ '{print tolower($2)}' www.csdn.net.sql | sort -r | uniq -c | sort -
r –n  | more
1960507 qq.com
1753036 163.com
800807 126.com
349357 sina.com
204019 yahoo.com.cn
200858 hotmail.com
184076 gmail.com
104189 sohu.com
  85930 yahoo.cn
  71946 tom.com
  52632 yeah.net
  50396 21cn.com
  34869 vip.qq.com
  28789 139.com
  24712 263.net
  19039 sina.com.cn
  18647 live.cn
  18441 sina.cn
  18244 yahoo.com
  16208 foxmail.com
  15140 163.net
  14083 msn.com

本以为会是网易163.com,没想到竟是用qq的最多,从数量上来看二者在仲伯之间。但如果综合网易其它的邮箱(如126,yeah.net等),网易还是绝对的老大。

8,怎样才是好的密码 ?

好的密码要具备以下几点:

  • 足够长:至少8位字符
  • 足够杂:最好同时包含大小写字母、数字、特殊符号(!@#$%^()*…)
  • 足够不相关:和你的信息及网站信息尽量不相关,或者由外人看来绝对是没意义的一串天文字符。所有字典里能查到的词或此次所泄漏的密码都不再是好密码了
  • 一个密码只专用在一个地方:这很重要。难保你注册的网站不是用明文存储密码的。还有,不小心地话,keyboard logger或sniffer等黑客工具也能嗅探到你的密码。

拿出几分钟时间来检查一下你的密码安全吗?不然,就再多花几分钟改一改吧。

Continue reading » · Rating: · Written on: 12-25-11 · No Comments »

勇气

不知“为人不做亏心事,不怕半夜鬼敲门”出自于什么年代,那时候有正气应该就有勇气,所以肯定不是现在了。

现在做个好人太难了,行事总是小心翼翼,一则怕被别人看在眼里横生误解;二则怕好事没做到位反成坏事。总之,唯有委曲求全及唯唯诺诺,哪里能谈得上勇气!

反观做坏事的,事越坏,勇气却是越大,胆量亦是愈大。逃犯逃腻了可以挺身而出,或打假、或征婚、或当演员。窃财、偷人、收脏的也是都油光满面、西装革履并大言不惭地不断叫嚷着冠冕堂皇的废话。

好在无论什么事情总有个例外,这才给人一点希望:

1,中国的农民兄弟最有勇气,庆幸我也出身于农民,咱也是种过地的,只是现在已是“五谷”不分了。我一直纳闷,为什么中国最成功最彻底的改革都是从最下层开始的,这样的改革成本太高了,因为所有的东西都要重新来过。为什么欧洲的改革却可以只发生在上层?难道即便是中国的精英层也被鲁讯笔下的国人劣根性所禁锢?

2,1921年7月23日上海法租界望志路106号里的那批人也是有勇气的。可在穿越剧充斥着屏幕的当下,又涌出有勇气的一批人:他们决定穿越到21年8月的嘉兴南湖(毕竟上海法租界不方便),要么招一批小弟自己动手;要么就直奔警署去告密。

Continue reading » · Rating: · Written on: 12-20-11 · No Comments »

杭州南高峰攀岩

12/17号周六在南高峰攀了一天,成果算不上颇丰,但还过得去。最让我庆幸的是,虽然4年多没爬了,但对岩壁的感觉和功力还在,面对线路难点并不怯场,只是耐力上远远不及之前了。

先锋了三条5.8/5.9的线路,对10的线路,特别是“金香玉”线,现在只能望而兴叹了,不知要训练多久才能恢复到以前的水平。

攀岩的乐趣在于你很快就能找到自己的极限,同时呢线路都是死的,只要多加琢磨及进行有针对性的训练,你便可以突破这个极限,然后又会触到了新的极限。

在“秋风扫落叶”线上,便达到了目前的水平极限,线路有点小仰角,在第三个快挂快,由于没有好的脚点,无论如何也腾不出右手去挂快挂,冲坠了几次后,只得先放弃。

回沪的路上约好下周同去岩馆训练。不经意间,我又要开始攀爬生活了 ……

发现对一件事情的喜欢及热情,并不总是随着时间而褪去的,今天面对着岩壁,还是有着莫名的兴奋和激动。

Continue reading » · Rating: · Written on: 12-20-11 · No Comments »

_snwprintf_s的潜规则

在程序中为了构造文件全路径时,使用了函数_snwprintf_s。结果在释放buffer时运行时库(runtime library)报错,提示buffer已被破坏了。再次审视代码,看不出有什么毛病,只得动手调试,然后便定位问题出在了_snwprintf_s的调用上。

_snwprintf_s函数的原型定义如下:

int _snwprintf_s( wchar_t *buffer, size_t sizeOfBuffer, size_t count, const wchar_t *format [, argument] ... );

在细致地阅读了MSDN中关于它的说明后才发现问题原因:

此函数第二个参数(size_t sizeOfBuffer)是以word (双字节)为单位的,而不是byte。问题找到,更改传入参数后,buffer corruption的问题消失。

但是,还有个奇怪的问题,也许你已注意到,如果第二个参数是以word为单位的,那第三个参数呢?不应该也是以word为单位吗?

可惜,不是。第三个参数依然还是以byte为单位,否则你的程序又不能工作了,只是这次错误将会更加地隐蔽。

你只能感叹:同样都是count,咋相差这么大呢!

这里再说说_XXX_printf_X等一系列相关的函数,如果你看了MSDN中关于snprintf的说明,你这定会惊讶于它众多的兄弟姐妹,个个相像,可绝对又各不相同:如_snprintf, _snwprintf, _snwprintf_s, _snwprintf_s_l:

  • sprintf是ANSI C所定义的函数之一,应该是最古老的一个,当然也是最容易受缓存区溢出攻击的一个
  • _snprintf: 多了一个“n”表示是多了一个描述buffer长度的参数,如果输入字串过长将被截断,毫不留情。
  • _snwprintf: 多了个“w”表示是字串为双字节字串,如unicode
  • _snwprintf_s:又多了个”s”后缀,表示是“Security Enhancement”。为了应对缓存区溢出攻击,而对函数进行改进以对输入参数进行多项检查。更多信息见于:MSDN
  • _snwprintf_s_l: 更进一步,又多了个“l”后辍,表示此函数支持字符集指定,而不是默认使用当前字符集。
  • _snwprintf_s_l_? : 不久的将来又将怎样演化呢 ?我且拭目以待。
Continue reading » · Rating: · Written on: 12-19-11 · No Comments »