Shell's Home

Jul 9, 2005 - 1 minute read - Comments

代码和数据

从某种意义上说,代码即数据,数据即代码。不仅仅是因为无论何种代码,何种系统,什么格式,什么CPU,代码都是以数据方式存储的。更重要的是,设计良好的数据会自动驱动程序的运行。使得精简的代码发挥意外的功能。最出名的例子有XML,MFC的MessageRoute。或者从某个意义讲,所以代码都是数据驱动的。 现在的所有数据结构都是基于三个内容,数据,列表,指针。数据,即内容本身,也可以认为是某个数字。毕竟电脑是按数字方式编码所有数据的。列表,指某个定长数据区域。指针,即使用某种方式指向的另外一个数据。例如寻址编码。按这三种内容,可以构建出多数的结构来。例如树,图,列表,等等。 如果基于另外的数据方式,是否能构建出另外的数据结构呢?这种结构是否能更好的驱动程序的运行,或者使得程序更智能化的运行呢?我不知道,不过按照我的预感,遗传算法可能是其中的突破口。

Jul 7, 2005 - 1 minute read - Comments

毕设答辩

好久没写blog了。其实不是没写,而是都更新堆在了一个项下面。就是那个NTFS格式解析那个,回头还要继续看,新出一个项吧。 今天下午三点答辩,目前还有两个半小时(注意,不是两个“半小时”)。我不知道别人在答辩前面干些啥,不过我觉得很无聊。资料准备好了,演示和示例代码做好了,文档写的差不多了,就差N臭N长N烦琐的引用列表。我还特定找了个秒表(杀鸡用牛刀?)测了PPT的讲解时间,预期是十分钟。如果加上支线和突发,可以到十五到二十分钟。很好,偶很满意,然后呢? 突然发现,同学一个个都已经有确定的将来,只有偶还在这里迷茫。今天下午的答辩应该是过的去了(至少我没有听说答辩做了还过不去的……),补考也都合格了(嘿嘿,特别感谢马师姐)。还有呢?我的毕业手续也应该要办了。虽然烦琐点,但是总是要过去的。然后呢? 我不知道我将来准备干吗?读研和出国肯定不考虑的了。我不喜欢本系相关的研究生,出国到是可以读计算机,可惜我的英文差到在国外生存都是一个奇迹。这样的英文还在玩电脑,想必是一个更了不得的奇迹吧。那么我准备找工作吗?北京上海?什么类型?怎么发展?我统统不知道。 目前我的生活就是做一天和尚撞一天钟。如果这个和尚突然发现钟被偷了呢?他是找个木鱼来敲?找人重新弄个钟出来?还是还俗?我也不知道。不过我知道,我做和尚的岁月永远的过去了。那不闻窗外事,只读圣贤书的岁月过去了。那单纯无忧,自由自在的时光过去了。我们都要还俗,投身到俗世浊流中,直到死亡将我们带出。

Jul 3, 2005 - 2 minute read - Comments

实践NTFS格式解析

刚刚在想NTFS格式的问题,感叹没有个实例拿来看看。然后在看小说的时候不知道怎么回事,想到点子上了。不由骂自己白痴,这个问题其实早就解决了阿。直接用CreateFile去读[\.c]():文件不就好了…… OK,明天写个程序看看NTFS的实质……也许还有别的用途,再说了。 另外写个想法,也许NTFS中很多MFT表项没有被某个目录引用成为文件,而其引用计数大于一(这样会被chkdsk查出来吗?等于0会吗?会删除吗?表问咯,偶都不知道……)。这样就会造成系统空间的神秘减少。例如上次系统文件复制时候空出来的硬盘,上面全空,但是使用了400M多的空间。估计就是这么搞出来的。具体要察看chkdsk的机理才知道,因为偶的硬盘经常chkdsk的。如果是属于能查的出来的错误,肯定就不会延迟到换硬盘才发现。可能是chkdsk不检查这个…… 另外回头准备看看内核的机制,试试记录或者反木马能不能提前挂在内核态上……嘿嘿,里席必争,咏春的要诀…… 这次仔细看了MFT的格式。有点心得,先写下来。 首先是从MBR定位到每个BOOT区的BPB,这样才可以获得BPB中的\$MFT和\$MFTMirr的LCN。并且会获得卷因子(多数都是0x08吧,4k的簇)。\$MFT的LCN多数是4,定位就是32(0x20)。而后就会定位到MFT表上去。 MFT的表项分析起来是遵循链式结构的,不过为什么有那么好的性能和抗崩溃能力呢?可能在于USN和LSN吧。每个表项有个头部(详细看linux的ntfs/layout.h去),指明了大小,关联了相关MFT表项和上下MFT表项,以及这个MFT表项的全局属性。由其中可以引出首个属性的相对偏移。 每个属性都有个公用的属性头部,这个头部说明了属性的类型和大小,还有属性是否直接存储,如何存储等等信息。由上个属性可以推知下个属性偏移,所以属性应该是链式存储的。不知道这里是否具有超长链溢出的问题(长度超过最大值的一半)。 另外,在文件名称属性中具有引用目录项目,所以上面猜测的可能无法成立。不过引用目录和硬连接是违背的阿……下次再分析好了,困了困了…… OK,继续分析。根据刚刚的阅读,一个文件可以分散在多个MFT中,而后就会引入一个叫attribute list的属性。这个属性指明了每个属性属于那个MFT引用中。其中VCN的换算关系比较特别,基本MFT算-1,下面依次排开,扩展MFT也算进去的。似乎一个MFT就算一簇。不过VCN和LCN的映射关系让我头痛了半个钟头,最后也没有在linux的头文件中找到。到是在NTFS.com中文件恢复上找到了说明。原文如下: 00012580 2E 00 70 00 70 00 74 00 80 00 00 00 48 00 00 00 ..p.p.t.Ђ...H... 00012590 01 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 ................ 000125A0 6D 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 m.......@....... 000125B0 00 DC 00 00 00 00 00 00 00 DC 00 00 00 00 00 00 .

Jul 3, 2005 - 1 minute read - Comments

COM运作机理初探

今天偶看本COM的书,七搞八搞还是没有太搞明白COM的机理。先把看的差不多的写出来好了,省得下次忘记了。也不一定对,整理整理思路继续学…… COM在运行的时候有一个GetClassObject的导出函数,由这个函数负责生成对象实例并且返回合适的接口。所谓接口,就是派生于一些特定的基类的纯虚类。GetClassObject先构造某个类的实例(根据UUID),然后再获得这个类中的某个IUnknown派生接口,再向这个接口查询其他接口实例(又是根据UUID),这个查询函数名字就是QueryInterface。 根据MSDN的资料显示,QueryInterface具备三个理由。一个是每个接口都要 **** Identity,二是在对象实例中的接口集必须静态,三是每个接口都要能够查询到别的在同个对象实例中的接口。三还跟了很多例子,必须成功等等的。 同样从IUnknown中继承的还有Release和AddRef。每次引用一个接口都会有计数变化,这形成了接口的创立和析构。感觉上这个很类似于iNode和MFT中的引用计数,以及dll载入中的使用计数。 简单来说COM的机理上大致就是。通过GetClassObject寻找并且产生合适的对象实例。通过GetClassObject给出的接口QueryInterface返回其他接口。由于每个对象实例中QueryInterface都是自行编写的,所以可以轻易返回其他所有对象接口。于是通过一对UUID可以定位到某个特定的Interface,用C++术语说就是纯虚基类。

Jun 27, 2005 - 1 minute read - Comments

纪念偶可怜的硬盘

今天偶的硬盘坏了,感觉是……终于坏了阿。嘿嘿…… 偶的硬盘从两年前就开始不好了。其实也没啥好奇怪的,一天二十四小时工作,工作量奇大,天天拖BT。而且还没有好位置,都是用电源线悬挂利于散热(偶用双硬盘的)。能好的了才奇怪了。 不过这个硬盘也算比较奇怪的了,我在服务器上工作的硬盘还没有坏,他先去了。按说服务器上的硬盘无论工时还是工量都比较大,但是却坚持不坏。工作站养护的还算不错,但是又死机又坏硬盘的……看来下次这家DIY公司不能去。(还去啥,都关门了) 两年前,偶的硬盘经常可以听到敲击声,伴随服务器假死状态(整体挂在这个点状态上了)。同时某些部分的数据有CRC错误,读取这个数据时就会引发上述状态。于是偶按照坏区处理,先将整个硬盘格FAT32,重格NTFS,然后重分。将最容易引发的地方分离,然后Copy中等文件,将引发错误的文件保留。于是整理出一个还可以用的硬盘,勉强度日两年。 就在前些日子,偶机器从学校永久的带回家来。由于容易引发死机,所以整个机器经常就裸露在外,利于散热。恐怕加速了硬盘的老化。在一次Copy了大量的ED数据上去准备做压缩的时候(偶好容易从ED上拖下来的阿),硬盘突然狂响。重起后继续响,并且兰屏,再重起……没有了。硬盘整个从系统里面消失了,BIOS都找不到硬盘。看来是硬件电路一起废物了,彻底没救了。 算了算了,反正最近下ED+BT,下的我的硬盘小的要死,正想换个新的。新买个120G的得了。原来我是两个40G分别在两个电脑上,后来貌似就因为这个硬盘不稳定,所以买了个新的硬盘放在WorkStation上。然后Server为了扩容,又添加了一个80G。于是形成了惊人的双电脑双硬盘。然后今天在WorkStation上报废了一个SecondaryDisk40G。所以我买了一个希捷120G放到了Server上面,将原来最初40G的SecondaryDisk(最初是Server的PrimeryDisk)上面的数据移动过去,重新组织了下。和新的80G组成200G服务器双硬盘组,两个都是新的。WorkStation上面换上一个原来的40G作为SecondaryDisk,重新形成80G双硬盘。这样两边都比较稳定,没有大变动。 然后两边都是数据狂移动(40G的数据换位花了我两个钟头,平均数据传输速度是6M/s,实在慢了点,用我自己写的高速移动程序又不放心,嘿嘿,还没有测试完呢)。又重新整理所有硬盘(总算有空间了),打系统补丁(老死机),升级杀毒,整理系统。整整忙了一个晚上,总算将整个系统稳定了下来。 哎,好久没做系统维护的动作了,真的很不适应。八百伴电脑商场搬地方了,新的商家愣是没找到。维护上也头痛的要死……都记不起来了。最头痛的是我多了700的外债,目前已经达到2200,足足是将来三个月的薪水(当然,要吃饭先的)。不过无论怎么叹,硬盘也是回不来了,就像过去一般。所谓永恒和稳定只是虚无的东西,谨以此文纪念我的硬盘。 呜呼,尚觞。

Jun 25, 2005 - 1 minute read - Comments

撑死我了……

今天真是忙碌,闵行到处跑。 先是答应了参加初中同学聚会,然后早上匆匆爬起来,坐两钟头车跑到闵行。结果据说中午不聚会了,我哭…… 幸好班上同学正好有聚会,四个还没有请客的集体请客,去“小尾羊”撮顿好的。前几天在学院里面撮的够厉害的了,后来又跑KaKa家,实在撑的厉害。幸好在家一天消化了不少,撮就撮。于是跑到小尾羊去撮了顿赞的。然后席间小方跑过来问我有个师姐要请教问题(嘿嘿嘿嘿……我伟大吧),他已经同意了,问有时间吗?我说可以啊。后来小方说我运筹补考就是这个师姐代替监考和批阅,所以直接替我答应了,希望不要生气云云…… 靠,我生啥气啊。简直是拯救我于危难中。哈哈,谢谢小方,谢谢陈峰,谢谢蒋祖华。马师姐,您爱问啥就问啥。保证知无不言,言无不尽,不知道的回去给你查。请教绝对不感当,只要你不当我就行……So两点多撮完后,跑到东食,解答师姐的问题。实在很简单哎,只是如何使用的问题。不过模型建不上去让我比较糗,有功夫问问KaKa好了。 解答完毕已经快四点了。打电话问过同学,他们跑到了兰坪路上一家叫自由港的KTV去K歌了。赶快从校门口拉了部QQ去那里。过去一看,结果还没有开始唱呢……嘿嘿,赶上去猥琐了番(不过没有贱人和老大两个猥琐),喝了点饮料(失误……),然后五点多接到荷马的短信,说要初中同学聚会,改在了晚上。嗯,地点在……还是“小尾羊”! 靠,我过去的时候,眼睛都不知道往哪里看。总觉得很尴尬。中午刚刚撮完,晚上又跑过去……有没有搞错?然后席上吃了点就over了,都不知道该怎么吃,中午实在吃的太饱了。不过吃东西的前段时间是大家抢啊,后面就是……谁吃啊,谁吃啊……看来大家近几天吃的都很辛苦。 聊了聊,发现有三个要出国的,N多准备出国的,还有e的N方多已经在国外的我认识不认识的大牛。怎么大家都往外跑啊……GiGi也是……小姚也是……老鼠也是……靠……都知道我外语不好。算了,自立自强,坚持自学计算机…… 对了对了,先记录下来。鸡问了一个DB的问题,如何放置大规模二进制数据。现在估计下来是读写不正确,回头问问他加没有效验返回值和错误状态。还有要了所有同学的手机号码(嘿嘿……),可怜了我的手机卡。希望所有我加了MSN的friends看到本页的时候不要生气,不要惊讶,嘿嘿。 最后本来准备去物理王老师家玩的,结果发现不在家。然后商量怎么回去。鸡说他有车,我们大喜过望。然后他悠闲的补了句……不过要半个钟头……吐血ing。好你个鸡,回头我碰得到电脑了,整死你……!@#¥%^&×(。罢也罢也,就凑合坐个徐闵线吧。最后和顾功坤李白璐杨卿边聊边晃到车站,坐车回家。发现两个广电的都不知道我认识甄小璐……明明路上都会打招呼的说。真是……怪事天天有,毕业特别多。算了,不计较这个问题了,赶快上地铁吧,我热死了。哎,今天还真有意思,不过还是家里舒服。 最后地铁上,小方个家伙打过来问我要不要去养思亭。本来挺好的,我四年都没有去过说。(记得找个时间去次,否则抱憾终身,初中就没有去过,都十年了)但是很遗憾,我都在地铁上了。还因为把这个答案吼回给小方差点没有下车。我!@#$%^&*()_+}{”:?

Jun 23, 2005 - 1 minute read - Comments

KaKa的家

昨天KaKa带我们去了她的家,我们终于见到了传说中的KaKa的父亲。果然能喝,居然要求男生两杯女生一杯,点名要求我三杯。幸好后来有事,把这个事情给揭了过去,否则我就回不来了…… 对KaKa家的第三印象,好大,第二印象,环境好漂亮,第一印象,蚊子好多……晚上睡觉的时候没有被子也没有枕头,放我们在外面就是喂蚊子的。幸好小费买了瓶蚊补丁,打上后果然稳定多了……不是不是……是蚊子少多了。早上给大班叫起来,发现三个女生通宵到七点半。汗……好恐怖的精力,贝壳是困了就要睡觉了。 孙大班的家啥都好,就是路远了点(当然,蚊子也多了点……)。从学校过去是两个多钟头,偶跑回自己家又用了两个钟头,加上去学校的两个钟头,可以证明,三者形成等边三角型。贝壳出来的时候,孙大班还特意嘱咐在对面乘车。结果贝壳是属蚂蚁的,先爬会熟悉的地头,再走熟悉的路线。特意开回南汇,然后一部班车到家。省却不少麻烦,就是乘车时间稍微长了点。 昨天晚上喝酒当中不知道怎么提到的(好像是杨文卓喝酒不喝酒弄出来的),袁乐突然发神经,要在毕业一周内结婚,预定时间是七月一号,因为是党的生日。各位各位,如果我们全班没有被耍的话,七一贝壳就要去重庆玩两天了。虽然临近答辩,老师催的很紧的说。这些都不重要,但是……但是……但是我的钱包啊……负债已经一千五百了,再下去毕业前就要预支一个月的薪水了。

Jun 19, 2005 - 1 minute read - Comments

大教堂

很久以前就听过巴利奥斯的大教堂,不过一直都不知道叫什么。(相信大家也听过吧,尤其是男生,CS中某关在教堂附近的音乐……)然后,我学了吉他,知道了名字。不过很抱歉也很遗憾,我弹不来。嘿嘿,好像我有点懒…… 不过大教堂的却也够难……不但技术上要求技巧高,弹奏速度快,而且持续时间超长。技术差点,不是弹不出来,就是断断续续,或者根本弹不完。开始的时候就要用拇指食指中指交替快速弹奏,我现在连这段都无法连贯弹出来。看来弹完它这个梦想是终身无望了…… 大教堂给人的感觉有点庄严不是那么特别的庄严。每次烦躁的时候听,心里面都会平静下来。但是静心仔细听,又给我一种蠢蠢欲动的感觉。上跳下窜的音符引发隐约的躁动,仿佛要发生什么,又什么都不会发生。每个走向都非常出人意料,就像人生,你永远不知道下一刻你会得到什么。

Jun 18, 2005 - 1 minute read - Comments

blogs

今天觉得MSNSpace还不错,呃,我没有在做广告。刚刚发现上面可以加入音乐列表和图书列表……虽然这些都需要外置空间的支持,不过,it’s better then nothing。今天加了五首动漫曲和六首吉他曲。回头再改。我实在无法在更改IP的时候更换太多的URL的IP。也许我真的应该申请一个虚拟域名了。 OK,最近还不错,除了昨天晚上发神经的和real抱怨了通中国的软件业,还有和Gigi抱怨了通女人和结婚。其余一切OK,在此谢谢Gigi和real。 另外,最近开始分析NTFS格式了,看了MFT的说明,不过好头晕。现在下了一个linux内核中附带的NTFS解析部分在看。呵呵,也许我应该先吧前面的想法搞定,不是吗?不过现在不管这些了。反正我只是在玩电脑,快乐就好。也许几年后,连我自己都会忘记曾经有这么天,我在小小的房间里面,独自研究着NTFS。不过谁在意呢,千百年后,我们中的多少还能留下名字?与其将生命浪费在无谓的虚妄中,我更宁可做点现在就可以快乐的事情。而电脑,就是其中之一。 今天下了BitComet0.59用,终于支持用户列表交换和DHT了。感觉真好。不能不说,BC是目前国产软件中最有活力的一个。不是说推出的速度和宣传,而是各个软件的方面。例如支持XML,支持多语言扩展,各种新技术(像UDP内网穿越),广告,内嵌浏览器,内核定制和重用。让我想起以前的netant,winamp等等软件,充满了活力。也许软件维持活力和生命的关键,在于不断引入新鲜血液,并且加入市场来活化它。可能在几年后,现在BC的缔造者会成为将来的网络新贵。不过现在一切都还未知。

Jun 13, 2005 - 1 minute read - Comments

抱怨

吃了人家的免费午餐,照例应该专程为人做做广告,致致贺词。不济也不应该抱怨连连。不过MSN的空间的却引我腹诽。过去的文章找不到……不知道是我方法不对还是什么。如果真的如此我干脆另觅它处,好过我珍贵的文章白白无人看…… OK,先放下MSN空间的问题吧。本周我分析了UPX的压缩原理分析结果亦不外如是。不过话说回来UPX毕竟不是专业的防跟踪壳,仅仅是资源压缩程序而已。好分析也没有什么值得意外的。 源程序如下,是最最出名的Hello,World.: #include "stdafx.h" #include <windows.h> #pragma comment(linker, "/ENTRY:main") //#pragma comment(linker, "/ALIGN:0x1000")//这厮一上程序就变成3k党了,然后UPX就死气活样的不肯工作 #define put(x) WriteFile(hOutput, (x), sizeof(x), &amp;NumOfBytes, NULL) #define get(x) ReadFile(hInput, (x), sizeof(x), &amp;NumOfBytes, NULL) HANDLE hOutput, hInput; DWORD NumOfBytes; void main(){ char tmp[1]; hOutput=GetStdHandle(STD_OUTPUT_HANDLE); hInput=GetStdHandle(STD_INPUT_HANDLE); put("Hello,World.n"); get(tmp); return ; } UPX压缩下来的程序,section会变成三个。UPX0,UPX1,UPX2。其中UPX0是虚段,具备实际的段名称和段地址,但是RawDateSize是0。所以这个段在载入后是全0数据。数据和解压代码合并在了UPX1段中,由UPX1的解压代码注入UPX0的段中。看样子解压代码是附在了最后,从入口点到段实际内容结束点之间的范围。而UPX3的段最是搞笑,是一个单独的ImportTable,仅仅导入了Kernel32.dll中ExitProcess,LoadLibrary和GetProcessAddr三个函数。UPX1在解压并且注入UPX0后,会调用这三个函数来分析和获得每个导入表项的地址,然后完成导入表的动作。 换言,程序在从UPX1段JMP入UPX0段的瞬间,从UPX0段DUMP出来的数据就是正常的数据,除了要重建Section,并且重建所有DateDirectory外。 OK,下面说说压缩算法的问题。上面可以看出,压缩动作不难,但是算法我可没有能力分析和实现。所以我脑筋就动到了zip算法上去。可是根据我以前看zip文档得到的经验,zip内部分多种格式。貌似rar也分多种格式。所以我不打算挑战极限,自行写出每种算法的代码。不过我打算做一个标准的扩展接口,可以让所有的压缩算法都容纳在这一个框架内。并且可以支持多种压缩文件的格式。对上可以封装成标准的文件读写函数,然后再写一个COM组件,让所有的人都可以任意的运用(嘿嘿,写网页的人估计最需要)。至于后面要不要写一个什么东西让整个windows可以把压缩文件无缝的当成文件夹处理,那就再说了。