另外，在看到章章的这种说法之前，我想到的一种情况其实就是，
这些“可疑的地址”之前可能根本就不是有效的指令。
也就是说某些字节是跟在return或是jmp这一类指令的后面，完全没有执行的机会，因此有垃圾数据也不奇怪。

实际的应用当中这段小代码是用来在动态执行当中中断下面，并且进行反向推断使用的。
一个常用的场景是shellcode检测。在这种情况下面，检测的时候，无法获取之前的调用序列，因此需要通过反推的方式进行。
而去误报的话，可以通过二次校验，即根据指令计算该call指令的目标，看该目标是否是一段合理的可执行内存。

intel的指令集手册我也有收集，但是光看目录的规模就头大……

这个Mod R\M我以前看一本x86教程的时候就有学，当时就是看到这里，实在没看懂就放弃了后来没再碰，今天看到博主的文章，感到博主真的相当的niubility！讲的太清楚了！

今天真的收获很大！我本来是发觉windows里默认情况下，栈上的数据可以畅通无阻的执行，于是后面实验的时候搜“call 指令编码 e8”找到这里的。

对了，关于楼上章章童鞋说的这个情况，我特意做了个实验，小改了一下博主你的程序，
在内存中从IsAddressAfterCallInstruction这个函数一路搜索到main函数后面一段，
发觉还真是很多章章童鞋说的这个情况。
代码在：http://codepad.org/J8gKdO8B
（似乎有听说某些系统里的可执行内存区域是不可读的，这样的话我这种做法肯定不行，不过windows里没有这种情况）。

也就是说，有一半以上的call指令都是由于指令中的立即数产生的误报~感觉如果自己再探索一下这个方面，过滤掉一些误报也会很有趣的~~

祝博主一切顺利~~

这种是没有办法的，因为CPU执行是自上而下解析，指令集只要保证正向解析的时候没有歧义即可；而这边的代码是自下而上的推算，是无法避免歧义的。因此这种手段只是启发式规则的当中的一部分，必须和其他的规则合并考虑才行。