说白了，IFEO本质是系统厂商为某些可能以早期设计模式运行的软件提供一种保全措施而设计出来的产物，并对其加以扩充形成了一套可用于调试程序的简易方案，如“BreakOnDllLoad”参数可设定在载入某个DLL时设置断点，便于程序员调试ISAPI接口;带有“Range”字样的几个参数则用于限制堆的大小等。
而里面有一个导致了今天这种局面的参数：Debugger。或许微软当初的用意是便于程序员能够通过双击某个设置了IFEO控制列表的执行体文件来直接调用调试器对其进行调试，而不用再通过繁琐的打开调试器再进行文件载入来实现调试，提高了工作效率。
为了使得IFEO能够影响到任何一个程序启动请求，NT架构中将IFEO的优先权设置得很高，基本上，当用户要求执行某个程序时，系统首先判断该程序文件是否可执行体，然后就到IFEO的入口项进行文件名配对了，直到通过IFEO这一步后，进程才真正开始申请内存创建起来。
如果系统在IFEO程序列表里匹配了当前运行的文件名，它就会读取文件名下的参数，这些参数在未被人为设置之前均有个默认值，而且它们也具备优先权，“Debugger”的优先权是最高的，所以它是第一个被读取的参数，如果该参数未被设置，则默认不作处理，如果设置了这个参数，情况就变得复杂了……
三. 罪魁祸首“Debugger”
前面一章里大家应该都了解IFEO的本质了，从实际现象来说，把IFEO直接称为“映像劫持”未免有点冤枉它了，因为里面大部分参数并不会导致今天这种局面的发生，惹祸的参数只有一个，那就是“Debugger”，将IFEO视为映像劫持，大概是因为国内一些人直接套用了“Image File Execution Options”的缩写罢，在相对规范的来自Sysinternals的专业术语里，利用这个技术的设计漏洞进行非法活动的行为应该被称为“Image Hijack”，这才是真正字面上的“映像劫持”!
Debugger参数，直接翻译为“调试器”，它是IFEO里第一个被处理的参数，其作用是属于比较匪夷所思的，系统如果发现某个程序文件在IFEO列表中，它就会首先来读取Debugger参数，如果该参数不为空，系统则会把Debugger参数里指定的程序文件名作为用户试图启动的程序执行请求来处理，而仅仅把用户试图启动的程序作为Debugger参数里指定的程序文件名的参数发送过去!光是这个概念大概就足够一部分人无法理解了，所以我们放简单点说，例如有两个客人在一起吃自助餐，其中一个客人(用户)委托另一个客人(系统)去拿食物时顺便帮自己带点食物回来(启动程序的请求)，可是系统在帮用户装了一盘子食物并打算回来时却发现另一桌上有个客人(Debugger参数指定的程序文件)居然是自己小学里的暗恋对象!于是系统直接端着原本要拿给用户的食物放到那桌客人那里共同回忆往事去了(将启动程序请求的执行文件映像名和最初参数组合转换成新的命令行参数……)，最终吃到食物的自然就是Debugger客人(获得命令行参数)，至此系统就忙着执行Debugger客人的启动程序请求而把发出最初始启动程序请求的用户和那盘食物(都送给Debugger客人做命令行参数了)给遗忘了。
在系统执行的逻辑里，这就意味着，当一个设置了IFEO项Debugger参数指定为“notepad.exe”的“iexplore.exe”被用户以命令行参数“-nohome bbs.nettf.net”请求执行时，系统实际上到了IFEO那里就跑去执行notepad.exe了，而原来收到的执行请求的文件名和参数则被转化为整个命令行参数“C:\Program Files\Internet Explorer\IEXPLORE.EXE - nohome bbs.nettf.net”来提交给notepad.exe执行，所以最终执行的是“notepad.exe C:\Program Files\Internet Explorer\IEXPLORE.EXE - nohome bbs.nettf.net”，即用户原来要执行的程序文件名iexplore.exe被替换为notepad.exe，而原来的整串命令行加上iexplore.exe自身，都被作为新的命令行参数发送到notepad.exe去执行了，所以用户最终看到的是记事本的界面，并可能出现两种情况，一是记事本把整个iexplore.exe都作为文本读了出来，二是记事本弹出错误信息报告“文件名不正确”，这取决于iexplore.exe原来是作为光杆司令状态请求执行(无附带运行命令行参数)的还是带命令行参数执行的。
Debugger参数存在的本意是为了让程序员能够通过双击程序文件直接进入调试器里调试自己的程序，曾经调试过程序的朋友也许会有一个疑问，既然程序启动时都要经过IFEO这一步，那么在调试器里点击启动刚被Debugger参数送进来的程序时岂不是又会因为这个法则的存在而导致再次产生一个调试器进程?微软并不是傻子，他们理所当然的考虑到了这一点，因此一个程序启动时是否会调用到IFEO规则取决于它是否“从命令行调用”的，那么“从命令行调用”该怎么理解呢?例如我们在命令提示符里执行taskmgr.exe，这就是一个典型的“从命令行调用”的执行请求，而我们在点击桌面上、普通应用程序菜单里的taskmgr.exe时，系统都会将其视为由外壳程序Explorer.exe传递过来的执行请求，这样一来，它也属于“从命令行调用”的范围而触发IFEO规则了。为了与用户操作区分开来，系统自身加载的程序、调试器里启动的程序，它们就不属于“从命令行调用”的范围，从而绕开了IFEO，避免了这个加载过程无休止的循环下去。
从编程角度来说明“命令行调用”，那就是取决于启动程序时CreateProcess是使用lpCommandLine(命令行)还是lpApplicationName(程序文件名)来执行，默认情况下大部分程序员编写的调用习惯是lpCommandLine——命令行调用
Quote:
BOOL CreateProcess
(
LPCTSTR lpApplicationName,
LPTSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes。
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation
);
由于Debugger参数的这种特殊作用，它又被称为“重定向”(Redirection)，而利用它进行的攻击，又被称为“重定向劫持”(Redirection Hijack)，它和“映像劫持”(Image Hijack，或IFEO Hijack)只是称呼不同，实际上都是一样的技术手段。
讲解完Debugger参数的作用，现在我们来看看“映像劫持”到底是怎么一回事，遭遇流行“映像劫持”病毒的系统表现为常见的杀毒软件、防火墙、安全检测工具等均提示“找不到文件”或执行了没有反应，于是大部分用户只能去重装系统了，但是有经验或者歪打正着的用户将这个程序改了个名字，就发现它又能正常运行了，这是为什么?答案就是IFEO被人为设置了针对这些流行工具的可执行文件名的列表了，而且Debugger参数指向不存在的文件甚至病毒本身!
以超级巡警的主要执行文件AST.exe为例，首先，有个文件名为kkk.exe的恶意程序向IFEO列表里写入AST.exe项，并设置其Debugger指向kkk.exe，于是系统就会认为kkk.exe是AST.exe的调试器，这样每次用户点击执行AST.exe时，系统执行的实际上是作为调试器身份的kkk.exe，至于本该被执行的AST.exe，此刻只能被当作kkk.exe的执行参数来传递而已，而由于kkk.exe不是调试器性质的程序，甚至恶意程序作者都没有编写执行参数的处理代码，所以被启动的永远只有kkk.exe自己一个，用户每次点击那些“打不开”的安全工具，实际上就等于又执行了一次恶意程序本体!这个招数被广大使用“映像劫持”技术的恶意软件所青睐，随着OSO这款超级U盘病毒与AV终结者(随机数病毒、8位字母病毒)这两个灭杀了大部分流行安全工具和杀毒软件的恶意程序肆虐网络以后，一时之间全国上下人心惶惶，其实它们最大改进的技术核心就是利用IFEO把自己设置为各种流行安全工具的调试器罢了，破解之道尤其简单，只需要将安全工具的执行文件随便改个名字，而这个安全工具又不在乎互斥量的存在，那么它就能正常运行了，除非你运气太好又改到另一个也处于黑名单内的文件名去了，例如把AST.exe改为IceSword.exe。
小知识：互斥量
为了预防用户简单的更改一个文件名就使得大部分安全工具破笼而出，一些木马还同时采用了一种被称为“互斥量”的技术来彻底阻止安全工具运行。在系统里，有一类特殊的系统对象被称为“互斥量”(Mutex)，它们的存在是为了减少系统开销而设，例如一些工具在运行时会检测是否已经有另一个自己的副本在运行，要做这种检测最有效率的方法就是在第一次运行时创建一个互斥量，以后再运行时检测即可，这实际上是很简单的方法，因为系统会为我们保存已经创建的互斥量，直到程序请求销毁互斥量，否则它将一直存在。这样一来，问题又出现了，如果恶意程序掌握了一些安全工具的互斥量并伪造呢?这些安全工具就会因为检测到“自身已经运行”而放弃继续执行的权利，恶意程序就没有克星了。
而那些双击时明明程序文件就在眼前，系统却报错说“找不到文件”，又是什么回事呢?这也是IFEO的另一种应用罢了，其秘诀是将Debugger参数指向一个不存在的文件位置，这样系统就会因为找不到这个调试器而无法顺利执行下去，如果系统老老实实报出“找不到调试器”的错误提示那倒还好了，但就不知道微软是出于对IFEO这个东西存在的事实掩盖还是什么苦衷，却死活不肯承认是Debugger指向的调试器不存在导致的错误，而是把已经被“变异”成为命令行参数无法进入系统创建进程机制的原执行请求作为“找不到的文件”给报了回去，于是未曾了解过IFEO的用户只能莫名其妙的看着眼前就存在而系统“不承认”的安全工具发愣了。