防病毒程序如何检测 EICAR 测试病毒？
EICAR 测试病毒用于测试防病毒程序的功能。 为了将其检测为病毒，
防病毒程序是否具有测试病毒的病毒定义
或
启发式将其检测为可疑模式并将其检测为病毒。
（我曾经见过一个反病毒程序在下载时删除文件，但没有将病毒识别为EICAR测试病毒。就像一个可疑对象-->即如果它有定义，它应该识别病毒名称，详细信息等是不是吗？）
The EICAR test virus is used to test the functionality of the anti virus programs. In order to detect it as a virus,
Should the antivirus program have the virus definition for the test virus
OR
The heuristics detect it as a suspicious pattern and detect it as a virus.
(I have seen an occasion that an AV program deletes the file while downloading but without identifying the virus as EICAR test virus. Just as a suspicious object--> i.e If it has the definition it should identify the virus name, details etc Isn't it?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
恕我直言，测试病毒的目的是拥有已知无害且被接受为病毒的东西，以便最终用户可以验证反病毒软件是否已打开，并可以看到病毒识别的效果。 想想针对 AV 软件的消防演习。
我想大多数人都有它的签名，并且直接识别它。
如果实际 EICAR 测试的位模式碰巧包含闻起来像可疑活动操作码的位模式，我不会感到惊讶，但我不知道情况是否如此。 如果是，那么它可能是对简单启发式病毒识别器的有效测试。 然而，由于 EICAR 测试已经存在了很长时间，我也认为任何缓存它的启发式方法都不足以捕获现在野外的任何东西。
我不认为承认 EICAR 是任何比“安装了 AV 并扫描预期扫描的内容”更强有力的声明的证据，并且如果开发 AV 系统，我不会尝试对此做出任何更强有力的声明。
更新：
实际的 EICAR 测试病毒是以下字符串：
精心制作的（根据 维基百科文章）具有一些有趣的属性。
首先，它仅包含可打印的 ASCII 字符。 它通常会在末尾包含空格和/或换行符，但这对其识别或其功能没有影响。
这就提出了第二个属性：它实际上是 8086 CPU 的可执行程序。 它可以保存（例如通过记事本）在扩展名为 .COM 的文件中，并且可以在 MSDOS、MSDOS 的大多数克隆上运行，甚至可以在 Windows 命令提示符的 MSDOS 兼容模式下运行（包括在 Vista、但不适用于任何 64 位 Windows，因为他们认为与 16 位实模式的兼容性不再是优先事项。）
运行时，它会生成字符串“EICAR-STANDARD-ANTIVIRUS-TEST-FILE！”作为输出。 然后退出。
他们为什么要做出这样的努力？ 显然，研究人员想要一个已知可以安全运行的程序，部分原因是这样可以测试实时扫描仪，而无需捕获真正的病毒并冒真正感染的风险。 他们还希望它能够通过传统和非常规方式轻松分发。 由于事实证明 x86 实模式指令集有一个有用的子集，其中每个字节都满足它也是可打印 ASCII 字符的限制，因此他们实现了这两个目标。
维基文章有一个链接，指向详细解释，说明如何程序确实有效，这也是一本有趣的读物。 更复杂的是，在 DOS 实模式下打印到控制台或退出程序的唯一方法是发出软件中断指令，其操作码 (0xCD) 不是可打印的 7 位 ASCII 字符。 此外，两个中断均需要一个一字节立即数参数，其中之一需要是空格字符。 由于自我强加的规则是不允许空格，因此在指令指针到达执行它们之前，程序的最后四个字节（字符串中的“H+H*”）都会被就地修改。
在我的 XP 机器上的命令提示符下使用 DEBUG 命令反汇编和转储 EICAR.COM，我看到：
在执行到
JGE 0140的指令后，最后两条指令已修改为：大多数 DOS 系统调用通过
INT 21调度，AH或AX寄存器的值指定要执行的函数。 在本例中，AH为 0x09，这是打印字符串函数，该函数打印从偏移量 0x011C 开始、以美元符号结束的字符串。 （在纯 DOS 中，您必须使用不同的技巧来打印美元符号。）INT 20调用会在执行该点之后的任何额外字节之前终止进程。自修改代码是一种早期的病毒伎俩，但这里它用于保留对字符串中可以使用的字节值的限制。 在现代系统中，如果在运行 COM 文件的 MSDOS 兼容模式上强制执行，数据执行保护功能可能会捕获修改。
IMHO, the point of the test virus is to have something that is both known to be harmless, and accepted as a virus so that end users can verify that the AV software is turned on, and can see the effect of a virus identification. Think fire drill, for AV software.
I would imagine that most have a signature for it, and directly recognize it as such.
I wouldn't be surprised if the bit pattern of the actual EICAR test happened to include bit patterns that smelled like opcodes for suspicious activity, but I don't know if that is the case. If it is, then it might be valid test of a simple heuristic virus recognizer. However, since the EICAR test has been around for a long time, I would also imagine that any heuristic that caches it isn't good enough to catch anything now in the wild.
I wouldn't expect that recognizing EICAR is proof of any claim stronger than "the AV is installed and scanning what it was expected to scan", and if developing an AV system, I wouldn't attempt to make any stronger claim about it.
Update:
The actual EICAR test virus is the the following string:
which was carefully crafted (according to the Wikipedia article) to have a couple of interesting properties.
First, it consists of only printable ASCII characters. It will often include whitespace and/or a newline at the end, but that has no effect on its recognition, or on its function.
Which raises the second property: it is in fact an executable program for an 8086 CPU. It can be saved (via Notepad, for example) in a file with the extension .COM, and it can be run on MSDOS, most clones of MSDOS, and even in the MSDOS compatibility mode of the Windows command prompt (including on Vista, but not on any 64-bit Windows since they decided that compatibility with 16-bit real mode was no longer a priority.)
When run, it produces as output the string "EICAR-STANDARD-ANTIVIRUS-TEST-FILE!" and then exits.
Why did they go to this effort? Apparently the researchers wanted a program that was known to be safe to run, in part so that live scanners could be tested without needing to capture a real virus and risk a real infection. They also wanted it to be easy to distribute by both conventional and unconventional means. Since it turns out that there is a useful subset of the x86 real-mode instruction set where every byte meets the restriction that it also be a printable ASCII character, they achieved both goals.
The wiki article has a link to a blow-by-blow explanation of how the program actually works which is also an interesting read. Adding to the complexity is the fact that the only way to either print to the console or exit a program in DOS real mode is to issue a software interrupt instruction, whose opcode (0xCD) is not a printable 7-bit ASCII character. Furthermore, the two interrupts each require a one byte immediate parameter, one of which would need to be a space character. Since the self-imposed rule was to not allow spaces, all four of the last bytes of the program ("H+H*" in the string) are modified in place before the instruction pointer gets there to execute them.
Disassembling and dumping EICAR.COM with the DEBUG command at a command prompt on my XP box, I see:
After executing instructions up to
JGE 0140, the last two instructions have been modified to be:Most DOS system calls were dispatched through
INT 21with the value of theAHorAXregister specifying the function to execute. In this case,AHis 0x09, which is the print string function, which prints the string starting at offset 0x011C, terminated by the dollar sign. (You had to print a dollar sign with a different trick in pure DOS.) TheINT 20call terminates the process before any extra bytes past that point can be executed.Self-modifying code was an early virus trick, but here it is used to preserve the restriction on byte values that can be used in the string. In a modern system, it is possible that the data execution protection feature would catch the modification, if that is enforced on MSDOS compatibility mode running a COM file.