无意间中了这个病毒 发现百度没有此病毒修复程序 以及详细修复过程，此病毒为流行病毒 又因自身电脑包含绝大部分常用工具以及误报的木马工具 无法使用360破坏大师修复只好自己分析了该木马的详细感染过程，制作了反向修复的工具，由于时间问题，仅仅对该病毒的感染方式以及修复做了文章其他地方并未进行仔细分析，目的只做文件修复详细记录如下：病毒分析：Neshta该款病毒使用简单的解密算法对一些加密数据进行解密。该算法为循环，使用以下方式解密每个字节：有符号整数乘法将变量乘以0x8088405。（变量的初始值是要解密的字节数。）乘积加1保存为变量的下一个值。并将同一乘积乘以0xFF以产生解密字节，然后将其与加密字节异或，以获得解密（见图1）。解密算法多次用于获取以下相关字符串：“3582-490”、“exe”和“****” 跳过不需要的文件夹以及核心的数据获取如果找到扩展名为“.exe”的可执行文件，病毒将使用GetShortPathNameA API获取短路径名，短路径名是MS-DOS的命名约定。它的格式是8:3，其中8是文件名中的字符数，3是扩展名中的字符数。然后使用GetWindowsDirectoryA API获取“%windows%”文件夹。如果受害者文件的当前短路径名包含“%windows%”文件夹名，病毒将跳过感染例程。如果受害者文件位于“%temp%”文件夹内，并且受害者文件的路径名包含“PROGRA~1”（“Program Files”）他同样会跳过感染。当路径名通过筛选后，它将使用FindFirstFileA API获取受害者文件的大小。文件大小取自生成的WIN32_FIND_数据结构。此病毒作者考虑到文件大小如果大小等于病毒自身 41472（0xA200）字节或大于10000000（0x989680）他也将跳过感染例程。如果文件通过了所有必要的过滤，它就可以被感染了。病毒所做的第一件事是使用GetFileAttributesAPI获取被感染文件的属性。如果文件的属性为只读属性，则恶意软件会使用SetFileAttributesA API将其设置回0。然后通过对ExtractIconA、GetIconInfo、GetObjectA和DeleteObject API的一系列调用，进行伪造原本软件的图标。检测二次感染：此病毒首先使用CreateFileA API打开受害者的文件。然后将文件指针设置为文件开头处的后1000（0x3E8）字节。然后使用ReadFile API将256（0x100）字节读取到内存中，使用CloseHandle API关闭文件。为了避免再次感染，病毒读取文件开头后的256（0x100）字节数据与内存中病毒组件的数据进行比较。如果字节匹配，病毒将跳过感染其他说明：由于此款病毒为前置文件感染篡改，每个被感染文件的前41472（0xA200）字节属于病毒。被感染文件末尾附近的一块地方是受感染文件的图标。然后使用CreateFileA API打开受害者文件。病毒读取前两个字节，并通过检查字符串“MZ”来检查该文件是否为有效的可执行文件。然后，它使用SetFilePointer 将文件指针挪到文件开头处。使用ReadFile API读取受害者文件的前41472（0xA200）字节。使用前面讨论的解密算法，对数据的前1000（0x3E8）字节进行加密。注意（加密和解密算法由于是亦或。所以互相对应，该病毒解密的key值位于文件末尾前41472字节后的1234（0x4D2）字节处，其余部分我没有仔细进行分析，道理余同，分析出该病毒的解密方式恢复文件后病毒影响并不是很大，所以分析主要以文件修复为主）其余补充：常规的前置病毒感染会修改可执行文件的EXE区段，并将病毒文件放在最开始的位置。但是此款病毒使用SetFilePointer和WriteFile API的api组合，将病毒文件替换原来文件的前41472（0xA200）字节，而不是往后推推原始数据。此款病毒行为比较骚，修复方法也比较简单，现附上修复病毒文件的部分源代码病毒完成感染后，病毒将关闭现在已感染的文件。并将原可执行文件施放到临时目录的3582-490病毒会遍历每个硬盘中的每个文件夹，查找exe可执行文件。感染所有文件后终止当前病毒进程（这些前台是无法感知的）。附上感染病毒样本以及修复病毒的核心算法源代码，以及成品