Monthly Archives: December 2017

使用WinAppDbg解决Flareon第3题

本文已发表在看雪论坛, 详情可见: https://bbs.pediy.com/thread-223525.htm 文章作者: Parsia’s Den 博客地址: https://parsiya.net/ 原文链接: WinAppDbg – Part 4 – Bruteforcing FlareOn 2017 – Challenge 3 翻译前言: 这是解决Flareon4第3题的第4种方法, 也是这个系列翻译的完结篇. 作者用的WinAppDbg跟ODScript有类似的感觉, 虽然不及之前2篇让人耳目一新, 但这是作者对于WinAppDbg写的简易教程的第4篇, 如果感兴趣可以点击原文链接从其它3篇WinAppDbg的教程开始阅读. 文中分析的程序你可以点击此处下载: greek_to_me.zip, 解压密码: www.pediy.com 如果朋友想看我之前翻译的用其他3种全新的方法解决该题的文章, 可以点击以下链接: Flareon challenge 4 第3题 使用libPeConv来解决Flareon4题目3 使用Angr解决Flareon4题目3 侦查 … Continue reading

Posted in reverse engnieering | Leave a comment

使用Angr解决Flareon4题目3

本文已发表在看雪论坛, 详情可见: https://bbs.pediy.com/thread-223512.htm 文章作者: XOR Hex 博客地址: https://blog.xorhex.com/ 原文链接: Flare-On 2017: Challenge 3 翻译前言: 这是解决Flareon4第3题的第3种方法. 文章中使用angr编写python脚本来获得flag, 对比之前我翻译的使用Unicorn框架的文章里的代码, 对于刚接触Angr或Unicorn的朋友会有不少帮助. 文中分析的程序你可以点击此处下载: greek_to_me.zip, 解压密码: www.pediy.com 准备 我们用IDA打开文件并调到入口点, 入口点简单地调用了函数sub_401008 我们打开这个函数看看, 向下滚动我们可以看到看起来像成功提示的文本字符串, 接下来的标准流程就是找寻成功的分支. 从字符串往回分析, 我们发现一个在0x40105E处的比较, eax跟值0xFB5E进行比较. 如果eax匹配成功, 那么随后程序就会继续执行成功分支. 所以我们该如何满足这个匹配呢? 来看看sub_4011E6函数内部. 我们看到一堆的mov,add,shl和shr指令, 这可能是某种形式的混淆. 让我们看看传入进函数的参数: .text:00401047 mov … Continue reading

Posted in reverse engnieering | Leave a comment

使用libPeConv来解决Flareon4第3题

本文已发表在看雪论坛, 详情可见: https://bbs.pediy.com/thread-223494.htm 文章作者: hasherezade(@hasherezade) 原文链接: Import all the things! Solving FlareOn4 Challenge 3 with libPeConv 翻译前言: 虽然依旧是Flareon4第3题的分析,但是一道题的解决方法多种多样,这次给大家分享如何使用libPeConv来解决问题,又可以get到新姿势啦 libPeConv: 是作者hasherezade开发的用于加载和转换PE文件的库,github仓库地址是:libpeconv 文中分析的程序你可以点击此处下载: greek_to_me.zip, 解压密码: www.pediy.com 总览 题目greek_to_me.exe是一个32位PE文件, 程序已经剔除了重定位信息. 我们以下就简称该程序为crackme 我们运行crackme, 只有一个空白的控制台程序, 并且没有从标准输入中读取任何数据, 所以我们可以推断程序是使用了一些其他方式来读取用户的password 我们使用IDA静态分析, crackme结构非常简洁并没有混淆过. 我们可以在代码开头看见程序创建了一个socket并等待着输入 socket监听着本地2222端口 在建立连接后, crackme从用户输入中取前4字节读入到缓冲区中: 读入4字节后, crackme开始处理输入并用来解码已加密的缓冲区数据 … Continue reading

Posted in reverse engnieering | Leave a comment

Flareon4 third challenge

本文已发表在看雪论坛, 详情可见: https://bbs.pediy.com/thread-223473.htm 题目作者: Matt Williams (@0xmwilliams) 翻译前言: 文章对代码自修改的分析很细致, 使用Unicorn框架来模拟执行代码和Capstone进行反汇编. 文中分析的程序你可以点击此处下载: greek_to_me.zip, 解压密码: www.pediy.com greek_to_me.exe是一个Windows x86可执行文件, 如下图所示, 程序中的字符串表露了00401101处要达成的情况, 如下所示. 004010F5 push 0 ; flags 004010F7 push 2Bh ; len 004010F9 push offset aCongratulation ; “Congratulations! But wait, where’s…” 004010FE push … Continue reading

Posted in reverse engnieering | Leave a comment

wsnpoem unpack part two

本文已发表在看雪论坛, 详情可见: https://bbs.pediy.com/thread-223401.htm 承接之前写的zbot变种木马wsnpoem脱壳笔记 part 1,我们这次用另外一种方式来脱壳。并且本文还将分析另外两个恶意样本。 文中分析的程序你可以点击此处下载: wsnpoem恶意样本par2.zip, 解压密码: www.pediy.com OD重载wsnpoem-with-rootkit.exe,依然是之前的顺序,在leave处设下硬件断点后运行,让第1阶段的解密完成。然后删除设下的硬件断点,向下翻看。 不过这次我们就不会在00409EDA处的jmp eax下断了,我们再向下翻到00409F26处的mov eax, 004051B7,这句汇编代码下面是call eax,也就是说程序将要执行OEP处的代码。 我们在004051B7设下硬件执行断点,然后执行断下,程序停在了OEP处,我们删除硬件断点 那么我们接下来的步骤就跟之前一样,运行步过004051D2处的call 0040aad4导入函数表,然后将EIP重设为004051B7。 之前用Ollydump+ImportREC我们手动cut chunks来修复导入表,这样不仅枯燥费力,而且还有可能误删正确的chunks导致修复失败,这次我们使用额外一个工具 – Universial Import Fixer 1.0[Final],也就是UIF。这个工具可以为我们自动修复导入表,我们只需要将wsnpoem的进程id输入进去就可以。 在重设完EIP后,我们打开UIF,然后再通过在cmd里用tasklist命令查询到wsnpoem的pid,我的是1816,将其转为16进制,也就是0x718,填入到UIF的Process ID中,取消掉默认勾选的Fix NtDll to Kernel32,然后点击Start UIF就会帮你自动修复导入表并显示修复后的信息。这些信息我们等下用ImportREC是需要使用的,也就是下图的IAT RVA和IAT Size 既然修复好了导入表,那么我们就可以用Ollydump将程序转储出来,记得在dump时要取消勾选rebuild imports,转储文件保存为dump.exe 打开ImortREC,然后选择wsnpoem进程,输入OEP,并按照UIF修复给出的IAT RVA和IAT Size填入到ImportREC中 你可以看到导入表直接就是可用的,我们不需要手动修复导入表。我们就可以直接转储到文件就行了。IDA打开当然也是脱壳完成并且各导入函数清晰的。 … Continue reading

Posted in malware, unpack | Leave a comment

wsnpoem unpack part one

本文已发表在看雪论坛, 详情可见: https://bbs.pediy.com/thread-223393.htm wsnpoem恶意程序是zbot木马家族的变种,经过加壳保护,我们接下来就来脱壳。 文中分析的程序你可以点击此处下载: wsnpoem恶意样本par1.zip, 解压密码: www.pediy.com OD载入wsnpoem-with-rootkit.exe 这是wsnpoem解密的第一阶段,我们直接在00409D41的LEAVE处右键设下硬件执行断点,然后运行 然后我们选择菜单Debug->Hardware Breakpoint移除刚才设下的断点,向下翻到00409EDA处 我们在这行设下软件断点(F2)然后运行,停在断点处,我们取消掉这行的断点,按下Enter进入到跳转的分支去,向下翻到00412449处 在翻过了第2层解密后,00412449处所指向的004051B7便是我们的OEP,同样设下一个软件断点(F2),然后运行,停在断点处,我们取消掉这行的断点,然后步入OEP 然后向下一点,看到0040523A处,在数据窗口中转向0040FD34 可以看见,这里的这个call所调用的函数地址处是全零,这会造成程序的崩溃,因此我们可以推测在call以上的代码中有填充这个空间 我们现在边步过,边观察数据窗口中的0040FD34,看什么时候向该处填充了数据,可以很容易发现,在步过004051D2处的Call 0040AAD4后,数据窗口中填充了许多的数据 那这样看来,004051D2处的Call 0040AAD4就是将所有的函数都导入到内存空间中,而我们的0040FD34则是导入表的一部分,因此我们可以右键重新将EIP设到OEP处。 向上翻看导入表空间,貌似可能的函数地址块,也就是我们的导入表头,是从0040FB3C开始 我们也可以在ascii块中右键选择Long->Address,这样数据窗口会以地址格式进行显示,方便我们查看导入表 同样,我们向下翻看,查找导入表的结尾是在0040FEB8 这样,找到了OEP,也有导入表信息,那么我们就可以用Ollydump+ImportREC来进行脱壳,如下,点击dump保存为dump.exe 打开ImportREC,选择正在运行的wsnpoem-with-rootkit.exe,然后在OEP、RVA和SIZE处填写好我们获得的信息,然后点击Get Imports 但显然,我们的导入表函数虽然有找到,但都是无效的。所以我们需要手动修复导入表函数,因为可能在导入表内混有一些垃圾地址,所以我们需要手动进行移除,比如第一个chunk中 点击对应的shell32.dll右键显示反汇编,可以看到如下代码,显然不是一个正常的函数的代码,因此可以确定是垃圾地址。我们右键cut chunks 然后有的块显示反汇编提示read error,那么其实也是垃圾地址。依照类似的方法将所有的垃圾地址清除干净后,你就可以转储到文件,然后用IDA打开,你会发现壳已经脱干净并且导入函数也很清晰

Posted in malware, unpack | Leave a comment