原因是在某个客户端的服务器上，只要服务器启动，几秒内就会被杀掉，然后错误日志什么都不显示。服务端是基于jvm的，如何查看是哪个进程杀死了一个进程，这个可以写一篇文章。请放心，导致JVM崩溃的不是我们的代码，毫无疑问是安全脚本小子。搜搜搜，套路无非就是crontab，mount伪装这些东西。至于篡改ps、top隐藏进程等，相信大部分脚本小子都没有这个本事。当然，这个行业很多人都有传承，也难说他们所属的家族承受不了。嗯，终于在.log目录下找到了一个名为x86-64的可执行程序。是因为我以小人之心论君子之腹，他们并没有做隐藏ps的操作，只是每秒醒来杀掉占用CPU最多的程序，以免影响其工作..这个心机婊，名字这么乱，我信你是系统文件不碰？cp一份，保留备份，killall，然后分析。vim一看，不是脚本，是elf。Linux下快速分析elf文件的工具有几种，一种是readelf，一种是objdump，还有一种是ldd。通常ldd用于分析动态加载的库，objdump用于反编译。但是这些工具在面对一些恶意文件时并不总是有效。例如，对于静态编译的程序或变体脚本，ldd是无效的。对于没有节表的程序，objdump可能取不到结果。#objdump-d./wi./wi:fileformatelf64-x86-64因为objdump需要依赖codesections或者sectiontable，可以用readelf看[root@localhost~]#readelf-a./wiELFHeader:Magic:7f454c46020101000000000000000000类：ELF64数据：2的补码，小端版本：1（当前）操作系统/ABI：UNIX-系统VABI版本：0类型：EXEC（可执行文件)机器：AdvancedMicroDevicesX86-64版本：0x1入口点地址：0x5c9e70程序头开始：64（字节到文件）节头开始：0（字节到文件）标志：0x0这个头的大小：64（字节）)Sizeofprogramheaders:56(bytes)程序头数量:3Sizeofse节头：64（字节）节头数：0节头字符串表索引：0此文件中没有节。此文件中没有要分组的节。程序头：类型偏移VirtAddrPhysAddrFileSizMemSiz标志对齐负载0x00000000000000000x00000000004000000x00000000004000000x00000000001ca78b0x00000000001ca78bRE200000LOAD0x00000000000000000x00000000005cb0000x00000000005cb0000x00000000000000000x0000000000597d58RW1000GNU_STACK0x00000000000000000x00000000000000000x00000000000000000x00000000000000000x0000000000000000RW10Thereisnodynamicsectioninthisfile.Therearenorelocationsinthisfile.ThedecodingofunwindsectionsformachinetypeAdvancedMicroDevicesX86当前不支持-64。动态符号inf信息不适用于显示符号。在此文件中找不到版本信息。那么这种情况下，可以这样来做，-D表示反汇编所有文件，-b表示二进制，-m表示指令集架构[root@localhost~]#objdump-bbinary-D-mi386./wi./wi:文件格式binaryDisassemblyofsection.data:00000000<.data>:0:7f45jg0x472:4cdec%esp3:46inc%esi4:0201add(%ecx),%al6:0100添加%eax,(%eax)...10:0200添加(%eax),%al12:3e0001添加%al,%ds:(%ecx)15:0000添加%al,(%eax)此外，strace和gdb等工具也有帮助。当然，使用IDA这样的大型武器效果会更好。这只是尝尝，就算甩了这么一堆汇编代码，有什么用，也不是那么好理解的。怎么才能让别人相信这个东西不是普通的二进制文件呢？拥有所有令人讨厌的隐藏行为是不够的。那么，为什么好的ELF可执行文件中没有节表呢？很简单，脚本小子就是喜欢玩点把戏，很容易想到打包。Linux下最容易想到的shell就是UPX。[root@localhost~]#strings./wi|grepUPXnUPX!($Info:此文件使用UPX可执行打包程序打包http://upx.sf.net$$Id:UPX3.95版权所有(C)1996-2018theUPXTeam.AllRightsReserved.$UPX!uUPX!UPX!脚本小子在他们的工作中仍然很粗糙，并且不知道如何隐藏他们的外壳。拿起它的混蛋外壳[root@localhost~]#./upx-dwiUltimatePackerforeXecutables版权所有(C)1996-2020UPX3.96MarkusOberhumer、LaszloMolnar和JohnReiser2020年1月23日文件大小比率格式名称---------------------------------------------------5011080<-187838037.48%linux/amd64wiUnpacked1file.IfscriptkiddieshidetheUPXshellinformation,那么UPX自带的-d命令是不能解包的，这时候必须用到IDA，加壳器的本质是将原程序的所有数据压缩加密，静态文件中无法解析执行，代码运行时会释放到内存中，我们可以使用ida远程调试测试程序，找到upx自解包后的OEP，然后dump内存实现手动解包。如何找到OEP，这个要靠经验。解包后继续使用strings、strace、netstat等命令进行定性分析。事实上，此时，strings命令足以分析其行为。[1;37monconnection*命令'h'哈希率，'p'暂停，'r'恢复，'s'结果，'c'连接>wz*ctz>3>c):w3[32m||[31m错误[32m||[37m在此范围内使用无效端口[36m'1-65535'[37me.g[31m(./xmrig-p3333)[32m||[31m错误[32m||[37m您可以使用的无效类只有这些类[36m'192.168'[32m,[36m'172'[32m,[36m'100'[32m,[36m'10'[37m例如[31m(./xmrig-lan192.168.0.1)[32m||[31mERROR[32m||[37mEmptyOrInvalidPoolAddress也可以分析为C++编写的木马。如果你想反汇编一个C++源文件，那你就是在放屁。Objdump必须依赖调试信息，没有脚本小子可以做到这一点。如果你想要一个C++源文件，只能使用IDAdump，它也给出了一个大概的源文件。当然，最简单的方法就是直接上传到virustotal，最后的结果确实是一个Linux.Risk.Bitcoinminer.Tbix。呵呵，脚本小子。
