回想两年前刚入职那会，真是“志得意满”，心想自己大学时由于着迷于当时流行的flash动漫，大部分业余时间基本耗在自学计算机之路的摸爬滚打上了，而且毕业后还不惜又耗一年的时间考取了华科的计算机研究生，为的是换个专业证书，接着熬过了所谓的硕士生涯然后就进入了国内口碑最好的安全厂商奇虎360；努力总没白费，正式踏上了曾“朝思暮想”的安全行业，可以继续做我的“黑客梦”了。
应届生入职时，会例行的培训3个月。说是培训，其实是一次“再面试”，也就是趁机考察下大家的动手解决问题的能力。从独立完成RSS阅读器、小组合作完成类似微软的计算器到小组合作完成网络五子棋，这个过程中确实让人比较有成就感，让我发现了自己的动手编码能力和快速学习解决问题的能力并不比科班出身的人差，甚至还可能比大多数人强那么一点点。而且正是当时小组的导师也发现了我这一点，收留我进入他所在的部门“主动防御”，去做后台。后台，这个词对于当时的我而言还是比较神秘和向往的，于是，我更加“意气风发”，决心一定要认真对待这次机会让自己也能正式踏入“安全圈”。
入部门之后，导师所在小组连我在内其实就3个人，导师、我、还一个社招的，下面就分别以张、我、颜代称吧。张负责哪块，当时我还真不清楚，毕竟是直属上级吧，他吩咐什么我照办就行了，其他的不在我该了解的范围；颜负责后台的数据统计和交互页面的开发；我嘛，张没给我说将来会去负责什么，只是给了我svn的代码阅读权限，先让我放羊式的自己浏览下。纯粹让你学习先，哪这么美，张给我了点体力活，让我用python写个简单的功能，将后台的url日志做下各种统计工作，日志哪来的、统计之后做什么的，这些我一概不知，我也不知道该不该问。他当时给我分配这个任务是在周五下班前，明摆就是给你个家庭作业了。正好我也想学习下python，就欣然的去加班，中间遇到各种琐碎细节的问题，基本都是不知道完成某个小功能有现成的库可用，或者知道某个库可用但是使用过程中会踩进各种容易掉进去的坑中，这都是初学者必然会遇到的共同问题吧。接下来，又接到了一个全新的任务：提取PE文件中的某些区块的信息，包括导入/导出表、图标资源等，从学习PE格式到研究pefile模块的实现，到eclipse下的调试，到成功提取想要的区块信息，这两个个小任务完成之后，开了个面对面的小会，张说我最好能做xen虚拟化的研究。我哪知道什么是xen，只知道是linux下的东西、开源的、用来运行虚拟机的，还蛮高端大气上档次的，于是就在没什么多余选择的情况下选了这个虚拟化研究。 既然选了，再怎么一无所知愚昧无知，也得硬着头皮耐着寂寞去潜心研究。于是，下载xen的源码、编译、安装、试验各种linux下的命令。。。说来一句话的事，听来连贯流畅，对于一个linux新手来说还是有点挑战的，单单是编译、安装启动内核所需的文件、配置启动菜单这些概念就够你折腾的了。这事折腾了几天倒也忘了，在裸机上装xen并能正常启动完成了，接着张在trac上给了我新的任务，在xen上创建一台能稳定运行的windows的虚拟机，于是又噼里啪啦去xen的官网上搜索各种资料，反正整个过程就是试验、看日志、调整、再试验，因为你对虚拟化没什么理论背景，只能采用这种简单粗暴的方法了。从安装xen到创建稳定的windows虚拟机大概用了一周时间吧。接下来比较有挑战性的任务到了，“改善xen下虚拟机网络的性能”，听来好玄啊，我只能默默点头，然后就是去分析xen的日志、看文档的解释、在源码里一顿grep查找，晕晕乎乎的，但总算是找到了创建虚拟网络接口的代码块了，好吧既然张说有个多余的网络设备对hvm模式的虚拟机来说是不需要的，那就直接取消掉那个创建过程吧，还真是，取消掉之后虚拟机仍然能正常联网，不错，将这个小的改造做成patch吧。做完补丁，接下来是解决“虚拟机网络稳定性”，至于这个问题的背景张也没给我提，看来他是觉得没必要说，只给我提示使用dnsmasq取代目前的libvirt来让虚拟机的使用dhcp和nat联上外网。好的，一下子各种概念如潮水般涌来，xen的网络结构是什么样子、大致什么原理、dnsmasq和dhcp什么关系、nat用什么来实现。。。时间有限，请记住不是让你来研究这些该概念和深层次理论的，只管在感性和肤浅的理性认识下去试验试验再试验，拿出爱迪生发明灯泡时的精神，失败的尝试是为最后的成功铺路的，确实，前面的铺路过程实质就是使用排除法不断排除错误方向的过程，所以只要你耐心足够和丰富点的想象力，那么问题是完全可以解决的，只是问题在于，当你知道解决了的时候你还是会去想：诶，真可以啊，我解决的理论依据在哪呢，好凌乱。。。真是剪不断，理还乱，懵懵懂懂的状态还在持续，新的任务纷至沓来，截止日期都定了，反正旧问题一时半会想不太通，还是先去面对新问题吧。于是乎，借助grub来写个读取虚拟机磁盘镜像中文件的命令行工具吧、写个在恰当时机生成虚拟机快照的命令工具吧、研究二进制快照的格式以及尝试修改来生成不同硬件配置的虚拟机、在样本检测流程中动态的修改虚拟机快照模块来快速启动不同配置的虚拟机、改进下从关闭后的虚拟机的磁盘镜像中提取文件的效率。。。等等这些细小的、研究型的活让你应接不暇。
这些对样本检测流程的性能和效率有影响的问题都解决之后，以为可以喘口气了，呵呵，想得美，之前的研究工作是在版本属于3.0系列的xen下，现在又出了一款4.0系列的稳定版，得升级。。。尼玛，意味着之前的那些工作都的在新版本上来次升级，什么升级啊，就是重新再去测试下修改下，保证那些补丁在xen4上面也能正常使用。xen3上的操作虚拟机的接口使用python实现的，xen4上使用c语言实现的，这次的改动比xen3中的要大，而且代码的编写量也更大，还好gdb调试起来比较灵活，升级过程总体还比较顺利，最终分别整理出了xen3、xen4下的各个干净的补丁，然后配合ops部门做了个专门为主防后台蜜罐服务器准备的xen内核和工具集的安装源及部署脚本。这个升级过程中其实还插进了一个不痛不痒的事情----为分析360杀毒引起的蓝屏原因专门搭建一个内部用来统计的后台流程，组内的流程框架还是相当不错的，3天就搭建好了，不由对这个分布式的多进程多线程应用程序框架多了几分兴趣，而且还了解到通过wine可以让windows下的应用程序在linux下运行，真是神奇。
至此，9个月的时间过去了。
蓝屏分析流程有了新的需求，为广大小白用户自动查找蓝屏原因并修复，这次是要对外发布的产品，挂在安全卫士的电脑门诊中，而且有一定的实时性要求，不错，这个活还比较有趣，我将亲身经历一个产品从无到有的全过程。其实流程很简洁，用户上传内存转储文件、后台接收文件、分析该dump文件提取属性、用这些属性去匹配原因规则得到原因标识号、根据原因标识号去匹配云端的方案规则、将解决方案展示给用户并尝试修复。由于这个过程所经历的阶段比较多，而且分析dump文件阶段的效率很难有大的提升，于是产品方面决定采纳我们开发人员的建议，将在客户端显示倒计时60秒，也就是将修复的可忍受时间的限制为60s，让用户有个盼头，心里有数，不用毫无征兆的等待下去，毕竟这个浮躁的年代能静心等待的人不多。。。
接下来的5个月就是交错在这几个任务中切换，维护蓝屏分析业务流程、为蜜罐的样本检测流程扩展出“rootkit检测”分支。
一年的多时间过去了，到了2013年1月。
全新任务到，去研究google上开源的volatility和github上的libvmi，看看哪个更适合用来分析虚拟机的内存。volatility看了个把月，初步了解到是怎样将某个进程的虚拟地址转化为物理地址、物理地址转为dump文件的偏移。这不快过年回家了，想起之前有个不紧急的任务拖着还没完成，于是心血来潮奋战5天，总算可以将虚拟机的磁盘镜像文件通过fuse挂载到文件系统上了，也就是说linux下可以读取基于qemu模拟器的虚拟磁盘中的的文件了，等于将虚拟磁盘的ntfs和fat文件系统无缝集成到了linux中，这下从关闭后的虚拟机的磁盘中提取样本行为日志文件就很便捷了，而且这个虚拟磁盘可以是增量盘。这下虚拟机可以抛弃使用原生格式的磁盘镜像了，增量盘的使用让虚拟机磁盘的母盘可以方便的复用，另外虚拟磁盘实际占用的物理空间也大大缩小了。
年后回公司已是3月了，开始欣赏libvmi这个读取虚拟机内存的库，c语言写的，不错，gdb调试起来方便。很强大，可以监视虚拟机读写内存的事件，并在恰当的时刻做回调处理，借此机会也了解到了windows的少部分内核数据结构。其实这一切的目的都是为了在虚拟机调用内核的某个函数时，比如NtReadFile，可以捕获这个动作，同时提取出该函数的参数从而得知在读取哪个文件，算是对当前运行程序的行为进行监控吧。断断续续研究这个库将近两月时间，顺便修复了其中一个比较隐蔽的bug，并和github上该项目的发起人讨论了下内存读写事件的注册方式。
到了2013年5月，公司的新产品天眼启动，于是我开始研究怎么制作一键安装盘，将xen内核、依赖的工具包、精简后的蜜罐检测流程等部署安装到企业客户的机器，保证傻瓜化、无人值守。
于是接下来的半年就一直在天眼这个产品上折腾，产品的部署安装、产品注册激活、部署机器间安全通信、产品升级等问题，设计、编码、测试、修正、再测试，如此往复、生生不息。。。
现在，2013年已经接近尾声了，我也离开了360，记下了这篇流水日志。
整体回顾下，这两年的经历，确实不能用一句话概括出来，因为所做的事情多数比较杂乱、细小，连贯性不够，以至于我和朋友在聊起时，对方会禁不住问我：我不清楚你究竟是负责做什么的。。。我笑笑说，什么事情上面需要人去做就做什么吧。
如果你能耐心读到这里，我只能说，朋友，留下你的网络联系方式吧，说不定你和我感同身受。。。可以交流下。
文章原于：博客园
文章原于：博客园
