Author Archives: Vancir

模糊测试: 初学者入门指南

模糊测试简介 模糊测试(Fuzzing), 简而言之, 就是为了触发新的或不可预见的代码执行路径或bug而在程序中插入异常的, 非预期的, 甚至是随机的输入. 因为模糊测试涉及到为目标提供大量的测试样例, 因此至少也会实现部分自动化. 模糊测试可以也应当用于测试每个需要接受某种形式输入的接口. 实际上, 模糊测试最起码就应该拿来用于测试每个从潜在恶意来源(比如互联网或用户提供的文件)获取输入的接口. 模糊测试是对其他测试技术的补充. 由模糊测试揭露出的问题往往是开发人员不太可能构建的输入(例如, 在处理一些边界情况, 数据正确性和错误处理例程时的输入)触发的. 在常规自动化测试过程中, 模糊测试扩大了代码覆盖范围, 提高了代码覆盖率测试程度. 通过模糊测试使用的非预期输入通常会触发一些平时不会触发的执行流. 很多地方都需要进行模糊测试. 它是你系统开发生命周期(SDLC)的一部分, 在这部分里, 你需要确保你完成了改善目标所要的系统性工作, 或是你只是想解决一些bug也行. 要如何费心于模糊测试取决于你的最终目标和相关资源, 本文只是帮你如何从模糊测试中获取更多的回报.

Posted in fuzzing | Leave a comment

检测Android虚拟机的方法和代码实现

刚刚看了一些关于Detect Android Emulator的开源项目/文章/论文, 我看的这些其实都是13年14年提出的方法, 方法里大多是检测一些环境属性, 检查一些文件这样, 但实际上检测的思路并不局限于此. 有的是很直接了当去检测qemu, 而其它的方法则是旁敲侧击比如检测adb, 检测ptrace之类的. 思路也很灵活. 最后看到有提出通过利用QEMU这样的模拟CPU与物理CPU之间的实际差异(任务调度差异), 模拟传感器和物理传感器的差异, 缓存的差异等方法来检测. 相比检测环境属性, 检测效果会提升很多.

Posted in android | Leave a comment

Intro to malware “TSCookie”

2018年1月17日左右, 社交媒体上开始出现一些关于恶意邮件的报道, 这些邮件声称来自日本的教育部, 文化部, 体育部和科技部. 这些邮件里包含有指向恶意软件”TSCookie”的URL链接(趋势科技将其称为为PLEAD恶意软件, 因为PLEAD取自趋势科技过往捕获到的一次APT攻击活动, 故本文中我们将该恶意软件命名为”TSCookie”). TSCookie在2015年在野外被发现, 并且怀疑黑客组织”BlackTech”与此次攻击活动有关. JPCERT/CC证实称, 使用恶意软件的敌对团伙已经对日本组织进行了针对性的攻击. 本文将介绍我们在分析TSCookie后的成果. TSCookie概述 下图描述了TSCookie的执行流程: TSCookie本身只是用作一个下载器, 通过从C&C服务器下载模块来扩展功能. 我们所检查的样本下载了一个具有传出信息和其他功能的DLL文件(以下简称”TSCookieRAT”). 下载的模块仅在内存上运行 TSCookie和TSCookieRAT的行为将在下面的章节中详细解释.

Posted in malware | Leave a comment

Solve the White Rabbit CrackMe

Crackme文件可以从此处下载: White Rabbit crackme! 因为crackme里稍微使用了混淆和一些像恶意程序的把戏, 所以可能会被一些杀毒软件标记为恶意程序, 所以也建议在虚拟机下运行. 这个crackme运行的截图如下: OK, 首先要做的第一件事就是将其载入到IDA中(我这里使用的是刚刚发布的IDA 7的免费版本). 通过搜索字符串Password#1来看它的交叉引用以及前后都发生了些什么. 就这了! 我们可以看到它被sub_4034D0所引用. 现在我们将跟随到引用处, 来看看接下来发生什么 在sub_403D90中有一些初始化操作, 随后在sub_404150的结果与可疑值0x57585384的比较后又一个分支跳转. 子分支中的sub_403990输出了一些提示语以及后续一些有关接受用户输入的内容. 我们首先来看初始化部分(sub_403D90): 函数取了两个参数, 内容看上去也非常清楚: 通过给出的标识符查找资源文件, 加载资源文件, 确定它的文件大小, 然后申请内存空间并将资源文件的数据复制进去. 该函数返回那个新申请的内存空间的指针, 并将资源文件的大小存储在第一个参数中. 现在我们唯一需要注意的就是图中的sub_406A70, 它取了3个参数(target pointer, source pointer 以及 data size)并且看起来非常像是memcpy(或memmove, 是哪个不重要, 因为内存区域没有重叠). 但是函数内的代码却包含有大量的分支, 难以分析. … Continue reading

Posted in reverse engnieering | Leave a comment

Intro to unicorn engine

什么是Unicorn引擎 Unicorn是一个轻量级, 多平台, 多架构的CPU模拟器框架. 我们可以更好地关注CPU操作, 忽略机器设备的差异. 想象一下, 我们可以将其应用于这些情景: 比如我们单纯只是需要模拟代码的执行而非需要一个真的CPU去完成那些操作, 又或者想要更安全地分析恶意代码, 检测病毒特征, 或者想要在逆向过程中验证某些代码的含义. 使用CPU模拟器可以很好地帮助我们提供便捷. 它的亮点(这也归功于Unicorn是基于qemu而开发的)有: 支持多种架构: Arm, Arm64 (Armv8), M68K, Mips, Sparc, & X86 (include X86_64). 对Windows和*nix系统(已确认包含Mac OSX, Linux, *BSD & Solaris)的原生支持 具有平台独立且简洁易于使用的API 使用JIT编译技术, 性能表现优异 你可以在Black Hat USA 2015获悉有关Unicorn引擎的更多技术细节. Github项目主页: unicorn … Continue reading

Posted in reverse engnieering | Leave a comment

The structure of .pyc files

原文链接: The structure of .pyc files 简单来说, 一个pyc文件包含以下三块 * 一个4字节的魔数(magic number) * 一个4直接的修改时间戳(modification timestamp) * 一个编排过的代码对象 对于各个版本的python解释器, magic number都各不相同, 对于python 2.5则是b3f20d0a 修改时间戳则是源文件生成.pyc文件的Unix修改时间戳, 当源文件改变的时候, 该值也会变化 整个文件剩下的部分则是在编译源文件产生的代码对象编排后的输出. marshal跟python的pickle类似, 它对python对象进行序列化操作. 不过marshal和pickle的目标不同. pickle目的在于产生一个持久的独立于版本的序列化, 而marshal则是为了短暂地序列化对象, 因此它的表示会随着python版本二改变. 而且, pickle被设计用于适用用户定义的类型, 而marshal这时用于处理python内部类型的复杂结构 marshal的特性给出了pyc文件的重要特征: 它对平台独立, 但依赖于python版本. 一个2.4版本的pyc文件不能在2.5版本下执行, 但是它可以很好地移植到不同操作系统里. 接下来的部分也简单: … Continue reading

Posted in reverse engnieering | Leave a comment