挖矿入侵记II
上面说到整个事情的经过，下面从程序员的角度来看看这个挖矿程序为啥这么诡异：
ps -ef | grep ld-linux
root 2541 2531 99 10:01 ? 09:06:50 /lib/lib/stak/ld-linux-x86-64.so.2 --library-path /lib/lib/stak /lib/lib/stak/xmr-stak
从形式上看ld-linux只是个loader而已， 一般都是c 库直接调用的，一般的程序不需要关系这个问题，真正的执行主体是xmr-stak， 进入到
xmr-stak目录下， 我们发现内容如下：
/lib/lib/stak/
ld-linux-x86-64.so.2 libdl.so.2 libgcrypt.so.20 libgpg-error.so.0 libidn.so.11 libm.so.6 libOpenCL.so.1 librt.so.1 libtasn1.so.6 libz.so.1
libcrypto.so.1.0.0 libffi.so.6 libgmp.so.10 libhogweed.so.4 libltdl.so.7 libnettle.so.6 libp11-kit.so.0 libssl.so.1.0.0 libxmrstak_cuda_backend.so xmr-stak
libc.so.6 libgcc_s.so.1 libgnutls.so.30 libhwloc.so.5 libmicrohttpd.so.10 libnuma.so.1 libpthread.so.0 libstdc++.so.6 libxmrstak_opencl_backend.so
看起来很多都是C库，gcc的库函数，使用google大法搜了下ld-linux， 发现下面的链接：
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
链接里提到ld-linux 其实跟 LD_LIBRARY_PATH 是一样的功能，也就是说让程序加载自己的库而不是依赖系统的库，如此看来挖矿程序这样做的目的就是为了这个程序不依赖于主机的执行环境，能独立运行，想想这个是多么重要，线上那么多机器，每个机器的环境都不一样，费了那么大的劲入侵到人家的系统然后就是因为环境问题执行不了，显然这不符合他们的做事风格， 于是乎产生了这个看起来不怎么常见的方法。
下面我们自己来验证下这个j结论是否正确：
1. 首先在ubuntu上面编译xmr-stak这个程序，参考 http://blog.csdn.net/hsdfz0201/article/details/78141733?locationNum=2&fps=1 这个链接， 这个链接里面编译的xmr-stak是cpu版本，但是
实际使用的还包含gpu版本。不过对于我们验证没有影响。大概过程如下：
sudo apt-get -y install gitgit clone https: //github.com/fireice-uk/xmr-stak-cpu.git sudo apt-get -y install libmicrohttpd-dev libssl-dev cmake build-essentialcd xmr-stak-cpu /
cmake -DHWLOC_ENABLE= OFF .make install
编译完成之后，接下来找到相应的动态链接库依赖：
root@docker-node1:/home/xmr-stak-cpu# ldd bin/xmr-stak-cpu
linux-vdso.so.1 => (0x00007ffda1de7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4a1b76f000)
libmicrohttpd.so.10 => /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10 (0x00007f4a1b557000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f4a1b2ee000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f4a1aeaa000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4a1ab28000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4a1a912000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4a1a548000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4a1b98c000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f4a1a218000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f4a19f37000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4a19d33000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4a19a2a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4a19810000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f4a195ac000)
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f4a19379000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f4a19166000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f4a18f30000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f4a18cfd000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f4a18a7d000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f4a18869000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f4a18661000)
将这些依赖库连同bin/xmr-stak-cpu bin/config.txt 拷贝到一个目录下然后打包传输到另外一台centos 6的机器上。
lsb_release -r
Release: 6.9
ls package/
config.txt libc.so.6 libgcc_s.so.1 libgnutls.so.30 libidn.so.11 libnettle.so.6 libssl.so.1.0.0 libz.so.1
ld-linux-x86-64.so.2 libdl.so.2 libgcrypt.so.20 libgpg-error.so.0 libmicrohttpd.so.10 libp11-kit.so.0 libstdc++.so.6 xmr-stak-cpu
libcrypto.so.1.0.0 libffi.so.6 libgmp.so.10 libhogweed.so.4 libm.so.6 libpthread.so.0 libtasn1.so.6
然后执行：
./package/ld-linux-x86-64.so.2 --library-path ./package ./package/xmr-stak-cpu ./package/config.txt [2018-02-12 11:39:07] : MEMORY ALLOC FAILED: mmap failed
[2018-02-12 11:39:07] : MEMORY ALLOC FAILED: mmap failed
-------------------------------------------------------------------
xmr-stak-cpu 1.3.0-1.5.0 mining software, CPU Version.
Based on CPU mining code by wolf9466 (heavily optimized by fireice_uk).
Brought to you by fireice_uk and psychocrypt under GPLv3.
Configurable dev donation level is set to 2.0 %
You can use following keys to display reports:
'h' - hashrate
'r' - results
'c' - connection
-------------------------------------------------------------------
[2018-02-12 11:39:07] : Starting double thread, affinity: 0.
[2018-02-12 11:39:07] : Starting double thread, affinity: 1.
[2018-02-12 11:39:07] : Starting double thread, affinity: 2.
[2018-02-12 11:39:07] : MEMORY ALLOC FAILED: mmap failed
[2018-02-12 11:39:07] : Starting single thread, affinity: 3.
[2018-02-12 11:39:07] : MEMORY ALLOC FAILED: mmap failed
[2018-02-12 11:39:07] : MEMORY ALLOC FAILED: mmap failed
[2018-02-12 11:39:07] : MEMORY ALLOC FAILED: mmap failed
[2018-02-12 11:39:07] : MEMORY ALLOC FAILED: mmap failed
[2018-02-12 11:39:07] : MEMORY ALLOC FAILED: mmap failed
[2018-02-12 11:39:07] : MEMORY ALLOC FAILED: mmap failed
[2018-02-12 11:39:07] : Connecting to pool pool.usxmrpool.com:3333 ...
[2018-02-12 11:39:07] : SOCKET ERROR - CONNECT error: GetAddrInfo: Temporary failure in name resolution
[2018-02-12 11:39:07] : Pool connection lost. Waiting 10 s before retry (attempt 1).