有可能做出专门用于调试的虚拟机吗？
那样的话，还有可能被反调试吗？

精神有什么问题?
跟你大哥说说.

forgot这方面蛮有天份的，前段时间闭门修炼，估计领悟了不少东西，合适的时候多放点出来，让大家也长长见识。

最初由 forgot 发布
最近发现自己精神不太正常........

我说呢，QQ上名字换来换去的，好象还cry、cry的，原来是闭观修炼那！

魔

最初由 forgot 发布
一般调试借助 INT 1 和 INT 3 来实现，1号是 CPU 调度，3 号则完全是系统实现的。

可以控制一个不存在的中断门，比如 NT 内核中的 INT 20h，将调试过程中写入 CC 改为 CD20 强行引发中断，从而抛弃 1 3 即使中断门被用来解码也不影响调试。
........

回顾一下当年dos下的中断控制权之争对当今设计和使用调试器大有裨益。debug不象sice那样能建个虚拟机把dos下的应用程序玩弄于股掌之中，面对int1和int3的封堵，高手们使出了两招：一是IVT的乾坤大挪移；二是修改debug ，彻底放弃int1，使用其它中断取代int3。虽然有些不便，但在空中、铁路、公路交通被封堵的情况下，乡间小道还是别有一番情趣的。当今的情况比当年debug的处境好多了，ollydbg内存断点的突破即是一例。实际上，只要sice别象TRW（别名TRounce Windows）那么霸道(当今的sice好象收敛了)，一上来不管三七二十一就接管int1和int3(应当该出手时再出手)，在实际应用中还是有些回旋余地的。

要是在加专门调试硬件的支持，，，

H 。。。BT

小 f 也要在硬件上加油.....................

到时候兄弟们爽了

最初由 forgot 发布
一般调试借助 INT 1 和 INT 3 来实现，1号是 CPU 调度，3 号则完全是系统实现的。

可以控制一个不存在的中断门，比如 NT 内核中的 INT 20h，将调试过程中写入 CC 改为 CD20 强行引发中断，从而抛弃 1 3 即使中断门被用来解码也不影响调试。

另外时光倒流始见于 swift 的 HardICE 中，实体电路中我可不知道怎么玩，但是 Windows 中可以保存几步的Image内存和被COMMIT的页与CONTEXT环境，用类似堆栈的结构保存，需要时恢复。
........

我看到你的那个什么什么进入ring0的代码里有hook int20
提醒一下，win2k3 sp1中所有中断都被系统用掉了。
还有，hook这玩意容易冲突，我看不如你用调用门吧，这样扩展性好。

要实现指令回溯，需要事先对CPU运行过的每条指令都记录下来，记录的工作是由位于主板总线上，IDE接口上，以及其他外设接口（如果需要的话，比如usb dongle，另外有时必须用到鼠标键盘）的侦测装置完成的。为了详细记录发生的一切，单独用一台电脑把指令记录写入海量存储器。同样一段代码，开启指令记录的运行时间比正常运行要慢几百倍。当然，被调试电脑的时钟已被接管，被调试的程序不可能用任何手段检测到自己运行的过程正在被监视和记录。此外，为了便于分析制作出的记录文件，还需要对记录文件后处理，把不同进程空间的指令分开，如往往有操作系统调度指令夹杂在被分析程序执行指令之中，为了便于分析必须对其进行分离。通常把一个加了壳/阴招的程序从入口记录到真实OEP，并且对生成的记录后处理，大概需要十几小时的时间，如果需要分析程序本身的算法，这个准备工作的时间就可能更长一些。为了分析一个复杂的程序，临时占用几Tb的盘阵空间是常有的事。

forgot描绘的调试器，仍然是基于softice或OD模式的，这种调试的理念和本人的调试器有着根本的不同。本人的调试器先运行记录，后分析，进行调试分析时看到的每条指令，每个变化其实在被调试程序中早已运行完毕。就像一盘录像带，一经录制完毕，想怎样前进后退都是轻而易举的。实际上这样的过程相当于静态分析，但是可以克服传统的静态分析中“分支预测”的难题。而forgot的调试器即使具备一定的指令回溯能力，往往只能回退有限步骤。而且调试器的代码和被调试程序的代码在一颗CPU上执行，理论上始终有被发现和反制的可能性。通过改变运行断点的方式，可以使现在大多数反调试机制失效，但是不依靠DRx的内存读写断点仍然难以实现，而内存读写断点对于数据流分析是非常有效的手段。

真正来说不会被检测出调试的只有硬件调试.
现在的软件调试无非就是利用x86提供的调试功能
一个单步Int1和断点Int3,还有就是DRx,
有人说改,但是这是由CPU硬件决定的,难道你改CPU去??

swift的方法确实是改硬件，比较绝一点。
另外问下swift，在此种情况，系统时钟被接管，常规方法难以查出被调试，但是通过网络仍然可以查出自己的速度慢了几百倍。针对网络游戏这种，完全可以加入这种检测，swift用什么方法来查呢？

对于有Ethernet接口访问和某些内部自带时钟的dongle，先以全速运行一次被调试程序，截获端口的各个变化，然后复原状态，再执行一遍监视记录，这时的端口就由我的调试器接管，速度可以任意放慢。对于程序调试中必须有键盘鼠标交互的场合，通常也用这种两次运行的方法。对被调试程序而言，两次运行前的初始状态，包括内存，硬盘，外设寄存器，甚至图形加速卡内的寄存器都是一模一样的，运行过程中的各个外部接口，如键盘鼠标，Ethernet和USB的响应时序也是完全相同，如果程序内有伪随机数生成，两次的结果也会完全一样。换句话说，就像洛仑兹描述的封闭系统，只要初始条件和边界条件完全一致，系统内发生的一切经历是唯一的，可以复现的。

如果利用检测风扇转速,和CPU温度来产生随机是否有用?
计算机的电源能划分在封闭系统内吗?

风扇转速第一次从I/O port读出的是真实的，第二次就重定向到伪装的I/O端口控制器上了，伪装的I/O端口控制器只管按照时序发送之前拦截到的数据。只要外部条件准确重现，封闭系统的发展状况就是唯一的。这里的封闭系统并非孤立系统。

调试代码时，经常需要对一段内存区域下读/写断点，断到相应的指令以后，往往需要回溯一段，看看这条指令之前发生了什么。如果是没有扰乱过的代码，结合静态分析很容易知道先前执行过那些指令，从哪里跳过来的。可是对刻意扰乱的代码，如加了花指令的壳，就很难通过简单的手段回溯之前运行过的指令。另外，调试者跟踪了某段代码后，有一些收获，但是经常需要再重新跟一次，这时最理想的就是能完全复现之前的状态。本人的调试器的理念起初就是由这两个基本的需求产生的。

其实：
单独地改变断点方式这类手段作为通用调试器来讲没什么意义，道高一尺魔高一丈，对抗的手段很容易。
理想的自然就是swift的硬件调试器，加上海量存储的高性能CPU就毫无障碍了。不过硬件调试器鉴于价格上的问题很难普及。
目前个人觉得缺少的是虚拟机调试器，正如CPU原来在开发板块提出的。现有的很多虚拟机已经能很好地模拟大多数系统，我们要做的就是为其改造和增加一个易用的调试接口（bochs的还太难用），以使调试过程完全可控。
完全自己写是资源浪费，很多GNU的项目可以用。

有时候我在想，会不会人们开始手动修改 windows 的内核，

把 windows改造成一个专门用来调试程序的版本， release 出来名叫 “debugger version windows 2000”

整个 windows 的每个部份都是被悉心修改，反调的程序即使拥有 ring 0 权限也没有用，因为接触的 kernel 根本是邪恶的 kernel

工作量太大，你又没有文档，MS的更新一般人跟不上吧。而且OS不直接控制硬件

最初由 hume 发布
工作量太大，你又没有文档，MS的更新一般人跟不上吧。而且OS不直接控制硬件

另一个想法是，像 linux 的 wine 一样，想办法可以使 windows 程序在一个  “假 windows” 中跑起来

( 例如把 wine 修改成一个用来调试和破解的 wine~~   

贴一张在 linux 下用 wine运行 window 程序的例子
http://www.winehq.com/images/shots/full/wine_4.png
)

虚拟机可以实现一部分功能，比如随心所欲的下执行断点。本人曾改装过bochs使其支持任意的指令回溯（真正的回溯，内存等一切状态都回复）和内存区域断点（原版只支持单地址断点），但是仍然有诸多限制。执行效率慢，难以接入外部USB Dongle（有些Dongle贼的很，你的虚拟机慢慢和它交互，能被它内部的独立时钟鉴别出来，然后反制）。抛开外部接口不说，bochs本身的模拟能力也有待改善，代码的bug太多，很多硬件特性都没充分刻画，比如不支持图形加速卡，甚至不支持VGA直接写屏（运行UCDOS就熄火了）。
可能是本人用惯了gdb，觉得bochs的控制台式调试界面没什么不好，现在的硬件调试器仍然采用命令行/控制台界面，没有图形界面。

我早就把kernal32.dll改成邪恶的了

最初由 riijj 发布
有时候我在想，会不会人们开始手动修改 windows 的内核，

把 windows改造成一个专门用来调试程序的版本， release 出来名叫 “debugger version windows 2000”

整个 windows 的每个部份都是被悉心修改，反调的程序即使拥有 ring 0 权限也没有用，因为接触的 kernel 根本是邪恶的 kernel

都是高手
强啊

我只改了下ntdll，kernel32好像没啥效果