捉虫日记读后感精选10篇
《捉虫日记》是一本由Tobias Klein著作，人民邮电出版社出版的平装图书，本书定价：39.00元，页数：180，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《捉虫日记》读后感(一)：捉虫日记
我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了
《捉虫日记》读后感(二)：Hunter your bug
这本书能告诉你怎么写代码可以避免一些常见的安全漏洞，它是作者寻找各种平台与知名软件漏洞的实践日记。不要以为这些都离你很远，恰恰是开发人员造就了各种漏洞。如果有些在写代码时就可以避免，为什么不这么做呢。
这本书读起来不会觉得艰深晦涩，但还是需要掌握一些基础知识，比如系统内存布局，堆栈调用与布局以及软件调试的一些知识。对于从未有过安全编程经验的人来说，相信这本书会给我们带来新的视角。
《捉虫日记》读后感(三)：看完第一章
《捉虫日记》读后感(四)：第三个虫子
为啥没有第二个虫子呢？
“永远不要相信媒体文件扩展名”，作者在第一个虫子提过，在第三个虫子又提了，而且用了永远这个词！
另外感觉作者的技术碾压了辣么多公司的开发者，发现的bug 被fix之后，又出现二次灾害。
哎 你没做好 快补救 哎哎你怎么补救得这么粗枝烂叶 这儿又漏水啦 哈哈哈
《捉虫日记》读后感(五)：好书妙评之《捉虫日记》
作者简介
Tobias Klein，安全问题研究员，创办NESO安全实验室，NESO是一家位于德国海尔布伦的信息安全咨询、研究公司。身为安全漏洞研究人员，Tobias发现了许多安全漏洞，并帮助修复它们。他也出版了另外两本信息安全领域的著作，由海德堡的出版商dpunkt在德国发行。
这本书在亚马逊上有21个评论：
★★★★★ 13个
★★★★ 8个
亚马逊书评
1. 切中要害
评分：★★★★★
有用：10/10
作者：Happy Cat
这本书短小精悍，阅读体验极佳。它不像其它一些书那样包罗万象，譬如《The Art Of Software Security Assessment》，这一整本《捉虫日记》几乎都是很有价值的内容。
每一章，作者完美地展示了如何走查发现漏洞，并且以直接、易懂的方式解释了思考的过程。简要列举了合理的漏洞披露途径，很好地解释了为什么捉虫人会穷尽其能。最后，很高兴能看到作者跟踪补丁包并确定所产生的漏洞。
Tobias Klein以简洁的方式全面、详细地介绍了他发现这些漏洞的过程。他准确地切中要害，不断地剖析、研究易受攻击的代码，用合适的条件和数据来触发这些代码。
对比每一章里披露漏洞时间线的差异也是一件很有趣的事情。中立地说，开源项目打补丁的速度远快于那些由庞大组织经营的项目。不确定作者是否故意这样安排，但终归是很有趣的。
这是一个简短但有趣的阅读体验，适合任何对漏洞分析和漏洞利用程序开发有兴趣的朋友。
评分：★★★★★
作者：bobblestiltskin
读这本书让我受益匪浅。作者知识面之广、研究之深给我留下深刻印象。每一章都专注在一个不同的操作系统上，介绍一个新的分析技术。
作者的写作风格也很吸引人——每当我坐下开始阅读，就很难放手。阅读此书就好像坐在Tobias的肩上，看他明确目标，然后一步步实现，获取对软件的控制。
必须加一句免责声明，我是从出版社收到审读副本的。但是我很高兴做出这个选择！
评分：★★★★
有用：2/2
作者：Tod Beardsley "Security Dork"
全面披露：我收到这本书的审校副本。
所以本书的重点是它可以很快读完，但令人沮丧的是它太短了。我喜欢作者Tobias和NoStarch出版社对这本书的设计安排——每一章都详细（并不过分）地介绍一个作者独立发现的具体的bug。对话式的行文，井井有条，因此如果你有捉虫和调试方面的背景，不会遇到什么问题。
如果你是在寻找一本教你如何通过寻找0day漏洞赚钱的书，这本书不是。如果你是在寻找这样一本书，用实例讲解你在别处读到的漏洞研究技术，选这本书就对了。
我的抱怨主要是关于篇幅——实在是太快就读完了。我希望能再增加五、六章，内容涉及封闭源代码的Windows客户端应用程序。
4. 发表在Ask Felgall上的书评
评分：★★★★
有用：5/5
作者：Stephen Chapman
阅读这本书会永久地改变你对计算机软件的看法。书中所讨论的安全漏洞都是在现实世界中各种平台上极流行软件中发现的，通过几个例子清晰地展示了大多数软件中通常都会有的这些漏洞。
要想完全理解这本书的内容，需要掌握相当高水准的编程知识，包括高级编程语言譬如C++和底层汇编语言。当然，这不是必须的，任何知识背景的读者都能从中有所收获。书中非常详细地介绍了每一处代码的更改，没有深厚编程知识背景的读者也能容易理解，如此改变代码会导致特定的结果，并能更好地理解软件有多脆弱。毕竟这都是作者在常用软件里找到的真实漏洞。作者在演示发现并利用漏洞的一些方法的同时，也展示了他是如何帮助软件开发者给漏洞打上补丁的。
也许这本书中关于软件安全话题最突出的是一个有经验的捉虫人是多么容易发现一个安全漏洞，其次是修复一个安全漏洞往往只需要修改一小处代码。
作者在书的开头介绍了写作本书的目的，他确实做到了。阅读时我注意到作者的一句评论：“一台崭新的MacBook：1,149美元。一台LED影院显示器：899美元。仅用11行代码让Mac OS X系统崩溃：无价”。实际上那段代码有3个空行，而且如果换一种编码风格的话还可以减少几行，在我看来那段代码是6行或者甚至是5行，而不是11行。
【from 图灵社区】http://www.ituring.com.cn/article/16342
《捉虫日记》读后感(六)：<捉虫日记>的书评
对于苦逼的IT男而言，对下面这个场景应该感到亲切。发出去的软件版本出现了bug，事情很紧急，于是大佬召集所谓一堆专家头脑风暴寻求解bug的思路，各路专家你一言我一语各抒己见，最终在众人齐心协力下，终于在最后关头定位出了根因。没有解不了的bug，只有不努力的coder。
然而这个世界上还有另外一种人，他们也是解bug，只不过是找别人软件中的bug，他们通常被我们称之为hacker。
同样是解bug，主动去找的就被称为黑客，被称作漏洞攻击，是人人都崇拜的行为艺术，就像街头弹吉他的青年歌手一样；而被动去定位的则被称为IT码农，被称作问题攻关，是人人都摇头的养家糊口，就像路边上拉二胡的老人一样。所以，不同的心态就会有不同的境界。凡事都要主动的好，这跟追女孩子是一个道理，美女身边有那么多人在追她，你不努力，美女怎么可能会想起你来哪？当然，你努力了，美女也未必会想起你来 ：）
《捉虫日记》这本书的作者Tobias Klein就是那种可以被称之为hacker的人。作者热衷于找各个os的bug，这本书描述了作者找到的7个bug，他详细的记录了如何去寻找bug，以及如何利用这个bug，当然他也给出了每个bug的解决方案。像作者这种hacker，或者说geeker，应该会有twitter的，于是我翻墙搜了下，他的确开通了twitter，twitter账号是 @ tobiklein ，虽然作者是德国人，可是所发推文都是英文。可见，要想在twitter这个世界混的好，就得学会用英文，否则就只能在自己那个狭窄的母语圈来混了。而中文推特圈，则以狭隘、偏激而著称，至于原因，你懂的。Tobias Klein在10年3月31日发了一条推文“My new book just got released!”，指的就是这本书。至今为止Tobias Klein所发推文不多，从他的推文可以看出，他现在应该主要在研究iOS的bug。
下面是作者这本书里面7个例子的大致介绍。
作者讲的第一个例子是个典型的栈缓冲区溢出（stack overflow）的例子。下面是个简单的stackoverflow示例程序。
／*stackoverflow.c*／
void overflow(char *argc)
{
char buff[8];
trcpy(buff, argc);
}
int main(int argc, char *argv[])
{
if(argc > 1){
overflow(argv[1]);
}
return 0;
}
对于上面这个简单的程序，如果我们输入的数据长度大于8，就会发生栈缓冲区溢出。这里涉及的知识点有栈桢、数组。注意在linux下使用gcc来编译时要禁用gcc的堆栈保护才会stackoverflow，使用-fno-stack-protector编译选项。作者在twitter上也提到了几个stack overflow的bug，是iOS和MacOS的。看来栈缓冲区溢出这个bug太容易犯了，因为字符串操作函数strcpy()和strcat()很容易导致出错。这也是很多hacker热衷于寻找的一类bug。
作者讲的第二个例子是solaris内核中内核态和用户态接口的一个bug。作者一直喜欢寻找操作系统内核漏洞，所以就拿solaris来开刀了，为什么不选择linux kernel哪？linux使用的人多，影响又大，而solaris则日薄西山了。对于操作系统而言，内核／用户态接口是最容易产生漏洞的地方。这些接口主要是以下几种：
1） ioctl
2） syscall
3） 文件系统网络协议栈
4） 第三方ko注册的钩子
作者发现的一个bug是ioctl的bug。
作者讲的第三个例子是空指针的一个bug。对于空指针，我想起一些工作上的事。有些新手经常问如何简单的让linux内核panic，我告诉他们访问一个null指针就好了。过了会，他们给我说，访问空指针的结果是segment fault，不是panic。我只好无奈的再解释，要写个ko，在内核态往null地址写数据就panic了，用户态出错，最多进程被杀死，是不会导致系统崩溃的。
作者讲的第四个例子是浏览器ActiveX控件的一个bug。我对windows编程不太熟悉，此例不多言。
作者讲的第五个例子是windows驱动的bug。用作者自己的话说，他想看看能不能在非开源的系统（比如windows）上找到bug。作者还特意把枪口瞄向了杀毒软件，真是大水冲龙王庙，自家人不认自家人啊。最终作者还真找到了bug，并通知给了杀毒软件厂商，他们及时的做了修复。
第六个例子是MacOS的一个bug，看来作者是要通吃所有的操作系统啊。怪不得作者不找linux的麻烦，是嫌降低自己的身份啊！这个MacOS的bug依然是ioctl的bug，看来作者认定了所有os的ioctl都会有bug。
最后一个例子是作者寻找iPhoneOS的bug，好吧，你赢了，你是真正的内核hacker。我只是一个内核码农，还只略微懂点linux的。
虽然作者针对的是每个os的bug，但是这些bug都是最基础的编程问题。一招鲜吃遍天，只要你编程能力强，通吃所有的os只是你愿不愿意的问题。
至于这本书的翻译，张伸，他也有twitter账号（@loveisbug），他竟然也是个足球迷。看在他是足球迷的份上，好吧，这本书翻译的挺好的。
本来我是打算follow一下这位译者的，后来看到了它的一个推文，就不打算follow他了。他的推文是：“请教，a backtrace of all stack frames是什么意思？backtrace是函数调用栈吗？”。在这里回答译者一下：
一个函数调用可以称之为一个栈帧，backtrace就是栈帧的集合，也就是函数调用栈。而缓冲区溢出（stack overflow）利用的的基本原理就是栈帧。使用gdb的bt命令就能够看出当前函数的调用栈。