0x00 前言
一切的一切要从 （盘古开天辟地）
0x01 投石问路
因为样本是基友直接发给我的，所以样本的发现过程这里按下不表，直奔主题吧。
拿到样本，一个朴实无华的 exe 可执行文件，再看这 exe 的图标更是已经烂大街的了：
于是本着没吃过猪肉也见过猪跑的道理，想起平时摸鱼时也看过不少大佬们做过的免杀和样本分析的文章，先草率地做出了一个最简单的猜想：很可能又是一个使用 rar 自解压制作的钓鱼样本。
于是就草率地先尝试使用 bandzip 打开，发现格式不对：
显然，这样草率的猜想果然是不靠谱的，遂转换思路。
于是又想到，正所谓他山之石可以攻玉，况且自己之前在这方面也几乎零基础，那不妨先扔在线的分析网站跑一波吧，就算只搞到个大概的报告也可以供参考。于是将样本拖进 VT，立等片刻后，得到结果：
只是瞧瞧这多引擎的检测结果，居然还有点小意外？！于是这个情况顿时让我对这个样本又多了几分好奇：看来有机会还是要搞清楚这个样本是怎么制作的呀。再说作为一条有理想的咸鱼，一直这样依赖工具也不是办法，有机会还是要锻炼下自己的动手能力。于是决定为基友献出自己的”第一次“，尝试手动分析下这个样本，顺便看看它这个查杀率是怎么做到的。
0x02 循序渐进
说是手动分析，但一来自己经验不足，二来身边也没有随时可抱大腿的大佬来解疑答惑，那眼前 VT 的分析结果还是要参考下的，起码起到风向标的作用。
VT 分析结果的前面几项都没有什么特别有价值的信息。直至切换到分析结果中的 BEHAVIOR 选项卡，发现样本执行过程释放和加载了一个名为python27.dll 的动态链接库文件：
看到这，作为一名常年网上冲浪、已经将喊666刻进DNA里的资深菜鸡，我的 privilege 又尽数体现了：根据经验，这大概又是一个 PyInstaller 打包的 exe文件。
于是现学现卖，从搜索引擎得知：
- PyInstaller 打包的文件可以使用一个名为
pyinstxtractor.py的 脚本 来进行解包反编译得到pyc文件 pyc是 python 源代码执行编译后得到的文件。可使用uncompyle6等工具进行反编译，得到最终的 python源码- 因此需准备工具有：
pyinstxtractor.py）（可github获取）、uncompyle6（可直接使用pip install安装）
有了以上前置知识后，那么依葫芦画瓢——下载脚本并执行： python pyinstxtractor flashplayerpp_install_cn.exe：
幸运的是，过程十分顺利，在当前目录下生成了解压文件夹：
然后，根据资料，在解压目录中找到可疑的 pyc文件，名为 main：
按照剧本，这里的 main 应该就是 main.py 编译之后得到的 pyc 文件。但实际操作中，无论是使用在线反编译工具如 http://tools.bugscaner.com/decompyle/，还是本地的 uncompyle6 和 EasyPythonDecompiler，发现都无法反编译成功。尤其是 uncompyle6，执行 uncompyle6 -o main.py main.pyc 后给出了详细报错：
根据报错信息不难发现，报错与一个 magic number的概念有关。因此要想继续分析流程，就必须先解决 magic number的问题。
于是继续求助搜索引擎。得到解释如下：
-
magic number是pyc文件结构的一部分，其位于文件开头的前 4 个字节，代表了 python 的版本信息。 - 出现
unknown magic number错误，很可能是制作样本的钓鱼佬对pyc文件做了手脚。这种情况在 CTF 中也比较常见 - 在知道 python 版本的情况下，可通过补全
magic number信息来尝试修复无法还原的pyc文件
0x03 原来是虚晃一枪
老实说，看完上面收集回来的信息，我当时的表情就是这样的：
显然，事情到这一步已经超出了一个我这个菜鸡的预期了。
所以说，要半途而废嘛，也不是没想过。。。可气氛都渲染到这里了，不继续下去好像也不太说得过去的样子。。。
于是，本着准备手动修复 magic number 信息的想法， winhex 打开 main.pyc，却惊喜地发现：
main 文件里面的竟然是源码明文？！！
这。。这。。。这是咋回事呢？跟说好的剧本不一样啊。。这样难道不会影响打包的 exe 文件的运行的吗？难道这就是这个样本被查杀率不高的原因？
于是本着知其所以然的心态，本人又围绕这这个问题，尝试找了不少资料。但可惜水平有限，最终也是没找到相应的解释，对此还希望有知道的师傅能指教一二。。。
不过言归正传，既然拿到了 python 的源码，那一切就好办了。。
直接将 main.pyc 改名为 main.py，用 sublime 打开，得到：
简单看了下源码，发现执行的过程如下：
- 1、
is_admin函数先判断是否为管理员权限，如果不是，则调用 API 请求以管理员身份运行该样本 - 2、如果当前已经是管理员权限，则执行
NDdFrvsmTh函数 - 3、
NDdFrvsmTh函数开辟两个线程，一个线程执行TFZWSTEcc函数下载真正的 flash 安装包到本地执行安装，另一个线程执行TENRWCTE函数加载 shellcode 使主机上线 - 4、
TFZWSTEcc函数先从远程地址 https://www.xxx.us/xxxxxyyyyyyvszzzzz 加载 CS 的shellcode，然后几句cPickle.loads分别为 shellcode 的执行分配内存空间、设置执行权限、创建线程并最终执行：
（PS：可能是我愚钝，总之一番概览下来，好像除了从远程加载 shellcode 而不是硬编码到代码中去之外，也没啥特别的。。。？所以至此 VT 的这个 6/64 的查杀率似乎也成了我的一个未解之谜。。😂 😂 😂 ）
同时既然已经知道 shellcode 的远程下载地址，那么可直接尝试获取 shellcode 到本地进行分析。编写了个简单的脚本：
执行后顺利得到 shellcode.bin 文件：
最后简单使用 strings 即可得到 teamserver 的地址：
不过可惜的是，上了CDN：
明显，这种情况，以本人的水平也暂时谈不上什么反制了。最后将自己的分析过程打包给基友后就洗洗睡第二天继续吃瓜去了。。。
0xFF 总结
本文主要记录了本人在对一钓鱼样本进行分析溯源学习时的踩坑经过。整个过程可简单概况为以下几部分：
- 使用
pyinstxtractor反编译 pyinstaller 打包的exe，得到 pyc 文件 - 尝试使用
uncompyle6反编译 得到的pyc文件，进一步得到 python 源码未果 - 根据
uncompyle6使用过程中出现的问题，寻找原因和解决办法，尝试手动修复pyc文件 - 尝试修复
pyc文件时直接发现 python 源码（是资料中未提及过的情况，很惊奇，遂于寻找原因，但未果） - 分析 python 源码，得到 teamserver 地址。最后能力有限，不会反制
最后本人技术粗浅，文章措辞轻浮，肯定有许多错漏之处，还望各位大佬大力斧正的同时轻喷。。。
