逆向 - 标签 - 有价值炮灰 https://evilpan.com/tags/%E9%80%86%E5%90%91/ 逆向 - 标签 - 有价值炮灰 Hugo -- gohugo.iozh-CNi@pppan.net (evilpan) i@pppan.net (evilpan)This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.Sun, 11 Apr 2021 12:40:00 +0800 从微信扔骰子看iOS应用安全与逆向分析 https://evilpan.com/2021/04/11/ios-hacking-101/ Sun, 11 Apr 2021 12:40:00 +0800 evilpan https://evilpan.com/2021/04/11/ios-hacking-101/

以微信扔骰子小游戏为例，记录一次完整 iOS 逆向分析的过程。

前言

在之前《免越狱调试与分析黑盒iOS应用》以及前几篇文章中已经介绍了如何开始分析iOS应用，不过都是基于非越狱的机器，其本意是为了能够在自己的主力设备中进行简单的分析和调试。但是执着于免越狱其实在很多情况下需要额外的工作，如果想要在iOS上做进一步研究的话，完全的访问权限是很有必要的。

Jailbreak

因为主要讨论的是应用安全，所以关于越狱实现的部分不做深入介绍。关于XNU内核漏洞的分析和利用网上有很多相关的文章或书籍，比如：

看一些公开的漏洞利用代码对加深印象也很有帮助，比如oob_timestamp的利用。对于本文而言只需要站在巨人的肩膀上使用这些封装好的利用即可。iOS越狱和Android root的的一个很大不同是前者系统封闭性高，碎片化较低，因此提权的方法也相对单一，不支持刷机，大部分都是通过漏洞去获取更高的权限(tfp0)。既然是专注应用层安全，就抓大放小，使用现有的越狱工具，站在前人肩膀上即可。

砸壳

越狱之后总算可以通过 ssh 进入到系统中，也就是相当于安卓世界的 adb shell 而已。既然是逆向分析，下一步就是获取应用的安装包，这在安卓中是一条adb pull命令，但苹果里要复杂一些。

iOS 中大部分应用都从 Apple Store 即应用商店下载，而从应用商店下载的 app 是通过苹果签名和加密保护的，这是苹果 FairPlay DRM 数字版权保护的重要部分。为了能使用逆向工具进行分析，需要先对其进行解密，即俗称的砸壳。网上关于砸壳的资料和工具都很多，比如:

  • stefanesser/dumpdecrypted：手动将动态库注入进程获取解密后的文件，不包括动态库
  • conradev/dumpdecrypted：更新版，支持对每个模块进行解密
  • Clutch：通过posix_spawnp创建进程并解密文件，支持重新打包为ipa (iOS12之后这类静态砸壳方法基本上都不行了)
  • frida-ios-dump：使用frida进行动态解密，并支持重新打包为ipa
  • bagbak：和前者类似，不过是基于 nodejs 的 frida binding

这里面有些工具已经年代久远年久失修了，比如我就注意到 dumpdecrypted 在文件沙盒的处理上有点问题导致无法保存文件，需要经过简单 patch 。

上面的这些工具大部分都是基于内存 dump，也就是需要通过 exec 执行目标程序才实现砸壳，这可能会让一些 App 通过在初始化函数中自我检测来对抗砸壳。如果出现这种情况，可以通过基于 mremap_encrypted 的方式进行解密，直接调用内核接口，无需启动目标程序实现静态砸壳。

抓手

狱也越了，壳也砸了，接下来呢？直接丢到 IDA 里分析？不是不可以，但 iOS 的应用主体是一个巨大的 mach-o 文件，直接分析是很难的。还是以微信为例，主程序解密后单 arm64 架构的可执行文件就有 218 MB，即便在逆向工具里分析也会让人无从下手。这时候就需要一个入手点，用互联网的黑话来说，就是需要一个抓手。

一个最常见的入手点就是 UI 界面。在安卓应用分析中一般通过 Android Studio 提供的uiautomatorviewer可以进行目标应用的 UI 分析，并通过 UI 的 ID 在反编译的代码中查找引用。不过这个方法我一般不用，而是直接获取顶层 Activity 然后找对应的类去分析。

在 iOS 中，UI 分析却是一个有效的入手点，因为 iOS 应用都是基于 MVC 结构，View 中触发的事件由对应的 Controller 去实现。不管是基于 Springboard 的拖拖拽拽还是通过代码布局，MVC 的基调是不变的。在 Xcode 中有视图层级调试功能(Debug View Hierarchy)，但需要目标开启调试。除此之外，更为常用的是一些视图调试框架，比如 Reveal 或者开源的 FLEX。

用 FLEX 直接注入到进程中可实现 UI 的分析:

flex.gif
使用 cycript 注入 libflex

这里用到了 cycript，后文再细说。或者可以用 Reveal 在电脑端分析，当然还是需要将 RevealServer.dylib 注入到目标进程中并调用[IBARevealLoader startServer]，参考官方的 lldb 脚本，启动后 PC 端界面如下:

Reveal

点击发送骰子的区域是一个 UIImageView，其本身是没有响应点击事件的，因此要找对应的 ViewController 或者 Gesture Recognizer。

动态分析

根据 UI 信息能知道的是当前界面的 Controller 类是 BaseMsgContentViewController，所以我们可以通过脚本去跟踪发送骰子时该类所有的函数调用，如下所示:

[-] 13:04:24.188 Hooked: -[BaseMsgContentViewController didRotateFromInterfaceOrientation:]
[-] 13:04:24.188 Hooked: -[BaseMsgContentViewController previewingContext:viewControllerForLocation:]
[-] 13:04:24.188 Hooked: -[BaseMsgContentViewController previewingContext:commitViewController:]
[-] 13:04:24.188 Hooked: -[BaseMsgContentViewController previewActionItems]
[-] 13:04:24.189 Hooked: -[BaseMsgContentViewController m_delegate]
[!] 13:04:24.291 Failed to hook: -[BaseMsgContentViewController willShow]
[-] 13:04:24.291 Hooked: -[BaseMsgContentViewController canPasteImage]
[-] 13:04:24.292 Hooked: -[BaseMsgContentViewController setTableFooterView:]
[-] 13:04:24.292 Hooked: -[BaseMsgContentViewController documentInteractionControllerViewControllerForPreview:]
[-] 13:04:24.292 Hooked: -[BaseMsgContentViewController willAppear]
[-] 13:04:24.292 Hooked: -[BaseMsgContentViewController showLoadingView]
[-] 13:04:24.293 Hooked: -[BaseMsgContentViewController initTableView]
[-] 13:04:24.293 Hooked: 614 methods for class BaseMsgContentViewController

# 点击骰子图标发送表情
[-] 13:04:35.075 ENTER -[BaseMsgContentViewController useTransparentNavibar]
[-] 13:04:35.076 ENTER -[BaseMsgContentViewController useTransparentNavibar]
[-] 13:04:35.078 ENTER -[BaseMsgContentViewController shouldInteractivePop]
[-] 13:04:35.078 ENTER -[BaseMsgContentViewController toolView]
[-] 13:04:35.132 ENTER -[BaseMsgContentViewController SendEmoticonMesssageToolView:]
[-] 13:04:35.148 ENTER -[BaseMsgContentViewController findNodeDataByLocalId:]
[-] 13:04:35.148 ENTER -[BaseMsgContentViewController addMessageNode:layout:addMoreMsg:]
[-] 13:04:35.148 ENTER -[BaseMsgContentViewController findNodeDataByLocalId:]
[-] 13:04:35.148 ENTER -[BaseMsgContentViewController getCurContentSizeHeight]
...

其中SendEmoticonMesssageToolView是个值得关注的函数，可以直接用 frida 打印函数堆栈:

import { kObjC } from "../../agent/objc";
import { kNative } from "../../agent/native";

// kObjC.traceClass("BaseMsgContentViewController");
kObjC.traceMethod("BaseMsgContentViewController", "- SendEmoticonMesssageToolView:", {
  onEnter: function(args) {
    log.i("SendEmoticonMesssageToolView", args[0], args[1]);
    kNative.printStackTrace(this.context);
  }
});

输出结果如下:

[-] 13:10:32.079 Hooked: -[BaseMsgContentViewController SendEmoticonMesssageToolView:]
[+] 13:10:37.212 SendEmoticonMesssageToolView 0x11f8a1800 0x10bf6e8ba
[-] 13:10:37.636 backtrace:
0x104e06de4 WeChat!0x2676de4
0x10294cde8 WeChat!0x1bcde8
0x1041bb930 WeChat!0x1a2b930
0x1b8331e34 UIKitCore!-[UICollectionView _selectItemAtIndexPath:animated:scrollPosition:notifyDelegate:deselectPrevious:]
0x1b83464b0 UIKitCore!-[UICollectionView _cellForItemAtIndexPath:includePrefetchedCells:]
0x1b8359e10 UIKitCore!-[UICollectionView touchesEnded:withEvent:]
0x1b46ef730 libsystem_malloc.dylib!nanov2_calloc
0x1b46f4100 libsystem_malloc.dylib!calloc
0x1b48ddae4 CoreFoundation!-[__NSSetM addObject:]
0x1b473926c libobjc.A.dylib!objc_autoreleasePoolPop
0x1b4a14320 CoreFoundation!_CFAutoreleasePoolPop
0x1b48dd594 CoreFoundation!-[__NSSetM enumerateObjectsWithOptions:usingBlock:]
0x1b498bc7c CoreFoundation!__NSSetM_new
0x1bb64e208 QuartzCore!CA::Layer::retain_parent(CA::Transaction*) const
0x1b8b5d9e8 UIKitCore!forwardTouchMethod
0x1b8b5dae4 UIKitCore!-[UIResponder touchesEnded:withEvent:]

在 WeChat 部分的回溯没有符号，因为已经去掉了。

在 lldb 中也可以看到类似的结果:

(lldbinit) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x0000000105334f04 WeChat`___lldb_unnamed_symbol201841$$WeChat
    frame #1: 0x0000000104b32f80 WeChat`___lldb_unnamed_symbol170264$$WeChat + 160
    frame #2: 0x0000000104e06de4 WeChat`___lldb_unnamed_symbol182196$$WeChat + 2600
    frame #3: 0x000000010294cde8 WeChat`___lldb_unnamed_symbol8796$$WeChat + 248
    frame #4: 0x00000001041bb930 WeChat`___lldb_unnamed_symbol129751$$WeChat + 624
    frame #5: 0x00000001b8331e34 UIKitCore`-[UICollectionView _selectItemAtIndexPath:animated:scrollPosition:notifyDelegate:deselectPrevious:] + 952
    frame #6: 0x00000001b8359e10 UIKitCore`-[UICollectionView touchesEnded:withEvent:] + 572
    frame #7: 0x00000001b8b5d9e8 UIKitCore`forwardTouchMethod + 332
    frame #8: 0x00000001b8b5dae4 UIKitCore`-[UIResponder touchesEnded:withEvent:] + 64
    frame #9: 0x00000001b8b5d9e8 UIKitCore`forwardTouchMethod + 332
    frame #10: 0x00000001b8b5dae4 UIKitCore`-[UIResponder touchesEnded:withEvent:] + 64
    frame #11: 0x00000001b8b5d9e8 UIKitCore`forwardTouchMethod + 332
    frame #12: 0x00000001b8b5dae4 UIKitCore`-[UIResponder touchesEnded:withEvent:] + 64
    frame #13: 0x00000001b86e6478 UIKitCore`_UIGestureEnvironmentUpdate + 6992
    frame #14: 0x00000001b86e48dc UIKitCore`-[UIGestureEnvironment _deliverEvent:toGestureRecognizers:usingBlock:] + 380
    frame #15: 0x00000001b86e4698 UIKitCore`-[UIGestureEnvironment _updateForEvent:window:] + 248
    frame #16: 0x00000001b8b6d654 UIKitCore`-[UIWindow sendEvent:] + 3512
    frame #17: 0x00000001b8b48840 UIKitCore`-[UIApplication sendEvent:] + 348
    frame #18: 0x0000000103de4920 WeChat`___lldb_unnamed_symbol111457$$WeChat + 404
    frame #19: 0x00000001ebaaa87c UIKit`-[UIApplicationAccessibility sendEvent:] + 100

有符号更好，没有也无所谓，我们还是可以通过地址在逆向工具中查看代码。不过考虑到 ASLR 的存在，需要确认一下镜像的加载地址:

(lldbinit) vmmap /WeChat
000102790000 - 00010d6d4000  af44000 R-X /private/var/containers/Bundle/Application/2A5D623F-5F8E-4A99-96C8-8CBD00D8B6BE/WeChat.app/WeChat        0 __TEXT
00010d6d4000 - 00010fc40000  256c000 RW- /private/var/containers/Bundle/Application/2A5D623F-5F8E-4A99-96C8-8CBD00D8B6BE/WeChat.app/WeChat  af44000 __DATA
00010fc40000 - 000110ac4000   e84000 R-- /private/var/containers/Bundle/Application/2A5D623F-5F8E-4A99-96C8-8CBD00D8B6BE/WeChat.app/WeChat  cb68000 __LINKEDIT

vmmap 是我自己定义的一个 lldb 命令，参考了 gef 和 pwndbg 在 gdb 中的实现

这里加载地址是 0x000102790000，而在 IDA 中 text 段的加载地址是 0x100004000，可以在后者进行 rebase，但是因为函数不多，所以先手动查找。另外用 lldb 也可以直接查看对应函数地址的偏移:

(lldbinit) image lookup -a 0x0000000105334f04
      Address: WeChat[0x0000000102ba4f04] (WeChat.__TEXT.__text + 45747972)
      Summary: WeChat`___lldb_unnamed_symbol201841$$WeChat
(lldbinit) image lookup -a 0x0000000104b32f80
      Address: WeChat[0x00000001023a2f80] (WeChat.__TEXT.__text + 37351296)
      Summary: WeChat`___lldb_unnamed_symbol170264$$WeChat + 160
(lldbinit) image lookup -a 0x0000000104e06de4
      Address: WeChat[0x0000000102676de4] (WeChat.__TEXT.__text + 40316388)
      Summary: WeChat`___lldb_unnamed_symbol182196$$WeChat + 2600
(lldbinit) image lookup -a 0x000000010294cde8
      Address: WeChat[0x00000001001bcde8] (WeChat.__TEXT.__text + 1805800)
      Summary: WeChat`___lldb_unnamed_symbol8796$$WeChat + 248
(lldbinit) image lookup -a 0x00000001041bb930
      Address: WeChat[0x0000000101a2b930] (WeChat.__TEXT.__text + 27425072)
      Summary: WeChat`___lldb_unnamed_symbol129751$$WeChat + 624

根据 lldb 中每个函数地址在 TEXT 段中的偏移，可以在 IDA 中直接跳转到对应函数(返回值)，整理对应的调用函数分别是:

  • -[BaseMsgContentViewController SendEmoticonMesssageToolView:] (45747972)
  • -[MMInputToolView didSelectorSelfDefinedEmotcion:] (37351296)
  • -[EmoticonBoardView onTapEmoticonWrap:atIndex:maxCountPerLine:fromSection:] (40316388)
  • -[EmoticonBoardCrossCollectionController onEmoticonPageCellTapEmoticonWrap:atIndex:pid:maxCountPerLine:] (1805800)
  • -[EmoticonBoardCrossCollectionEmoticonPageCell collectionView:didSelectItemAtIndexPath:] (27425072)

既然 IDA 可以识别出对应 OC 函数的符号，那么理论上这些符号也是可以还原的，如果经常需要进行动态分析，那么可以通过一些方法自动化恢复对应的符号，可以参考 iOS符号表恢复 以及 restore-symbol 等项目。

静态分析

通过动态分析找到了着手点，以及通过回溯调用栈找到了一些相关函数，其中并没有一目了然的设置骰子点数的函数 setDiceValue，所以要想改点数还需要对上面的函数进行进一步分析。到这里，逆向工程是不可避免了，一般而言我是能躺着绝不坐着，能坐着绝不站着，不到万不得已是不去逆向的。

花开两朵，各表一枝，在前面砸完壳的第一时间我就预感到需要逆向，所以早早地把 200MB 的 MachO 丢进了 IDA，在文章写到这里时已经过去了四个小时，期间看了两集动漫，但是 IDA 还是没有全部分析完。所以在等待的时间里，先来简单介绍些 ObjectiveC 的底层实现。

在学习 OC 的时候，总会看到说 OC 语言实现面向对象是通过发送消息，具体是怎么发送呢？因此在实际逆向之前，我们先来自己写一个程序来进行分析，以便了解 OC 的调用原理。

以下面简单的 helloworld 为例:

#import <Foundation/Foundation.h>

@interface MyClass: NSObject
 - (void)insMethod:(const char *)a1 arg2:(int)a2;
 + (void)clsMethod:(const char *)a1 arg2:(int)a2;
@end

@implementation MyClass
 - (void)insMethod:(const char *)a1 arg2:(int)a2 {
     NSLog(@"insMethod called, self=%p, a1=%s", self, a1);
 }
 + (void)clsMethod:(const char *)a1 arg2:(int)a2 {
     NSLog(@"clsMethod called, self=%p, a1=%s", self, a1);
 }
@end

int main() {
    MyClass *c = [[MyClass alloc] init];
    [MyClass clsMethod:"hello" arg2:1];
    [c insMethod:"world" arg2:2];
    return 0;
}

主要调用了两个方法，一个类方法和一个成员方法，编译后查看其汇编代码如下:

(lldbinit) disassemble
main @ test_hello:
    0x100003e90: push   rbp
    0x100003e91: mov    rbp, rsp
    0x100003e94: sub    rsp, 0x10
    0x100003e98: mov    dword ptr [rbp - 0x4], 0x0
->  0x100003e9f: mov    rax, qword ptr [rip + 0x424a] ; (void *)0x0000000100008120: MyClass
    0x100003ea6: mov    rdi, rax
    0x100003ea9: call   0x100003f04               ; symbol stub for: objc_alloc_init
    0x100003eae: mov    qword ptr [rbp - 0x10], rax
    0x100003eb2: mov    rax, qword ptr [rip + 0x4237] ; (void *)0x0000000100008120: MyClass
    0x100003eb9: mov    rsi, qword ptr [rip + 0x4220] ; "clsMethod:arg2:"
    0x100003ec0: mov    rdi, rax
    0x100003ec3: lea    rdx, [rip + 0xa8]         ; "hello"
    0x100003eca: mov    ecx, 0x1
    0x100003ecf: call   qword ptr [rip + 0x12b]   ; (void *)0x00007fff20439d00: objc_msgSend
    0x100003ed5: mov    rax, qword ptr [rbp - 0x10]
    0x100003ed9: mov    rsi, qword ptr [rip + 0x4208] ; "insMethod:arg2:"
    0x100003ee0: mov    rdi, rax
    0x100003ee3: lea    rdx, [rip + 0x8e]         ; "world"
    0x100003eea: mov    ecx, 0x2
    0x100003eef: call   qword ptr [rip + 0x10b]   ; (void *)0x00007fff20439d00: objc_msgSend
    0x100003ef5: xor    eax, eax
    0x100003ef7: add    rsp, 0x10
    0x100003efb: pop    rbp
    0x100003efc: ret

且不管初始化部分，后面两个函数调用最终都进入了 objc_msgSend 函数，在苹果官网可以看到其函数原型:

id objc_msgSend(self, op, ...);

其中各个参数为:

  1. self: 消息的接收方，对于类方法为指向类的指针，对于对象方法而言为对象指针；
  2. op: 为消息的标识符，也称为 selector，实际上是一个表示对应方法名称的字符串；
  3. … 其他方法参数；

回到上面的例子，第一次类方法调用的参数为:

(lldbinit) p/x $rdi
(unsigned long) $29 = 0x0000000100008120
(lldbinit) x/1s $rsi
0x100003f86: "clsMethod:arg2:"
(lldbinit) x/1s $rdx
0x100003f72: "hello"
(lldbinit) p/x $rcx
(unsigned long) $32 = 0x0000000000000001

第二次成员方法的调用参数为:

(lldbinit) p/x $rdi
(unsigned long) $54 = 0x0000000100208340
(lldbinit) x/1s $rsi
0x100003f96: "insMethod:arg2:"
(lldbinit) x/1s $rdx
0x100003f78: "world"
(lldbinit) p/x $rcx
(unsigned long) $57 = 0x0000000000000002

程序的输出如下:

2021-04-10 22:54:19.487148+0800 test_hello[99332:5120374] clsMethod called, self=0x100008120, a1=hello
2021-04-10 22:54:54.565229+0800 test_hello[99332:5120374] insMethod called, self=0x100208340, a1=world

所以，ObjectiveC 在实现上还是挺接近 C 语言的，这对于我们逆向而言方便很多。

了解了简单的 OC 逆向之后，IDA 也跑的差不多了。根据栈回溯对应 OC 函数的名称，逐级往上看。首先是 didSelectorSelfDefinedEmotcion这个函数，表示选中了某个自定义表情，里面只是一些发送操作，所以并不是我们想要的；

然后是 -[EmoticonBoardView onTapEmoticonWrap:atIndex:maxCountPerLine:fromSection:] ，该函数中主要是判断所选择的表情是否为自拍表情或者自定义表情，如果是的话就进行异步上传。其调用didSelectorSelfDefinedEmotcion 的参数为 a3，即一个对象指针，虽然还不知道是哪个对象，但知道其包含这些属性(方法):

  • m_emojiInfo
  • m_isAsyncUpload
  • attachObject:forKey:

在 class-dump 导出的头文件中搜索，可以发现是CEmoticonWrap 类:

#import <objc/NSObject.h>

#import "PBCoding-Protocol.h"

@class EmojiInfoObj, NSData, NSString;

@interface CEmoticonWrap : NSObject <PBCoding>
{
    _Bool m_bCanDelete;
    _Bool m_isAsyncUpload;
    _Bool m_isRemoteRecommed;
    _Bool m_isLastSended;
    unsigned int m_uiType;
    unsigned int m_uiGameType;
    unsigned int m_lastUsedTime;
    unsigned int m_extFlag;
    NSString *m_nsAppID;
    NSString *m_nsThumbImgPath;
    NSString *m_query;
    EmojiInfoObj *m_emojiInfo;
    NSData *_m_imageData;
}

该函数主要是执行上传并记录一些信息，更新一些 emojiInfo 的字段，所以还是要继续往上走；

接着是-[EmoticonBoardView onTapEmoticonWrap:atIndex:maxCountPerLine:fromSection:]，该函数主要是作为 delegate 进行转发，没有什么实际功能。但是从名字可以猜测自定义表情栏是通过不同的行实现，而每行中每个表情又对应一个 Cell。

按照回溯的堆栈都看完了，也没有发现和骰子相关的代码。不管怎样，骰子的点数总归是在设置骰子图片之前确定的，而根据上面的逆向可以知道，自定义表情的图片应该是定义在 [CEmoticonWrap m_emojiInfo]中，该类的属性如下:

@interface EmojiInfoObj : MMObject <PBCoding, NSCopying>
{
    _Bool _disableExtern;
    NSString *md5;
    NSString *url;
    NSString *thumbUrl;
    NSString *designerId;
    NSString *encryptUrl;
    NSString *aesKey;
    NSString *productId;
    NSString *externUrl;
    NSString *attachedText;
    NSString *externMd5;
    NSString *activityId;
    NSString *attachedTextColor;
    NSString *lensId;
    NSString *linkId;
    NSString *_tpUrlString;
    NSString *_authkey;
}

接下来还是要通过结合动态分析来确定骰子图片加载的时机。

还是回到SendEmoticonMesssageToolView函数，通过逆向可以得知其参数为CEmoticonWrap类型，修改前面打印栈 callback 的脚本，令其打印参数的各个字段，如下:

[+] 21:50:18.958 Called SendEmoticonMesssageToolView:
[+] 21:50:18.958 emotion: <CEmoticonWrap: self.m_uiType=1, self.m_bCanDelete=1, self.m_uiGameType=2, self.m_nsAppID=(null), self.m_extFlag=0, self.m_nsThumbImgPath=(null), self.m_lastUsedTime=0, self.m_isAsyncUpload=0, self.m_isRemoteRecommed=0, self.m_isLastSended=0, self.m_query=(null), self.m_emojiInfo=<EmojiInfoObj: 0x2813c77b0> {
    activityId = <nil>;
    aesKey = <nil>;
    attachedText = <nil>;
    attachedTextColor = <nil>;
    authkey = <nil>;
    designerId = <nil>;
    disableExtern = 0;
    encryptUrl = <nil>;
    externMd5 = <nil>;
    externUrl = <nil>;
    lensId = <nil>;
    linkId = <nil>;
    md5 = "dice_emoticon_md5";
    productId = "custom_emoticon_pid";
    thumbUrl = <nil>;
    tpUrlString = <nil>;
    url = <nil>
}>

也就是说进入函数之时这些参数都是空的，m_emojiInfo 的 md5 为 “dice_emoticon_md5”，此时骰子图像并没有真正生成，所以印证了我们之前的猜想，即实际的操作还在后面。那么栈回溯是不是白看了？也不尽然，至少至少了参数格式和调用流程(逆向嘛，总是要学会安慰自己)。

回过头来继续看这个函数:

void __cdecl -[BaseMsgContentViewController SendEmoticonMesssageToolView:](BaseMsgContentViewController *self, SEL a2, id emotion)
{
  id v4; // x19
  id v5; // x20
  id *v6; // x21
  id v7; // x24
  unsigned __int8 v8; // w23
  id *v9; // x21
  id v10; // x0
  id *v11; // x21
  void *v12; // x20
  id v13; // x24
  unsigned int v14; // w22
  id *v15; // x21

  v4 = objc_retain(emotion);
  v5 = objc_loadWeakRetained((id *)&self->m_delegate);
  if ( ((unsigned int)objc_msgSend(v5, "respondsToSelector:", "CanSendEmoticonMessage") & 1) == 0 )
    goto LABEL_6;
  v7 = objc_loadWeakRetained(v6);
  v8 = (unsigned __int8)objc_msgSend(v7, "CanSendEmoticonMessage");
  objc_release(v7);
  objc_release(v5);
  if ( (v8 & 1) != 0 )
  {
    v10 = objc_loadWeakRetained(v9);
    if ( v10 )
    {
      v12 = v10;
      v13 = objc_loadWeakRetained(v11);
      v14 = (unsigned int)objc_msgSend(v13, "respondsToSelector:", "SendEmoticonMessage:");
      objc_release(v13);
      objc_release(v12);
      if ( v14 )
      {
        v5 = objc_loadWeakRetained(v15);
        objc_msgSend(v5, "SendEmoticonMessage:", v4);
LABEL_6:
        objc_release(v5);
        goto LABEL_7;
      }
    }
  }
LABEL_7:
  objc_release(v4);
}

又是一个 delegate 模式，直接打印出实例:

kObjC.traceMethod("BaseMsgContentViewController", "- SendEmoticonMesssageToolView:", {
  onEnter(args) {
    log.i("Called", args[1].readCString());
    const vc = new ObjC.Object(args[0]);
    const emotion = new ObjC.Object(args[2]);
    log.i("vc:", vc);
    log.i("m_delegate:", vc.valueForKey_("m_delegate"));
  }
});

结果如下:

[+] 19:15:24.203 Called SendEmoticonMesssageToolView:
[+] 19:15:24.204 vc: <BaseMsgContentViewController: 0x1200b8e00>
[+] 19:15:24.206 m_delegate: <WeixinContentLogicController: 0x11f340a90>

是个 WeixinContentLogicController，那就继续找它的SendEmoticonMessage:方法，没有的话就在父类或者 Category 里找。因为程序太大，我的破电脑在 IDA 里搜索比较卡，所以有个小技巧是直接通过函数名跳转，对应的 IDA 函数为名为 -[WeixinContentLogicController SendEmoticonMessage:]，当然实际并没有这个函数，而是在父类中定义的 -[BaseMsgContentLogicController SendEmoticonMessage:]。

ida.png

在上面高亮的一行，IDA 反编译的结果有点问题，显示 V7 是未初始化的，遇到这种情况直接看汇编即可，汇编是不会骗人的:

asm

即第一个参数实际上是 PluginUtil 类的地址，这里调用的则是类方法+[PluginUtil isPluginUserName:]。其中 m_uiGameType 前面已经通过 frida 打印出来了，其值是 2，继续动态分析得知进入 else 分支。按照这种动静结合的策略，最终分析得到向前的调用过程:

  • -[BaseMsgContentLogicController SendEmoticonMessage:]
  • +[GameController GameEmoticonMsgForEmoticonWrap:]
  • +[GameController SetGameContentForMsgWrap:] (参数类型是 CMessageWrap)

最终设置内容如下:

random

看到这逻辑应该很明显了，如果游戏类型为 1，则有:

content = 1 + rand - rand / 3 * 3 = 1 + rand % 3

如果游戏类型为 2，则有:

content = 4 + rand - rand / 6 * 6 = 4 + rand % 6

由于我们选的是扔骰子，游戏类型为 2，骰子的 content 取值范围为 4 ~ 9，正好对应 6 个点数；有理由猜测前面一个 3 个点数的应该就对应剪刀石头布游戏。

这里有两个值得注意的点，一是 random 函数调用了两次，但是后面一次的结果并没有使用，因此目的可能通过减少随机数连续性增加破解伪随机序列的难度；另外一个点是随机后的内容经过了 md5，所以修改点数的时候可能要一并修改哈希，否则会导致校验失败，或者直接修改 random 函数的返回值也是可以的。

kNative.trace(null, "random", {
  onLeave(retval) {
    log.i("random:", retval.toInt32());
    retval.replace(ptr(5));
  }
});

实现效果如下:

dice

至此，修改骰子点数的核心功能就分析完毕了。

再谈 Hook

说实话最近听 hook 这个词已经听到腻了，不管是 plt hook 还是 inline hook，其本质都是在运行时修改现有的代码，进而达到修改控制流的目的。对于二进制汇编代码的修改大同小异，不过对于 iOS 程序而言其实也有其他选择，下面逐一介绍:

这是最为通用的 hook 方式，即在指定地址前增加跳转指令，保存现场并跳转到用户指令，执行完后还原现场并返回执行。inline hook 可以实现汇编指令级别的 trace，也是大部分动态跟踪工具实现的基础。下图为 frida-gum 实现 inline hook 的的大致流程:

frida
OSDC 2015: The engineering behind the reverse engineering

当然原理归原理，要基于公式实现核弹在工程上还要做很多工作，比如代码段通常是不可修改的，因此需要 mmap 拷贝一份到自己的地盘去进行修改；另外保存和恢复现场的操作大多只能用汇编写，因此要实现跨平台还要针对不同指令集进行测试等等。这一切繁重的工作别人都已经为我们做好了，我们需要做的就只是调用一下 Interceptor.attach ，不得不感慨生活真幸福。

前面我们说过，Objective-C 实现面向对象是基于消息的发送，那么针对 Objc 的调用，我们其实可以动态的修改某个 selector 对应的实现，这个过程就称之为 method swizzling。苹果官方也提供了对应的 API:

void method_exchangeImplementations(Method m1, Method m2);

该方法相当于下面指令的原子实现:

IMP imp1 = method_getImplementation(m1);
IMP imp2 = method_getImplementation(m2);
method_setImplementation(m1, imp2);
method_setImplementation(m2, imp1);

还是那句老话，原理是简单的，实现是复杂的。现实中很少这样直接交换两个方法实现，而是在之前进行一些必要的检查，如下所示:

+ (void)load
{
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class aClass = [self class];
        
        SEL originalSelector = @selector(method_original:);
        SEL swizzledSelector = @selector(method_swizzle:);
        
        Method originalMethod = class_getInstanceMethod(aClass, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(aClass, swizzledSelector);
        BOOL didAddMethod =
        class_addMethod(aClass,
                        originalSelector,
                        method_getImplementation(swizzledMethod),
                        method_getTypeEncoding(swizzledMethod));
        
        if (didAddMethod) {
            class_replaceMethod(aClass,
                                               swizzledSelector,
                                               method_getImplementation(originalMethod),
                                               method_getTypeEncoding(originalMethod));
        } else {
            method_exchangeImplementations(originalMethod, swizzledMethod);
        }
    });
}

直接交换方法是危险的，因为如果类中没有实现该方法，那么 class_getInstanceMethod 会返回某个父类中的 Method 对象，实际交换的则是父类的方法，这样其他父类和子类的调用就会出现意想不到的问题。因此上面的代码会判断 selector 方法不存在的情况。

另外还要注意的是 selector 命名冲突问题、重复 swizzling 问题以及 _cmd 被修改的问题等等，因此也就有了 RSSwizzle 或者 jrswizzle 这些完善的实现方案。对于开发人员来说这是个需要仔细考虑的问题，毕竟这影响了程序的稳定性。

值得一提的是，frida 中对于 Objc 也提供了基于 method swizzling 的 hook 方案:

const myMethod_ = ObjC.classes.MyClass.myMethod_;
myMethod_.implementation = ObjC.implement(myMethod_, function (handle, selector, arg0) {
  log.i(`self=${handle}, selector=${selector}, arg0=${arg0}`);
});

在 Java 中，我们可以通过 java.lang.reflect.Proxy 基于反射机制来实现方法的动态代理，这种方式在很多地方被应用于 AOP 即切面编程。而 Objective-C 也有类似的方式，即 NSProxy，该类的定义如下:

/*	NSProxy.h
	Copyright (c) 1994-2019, Apple Inc. All rights reserved.
*/

#import <Foundation/NSObject.h>

@class NSMethodSignature, NSInvocation;

NS_ASSUME_NONNULL_BEGIN

NS_ROOT_CLASS
@interface NSProxy <NSObject> {
    __ptrauth_objc_isa_pointer Class	isa;
}

+ (id)alloc;
+ (id)allocWithZone:(nullable NSZone *)zone NS_AUTOMATED_REFCOUNT_UNAVAILABLE;
+ (Class)class;

- (void)forwardInvocation:(NSInvocation *)invocation;
- (nullable NSMethodSignature *)methodSignatureForSelector:(SEL)sel NS_SWIFT_UNAVAILABLE("NSInvocation and related APIs not available");
- (void)dealloc;
- (void)finalize;
@property (readonly, copy) NSString *description;
@property (readonly, copy) NSString *debugDescription;
+ (BOOL)respondsToSelector:(SEL)aSelector;

- (BOOL)allowsWeakReference API_UNAVAILABLE(macos, ios, watchos, tvos);
- (BOOL)retainWeakReference API_UNAVAILABLE(macos, ios, watchos, tvos);

// - (id)forwardingTargetForSelector:(SEL)aSelector;

@end

NS_ASSUME_NONNULL_END

可以看到其遵守 NSObject protocol，并且第一个 ivar 是 isa 指针，因此可以当成是一个 NSObject 或者其派生类使用，但是它并不是一个 NSObject 的子类。使用上只需要实现两个方法:

- (void)forwardInvocation:(NSInvocation *)invocation;
- (nullable NSMethodSignature *)methodSignatureForSelector:(SEL)sel;

NSInvocation 封装了一个方法调用的全部信息，包括调用参数和返回值。一个示例实现如下:

#import <Foundation/Foundation.h>

@interface MyProxy : NSProxy {
    id victim_;
}
+ (id)hookObject:(id)obj;
@end

@implementation MyProxy
+ (id)hookObject:(id)obj {
    MyProxy *p = [MyProxy alloc];
    p->victim_ = obj;
    return p;
}
- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    return [victim_ methodSignatureForSelector:sel];
}
- (void)forwardInvocation:(NSInvocation *)invocation {
    if ([victim_ respondsToSelector:invocation.selector]) {
        NSString *selectorName = NSStringFromSelector(invocation.selector);
        NSLog(@"ENTER %@", selectorName);
        [invocation invokeWithTarget:victim_];
        NSLog(@"LEAVE %@", selectorName);
    }
}
@end
  
int main(int argc, char *argv[]) {
    dispatch_semaphore_t sem = dispatch_semaphore_create(0);
    
    NSURL *url = [MyProxy hookObject:[NSURL URLWithString:@"https://evilpan.com"]];
    NSURLSessionDataTask *task = [[NSURLSession sharedSession] dataTaskWithURL:url completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
        dispatch_semaphore_signal(sem);
    }];
    [task resume];
    dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
    return 0;
}

输出:

$ ./test_proxy
2021-04-11 11:18:55.193 test_proxy[15011:5637371] ENTER absoluteURL
2021-04-11 11:18:55.194 test_proxy[15011:5637371] LEAVE absoluteURL

直接用我们的 MyProxy 对象替换了原始的 NSURL 对象，这样 NSURL 对象中所调用的所有方法都由我们的 Proxy 对象来进行代理，因此可以在执行原始函数之前以及返回之前执行我们自己的操作，从而实现 hook 的功能。

其他

补充一些前面没有提到的东西。

Mach-O程序是支持多架构的，例如同一个程序既能运行在arm32位也能运行在64位机器上。多架构(multiarch)的应用通常比原程序体积要大，但是比两个单架构的程序要小，因为多架构应用会共享资源。

iOS应用开发者为了保证兼容性通常会选择同时支持armv7和arm64，但对于逆向分析却不必要。因此，我们可以先对其进行瘦身(thin)，只保留arm64架构即可。首先查看应用是否为多架构：

# 通过file命令查看
$ file pp2048/Payload/2048.app/2048
pp2048/Payload/2048.app/2048: Mach-O universal binary with 2 architectures: [arm_v7:Mach-O executable arm_v7] [arm64]
pp2048/Payload/2048.app/2048 (for architecture armv7):	Mach-O executable arm_v7
pp2048/Payload/2048.app/2048 (for architecture arm64):	Mach-O 64-bit executable arm64

# 或者通过lipo命令查看
$ lipo -detailed_info pp2048/Payload/2048.app/2048
Fat header in: pp2048/Payload/2048.app/2048
fat_magic 0xcafebabe
nfat_arch 2
architecture armv7
    cputype CPU_TYPE_ARM
    cpusubtype CPU_SUBTYPE_ARM_V7
    offset 16384
    size 8838944
    align 2^14 (16384)
architecture arm64
    cputype CPU_TYPE_ARM64
    cpusubtype CPU_SUBTYPE_ARM64_ALL
    offset 8863744
    size 10265808
    align 2^14 (16384)

只保留arm64，可以使用lipo或者ditto，二者都是苹果自带的：

# 使用lipo工具
$ lipo -thin arm64 pp2048/Payload/2048.app/2048 -output thin_2048

# 或者使用ditto工具
$ ditto --arch arm64 pp2048/Payload/2048.app/2048 thin_2048

输出的文件是一样的。

前文中有用到 cycript 来注入动态库进行 UI 界面分析，这里再补充一下。cycript 由 saurik 大神开发，在 JavaScript REPL 中支持 ObjectiveC 的混合语法，使用起来比较直观。比如:

cy# [[UIApplication sharedApplication] keyWindow]
#"<iConsoleWindow: 0x11581f120; baseClass = UIWindow; frame = (0 0; 1194 834); gestureRecognizers = <NSArray: 0x2800d0570>; layer = <UIWindowLayer: 0x280eb1800>>"

支持直接调用 c 函数，并且直接使用 enum 常量:

cy# dlopen
(extern "C" void *dlopen(char const*, int))
cy# RTLD_NOW
2
cy# dlopen("/usr/lib/libFLEX.dylib", RTLD_NOW);
(typedef void*)(0x11a23e180)

前面使用 FLEX 进行 UI 分析就是直接通过 dlopen 注入动态库实现的(其实注入 Reveal 也是)。cycript 的功能很强大，但是文档不多，主要是参考官方的 manual。一些参考网站如下:

在越狱 iOS 中有类似于 Andoid Xposed 的 patch 框架 Cydia Substrate，其提供了 C API 给越狱 APP 的开发者来实现对特定方法的动态修改，还提供了基于 plist 的声明文件，让开发者可以选择指定的 APP 进行 hook，同时也很好地处理了同一个方法被 Hook 多次的问题。基于 Substrate 开发的 dylib 称为 Tweak，由 Substrate 根据 plist 在应用启动时选择进行注入。

一个 hook 示例如下:

NSString *(*oldDescription)(id self, SEL _cmd);

// implicit self and _cmd are explicit with IMP ABI
NSString *newDescription(id self, SEL _cmd) {
    NSString *description = (*oldDescription)(self, _cmd);
    description = [description stringByAppendingString:@"!"];
    return description;
}

MSHookMessageEx(
    [NSObject class], @selector(description),
    &newDescription, &oldDescription
);

如果觉得这样写还是太麻烦，可以使用 Logos 来简化代码，这是个基于预处理库的组件，包含一系列以%开头的宏方便编写 hook 代码，示例如下:

%hook SBApplicationController
-(void)uninstallApplication:(SBApplication *)application {
	NSLog(@"Hey, we're hooking uninstallApplication:!");
	%orig; // Call the original implementation of this method
	return;
}
%end

Logos 现在是 Theos 组件的一部分，可以通过 NIC 工程模板系统快速地创建一个基于 Makefile 的 Tweak 项目。初学者可以通过参考一些 开源的 Tweaks 来熟悉开发流程。

LLDB是个功能十分强大的调试器，在有些场景下比GDB还要好用。关于GDB命令可以参考GDB调试笔记，而GDB命令对应的LLDB命令可以参考GDB and LLDB Command Examples，这里只介绍一些常用的例子:

在一个ObjectiveC类中的所有方法下设置断点(正则表达式)：

(lldb) breakpoint set -r '\[ClassName .*\]$'

打印 Objective-C 对象:

(lldb) po addr

查看各个模块的映射地址(target module list)：

(lldb) image list -h -f

设置zero flag，常用于修改跳转指令:

(lldb) register write rflags `$rflags|0x40`

更详细的功能以及 lldb 脚本的编写可以参考下面的链接:

后记

本文以微信扔骰子小游戏为例，介绍了一次完整的 iOS 逆向分析过程。以最初的越狱开始，分别介绍了砸壳、UI 分析、动态分析和静态分析的具体操作，最后还介绍了 iOS 中常见的 hook 方案以及一些越狱开发相关的工具。之前分析过 Android 中微信的扔骰子，里面大部分代码都经过了混淆，相比之下 iOS 中逆向代码就直观很多。现今很多应用都是同时支持两个平台，在一个平台中受阻可以切换到另一个平台说不定有意想不到的收获，比如对于 Unity3D 中 C# 代码的逆向，Android 平台就比 iOS 要方便点 (因为 IL2CPP)。因此，对于有志深造的逆向工程师而言，保持灵活和开放的心态也是至关重要的。

参考资料

]]> 安卓逆向之自动化JNI静态分析 https://evilpan.com/2020/10/07/jni-helper/ Wed, 07 Oct 2020 12:40:00 +0800 evilpan https://evilpan.com/2020/10/07/jni-helper/ 国庆几天在家写了个用于辅助 JNI 接口逆向分析的工具，同时支持 Ghidra、IDA 以及 Radare2。本文即是对这个工具的简单介绍，以及一些编写插件的体验记录。

前言

平时进行安卓逆向时，一个常见的场景就是目标把关键逻辑放到 Native 代码中，使用 JNI 接口进行实现。进行分析一般是把对应的动态库so拖进逆向工具中，然后定位具体的 Native 实现，再对参数类型、JNI 调用等逻辑进行一些优化方便对反汇编/反编译代码的理解。比如对于大家常用的 IDA-Pro 就是 Parse C Header 加载 jni_all.h，然后修改 JNI 接口的函数原型和变量结构。

这对于少量代码来说不是大问题，但显然是一种重复性的劳动，因此我们可以对这个过程进行一定的自动化。目前已经有了一些优秀的项目，比如 aryx 的 JNIAnalyzer，这是一个 Ghidra 插件，支持从 apk 中提取 JNI 接口并批量修改动态库的函数原型。但是这些项目都存在一些问题，而且缺乏拓展性，所以为了方便自己使用就构建了 JNI Helper 项目，支持各类日常使用的逆向工具。

JNI Helper

该项目的详细介绍可以参考 Github，其主要特性有下面这些:

  • 基于 Jadx api 提供一个独立的 Java 可执行程序 JadxFindJNI.jar，用来分析 apk 并提取其中的 JNI 接口信息，并产出一个 JSON 文件；
  • 同时支持 C 和 C++ 类型的 JNI 接口实现；
  • 支持重载的 JNI 函数；
  • 分别实现了 Ghidra、IDA 和 Radare2 的插件用来加载 JadxFindJNI.jar 生成的 JSON 文件；

得益于 Jadx 项目整洁的函数接口，我们可以很方便在其基础上实现自己的功能，如下所示:

JadxArgs jadxArgs = new JadxArgs();
jadxArgs.setDebugInfo(false);
jadxArgs.setSkipResources(true);
jadxArgs.getInputFiles().add(new File(args[0]));
JadxDecompiler jadx = new JadxDecompiler(jadxArgs);
jadx.load();

我们需要实现的主要功能就是调用 Jadx 分析目标 apk，然后迭代每个类和其中的 native 方法。只是有一些需要注意的点，比如对于重载的 JNI 函数。根据 Oracle 的文档，JNI native 函数的命名由以下方式组成:

  • 以Java_为前缀；
  • 格式化的类名完整路径；
  • 下划线分隔符_；
  • 格式化的函数名称；
  • 对于重载函数，需要加双下划线__并跟着参数签名；
  • 对于特殊的字符需要进行转义，比如_、;和]需要分别转义成_1、_2 和_3等；

对于使用者而言，无需关心内部细节:

$ java -jar JadxFindJNI/JadxFindJNI.jar
Usage: JadxFindJNI.jar <file.apk> <output.json>

我在仓库中上传了一个编译好的 demo/app-debug.apk，所生成的 JNI 签名信息如下:

{
  "Java_com_evilpan_demojni_MainActivity_testOverload__I": {
    "argumentSignature": "I",
    "argumentTypes": [
      "jint"
    ],
    "returnType": "jint",
    "isStatic": false
  },
  "Java_com_evilpan_demojni_MainActivity_testStatic": {
    "argumentSignature": "I",
    "argumentTypes": [
      "jint"
    ],
    "returnType": "jint",
    "isStatic": true
  },
  "Java_com_evilpan_demojni_MainActivity_stringFromJNI": {
    "argumentSignature": "",
    "argumentTypes": [],
    "returnType": "jstring",
    "isStatic": false
  },
  "Java_com_evilpan_demojni_MainActivity_c_1testArray": {
    "argumentSignature": "[I",
    "argumentTypes": [
      "jintArray"
    ],
    "returnType": "void",
    "isStatic": false
  },
 	...
}

该 JSON 函数签名文件以 JNI 函数的 native 名称为键，可以方便地在各种语言中反序列化为哈希表，从而方便函数的查找。

JadxFindJNI.jar可以自己编译，也可以使用打包好的版本。

只要有了函数签名信息，就很方便在各种逆向工具中进行自动化处理了，这里选取的是我比较常用的几个逆向工具，Ghidra、IDA 和 Radare2。这几个工具的插件都是使用 Python 编写的，感兴趣可以直接查看源码，优化前后的反编译代码如下图所示。

Ghidra 优化前:

Ghidra 优化前

Ghidra 优化后:

Ghidra 优化后

IDA-Pro 优化前:

IDA-Pro 优化前

IDA-Pro 优化后:

IDA-Pro 优化后

详见 https://github.com/evilpan/jni_helper 。

插件编写体验

在实现 JNI Helper 的过程中，摸索了一遍不同逆向工具的拓展功能，所以这里谈谈编写过程中的一些感受，正好也可以作为一次横向对比。

Ghidra 作为 NSA 出品的工具，拥有丰富的内部资料，开发文档非常整洁规范。虽然说是机缘巧合之下泄露出来才开源的版本，但其质量可以和许多商业工具相媲美，甚至在很多方面还稍胜一筹。使用下来发现 Ghidra 有很多在线文档和资料，可以很方便地实现指定功能，这个跟后面的两个工具可以说形成鲜明对比。

由于 Ghidra 是使用 Java 进行开发的，因此一个明显的问题是运行分析速度相对较慢。这个问题我的一个解决办法是通过 headlessAnalyzer 在性能较好的云服务器后台对目标先进行分析，导出 .gzf 项目文件再在本地导入。本地的 Ghidra 插件通常使用 Java 进行开发，但可以通过 JPython 使用 Python 脚本编写。

得益于开源软件的特性，开源社区中对于 Ghidra 插件和资料的贡献一直呈爆发式增长。当然这也是因为软件本身投入了很多国家经费被打磨过很长时间，另外一个开源逆向工具 Radare2 就相形见绌了，后面会说到。

一些比较有用的 Ghidra 相关参考资料如下:

老牌逆向工具，在 Ghidra 出来之前已经制霸了十几年，因此也拥有丰富的插件生态。从使用者的角度来说，IDA 无疑是一个优秀的选择，其反编译器可以给出非常接近源码的高层伪代码，极大减少了逆向工程师的工作量。缺点也就一个: 太贵。每年几千美刀的授权费用对于个人逆向爱好者而言并不是一个小数目，而且还分别针对不同的指令集架构进行收费。之前还满心期待家庭版的 IDA Home，365美元一年，但是没有 decompiler、没有 SDK、还不能商业使用，于是我又默默关闭页面并掏出了 Binary Ninja。

因此要有一个舒适的逆向体验，还是需要一个 IDA Pro。从插件开发者的角度来说，IDA Pro 本身确实提供了接口文档，而且由于年代久远也积累了许多插件生态，但是实际使用下来还是有些卡壳。举例来说，在写插件的过程中遇到一个需求，比如判断jni_all.h这个头文件是否已经加载过，即某个结构体是否已经定义，在文档中说是使用下面的 idapython 接口:

idaapi.get_struc_id('JNIInvokeInterface_') != idaapi.BADADDR

可是实际上这样即便 JNI 接口已经定义，返回也是 BADADDR 。最终实现还是通过一种比较取巧的方法，即根据下面的语句是否抛出异常来判断:

idc.parse_decl('JNIInvokeInterface_ *if', idc.PT_SILENT)

类似的问题还有不少，而且很多技巧需要通过阅读其他人的插件代码去了解，对于不熟悉的开发者来说体验并不是太好。下面是一些 IDA 开发相关的资料:

作为一个骨灰级命令行爱好者，接触 Radare2(r2) 也是顺应自然的选择。最初使用 Radare2 的一个原因是因为其开源，可以在各个平台中使用；另外一个原因是支持 VI 快捷键，省去了我很大的学习成本。虽然一开始以命令行逆向工具为卖点，但也可以配合 Cutter 使用。

虽然每次我都狂热推荐使用 r2，但实际上他也有明显的局限性，其中一个是 decompiler 的缺乏。这可以使用一些三方的 decompiler 实现，比如:

  • Ghidra Decompiler
  • RetDec Decompiler
  • r2dec

作为插件开发者，使用的主要是 r2pipe 接口，这个接口实际上是 r2 的命令行参数的管道，所以写插件本质上还是需要通过 r2 的命令实现。说到 r2 的命令，内置的帮助信息可以方便日常使用的查询，用户只需要记得大致的命令类目，比如分析类命令是a开头，可以使用a?查看所有分析相关的命令，进而可以使用af?查看所有和函数分析相关的命令。

虽然和 Ghidra 一样是开源工具，但由于 r2 主要是爱好者去维护，因此投入上的差距也导致了开发进度的差距。在 Github 中可以看到开发者们经常在努力修 bug 以及更新优化代码，但关闭 issue 的速度远跟不上新开 issue 的速度。举一个遇到的例子，我想要修改某个地址对应函数的签名为对应 JNI 函数签名，搜索后发现有几种方法: 一是使用 afvr/avfn/afvt 修改变量；二是使用 tl (type link)去连接类型；三是使用 afs 去直接修改签名信息。可测试下来这几种方式都有问题。其中 afs 是最接近我需求的命令了，但是却不支持自定义的类型，而解决这个问题还需要等 r2 项目组将内置 parser 从 Tcc 迁移到 tree-sitter (见 issue#17432)。诸如此类的问题也是比较打击插件开发者积极性的，毕竟谁也不想为了一个简单的功能找半天文档发现无法实现。

尽管如此，我还是非常看好 Radare2 的未来，他年岁尚浅，但有很大的拓展性，值得持续保持关注。同时也应该给开发者更多的耐心和支持，如果可以的话，为其添砖加瓦。下面是一些 r2 相关的资料:

后记

本文主要是分享 JNI Helper 这个辅助自动化静态逆向分析 JNI 接口的工具，可以在日常安卓逆向时候减少一些重复的劳动。俗话说工欲善其事，必先利其器，在日常中打磨自己的武器库值得投入必要时间，但也要避免陷入盲目造轮子的冲动。另一方面，也记录一下在编写各个逆向工具插件过程中的一些感受。总的来说 Ghidra 的插件编写体验最好，文档丰富且完善，不愧为 NSA 的产品；其次是 IDAPython，虽然有部分文档，但很多都只是一句话带过，想查找某些特定功能需要花费额外时间；而对于 Radare2，虽然是使用管道来进行批处理，但基本的交互都可以支持，只是部分功能实现尚不完善，需要给开发者更多的支持和耐心，毕竟大家都是花费着自己的业余时间和精力去维护和贡献。希望能有更多人投入到 Radare2 的社区中，哪怕只是贡献一点文档，写一写 writeup，对开源社区的帮助也是很大的。

参考链接

]]> GDB的那些奇淫技巧 https://evilpan.com/2020/09/13/gdb-tips/ Sun, 13 Sep 2020 15:40:00 +0800 evilpan https://evilpan.com/2020/09/13/gdb-tips/ gdb也用了好几年了，虽然称不上骨灰级玩家，但也有一些自己的经验，因此分享出来给大家，顺便也作为一个存档记录。

多进程调试

最近在调试一个漏洞的exploit时遇到一个问题。目标漏洞程序是一个 CGI 程序，由主进程调起，而且运行只有一瞬的时间；我的需求是想要在在该程序中下断点，在内存布局之后可以调试我的 shellcode，该如何实现？当然目标程序是没有符号的，而且我希望下的断点是一个动态地址。在 lldb 中有--wait-for，gdb 里却没有对应的命令，经过多次摸索，终于总结出一个比较完美的解决方案。

这里构建一个简单的示例来进行实际演示。首先是父进程:

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

int main(int argc, char **argv, char **env) {
    printf("parent started, pid=%d\n", getpid());

    char *line = NULL;
    size_t len = 0;
    ssize_t read;
    while ((read = getline(&line, &len, stdin)) != -1) {
        pid_t pid = fork();
        if (pid == -1) {
            perror("fork");
            break;
        }

        if (pid == 0) {
            printf("1 fork return in child, pid=%d\n", getpid());
            char *const av[] = {"child", line, NULL};
            if (-1 == execve("./child", av, env)) {
                perror("execve");
                break;
            }
        } else {
            printf("2 fork return in parent, child pid=%d\n", pid);
            int status = 0;
            wait(&status);
        }
    }

    return 0;
}

子进程很简单:

#include <stdio.h>
#include <string.h>

void vuln(char *str) {
    char buf[4];
    strcpy(buf, str);
    printf("child buf: %s", buf);
}

int main(int argc, char **argv) {
    puts("child started");
    vuln(argv[1]);
    return 0;
}

这里编译子进程时候指定-no-pie，并且strip掉符号。我们的调试目标是断点在子进程的strcpy中，拓展来说是希望能断点在子进程的任意地址上。

通过搜索可以找到一个 stackoverflow 的回答: gdb break when entering child process。根据其说法，使用 set follow-fork-mode child即可。这是一个 gdb 命令，其目的是告诉 gdb 在目标应用调用fork之后接着调试子进程而不是父进程，因为在 Linux 中fork系统调用成功会返回两次，一次在父进程，一次在子进程。我们来试一下，直接断点在 strcpy 符号中:

gdb child --pid $parent_pid
(gdb) set follow-fork-mode child
(gdb) b strcpy
Breakpoint 1 at 0x4004c0
(gdb) c
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x4004c0

Command aborted.

噢，断点都打不上，理由很简单，因为不同进程之间的虚拟地址空间都不一样。

另外一个回答中说了，虽然不能断在指定地址，但我们可以break main，告诉 gdb 把断点设置在 main 函数。不过我们的子进程是没有符号的，所以break main并没有卵用。

现在已经有了让 gdb 跟着子进程的方法，只不过问题是无法把断点打到子进程上，因为子进程还没有启动，那么用硬件断点可不可以？

gdb child --pid $parent_pid
(gdb) set follow-fork-mode child
(gdb) hb *0x4004c0
Hardware assisted breakpoint 1 at 0x4004c0
(gdb) c
Continuing.
[New process 309]
process 309 is executing new program: /pwn/child

Thread 2.1 "child" received signal SIGABRT, Aborted.
[Switching to process 309]

可以是可以，但是断点压根没有触发，子进程直接拷贝溢出崩溃了都没有停下来！所以硬件断点在这里并没有用。

那么把断点设置在一些起始函数的上呢？根据之前对 ELF 以及动态链接的学习，我们可以断在比如_start或者__libc_start_main上面:

gdb child --pid $parent_pid
(gdb) set follow-fork-mode child
(gdb) b _start
Breakpoint 1 at 0x7fbfb4c30090

实际上该断点也不会触发，因为这个地址是是父进程的地址空间。

不过到现在答案已经呼之欲出了，总结一下，gdb 支持:

  • fork 之后跟踪到子进程
  • 可以设置软断点
  • 子进程有 _start 符号

所以，就有了一个最终方案。

我的最终方案如下:

set detach-on-fork on
set follow-fork-mode child
set breakpoint pending on
b _start
attach $parent_pid
file child
continue

首先告诉 gdb 跟踪子进程；然后设置set breakpoint pending on是为了在设置断点时让 gdb 不强制在对符号下断点时就需要固定地址，这样在b _start时就会 pending 而不是报错；最后再连接到父进程以及加载子进程的符号。

detach-on-fork on是为了在 fork 之后断开父进程，避免 gdb 退出时把父进程杀死，并不是这节的重点。

其中的时序非常重要。如果先 attach 父进程再下断点，那么断点会直接下到父进程空间从而不会触发；如果先读取了子进程的符号再下断点，可能会下在一个错误的虚拟地址上。

这也是我用了很久的一个方法，不过后来我知道了有更官方的解决方式:

set follow-fork-mode child
catch exec

囧，……

Catch Point真是个好东西，支持很多有用的事件:

  • 常规的C++异常事件
  • 系统调用事件(可直接指定系统调用号)
  • 动态库的加载/卸载事件
  • exec/fork/vfork
  • …

看来文档搜索能力还有待提高啊。……

多线程调试

在调试大型程序的时候，经常会遇到这么一个问题，即涉及到的线程很多，少则十几个多则上百个线程。在这些线程之间穿梭也是一个常见的困难。

首先最基本的是线程的切换命令:

  • info threads: 查看当前所有的线程
  • thread n: 切换到 id 为n的线程中

对于进程也有类似的命令info inferiors/inferior n，在调试多进程交互的程序时会经常用到。

其次，在对某个线程进行单步调试时，会遇到 CPU 的迷之调度，突然一个next或者nexti就跑到其他线程去了，这个时候有个特殊的参数scheduler-locking可以解决这个问题:

(gdb) help set scheduler-locking
Set mode for locking scheduler during execution.
off    == no locking (threads may preempt at any time)
on     == full locking (no thread except the current thread may run)
          This applies to both normal execution and replay mode.
step   == scheduler locked during stepping commands (step, next, stepi, nexti).
          In this mode, other threads may run during other commands.
          This applies to both normal execution and replay mode.
replay == scheduler locked in replay mode and unlocked during normal execution.

通常设置为step模式可解决单步调试的问题。

程序运行

我经常用到的一个功能是需要使用 gdb 执行某个程序，并且能精确控制程序的参数，包括命令行、标准输入和环境变量等。gdb 的 run 命令就是用来执行程序的。

这里还是先写个示例测试程序:

// demo.c
#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv) {
    int n;
    char buf[10];
    for (int i = 0; i < argc; i++)
        printf("argv[%d] = %s\n", i, argv[i]);

    int nread;
    nread = read(STDIN_FILENO, buf, 10);
    printf("first read: %d\n", nread);
   
    nread = read(STDIN_FILENO, buf, 10);
    printf("second read: %d\n", nread);
    return 0;
}

最基本的，通过 run 命令控制命令行参数:

$ gdb demo
(gdb) run hello world
Starting program: /pwn/demo hello world
argv[0] = /pwn/demo
argv[1] = hello
argv[2] = world

或者在运行前设置args参数:

(gdb) set args hello world
(gdb) run
Starting program: /pwn/demo hello world
argv[0] = /pwn/demo
argv[1] = hello
argv[2] = world

在漏洞挖掘或者 CTF 比赛中经常遇到的情况是某些输入触发了进程崩溃，因此要挂 gdb 进行分析，这时候就需要gdb 挂载的程序能够以指定的标准输入运行。如果标准输入是文件，那很简单:

$ gdb demo
(gdb) run <file

但更多时候为了方便调试，希望能以其他程序的输出来运行，比如:

$ python -c 'print "A"*100' | ./demo

可惜 gdb 不支持这种管道，不过可以通过下面的方法实现:

$ gdb demo
(gdb) run < <(python -c 'print "A"*100')
Starting program: /pwn/demo < <(python -c 'print "A"*100')
argv[0] = /pwn/demo
first read: 10
second read: 10

或者:

$ gdb demo
(gdb) run <<<$(python -c 'print "A"*100')
Starting program: /pwn/demo <<<$(python -c 'print "A"*100')
argv[0] = /pwn/demo
first read: 10
second read: 10

后者实际上是 shell 命令 here string的一种形式。这两种方式是有区别的，注意示例程序中 read 调用会提前返回，所以如果我们想要第一次读取3个字符，第二次读取4个字符的话，就不能一次性全部输入。比如下面这样就不符合预期了:

$ gdb demo
(gdb) run < <(echo -n 1112222)
Starting program: /pwn/demo < <(echo -n 1112222)
argv[0] = /pwn/demo
first read: 7
second read: 0

正确的方式应该是这样:

$ gdb demo
(gdb) run < <(echo -n 111; sleep 1; echo -n 2222)
Starting program: /pwn/demo < <(echo -n 111; sleep 1; echo -n 2222)
argv[0] = /pwn/demo
first read: 3
second read: 4

值得注意的是，这种情况下，使用here string是没用的，因为该字符串是计算完再一次性传给命令:

(gdb) run <<<$(echo -n 111; sleep 1; echo -n 2222)
Starting program: /pwn/demo <<<$(echo -n 111; sleep 1; echo -n 2222)
argv[0] = /pwn/demo
first read: 8
second read: 0

而且这里是8字节，因为末尾还带了个回车。 所以我更偏向于使用第一种方式。

对于运行程序而言，还有个重要的参数来源是环境变量，比如在调试 CGI 程序的时候。这在 gdb 中可以使用environment参数，不过需要注意的是该参数的设置是以空格为切分而不是传统的以=对环境变量赋值。

(gdb) help set environment
Set environment variable value to give the program.
Arguments are VAR VALUE where VAR is variable name and VALUE is value.
VALUES of environment variables are uninterpreted strings.
This does not affect the program until the next "run" command.

还有要注意的是这个参数要求变量是uninterpreted strings，也就是说只能指定可打印字符。如果我们要传输一个的 payload 或者 shellcode 还要用 gdb 调试怎么办呢？我一般使用的方式是在调用 gdb 时指定，比如:

$ env CONTENT_TYPE="$(python -c "print 'A'*10 + '\x04\x03\x02\x01'")" gdb demo
(gdb) run

后记

对于二进制研究人员来说，gdb 是一个锋利的好工具，支持X86、ARM、MIPS、RISCV、Xtensa等各种常用和不常用的系统架构，对其熟练使用有时候可以达到事半功倍的效果，在文末的附录中我也列举了一些比较常用的命令。由于 gdb 本身支持 python 接口，因此现实中使用通常结合一些拓展使用，比如:

这几个我都用过，各有千秋。现在工作中使用更多的是gef，因为安装太方便了，一个文件搞定。

上面这几个拓展可能大家可能都不陌生，但还有另外一个我比较常用的是 gdb-dashboard，其功能更为简单，而且使用的是 gdb 原本的信息，所以支持的指令集更多。比如下面的截图就是我曾经用 gdb + OpenOCD 来调试 ESP32固件的示例:

esp32
Xtensa指令集调试

ESP32是比较少见的Xtensa指令集架构，上面的拓展都不支持，不过 gdb 本身支持，因此配合使用的效果绝佳。

附录: gdb命令表

gdb 还有其他一些小技巧，可以参考awesome-cheatsheets/tools/gdb.txt中的列表。该列表最初由韦神创建，我时不时也会添加一些上去。当然为了方便大家的查阅，这里直接给出汇总表格附录:

命令 含义 备注
gdb object 正常启动，加载可执行
gdb object core 对可执行 + core 文件进行调试
gdb object pid 对正在执行的进程进行调试
gdb 正常启动，启动后需要 file 命令手动加载
gdb -tui 启用 gdb 的文本界面（或 ctrl-x ctrl-a 更换 CLI/TUI）
命令 含义 备注
help 列出命令分类
help running 查看某个类别的帮助信息
help run 查看命令 run 的帮助
help info 列出查看程序运行状态相关的命令
help info line 列出具体的一个运行状态命令的帮助
help show 列出 GDB 状态相关的命令
help show commands 列出 show 命令的帮助
命令 含义 备注
break main 对函数 main 设置一个断点，可简写为 b main
break 101 对源代码的行号设置断点，可简写为 b 101
break basic.c:101 对源代码和行号设置断点
break basic.c:foo 对源代码和函数名设置断点
break *0x00400448 对内存地址 0x00400448 设置断点
info breakpoints 列出当前的所有断点信息，可简写为 info break
delete 1 按编号删除一个断点
delete 删除所有断点
clear 删除在当前行的断点
clear function 删除函数断点
clear line 删除行号断点
clear basic.c:101 删除文件名和行号的断点
clear basic.c:main 删除文件名和函数名的断点
clear *0x00400448 删除内存地址的断点
disable 2 禁用某断点，但是部删除
enable 2 允许某个之前被禁用的断点，让它生效
rbreak {regexpr} 匹配正则的函数前断点，如 ex_* 将断点 ex_ 开头的函数
tbreak function/line 临时断点
hbreak function/line 硬件断点
ignore {id} {count} 忽略某断点 N-1 次
condition {id} {expr} 条件断点，只有在条件生效时才发生
condition 2 i == 20 2号断点只有在 i == 20 条件为真时才生效
watch {expr} 对变量设置监视点
info watchpoints 显示所有观察点
catch exec 断点在exec事件，即子进程的入口地址
命令 含义 备注
run 运行程序
run {args} 以某参数运行程序
run < file 以某文件为标准输入运行程序
run < <(cmd) 以某命令的输出作为标准输入运行程序
run <<< $(cmd) 以某命令的输出作为标准输入运行程序 Here-String
set args {args} ... 设置运行的参数
show args 显示当前的运行参数
cont 继续运行，可简写为 c
step 单步进入，碰到函数会进去
step {count} 单步多少次
next 单步跳过，碰到函数不会进入
next {count} 单步多少次
CTRL+C 发送 SIGINT 信号，中止当前运行的程序
attach {process-id} 链接上当前正在运行的进程，开始调试
detach 断开进程链接
finish 结束当前函数的运行
until 持续执行直到代码行号大于当前行号（跳出循环）
until {line} 持续执行直到执行到某行
kill 杀死当前运行的函数
命令 含义 备注
bt 打印 backtrace
frame 显示当前运行的栈帧
up 向上移动栈帧（向着 main 函数）
down 向下移动栈帧（远离 main 函数）
info locals 打印帧内的相关变量
info args 打印函数的参数
命令 含义 备注
list 101 显示第 101 行周围 10行代码
list 1,10 显示 1 到 10 行代码
list main 显示函数周围代码
list basic.c:main 显示另外一个源代码文件的函数周围代码
list - 重复之前 10 行代码
list *0x22e4 显示特定地址的代码
cd dir 切换当前目录
pwd 显示当前目录
search {regexpr} 向前进行正则搜索
reverse-search {regexp} 向后进行正则搜索
dir {dirname} 增加源代码搜索路径
dir 复位源代码搜索路径（清空）
show directories 显示源代码路径
命令 含义 备注
print {expression} 打印表达式，并且增加到打印历史
print /x {expression} 十六进制输出，print 可以简写为 p
print array[i]@count 打印数组范围
print $ 打印之前的变量
print *$->next 打印 list
print $1 输出打印历史里第一条
print ::gx 将变量可视范围（scope）设置为全局
print 'basic.c'::gx 打印某源代码里的全局变量，(gdb 4.6)
print /x &main 打印函数地址
x *0x11223344 显示给定地址的内存数据
x /nfu {address} 打印内存数据，n是多少个，f是格式，u是单位大小
x /10xb *0x11223344 按十六进制打印内存地址 0x11223344 处的十个字节
x/x &gx 按十六进制打印变量 gx，x和斜杆后参数可以连写
x/4wx &main 按十六进制打印位于 main 函数开头的四个 long
x/gf &gd1 打印 double 类型
help x 查看关于 x 命令的帮助
info locals 打印本地局部变量
info functions {regexp} 打印函数名称
info variables {regexp} 打印全局变量名称
ptype name 查看类型定义，比如 ptype FILE，查看 FILE 结构体定义
whatis {expression} 查看表达式的类型
set var = {expression} 变量赋值
display {expression} 在单步指令后查看某表达式的值
undisplay 删除单步后对某些值的监控
info display 显示监视的表达式
show values 查看记录到打印历史中的变量的值 (gdb 4.0)
info history 查看打印历史的帮助 (gdb 3.5)
命令 含义 备注
file {object} 加载新的可执行文件供调试
file 放弃可执行和符号表信息
symbol-file {object} 仅加载符号表
exec-file {object} 指定用于调试的可执行文件（非符号表）
core-file {core} 加载 core 用于分析
命令 含义 备注
info signals 打印信号设置
handle {signo} {actions} 设置信号的调试行为
handle INT print 信号发生时打印信息
handle INT noprint 信号发生时不打印信息
handle INT stop 信号发生时中止被调试程序
handle INT nostop 信号发生时不中止被调试程序
handle INT pass 调试器接获信号，不让程序知道
handle INT nopass 调试起不接获信号
signal signo 继续并将信号转移给程序
signal 0 继续但不把信号给程序
命令 含义 备注
info threads 查看当前线程和 id
thread {id} 切换当前调试线程为指定 id 的线程
break {line} thread all 所有线程在指定行号处设置断点
thread apply {id..} cmd 指定多个线程共同执行 gdb 命令
thread apply all cmd 所有线程共同执行 gdb 命令
set schedule-locking ? 调试一个线程时，其他线程是否执行
set non-stop on/off 调试一个线程时，其他线程是否运行
set pagination on/off 调试一个线程时，分页是否停止
set target-async on/off 同步或者异步调试，是否等待线程中止的信息
命令 含义 备注
info inferiors 查看当前进程和 id
inferior {id} 切换某个进程
kill inferior {id...} 杀死某个进程
set detach-on-fork on/off 设置当进程调用fork时gdb是否同时调试父子进程
set follow-fork-mode parent/child 设置当进程调用fork时是否进入子进程
命令 含义 备注
info registers 打印普通寄存器
info all-registers 打印所有寄存器
print/x $pc 打印单个寄存器
stepi 指令级别单步进入 si
nexti 指令级别单步跳过 ni
display/i $pc 监控寄存器（每条单步完以后会自动打印值）
x/x &gx 十六进制打印变量
info line 22 打印行号为 22 的内存地址信息
info line *0x2c4e 打印给定内存地址对应的源代码和行号信息
disassemble {addr} 对地址进行反汇编，比如 disassemble 0x2c4e
命令 含义 备注
show commands 显示历史命令 (gdb 4.0)
info editing 显示历史命令 (gdb 3.5)
ESC-CTRL-J 切换到 Vi 命令行编辑模式
set history expansion on 允许类 c-shell 的历史
break class::member 在类成员处设置断点
list class:member 显示类成员代码
ptype class 查看类包含的成员 /o可以看成员偏移，类似pahole
print *this 查看 this 指针
define command ... end 定义用户命令
<return> 直接按回车执行上一条指令
shell {command} [args] 执行 shell 命令
source {file} 从文件加载 gdb 命令
quit 退出 gdb
]]> 深入浅出MachO https://evilpan.com/2020/09/06/macho-inside-out/ Sun, 06 Sep 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/09/06/macho-inside-out/ 之前写了一篇深入浅出ELF，作为姊妹篇这次就来聊聊MacOS的可执行文件格式MachO。

Mach-O 101

在之前的文章中我们说过，可执行文件的使命有两个，一是方便开发者在编译、链接时提供可扩展的封装结构；二是在执行时能给操作系统(内核)提供内存映射信息。MachO也不例外。

MachO本身没有什么特别的含义，就是Mach object的简写，而Mach是早期的一个微内核。和ELF一样，MachO也极具拓展性，从全局视角来看，MachO文件可以分为三个部分，分别是:

  1. Mach Header: 文件头信息
  2. 可变长度的LOAD_COMMAND信息
  3. 上述LOAD_COMMAND中所用到的具体信息(segments)

这里的segment可以理解为一段连续的内存空间，拥有对应的读/写/执行权限，并且在内存中总是页对齐的。每个segment由一个或者多个section组成，section表示特定含义数据或者代码的集合(不需要页对齐)。在macOS中，通常约定segment的名称为双下划线加全大写字母(如__TEXT)，section的名称为双下划线加小写字母(如__text)。

下面对这三个部分进行分别介绍。

注: MachO文件结构的表示通常分为32位和64位两种，本文以64位为例，毕竟这是历史的进程。

文件头信息参考mach-o/loader.h中的定义如下:

/*
 * The 64-bit mach header appears at the very beginning of object files for
 * 64-bit architectures.
 */
struct mach_header_64 {
	uint32_t	magic;		/* mach magic number identifier */
	cpu_type_t	cputype;	/* cpu specifier */
	cpu_subtype_t	cpusubtype;	/* machine specifier */
	uint32_t	filetype;	/* type of file */
	uint32_t	ncmds;		/* number of load commands */
	uint32_t	sizeofcmds;	/* the size of all the load commands */
	uint32_t	flags;		/* flags */
	uint32_t	reserved;	/* reserved */
};

/* Constant for the magic field of the mach_header_64 (64-bit architectures) */
#define MH_MAGIC_64 0xfeedfacf /* the 64-bit mach magic number */
#define MH_CIGAM_64 0xcffaedfe /* NXSwapInt(MH_MAGIC_64) */

filetype表示类型，常见的有:

  • MH_OBJECT: 可重定向的目标文件
  • MH_EXECUTE: 可执行文件
  • MH_DYLIB: 动态绑定的共享库文件
  • …

flags为不同的文件标签的组合，每个标签占一个位，可以用位或来进行组合，常见的标签有:

  • MH_NOUNDEFS: 该文件没有未定义的引用
  • MH_DYLDLINK: 该文件将要作为动态链接器的输入，不能再被静态链接器修改
  • MH_TWOLEVEL: 该文件使用两级名字空间绑定
  • MH_PIE: 可执行文件会被加载到随机地址，只对MH_EXECUTE有效
  • …

另外一个值得关注的就是ncmds和sizeofcmds，分别指定了 LOAD_COMMAND 的个数以及总大小，从这里也大概能猜到，每个 command 的大小是可变的。

LOAD_COMMAND是体现MachO文件拓展性的地方，每个 command 的头两个word分别表示类型和大小，如下:

struct load_command {
	uint32_t cmd;		/* type of load command */
	uint32_t cmdsize;	/* total size of command in bytes */
};

不同的cmd类型都会有其对应的结构体来描述其内容，cmdsize表示的是整个cmd的大小，即包括头部和内容。也就是说在处理的时候当前cmd的位置加上cmdsize就是下一个cmd的位置。注意每个command的大小(即cmdsize)需要word对齐，对于32位CPU来说是4字节，64位则是8字节；同时对齐末尾的填充部分必须是0。

loader.h中绝大部分的篇幅就是用来定义各种不同command类型的结构体了，这里挑选一些比较常见的来进行介绍。

LC_SEGMENT/LC_SEGMENT64可以说是最重要的一个command。表示当前文件的一部分将会映射到目标进程(task)的地址空间中，包括程序运行所需要的所有代码和数据。假设当前MachO文件的起始地址为begin，则映射的内容为:

  • 原始地址(文件地址): begin + fileoff，大小为filesize
  • 目的地址(进程虚址): vmaddr，大小为vmsize

其中vmsize >= filesize，如果有多出来的部分需要填充为零。segment_command的结构体表示如下:

struct segment_command_64 { /* for 64-bit architectures */
	uint32_t	cmd;		/* LC_SEGMENT_64 */
	uint32_t	cmdsize;	/* includes sizeof section_64 structs */
	char		segname[16];	/* segment name */
	uint64_t	vmaddr;		/* memory address of this segment */
	uint64_t	vmsize;		/* memory size of this segment */
	uint64_t	fileoff;	/* file offset of this segment */
	uint64_t	filesize;	/* amount to map from the file */
	vm_prot_t	maxprot;	/* maximum VM protection */
	vm_prot_t	initprot;	/* initial VM protection */
	uint32_t	nsects;		/* number of sections in segment */
	uint32_t	flags;		/* flags */
};

maxprot/initprot表示对应segment虚拟地址空间的RWX权限。如果segment包含一个或者多个section，那么在该segment结构体之后就紧跟着对应各个section头，总大小也包括在cmdsize之中，其结构如下:

struct section_64 { /* for 64-bit architectures */
	char		sectname[16];	/* name of this section */
	char		segname[16];	/* segment this section goes in */
	uint64_t	addr;		/* memory address of this section */
	uint64_t	size;		/* size in bytes of this section */
	uint32_t	offset;		/* file offset of this section */
	uint32_t	align;		/* section alignment (power of 2) */
	uint32_t	reloff;		/* file offset of relocation entries */
	uint32_t	nreloc;		/* number of relocation entries */
	uint32_t	flags;		/* flags (section type and attributes)*/
	uint32_t	reserved1;	/* reserved (for offset or index) */
	uint32_t	reserved2;	/* reserved (for count or sizeof) */
	uint32_t	reserved3;	/* reserved */
};

每个section头对应一个section，位置在相对文件起始地址的offset处，大小为size字节，对应的虚拟地址为addr。这里的align对齐指的是在虚拟地址空间中的对齐，实际上在文件中是连续存放的，因为有size指定大小。reloff和nreloc与符号的重定向有关，在下面的加载过程一节中再进行介绍。

从这里可以看出，section的内容和segment是不连续存放的，只是section header在对应segment之后。而segment的vmsize实际上会大于segment+section_header的大小(即cmdsize)，猜测多出来的空间是内核加载MachO时将对应section内容填充进去，后面将会对这一猜测进行验证。

TEXT

__TEXT段包含__text、__stubs、__stub_helper、__cstring等section，一般用来存放不可修改的数据，比如代码和const字符串，可以用otool查看对应的section内容:

$ otool -V main -s __TEXT __stubs
main:
Contents of (__TEXT,__stubs) section
0000000100000f6a	jmpq	*0xa8(%rip) ## literal pool symbol address: _printf
0000000100000f70	jmpq	*0xaa(%rip) ## literal pool symbol address: _set_foo

在实际的MachO可执行文件中观察发现TEXT的fileoff为0，也就是说TEXT段映射的时候会将当前文件头部分也映射到进程空间中。

(lldbinit) image dump sections main
Sections for '/Users/evilpan/temp/macho-test/main' (x86_64):
  SectID     Type             Load Address                             Perm File Off.  File Size  Flags      Section Name
  ---------- ---------------- ---------------------------------------  ---- ---------- ---------- ---------- ----------------------------
  0x00000100 container        [0x0000000000000000-0x0000000100000000)* ---  0x00000000 0x00000000 0x00000000 main.__PAGEZERO
  0x00000200 container        [0x0000000100000000-0x0000000100001000)  r-x  0x00000000 0x00001000 0x00000000 main.__TEXT
  0x00000001 code             [0x0000000100000ee0-0x0000000100000f6a)  r-x  0x00000ee0 0x0000008a 0x80000400 main.__TEXT.__text
  0x00000002 code             [0x0000000100000f6a-0x0000000100000f76)  r-x  0x00000f6a 0x0000000c 0x80000408 main.__TEXT.__stubs
  0x00000003 code             [0x0000000100000f78-0x0000000100000f9c)  r-x  0x00000f78 0x00000024 0x80000400 main.__TEXT.__stub_helper
  0x00000004 data-cstr        [0x0000000100000f9c-0x0000000100000fb0)  r-x  0x00000f9c 0x00000014 0x00000002 main.__TEXT.__cstring
  0x00000005 compact-unwind   [0x0000000100000fb0-0x0000000100000ff8)  r-x  0x00000fb0 0x00000048 0x00000000 main.__TEXT.__unwind_info
  0x00000300 container        [0x0000000100001000-0x0000000100002000)  rw-  0x00001000 0x00001000 0x00000000 main.__DATA
  0x00000006 data-ptrs        [0x0000000100001000-0x0000000100001008)  rw-  0x00001000 0x00000008 0x00000006 main.__DATA.__nl_symbol_ptr
  0x00000007 data-ptrs        [0x0000000100001008-0x0000000100001018)  rw-  0x00001008 0x00000010 0x00000006 main.__DATA.__got
  0x00000008 data-ptrs        [0x0000000100001018-0x0000000100001028)  rw-  0x00001018 0x00000010 0x00000007 main.__DATA.__la_symbol_ptr
  0x00000009 zero-fill        [0x0000000100001028-0x000000010000102c)  rw-  0x00000000 0x00000000 0x00000001 main.__DATA.__common
  0x00000400 container        [0x0000000100002000-0x0000000100007000)  r--  0x00002000 0x00004a90 0x00000000 main.__LINKEDIT

上面例子中__TEXT段的的vm_size和file_size都是0x1000，这个大小在文件中正好是第一个__DATAsection的起始地址:

data.png

__PAGEZERO是一个特殊的段，主要目的是将低地址占用，防止用户空间访问。个人理解这是对空指针引用类型漏洞的一种缓解措施，Linux内核中也有mmap_min_addr来限制用户可以mmap映射的最低地址。

__DATA段则包含__got、__nl_symbol_ptr、__la_symbol_ptr等section，一般包括可读写的内容。

另外一个重要的段为__LINKEDIT，其中包含需要被动态链接器使用的信息，包括符号表、字符串表、重定位项表、签名等。该段和PAGEZERO一样的是末尾没有额外的section信息，所以cmdsize都等于72(sizeof(struct segment_command_64))。其内容即begin + fileoff指向的地方保存linkedit command的内容，这个内容的格式根据具体cmd的不同而不同。LINKEDIT可以理解为元数据，值得一提的是，经过观察，fileoff +filesize 即为MachO文件末尾，也就是等于文件的大小。

那么LINKEDIT块中的内容是什么格式呢？其实大部分有其专门的格式，比如对Dynamic Loader Info来说是字节码，对于符号表来说是符号表结构体，对于函数地址项来说是uleb128编码的地址值，……因此LINKEDIT可谓包罗万象，需要具体问题具体分析，下面介绍的几个command就是其中几个例子。

Signature Command指定当前文件的签名信息，没有单独的结构体，而是使用下面这个结构来表示:

struct linkedit_data_command {
    uint32_t	cmd;		/* LC_CODE_SIGNATURE, LC_SEGMENT_SPLIT_INFO,
                                   LC_FUNCTION_STARTS, LC_DATA_IN_CODE,
				   LC_DYLIB_CODE_SIGN_DRS or
				   LC_LINKER_OPTIMIZATION_HINT. */
    uint32_t	cmdsize;	/* sizeof(struct linkedit_data_command) */
    uint32_t	dataoff;	/* file offset of data in __LINKEDIT segment */
    uint32_t	datasize;	/* file size of data in __LINKEDIT segment  */
};

cmd/cmdsize和前面LC_SEGMENT的含义类似，只不过cmdsize是个常数，等于当前结构体的大小。dataoff表示前面信息在LINKEDIT数据中的偏移，注意这里不是相对文件头的偏移；datasize则表示签名信息的大小。

苹果的签名数据格式并不是常规类型，对其详细介绍超过了本文的范围，对于具体的签名实现有兴趣的可以参考Jonathan大神的*OS Internal或者Code Signing – Hashed Out。使用jtool工具可以打印出详细的签名信息，如下所示:

$ jtool2 --sig -v main
An embedded signature of 1953 bytes, with 3 blobs:
	Blob 0: Type: 0 @36: Code Directory (213 bytes)
		Version:     20100
		Flags:       none
		CodeLimit:   0x22c0
		Identifier:  main (@0x30)
		CDHash:	     f3d8c9a75487ecc6f3adbddca11ad987a171e8974e6df15e857d2ac962e4b886 (computed)
		# of hashes: 3 code (4K pages) + 2 special
		Hashes @117 size: 32 Type: SHA-256
	Blob 1: Type: 2 @249: Requirement Set (80 bytes) with 1 requirement:
Unknown opcode 14 - has Apple changed the op codes?Please notify J!
		0: Designated Requirement (@20, 48 bytes): Ident(main) AND
	Blob 2: Type: 10000 @329: Blob Wrapper (1624 bytes) (0x10000 is CMS (RFC3852) signature)
		Timestamp: 00:12:38 2020/09/06

当然官方的codesign -d也可以。

这个Command的信息主要是提供给动态链接器dyld的，其结构如下:

struct dyld_info_command {
   uint32_t   cmd;		/* LC_DYLD_INFO or LC_DYLD_INFO_ONLY */
   uint32_t   cmdsize;		/* sizeof(struct dyld_info_command) */
   uint32_t   rebase_off;	/* file offset to rebase info  */
   uint32_t   rebase_size;	/* size of rebase info   */
   uint32_t   bind_off;	/* file offset to binding info   */
   uint32_t   bind_size;	/* size of binding info  */
	 uint32_t   weak_bind_off;	/* file offset to weak binding info   */
   uint32_t   weak_bind_size;  /* size of weak binding info  */
   uint32_t   lazy_bind_off;	/* file offset to lazy binding info */
   uint32_t   lazy_bind_size;  /* size of lazy binding infs */
   uint32_t   export_off;	/* file offset to lazy binding info */
   uint32_t   export_size;	/* size of lazy binding infs */
}

虽然看起来很复杂，但实际上它的目的就是为了给dyld提供能够加载目标MachO所需要的必要信息: 因为可能加载到随机地址，所以需要rebase信息；如果进程依赖其他镜像的符号，则绑定需要bind信息；对于C++程序而言可能需要weak bind实现代码/数据复用；对于一些外部符号不需要立即绑定的可以延时加载，这就需要lazy bind信息；对于导出符号也需要对应的export信息。

为了描述这些rebase/bind信息，dyld定义了一套伪指令，用来描述具体的操作(opcode)及其操作数据。以延时绑定为例，操作符看起来是这样:

opcode.png

其表达的实际含义用中文来描述就是:

  1. _printf符号(来自libSystem.B.dylib)延时绑定到0x1018偏移地址；
  2. _set_foo符号(来自libfoo.dylib)延时绑定到0x1020偏移地址；

其中0x1018/0x1020地址在__DATA段，更准确来说是在__la_symbol_ptr这个section中，可以自行编译验证。

LC_LOAD_{,WEAK_}DYLIB用来告诉内核(实际上是dyld)当前可执行文件需要使用哪些动态库，而其结构如下:

struct dylib {
    union lc_str  name;			/* library's path name */
    uint32_t timestamp;			/* library's build time stamp */
    uint32_t current_version;		/* library's current version number */
    uint32_t compatibility_version;	/* library's compatibility vers number*/
};

struct dylib_command {
	uint32_t	cmd;		/* LC_ID_DYLIB, LC_LOAD_{,WEAK_}DYLIB, LC_REEXPORT_DYLIB */
	uint32_t	cmdsize;	/* includes pathname string */
	struct dylib	dylib;		/* the library identification */
};

动态库(filetype为MH_DYLIB)中会包含 LC_ID_DYLIB command 来说明自己是个什么库，包括名称、版本、时间戳等信息。需要注意的是lc_str并不是字符串本身，而是字符串的偏移值，字符串信息在command的内容之后，该偏移指的是距离command起始位置的偏移。

LC_REEXPORT_DYLIB表示加载并重新导出dylib

除了上面的介绍，还有许多其他类型的 command ，比如LC_FUNCTION_STARTS表示函数入口地址，LC_MAIN表示主函数地址，LC_ENCRYPTION_INFO表示加密的segment段等等，可以在遇到的时候用查看loader.h的定义，这里就不再赘述了。

加载过程

MachO的加载和ELF的加载过程没有太大区别，还是系统调用->内核处理->返回执行的一般流程，对于静态链接程序返回执行是直接返回到程序入口地址，而动态链接程序则需要在程序开始执行之前进行重定向，因此这里也按照这个顺序介绍。

内核空间的主要任务是创建新 task 并初始化内存页和对应的权限，我们主要关注MachO文件的处理部分，即parse_machfile函数，文件为bsd/kern/mach_loader.c，其主要功能为检查header以及cmdsize等长度符合预期，然后通过4次循环来处理不同的信息，如下:

	/*
	 *  Scan through the commands, processing each one as necessary.
	 *  We parse in three passes through the headers:
	 *  0: determine if TEXT and DATA boundary can be page-aligned
	 *  1: thread state, uuid, code signature
	 *  2: segments
	 *  3: dyld, encryption, check entry point
	 */

这里重点关注pass2，关键代码如下:

		offset = mach_header_sz;
		ncmds = header->ncmds;

		while (ncmds--) {

			/* ensure enough space for a minimal load command */
			if (offset + sizeof(struct load_command) > cmds_size) {
				ret = LOAD_BADMACHO;
				break;
			}

			/*
			 *	Get a pointer to the command.
			 */
			lcp = (struct load_command *)(addr + offset);
			oldoffset = offset;

      // offset = offset + lcp->cmdsize 
			if (os_add_overflow(offset, lcp->cmdsize, &offset) ||
					lcp->cmdsize < sizeof(struct load_command) ||
					offset > cmds_size) {
				ret = LOAD_BADMACHO;
				break;
			}
      
			switch(lcp->cmd) {
			case LC_SEGMENT: {/* 32位... */}
			case LC_SEGMENT_64: {
				struct segment_command_64 *scp64 = (struct segment_command_64 *)lcp;
				// pass 0/1 的处理
        // ...
				if (pass != 2)
					break;
				ret = load_segment(lcp /*, ... */);
        // ...
				break;
      }
			case LC_MAIN:
				// ...
				ret = load_main((struct entry_point_command *)lcp /*, ... */);
				break;
			case LC_CODE_SIGNATURE:
        // ...
				ret = load_code_signature((struct linkedit_data_command *)lcp /*, ... */);
        got_code_signatures = ret == LOAD_SUCCESS ? TRUE : FALSE;
				if (got_code_signatures) {
					while (off < alloc_size && ret == LOAD_SUCCESS) {
					     valid = cs_validate_range(vp,
								       NULL,
								       file_offset + off,
								       addr + off,
								       PAGE_SIZE,
								       &tainted);
            // ...
          }
        }
        break;
#if CONFIG_CODE_DECRYPTION
			case LC_ENCRYPTION_INFO:
			case LC_ENCRYPTION_INFO_64:
        if (pass != 3) break;
      	// 处理加密的segment，用于iOS中的Apple Store应用的加密，在macOS的内核中未启用
        // 内核中只是设置好decrypter，并没有真正解密
				ret = set_code_unprotect( (struct encryption_info_command *) lcp /*, ...*/)；
#endif
      // ...
			default:
				/* Other commands are ignored by the kernel */
				ret = LOAD_SUCCESS;
				break;
      }

其中很多command比如LC_LOAD_DYLIB、LC_DYLD_INFO_ONLY等不在内核态中进行处理，直接进入default分支忽略。

这个函数主要负责加载segment到内存中，实现有几个值得一提的点:

  • total_section_size = lcp->cmdsize - sizeof(struct segment_command_64)；这是文件后面section的大小
  • LC_SEGMENT_32会转换为LC_SEGMENT_64，使用widen_segment_command
  • 映射的内存地址是slide + scp->vmaddr，slide为随机化的地址偏移(如果有的话)，映射的内存大小是scp->vmsize
  • 文件中对应内容起始位置是scp->fileoff，大小为scp->filesize
  • file_offset = pager_offset + scp->fileoff，是该segment在内核空间中的地址，需要页对齐
  • 对于0地址页的映射，由于用户空间不能访问，因此直接增加了vm能访问的最低地址值(vm_map_raise_min_offset)，仅允许对PAGEZERO段执行0地址的映射命令

对于映射的地址和大小，都需要是4k页对齐的，并且最终使用map_segment进行映射:

file_start = vm_map_trunc_page(file_offset, effective_page_mask);
file_end = vm_map_round_page(file_offset + file_size, effective_page_mask);
vm_start = vm_map_trunc_page(vm_offset, effective_page_mask);
vm_end = vm_map_round_page(vm_offset + vm_size, effective_page_mask);
ret = map_segment(map, vm_start, vm_end, control, file_start, file_end,
                  initprot, maxprot, result);

根据对代码的分析，内核中并不关心具体section的内容，即不解析单个section头的具体字段，而是以segment为单位进行映射。一般而言映射的是具体内容的值，比如__DATA段就映射了数据段。前面也说过__TEXT段比较特别，它是从文件开头开始映射的，一直到代码段的末尾(数据段的开头)。

MachO和ELF的一个最大不同点，或者说XNU和Linux的不同点是前者原生支持了对可执行文件的签名认证，文件的签名信息保存在LINKEDIT数据段，在前面我们已经介绍过了LC_CODE_SIGNATURE的内容。

load_main函数主要用来处理LC_MAIN命令，这里面包括了可执行文件的入口地址以及栈大小信息。但是在内核中并不需要关心main函数信息，而只需要关心入口信息(entry_point)。因此在load_main中只对栈和线程进行初始化，并且修改对应的result信息:

	result->user_stack = addr;
	result->user_stack -= slide;

	result->needs_dynlinker = TRUE;
	result->using_lcmain = TRUE;

	ret = thread_state_initialize( thread );

此时result->entry_point还是0(MACH_VM_MIN_ADDRESS)。

另外一个能决定入口地址的command是LC_UNIXTHREAD，类似于UNIX中直接将start符号导出，该符号应该是在crt1.o里的，但苹果并不默认提供。也就是说如果想要静态编译，需要自己下载源文件自己去编译，或者自己链接并导出这个符号。苹果不支持静态编译的原因是出于兼容性的考虑。

在load_main结束后，需要加载动态链接器:

		/* Make sure if we need dyld, we got it */
		if (result->needs_dynlinker && !dlp) {
			ret = LOAD_FAILURE;
		}

		if ((ret == LOAD_SUCCESS) && (dlp != 0)) {
			/*
			 * load the dylinker, and slide it by the independent DYLD ASLR
			 * offset regardless of the PIE-ness of the main binary.
			 */
			ret = load_dylinker(dlp, dlarchbits, map, thread, depth,
					    dyld_aslr_offset, result, imgp);
		}

动态链接器就是dyld，在LC_LOAD_DYLINKER命令中指定，通常是/usr/lib/dyld。load_dylinker内部也同样调用了parse_machfile函数，因此大部分操作是类似的。注意到这里其实涉及到了递归调用，因此需要在该函数中加depth参数表示递归层数。

dyld文件中有LC_UNIXTHREAD命令，因此其result->entry_point将被设置，在原先的parse_mach返回到load_machfile后，则初始化新的内核task并将执行流交还给用户空间，对于大部分程序而言，就是跳转到dyld的起始地址执行。

从内核回到用户空间，便跳转到目标的入口地址开始执行。对于静态链接链接程序，实际上执行的是dyld中的指令，该程序的源码可以参考opensource-apple/dyld。

dyld的起始地址固定为0x1000，这个地址对应的符号是__dyld_start，文件定义在src/dyldStartup.s。这部分代码和crt0.o中的代码是一样的，主要是用来初始化C Runtime，唯一的不同点是有个额外的参数用来指定MachO文件头的地址。

初始化完成后调用call __ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm，demangle之后为下面的函数:

//
//  This is code to bootstrap dyld.  This work in normally done for a program by dyld and crt.
//  In dyld we have to do this manually.
//
uintptr_t start(const struct macho_header* appsMachHeader, int argc, const char* argv[], 
				intptr_t slide, const struct macho_header* dyldsMachHeader,
				uintptr_t* startGlue) {
  	// if kernel had to slide dyld, we need to fix up load sensitive locations
	// we have to do this before using any global variables
	if ( slide != 0 ) {
		rebaseDyld(dyldsMachHeader, slide);
	}

	// allow dyld to use mach messaging
	mach_init();

	// kernel sets up env pointer to be just past end of agv array
	const char** envp = &argv[argc+1];
	
	// kernel sets up apple pointer to be just past end of envp array
	const char** apple = envp;
	while(*apple != NULL) { ++apple; }
	++apple;

	// set up random value for stack canary
	__guard_setup(apple);

#if DYLD_INITIALIZER_SUPPORT
	// run all C++ initializers inside dyld
	runDyldInitializers(dyldsMachHeader, slide, argc, argv, envp, apple);
#endif

	// now that we are done bootstrapping dyld, call dyld's main
	uintptr_t appsSlide = slideOfMainExecutable(appsMachHeader);
	return dyld::_main(appsMachHeader, appsSlide, argc, argv, envp, apple, startGlue);
}

所以dyld真正的入口地址是dyld::_main，该函数的功能主要有:

  1. 初始化上下文(setContext)
  2. 将可执行文件的路径转为绝对路径
  3. 处理环境变量
  4. 判断是否需要加载共享缓存库，如果需要加载则直接映射到内存中(mapSharedCache)
  5. 加载注入的动态库(sEnv.DYLD_INSERT_LIBRARIES)
  6. 链接主程序(dyld::link)，实际上用的是虚函数ImageLoader::link
  7. initializeMainExecutable: 运行初始化函数(__mod_init_funcs)
  8. 执行最终的目标程序(LC_MAIN/LC_UNIXTHREAD)

最终目标程序正常执行，就像自己直接启动一样。下面挑几个比较关键的点进行深入分析。

链接是dyld的主要功能，执行实际动态链接功能的是link函数，除了链接待执行的目标程序，还链接所有插入的其他动态库:

		// link main executable
		gLinkContext.linkingMainExecutable = true;
		link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL));
		// link any inserted libraries
		// do this after linking main executable so that any dylibs pulled in by inserted 
		// dylibs (e.g. libSystem) will not be in front of dylibs the program uses
		if ( sInsertedDylibCount > 0 ) {
			for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
				ImageLoader* image = sAllImages[i+1];
				link(image, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL));
				image->setNeverUnloadRecursive();
			}
			// only INSERTED libraries can interpose
			// register interposing info after all inserted libraries are bound so chaining works
			for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
				ImageLoader* image = sAllImages[i+1];
				image->registerInterposing();
			}
		}

而dyld:link使用的是具体ImageLoader的link多态实现:

void link(ImageLoader* image, bool forceLazysBound, bool neverUnload, const ImageLoader::RPathChain& loaderRPaths)
{
	// add to list of known images.  This did not happen at creation time for bundles
	if ( image->isBundle() && !image->isLinked() )
		addImage(image);

	// we detect root images as those not linked in yet 
	if ( !image->isLinked() )
		addRootImage(image);
	
	// process images
	try {
		image->link(gLinkContext, forceLazysBound, false, neverUnload, loaderRPaths);
	}
	catch (const char* msg) {
		garbageCollectImages();
		throw;
	}
}

sMainExecutable的实现在开源代码中并没有给出，不过参考基类的默认实现如下:

void ImageLoader::link(const LinkContext& context, bool forceLazysBound, bool preflightOnly, bool neverUnload, const RPathChain& loaderRPaths)
{
	//dyld::log("ImageLoader::link(%s) refCount=%d, neverUnload=%d\n", this->getPath(), fDlopenReferenceCount, fNeverUnload);
	
	// clear error strings
	(*context.setErrorStrings)(dyld_error_kind_none, NULL, NULL, NULL);

	uint64_t t0 = mach_absolute_time();
	this->recursiveLoadLibraries(context, preflightOnly, loaderRPaths);
	context.notifyBatch(dyld_image_state_dependents_mapped);
	
	// we only do the loading step for preflights
	if ( preflightOnly )
		return;
		
	uint64_t t1 = mach_absolute_time();
	context.clearAllDepths();
	this->recursiveUpdateDepth(context.imageCount());

	uint64_t t2 = mach_absolute_time();
 	this->recursiveRebase(context);
	context.notifyBatch(dyld_image_state_rebased);
	
	uint64_t t3 = mach_absolute_time();
 	this->recursiveBind(context, forceLazysBound, neverUnload);

	uint64_t t4 = mach_absolute_time();
	if ( !context.linkingMainExecutable )
		this->weakBind(context);
	uint64_t t5 = mach_absolute_time();	

	context.notifyBatch(dyld_image_state_bound);
	uint64_t t6 = mach_absolute_time();	

	std::vector<DOFInfo> dofs;
	this->recursiveGetDOFSections(context, dofs);
	context.registerDOFs(dofs);
	uint64_t t7 = mach_absolute_time();	

	// interpose any dynamically loaded images
	if ( !context.linkingMainExecutable && (fgInterposingTuples.size() != 0) ) {
		this->recursiveApplyInterposing(context);
	}
	
	// clear error strings
  // ...
}

主要做的就是这几步:

  1. recursiveLoadLibraries
  2. recursiveUpdateDepth
  3. recursiveRebase
  4. recursiveBind
  5. weakBind
  6. recursiveGetDOFSections

根据名字不难看出其作用，其中大部分函数名称带recursive，这是因为动态库本身也可能会依赖其他的动态库，因此需要递归进行处理(当然循环依赖会有对应的处理)。其中recursiveUpdateDepth不太直观，其实作用只是为了对镜像进行排序，被依赖的库会出现在依赖者之前。

在上面第4步中说到要加载共享缓存库，这是个什么东西呢？这一步的目的其实是为了加速动态库的加载过程。对于我们自己编译的macOS命令行程序可能还好，但是对于图形界面应用来说，每个应用启动时需要加载的动态库可能有上百个，而其中很大一部分是系统库，比如UIKit、Foundation等。因此苹果就事先把这些常用的库打包成缓存，程序启动时候直接映射到内存中，而无需逐个执行繁琐的处理和解析。

映射共享缓存库的函数为mapSharedCache，首先检查共享缓存库是否已经映射过:

static int __attribute__((noinline)) _shared_region_check_np(uint64_t* start_address)
{
	if ( gLinkContext.sharedRegionMode == ImageLoader::kUseSharedRegion ) 
		return syscall(294, start_address);
	return -1;
}

294号系统调用定义在内核中(bsd/kern/syscalls.master):

294	AUE_NULL	ALL	{ int shared_region_check_np(uint64_t *start_address) NO_SYSCALL_STUB; }
295	AUE_NULL	ALL	{ int shared_region_map_np(int fd, uint32_t count, const struct shared_file_mapping_np *mappings) NO_SYSCALL_STUB; }

内核中的实现也比较简单，忽略错误检查，关键的代码如下:

int shared_region_check_np(
	__unused struct proc			*p,
	struct shared_region_check_np_args	*uap,
	__unused int				*retvalp) {
  // ...
  shared_region = vm_shared_region_get(current_task());
	if (shared_region != NULL) {
    		/* retrieve address of its first mapping... */
		kr = vm_shared_region_start_address(shared_region,
						    &start_address);
    		/* ... and give it to the caller */
		error = copyout(&start_address,
					(user_addr_t) uap->start_address,
					sizeof (start_address));
    // ...
		vm_shared_region_deallocate(shared_region);
  }
}

其内部实现姑且不管，继续回到用户空间，所返回的地址可以强制转换为dyld_cache_header格式:

struct dyld_cache_header
{
	char		magic[16];				// e.g. "dyld_v0    i386"
	uint32_t	mappingOffset;			// file offset to first dyld_cache_mapping_info
	uint32_t	mappingCount;			// number of dyld_cache_mapping_info entries
	uint32_t	imagesOffset;			// file offset to first dyld_cache_image_info
	uint32_t	imagesCount;			// number of dyld_cache_image_info entries
	uint64_t	dyldBaseAddress;		// base address of dyld when cache was built
	uint64_t	codeSignatureOffset;	// file offset of code signature blob
	uint64_t	codeSignatureSize;		// size of code signature blob (zero means to end of file)
	uint64_t	slideInfoOffset;		// file offset of kernel slid info
	uint64_t	slideInfoSize;			// size of kernel slid info
	uint64_t	localSymbolsOffset;		// file offset of where local symbols are stored
	uint64_t	localSymbolsSize;		// size of local symbols information
	uint8_t		uuid[16];				// unique value for each shared cache file
	uint64_t	cacheType;				// 1 for development, 0 for optimized
};

检查共享缓存空间存在则直接复制其UUID到进程的sharedCacheUUID中，然后直接使用该缓存。

如果不存在，就需要进行创建，创建的过程如下:

  1. 如果是x86环境，需要判断当前是否为安全启动模式，则会删除之前余留的cache文件，路径为/var/db/dyld/dyld_shared_cache_$arch
  2. 打开sharedCache文件，对于IPhone路径为/System/Library/Caches/com.apple.dyld/dyld_shared_cache_$arch
  3. 读取文件的前8192字节转换为struct dyld_cache_header，并做一些合法性检查
  4. 处理cache文件，主要是将mapping信息提取出来，保存为一个数组mappings[]
  5. 调用_shared_region_map_and_slide_np映射每个mapping

mapping信息如下:

struct dyld_cache_mapping_info {
	uint64_t	address;
	uint64_t	size;
	uint64_t	fileOffset;
	uint32_t	maxProt;
	uint32_t	initProt;
};

和之前提到的segment信息类似，没有feilsize，因为不存在padding。

_shared_region_map_and_slide_np函数分别处理每个mapping，并最终使用mmap来完成cache到内存的映射操作。

每个mapping info对应一个struct shared_file_mapping_np，但是这个结构体的定义在开源代码中没找到，并且在苹果文档中也进行了隐藏，见: https://developer.apple.com/documentation/kernel/shared_file_mapping_np

后记

本文通过对MachO文件的文件格式研究，介绍了MacOS和iOS中可执行文件的加载过程，从内核中的处理一直到动态连接器dyld的代码分析。可以看出MachO与ELF相比实现方式各有千秋，但是在内核中原生增加了对代码的签名和加密，其实ELF也很容易实现类似的功能，但开放系统需要更多考虑兼容性的问题，不像苹果可以大刀阔斧的随便改。

对于MachO的深入理解其实也有助于日常的相关研究，比如Apple Store的加密实现以及代码签名的大致原理，还有针对dyld_cache的处理等，其中每一项都值得去深入挖掘。而且本文也没有介绍到全部的MachO特性，比如Objective-C相关的段，具体的实战部分后面有时间会再去整理一下。

参考资料

]]> 深入浅出ELF https://evilpan.com/2020/08/09/elf-inside-out/ Sun, 09 Aug 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/08/09/elf-inside-out/

本文介绍了ELF的基本结构和内存加载的原理，并用具体案例来分析如何通过ELF特性实现HIDS bypass、加固/脱壳以及辅助进行binary fuzzing。

前言

作为一个安全研究人员，ELF可以说是一个必须了解的格式，因为这关系到程序的编译、链接、封装、加载、动态执行等方方面面。有人就说了，这不就是一种文件格式而已嘛，最多按照SPEC实现一遍也就会了，难道还能复杂过FLV/MP4？曾经我也是这么认为的，直到我在日常工作时遇到了下面的错误:

$ r2 a.out
Segmentation fault

作为一个开源爱好者，我的radare2经常是用master分支编译的，经过在github中搜索，发现radare对于ELF的处理还有不少同类的问题，比如issue#17300以及issue#17379，这还只是近一个月内的两个open issue，历史问题更是数不胜数。

总不能说radare的开发者不了解ELF吧？事实上他们都是软件开发和逆向工程界的专家。不止radare，其实IDA和其他反编译工具也曾出现过各类ELF相关的bug。

说了那么多，只是为了引出一个观点: ELF既简单也复杂，值得我们去深入了解。网上已经有了很多介绍ELF的文章，因此本文不会花太多篇幅在SPEC的复制粘贴上，而是结合实际案例和应用场景去进行说明。

ELF 101

ELF的全称是Executable and Linking Format，这个名字相当关键，包含了ELF所需要支持的两个功能——执行和链接。不管是ELF，还是Windows的PE，抑或是MacOS的Mach-O，其根本目的都是为了能让处理器正确执行我们所编写的代码。

在上古时期，给CPU运行代码也不用那么复杂，什么代码段数据段，直接把编译好的机器码一把梭烧到中断内存空间，PC直接跳过来就执行了。但随着时代变化，大家总不能一直写汇编了，即便编译器很给力，也会涉及到多人协作、资源复用等问题。这时候就需要一种可拓展(Portable)的文件标准，一方面让开发者(编译器/链接器)能够高效协作，另一方面也需要系统能够正确、安全地将文件加载到对应内存中去执行，这就是ELF的使命。

view.png
view

从大局上看，ELF文件主要分为3个部分:

  • ELF Header
  • Section Header Table
  • Program Header Table

其中，ELF Header是文件头，包含了固定长度的文件信息；Section Header Table则包含了链接时所需要用到的信息；Program Header Table中包含了运行时加载程序所需要的信息，后面会进行分别介绍。

ELF头部的定义在elf/elf.h中(以glibc-2.27为例)，使用POD结构体表示，内存可使用结构体的字段一一映射，头部表示如下:

#define EI_NIDENT (16)

typedef struct
{
  unsigned char	e_ident[EI_NIDENT];	/* Magic number and other info */
  Elf32_Half	e_type;			/* Object file type */
  Elf32_Half	e_machine;		/* Architecture */
  Elf32_Word	e_version;		/* Object file version */
  Elf32_Addr	e_entry;		/* Entry point virtual address */
  Elf32_Off	e_phoff;		/* Program header table file offset */
  Elf32_Off	e_shoff;		/* Section header table file offset */
  Elf32_Word	e_flags;		/* Processor-specific flags */
  Elf32_Half	e_ehsize;		/* ELF header size in bytes */
  Elf32_Half	e_phentsize;		/* Program header table entry size */
  Elf32_Half	e_phnum;		/* Program header table entry count */
  Elf32_Half	e_shentsize;		/* Section header table entry size */
  Elf32_Half	e_shnum;		/* Section header table entry count */
  Elf32_Half	e_shstrndx;		/* Section header string table index */
} Elf32_Ehdr;

注释都很清楚了，挑一些比较重要的来说。其中e_type表示ELF文件的类型，有以下几种:

  • ET_NONE: 未知类型
  • ET_REL: 可重定向类型(relocatable)，通常是我们编译的*.o文件
  • ET_EXEC: 可执行类型(executable)，静态编译的可执行文件
  • ET_DYN: 共享对象(shared object)，动态编译的可执行文件或者动态库*.so
  • ET_CORE: coredump文件

e_entry是程序的入口虚拟地址，注意不是main函数的地址，而是.text段的首地址_start。当然这也要求程序本身非PIE(-no-pie)编译的且ASLR关闭的情况下，对于非ET_EXEC类型通常并不是实际的虚拟地址值。

其他的字段大多数是指定Section Header(e_sh)和Program Header(e_ph)的信息。Section/Program Header Table本身可以看做是数组结构，ELF头中的信息指定对应Table数组的位置、长度、元素大小信息。最后一个e_shstrndx表示的是section table中的第e_shstrndx项元素，保存了所有section table名称的字符串信息。

上节说了section header table是一个数组结构，这个数组的位置在e_shoff处，共有e_shnum个元素(即section)，每个元素的大小为e_shentsize字节。每个元素的结构如下:

typedef struct
{
  Elf32_Word	sh_name;		/* Section name (string tbl index) */
  Elf32_Word	sh_type;		/* Section type */
  Elf32_Word	sh_flags;		/* Section flags */
  Elf32_Addr	sh_addr;		/* Section virtual addr at execution */
  Elf32_Off	sh_offset;		/* Section file offset */
  Elf32_Word	sh_size;		/* Section size in bytes */
  Elf32_Word	sh_link;		/* Link to another section */
  Elf32_Word	sh_info;		/* Additional section information */
  Elf32_Word	sh_addralign;		/* Section alignment */
  Elf32_Word	sh_entsize;		/* Entry size if section holds table */
} Elf32_Shdr;

其中sh_name是该section的名称，用一个word表示其在字符表中的偏移，字符串表(.shstrtab)就是上面说到的第e_shstrndx个元素。ELF文件中经常使用这种偏移表示方式，可以方便组织不同区段之间的引用。

sh_type表示本section的类型，SPEC中定义了几十个类型，列举其中一些如下:

  • SHT_NULL: 表示该section无效，通常第0个section为该类型
  • SHT_PROGBITS: 表示该section包含由程序决定的内容，如.text、.data、.plt、.got
  • SHT_SYMTAB/SHT_DYNSYM: 表示该section中包含符号表，如.symtab、.dynsym
  • SHT_DYNAMIC: 表示该section中包含动态链接阶段所需要的信息
  • SHT_STRTAB: 表示该section中包含字符串信息，如.strtab、.shstrtab
  • SHT_REL/SHT_RELA: 包含重定向项信息
  • …

虽然每个section header的大小一样(e_shentsize字节)，但不同类型的section有不同的内容，内容部分由这几个字段表示:

  • sh_offset: 内容起始地址相对于文件开头的偏移
  • sh_size: 内容的大小
  • sh_entsize: 有的内容是也是一个数组，这个字段就表示数组的元素大小

与运行时信息相关的字段为:

  • sh_addr: 如果该section需要在运行时加载到虚拟内存中，该字段就是对应section内容(第一个字节)的虚拟地址
  • sh_addralign: 内容地址的对齐，如果有的话需要满足sh_addr % sh_addralign = 0
  • sh_flags: 表示所映射内容的权限，可根据SHF_WRITE/ALLOC/EXECINSTR进行组合

另外两个字段sh_link和sh_info的含义根据section类型的不同而不同，如下表所示:

type.png
type

至于不同类型的section，有的是保存符号表，有的是保存字符串，这也是ELF表现出拓展性和复杂性的地方，因此需要在遇到具体问题的时候查看文档去进行具体分析。

program header table用来保存程序加载到内存中所需要的信息，使用段(segment)来表示。与section header table类似，同样是数组结构。数组的位置在偏移e_phoff处，每个元素(segment header)的大小为e_phentsize，共有e_phnum个元素。单个segment header的结构如下:

typedef struct
{
  Elf32_Word	p_type;			/* Segment type */
  Elf32_Off	p_offset;		  /* Segment file offset */
  Elf32_Addr	p_vaddr;		/* Segment virtual address */
  Elf32_Addr	p_paddr;		/* Segment physical address */
  Elf32_Word	p_filesz;		/* Segment size in file */
  Elf32_Word	p_memsz;		/* Segment size in memory */
  Elf32_Word	p_flags;		/* Segment flags */
  Elf32_Word	p_align;		/* Segment alignment */
} Elf32_Phdr;

既然program header的作用是提供用于初始化程序进程的段信息，那么下面这些字段就是很直观的:

  • p_offset: 该segment的数据在文件中的偏移地址(相对文件头)
  • p_vaddr: segment数据应该加载到进程的虚拟地址
  • p_paddr: segment数据应该加载到进程的物理地址(如果对应系统使用的是物理地址)
  • p_filesz: 该segment数据在文件中的大小
  • p_memsz: 该segment数据在进程内存中的大小。注意需要满足p_memsz>=p_filesz，多出的部分初始化为0，通常作为.bss段内容
  • p_flags: 进程中该segment的权限(R/W/X)
  • p_align: 该segment数据的对齐，2的整数次幂。即要求p_offset % p_align = p_vaddr。

剩下的p_type字段，表示该program segment的类型，主要有以下几种:

  • PT_NULL: 表示该段未使用
  • PT_LOAD: Loadable Segment，将文件中的segment内容映射到进程内存中对应的地址上。值得一提的是SPEC中说在program header中的多个PT_LOAD地址是按照虚拟地址递增排序的。
  • PT_DYNAMIC: 动态链接中用到的段，通常是RW映射，因为需要由interpreter(ld.so)修复对应的的入口
  • PT_INTERP: 包含interpreter的路径，见下文
  • PT_HDR: 表示program header table本身。如果有这个segment的话，必须要在所有可加载的segment之前，并且在文件中不能出现超过一次。
  • …

在不同的操作系统中还可能有一些拓展的类型，比如PT_GNU_STACK、PT_GNU_RELRO等，不一而足。

至此，ELF文件中相关的字段已经介绍完毕，主要组成也就是Section Header Table和Program Header Table两部分，整体框架相当简洁。而ELF中体现拓展性的地方则是在Section和Segment的类型上(s_type和p_type)，这两个字段的类型都是ElfN_Word，在32位系统下大小为4字节，也就是说最多可以支持高达2^32 - 1种不同的类型！除了上面介绍的常见类型，不同操作系统或者厂商还能定义自己的类型去实现更多复杂的功能。

程序加载

在新版的ELF标准文档中，将ELF的介绍分成了三部分，第一部分介绍ELF文件本身的结构，第二部分是处理器相关的内容，第三部分是操作系统相关的内容。ELF的加载实际上是与操作系统相关的，不过大部分情况下我们都是在GNU/Linux环境中运行，因此就以此为例介绍程序的加载流程。

Linux中分为用户态和内核态，执行ELF文件在用户态的表现就是执行execve系统调用，随后陷入内核进行处理。

内核空间对execve的处理其实可以单独用一篇文章去介绍，其中涉及到进程的创建、文件资源的处理以及进程权限的设置等等。我们这里主要关注其中ELF处理相关的部分即可，实际上内核可以识别多种类型的可执行文件，ELF的处理代码主要在fs/binfmt_elf.c中的load_elf_binary函数中。

对于ELF而言，Linux内核所关心的只有Program Header部分，甚至大部分情况下只关心三种类型的Header，即PT_LOAD、PT_INTERP和PT_GNU_STACK。以3.18内核为例，load_elf_binary主要有下面操作:

  1. 对ELF文件做一些基本检查，保证e_phentsize = sizeof(struct elf_phdr)并且e_phnum的个数在一定范围内；
  2. 循环查看每一项program header，如果有PT_INTERP则使用open_exec加载进来，并替换原程序的bprm->buf;
  3. 根据PT_GNU_STACK段中的flag设置栈是否可执行；
  4. 使用flush_old_exec来更新当前可执行文件的所有引用；
  5. 使用setup_new_exec设置新的可执行文件在内核中的状态；
  6. setup_arg_pages在栈上设置程序调用参数的内存页；
  7. 循环每一项PT_LOAD类型的段，elf_map映射到对应内存页中，初始化BSS；
  8. 如果存在interpreter，将入口(elf_entry)设置为interpreter的函数入口，否则设置为原ELF的入口地址；
  9. install_exec_creds(bprm)设置进程权限等信息；
  10. create_elf_tables添加需要的信息到程序的栈中，比如ELF auxiliary vector；
  11. 设置current->mm对应的字段；

从内核的处理流程上来看，如果是静态链接的程序，实际上内核返回用户空间执行的就是该程序的入口地址代码；如果是动态链接的程序，内核返回用户空间执行的则是interpreter的代码，并由其加载实际的ELF程序去执行。

为什么要这么做呢？如果把动态链接相关的代码也放到内核中，就会导致内核执行功能过多，内核的理念一直是能不在内核中执行的就不在内核中处理，以避免出现问题时难以更新而且影响系统整体的稳定性。事实上内核中对ELF文件结构的支持是相当有限的，只能读取并理解部分的字段。

内核返回用户空间后，对于静态链接的程序是直接执行，没什么好说的。而对于动态链接的程序，实际是执行interpreter的代码。ELF的interpreter作为一个段，自然是编译链接的时候加进去的，因此和编译使用的工具链有关。对于Linux系统而言，使用的一般是GCC工具链，而interpreter的实现，代码就在glibc的elf/rtld.c中。

interpreter又称为dynamic linker，以glibc2.27为例，它的大致功能如下:

  • 将实际要执行的ELF程序中的内存段加载到当前进程空间中；
  • 将动态库的内存段加载到当前进程空间中；
  • 对ELF程序和动态库进行重定向操作(relocation)；
  • 调用动态库的初始化函数(如*.preinit_array, .init, .init_array*)；
  • 将控制流传递给目标ELF程序，让其看起来自己是直接启动的；

其中参与动态加载和重定向所需要的重要部分就是Program Header Table中PT_DYNAMIC类型的Segment。前面我们提到在Section Header中也有一部分参与动态链接的section，即.dynamic。我在自己解析动态链接文件的时候发现，实际上 .dynamic section中的数据，和PT_DYNAMIC中的数据指向的是文件中的同一个地方，即这两个entry的s_offset和p_offset是相同。每个元素的类型如下:

typedef struct
{
  Elf32_Sword	d_tag;			/* Dynamic entry type */
  union
    {
      Elf32_Word d_val;			/* Integer value */
      Elf32_Addr d_ptr;			/* Address value */
    } d_un;
} Elf32_Dyn;

d_tag表示实际类型，并且d_un和d_tag相关，可以说是很有拓展性了:) 同样的，标准中定义了几十个d_tag类型，比较常用的几个如下:

  • DT_NULL: 表示_DYNAMIC的结尾
  • DT_NEEDED: d_val保存了一个到字符串表头的偏移，指定的字符串表示该ELF所依赖的动态库名称
  • DT_STRTAB: d_ptr指定了地址保存了符号、动态库名称以及其他用到的字符串
  • DT_STRSZ: 字符串表的大小
  • DT_SYMTAB: 指定地址保存了符号表
  • DT_INIT/DT_FINI: 指定初始化函数和结束函数的地址
  • DT_RPATH: 指定动态库搜索目录
  • DT_SONAME: Shared Object Name，指定当前动态库的名字(logical name)
  • …

其中有部分的类型可以和Section中的SHT_xxx类型进行类比，完整的列表可以参考ELF标准中的Book III: Operating System Specific一节。

在interpreter根据DT_NEEDED加载完所有需要的动态库后，就实现了完整进程虚拟内存映像的布局。在寻找某个动态符号时，interpreter会使用广度优先的方式去进行搜索，即先在当前ELF符号表中找，然后再从当前ELF的DT_NEEDED动态库中找，再然后从动态库中的DT_NEEDED里查找。

因为动态库本身是位置无关的(PIE)，支持被加载到内存中的随机位置，因此为了程序中用到的符号可以被正确引用，需要对其进行重定向操作，指向对应符号的真实地址。这部分我在之前写的关于GOT,PLT和动态链接的文章中已经详细介绍过了，因此不再赘述，感兴趣的朋友可以参考该文章。

实际案例

有人也许会问，我看你bibi了这么多，有什么实际意义吗？呵呵，本节就来分享几个我认为比较有用的应用场景。

在渗透测试中，红队小伙伴们经常能拿到目标的后台shell权限，但是遇到一些部署了HIDS的大企业，很可能在执行恶意程序的时候被拦截，或者甚至触发监测异常直接被蓝队拔网线。这里不考虑具体的HIDS产品，假设现在面对两种场景:

  1. 目标环境的可写磁盘直接mount为noexec，无法执行代码
  2. 目标环境内核监控任何非系统路径的程序的执行都会直接告警

不管什么样的环境，我相信老红队都有办法去绕过，这里我们运用上面学到的ELF知识，其实有一种更为简单的解法，即利用interpreter。示例如下:

$ cat hello.c
#include <stdio.h>
int main() {
	return puts("hello!");
}
$ gcc hello.c -o hello
$ ./hello
hello!

$ chmod -x hello
$ ./hello
bash: ./hello: Permission denied
$ /lib64/ld-linux-x86-64.so.2 ./hello
hello!
$ strace /lib64/ld-linux-x86-64.so.2 ./hello 2>&1 | grep exec
execve("/lib64/ld-linux-x86-64.so.2", ["/lib64/ld-linux-x86-64.so.2", "./hello"], 0x7fff1206f208 /* 9 vars */) = 0

/lib64/ld-linux-x86-64.so.2本身应该是内核调用执行的，但我们这里可以直接进行调用。这样一方面可以在没有执行权限的情况下执行任意代码，另一方面也可以在一定程度上避免内核对execve的异常监控。

利用(滥用)interpreter我们还可以做其他有趣的事情，比如通过修改指定ELF文件的interpreter为我们自己的可执行文件，可让内核在处理目标ELF时将控制器交给我们的interpreter，这可以通过直接修改字符串表或者使用一些工具如patchelf来轻松实现。

对于恶意软件分析的场景，很多安全研究人员看到ELF就喜欢用ldd去看看有什么依赖库，一般ldd脚本实际上是调用系统默认的ld.so并通过环境变量来打印信息，不过对于某些glibc实现(如glibc2.27之前的ld.so)，会调用ELF指定的interpreter运行，从而存在非预期命令执行的风险。

当然还有更多其他的思路可以进行拓展，这就需要大家发挥脑洞了。

与逆向分析比较相关的就是符号表，一个有符号的程序在逆向时基本上和读源码差不多。因此对于想保护应用程序的开发者而言，最简单的防护方法就是去除符号表，一个简单的strip命令就可实现。strip删除的主要是Section中的信息，因为这不影响程序的执行。去除前后进行diff对比可看到删除的section主要有下面这些:

$ diff 0 1
1c1
< There are 35 section headers, starting at offset 0x1fdc:
---
> There are 28 section headers, starting at offset 0x1144:
32,39c32
<   [27] .debug_aranges    PROGBITS        00000000 00104d 000020 00      0   0  1
<   [28] .debug_info       PROGBITS        00000000 00106d 000350 00      0   0  1
<   [29] .debug_abbrev     PROGBITS        00000000 0013bd 000100 00      0   0  1
<   [30] .debug_line       PROGBITS        00000000 0014bd 0000cd 00      0   0  1
<   [31] .debug_str        PROGBITS        00000000 00158a 000293 01  MS  0   0  1
<   [32] .symtab           SYMTAB          00000000 001820 000480 10     33  49  4
<   [33] .strtab           STRTAB          00000000 001ca0 0001f4 00      0   0  1
<   [34] .shstrtab         STRTAB          00000000 001e94 000145 00      0   0  1
---
>   [27] .shstrtab         STRTAB          00000000 00104d 0000f5 00      0   0  1

其中**.symtab是符号表，.strtab**是符号表中用到的字符串。

仅仅去掉符号感觉还不够，熟悉汇编的人放到反编译工具中还是可以慢慢还原程序逻辑。通过前面的分析我们知道，ELF执行需要的只是Program Header中的几个段，Section Header实际上是不需要的，只不过在运行时动态链接过程会引用到部分关联的区域。大部分反编译工具，如IDA、Ghidra等，处理ELF是需要某些section信息来构建程序视图的，所以我们可以通过构造一个损坏Section Table或者ELF Header令这些反编译工具出错，从而干扰逆向人员。

当然，这个方法并不总是奏效，逆向人员可以通过动态调试把程序dump出来并对运行视图进行还原。一个典型的例子是Android中的JNI动态库，有的安全人员对这些so文件进行了加密处理，并且在.init/.initarray这些动态库初始化函数中进行动态解密。破解这种加固方法的策略就是将其从内存中复制出来并进行重建，重建的过程可根据segment对section进行还原，因为segment和section之间共享了许多内存空间，例如:

$ readelf -l main1
...
 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .init_array .fini_array .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
   08     .init_array .fini_array .dynamic .got

在Section to Segment mapping中可以看到这些段的内容是跟对应section的内容重叠的，一个segment可以包含多个section，但是依然可以根据内存的读写属性、内存特征以及对应段的一般顺序进行区分。

如果程序中有比较详细的日志函数，我们还可以通过反编译工具的脚本拓展去修改.symtab/.strtab段来批量还原ELF文件的符号，从而高效地辅助动态调试。

考虑这么一种场景，我们在分析某个IoT设备时发现了一个定制的ELF网络程序，类似于httpd，其中有个静态函数负责处理输入数据。现在想要单独对这个函数进行fuzz应该怎么做？直接从网络请求中进行变异是一种方法，但是网络请求的效率太低，而且触达该函数的程序逻辑也可能太长。

既然我们已经了解了ELF，那就可以有更好的办法将该函数抽取出来进行独立调用。在介绍ELF类型的时候其实有提到，可执行文件可以有两种类型，即可执行类型(ET_EXEC)和共享对象(ET_DYN)，一个动态链接的可执行程序默认是共享对象类型的:

$ gcc hello.c -o hello
$ readelf -h hello | grep Type
  Type:  DYN (Shared object file)

而动态库(.so)本身也是共享对象类型，他们之间的本质区别在于前者链接了libc并且定义了main函数。对于动态库，我们可以通过dlopen/dlsym获取对应的符号进行调用，因此对于上面的场景，一个解决方式就是修改目标ELF文件，并且将对应的静态函数导出添加到dynamic section中，并修复对应的ELF头。

这个思想其实很早就已经有人实现了，比如lief的bin2lib。通过该方法，我们就能将目标程序任意的函数抽取出来执行，比如hugsy就用这个方式复现了Exim中的溢出漏洞(CVE-2018-6789)，详见Fuzzing arbitrary functions in ELF binaries(中文翻译)。

总结

本文主要介绍了32位环境下ELF文件的格式和布局，然后从内核空间和用户空间两个方向分析了ELF程序的加载过程，最后列举了几个依赖于ELF文件特性的案例进行具体分析，包括dynamic linker的滥用、程序加固和反加固以及在二进制fuzzing中的应用。

ELF文件本身并不复杂，只有三个关键部分，只不过在section和segment的类型上保留了极大的拓展性。操作系统可以根据自己的需求在不同字段上实现和拓展自己的功能，比如Linux中通过dymamic类型实现动态加载。但这不是必须的，例如在Android中就通过ELF格式封装了特有的.odex 、 .oat文件来保存优化后的dex。另外对于64位环境，大部分字段含义都是类似的，只是字段大小稍有变化(Elf32->Elf64)，并不影响文中的结论。

参考链接

]]> Android进程间通信与逆向分析 https://evilpan.com/2020/07/11/android-ipc-tips/ Sat, 11 Jul 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/07/11/android-ipc-tips/ 最近在分析一个运行Android系统的IoT平台，其中包含设备管控和日志服务(Agent)、升级服务(FOTA)、自定义桌面(Launcher)、端上IDS以及前台的图形界面应用等多个前后台进程。在对其中某个功能进行逆向时发现调用链路跨越了多个应用，因此本文就做个简单记录。

前言

熟悉安卓开发的同学应该都知道构建IPC的流程，但从逆向工程的角度分析的却比较少见。 说到安卓跨进程通信/调用，就不得不提到AIDL和Binder，在逆向一个东西之前，首先需要了解它，因此本文也会先对其工作流程和工作原理进行介绍。

AIDL 101

AIDL是Google定义的一个接口定义语言，即Android Interface Definition Language。两个进程(称为客户端和服务端)共享同一份AIDL文件，并在其基础上实现透明的远程调用。

从开发者的角度如何使用AIDL呢？下面参考Android的官方文档以一个实例进行说明。我们的目标是构建一个远程服务FooService，并且提供几个简单的远程调用，首先创建AIDL文件IFooService.aidl：

package com.evilpan;

interface IFooService {
    void sayHi();
    int add(int lhs, int rhs);
}

AIDL作为一种接口语言，其主要目的一方面是简化创建IPC所需要的IPC代码处理，另一方面也是为了在多语言下进行兼容和适配。使用Android内置的SDK开发工具可将其转换为目标语言，本文以Java为例，命令如下：

aidl --lang=java com/evilpan/IFooService.aidl -o .

生成的文件为IFooService.java，文件的内容后面再介绍，其大致结构如下：

public interface IFooService extends android.os.IInterface {
    /** Default implementation for IFooService. */
	public static class Default implements com.evilpan.IFooService
  {
  	// ...
  }
	/** Local-side IPC implementation stub class. */
  public static abstract class Stub extends android.os.Binder implements com.evilpan.IFooService
  {
    // ...
  }

  public void sayHi() throws android.os.RemoteException;
  public int add(int lhs, int rhs) throws android.os.RemoteException;
}

在这个文件的基础上，服务端和客户端分别构造远程通信的代码。

服务端要做两件事：

  1. 实现AIDL生成的的接口
  2. 创建对应的Service并暴露给调用者

实现接口主要是实现AIDL中的Stub类，如下：

package com.evilpan.server;

import android.os.RemoteException;
import android.util.Log;
import com.evilpan.IFooService;

public class IFooServiceImpl extends IFooService.Stub {
    public static String TAG = "pan_IFooServiceImpl";

    @Override
    public void sayHi() throws RemoteException {
        Log.i(TAG, "Hi from server");
    }

    @Override
    public int add(int lhs, int rhs) throws RemoteException {
        Log.i(TAG, "add from server");
        return lhs + rhs;
    }
}

客户端调用接口需要经过Service，因此我们还要创建对应的服务：

package com.evilpan.server;

import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.util.Log;

public class FooService extends Service {
    public static String TAG = "pan_FooService";
    private IBinder mBinder;

    public FooService() {
        Log.i(TAG, "Service init");
        mBinder = new IFooServiceImpl();
    }

    @Override
    public IBinder onBind(Intent intent) {
        Log.i(TAG, "return IBinder Object");
        return mBinder;
    }
}

注意这个服务需要在AndroidManifest.xml中导出：

<service android:name=".FooService"
         android:enabled="true"
         android:exported="true"/>

这里的服务与常规服务不同，不需要通过startService之类的操作去进行启动，而是让客户端去绑定并启动，因此也称为Bound Service。客户端绑定成功后拿到的IBinder对象(远程对象)就相当于上面onBind中返回的对象，客户端中操作本地对象可以实现远程调用的效果。

客户端在正常调用远程方法之前也需要做两件事：

  1. 实现ServiceConnection接口
  2. bindService

ServiceConnection接口主要是连接远程服务成功的异步回调，示例如下：

    private ServiceConnection mConnection = new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            Log.i(TAG, "onServiceConnected");
            mService = IFooService.Stub.asInterface(service);

            Log.i(TAG, "sayHi");
            try {
                mService.sayHi();
                Log.i(TAG, "add");
                mService.add(3 , 4);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {
            Log.i(TAG, "onServiceDisconnected");
        }

连接成功时会获得一个IBinder对象，就是前面说的IFooService.Stub实现。我们可以直接通过asInterface将其转换为IFooService对象。

bindService方法用来将Activity绑定到目标Service上，第一个参数为目标Service的Intent，第二个参数为上面的ServiceConnection实例。

    @Override
    protected void onStart() {
        super.onStart();
        Log.i(TAG, "onStart");

        Intent intent = new Intent();
        String pName = "com.evilpan.server";
        intent.setClassName(pName, pName + ".FooService");
        boolean ret = bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
        Log.i(TAG, "bindService: " + ret);
    }

注意这里的包名指定的是服务端的包名，并且类名是服务类而不是AIDL中的接口类。绑定成功后启动客户端进程，可看到ADB日志如下所示：

07-11 06:01:25.767  8492  8492 I pan_Client: onCreate
07-11 06:01:25.768  8492  8492 I pan_Client: onStart
07-11 06:01:25.769  8492  8492 I pan_Client: bindService: true
07-11 06:01:25.770  8451  8451 I pan_FooService: Service init
07-11 06:01:25.770  8451  8451 I pan_FooService: return IBinder Object
07-11 06:01:25.785  8492  8492 I pan_Client: onServiceConnected
07-11 06:01:25.785  8492  8492 I pan_Client: sayHi
07-11 06:01:25.785  8451  8463 I pan_IFooServiceImpl: Hi from server
07-11 06:01:25.786  8492  8492 I pan_Client: add
07-11 06:01:25.786  8451  8508 I pan_IFooServiceImpl: add from server

Server和Client示例文件可见附件。

前面我们简单介绍了AIDL的使用，实际上AIDL支持丰富的数据类型，除了int、long、float、String这些常见类型外，还支持在进程间传递对象(Parcelable)，以及传递函数。在AIDL中定义对象如下：

package com.evilpan;
parcelable Person {
	int age;
	String name;
}

也可以在AIDL中只声明parcelable对象，并在Java文件中自己定义。

而函数也可以看做是一个类型进行传递，例如：

package com.evilpan;
oneway interface IRemoteServiceCallback {
	void onAsyncResult(String result);
}

可以把IRemoteServiceCallback当做一个类型，在其他的AIDL中使用：

package com.evilpan;

import com.evilpan.IRemoteServiceCallback;

interface IRemoteService {
	void registerCallback(IRemoteServiceCallback cb);
}

这种模式可以让服务端去调用客户端实现的函数，通常用来返回一些异步的事件或者响应。

Binder

通过上面的介绍我们知道AIDL实际上只是对boundService接口的一个抽象，而boundService的核心是有一个跨进程的IBinder接口(即上面onBind返回的对象)。实现这个接口有三种方式：

  1. 拓展Binder类来实现接口
  2. 使用Messenger来创建服务的接口，实际上底层也是基于AIDL实现的
  3. 直接使用AIDL

通常实现IPC用得更多的是Messenger，因为其接受的信息是在同一个线程中处理的；直接使用AIDL可能需要多线程的能力从而导致复杂性增加，因此不适合大部分应用。

但不管是AIDL还是Messenger，其本质都是使用了Binder。那么什么是Binder？简单来说Binder是Android系统中的进程间通信(IPC)框架。我们都知道Android是基于Linux内核构建的，而Linux中已经有了许多进程间通信的方法，如：

  • 管道（半双工/全双工）
  • 消息队列
  • 信号量
  • 共享存储
  • socket
  • …

理论上Binder可以基于上面的这些机制实现一套IPC的功能，但实际上Binder自己构建了新的进程间通信方法，这意味着其功能必须要侵入到Linux内核中。为满足商业公司需求而提交patch到Linux upstream，所受到的阻力可想而知，为什么Google仍然坚持呢？Brian Swetland在Linux邮件组中指出，现有的Linux IPC机制无法满足以下两个需求：

  1. 通过内核将数据直接到目标地址空间的环形缓冲区，从而减少拷贝开销。
  2. 对可在进程间共享和传递的远程代理对象的生命周期管理。

因此目前Binder在内核中实现为独立的驱动，即/dev/binder(后续还进行了细分，如hwbinder、vndbinder)。

除了Binder之外，Android还在Linux的基础上增加了一些其他驱动，比如Ashmem、Low Memory Killer等，在内核的drivers/[staging]/android目录中。

从驱动的层面看，Binder的使用也很简单：使用open(2)系统调用打开/dev/binder，然后使用ioctl(2)系统调用进行数据传输。以前面的AIDL IPC为例，其底层的实现如下图所示：

img-binder

图：http://newandroidbook.com/files/Andevcon-Binder.pdf

逆向分析

上面介绍了那么多，但本文不是Binder Internal的文章，不要忘记了我们的目的是逆向。从上面Binder IPC的流程中可以看到一个很重要的特点，即Binder使用transact发送数据，并且在(另一个进程的)onTransact回调中接收数据。

大部分逆向工程的工作都是类似的，寻找一种经过编译器处理特定文件后的的模式，并在此基础上构建还原出原始的操作。比如，对于C语言的逆向是通过调用约定以及函数入口/出口对栈的分配/释放来判断函数的调用，对于C++则是通过对vtable的查找/偏移来判断虚函数的调用。

对于我们一开始的目标而言，就是需要分析出系统中存在的进程间调用，更准确地说是需要确定某个进程中函数的交叉引用(xref)。以AIDL为例，.aidl文件是不包含在release后的apk文件中的，不过我们还是可以通过生成文件的特征判断这是一个AIDL服务。从生成的代码上来看，主要有这些特点：

  1. 服务端和客户端生成的接口文件是相同的
  2. 生成的主类拓展android.os.IInterface，包含AIDL中所定义的函数声明
  3. 主类中包含了自身的3个实现，分别是默认实现Default、本地实现Stub以及远程代理实现Proxy

一般而言，本地的实现(Stub)需要服务端继承并实现对应方法，Stub同时也拓展Binder类，并在onTransact方法中根据code来选择不同的函数进行处理。比如对于前面的例子，有：

public static abstract class Stub extends android.os.Binder implements com.evilpan.IFooService {
  public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) {
    // ...
    switch (code) {
        //...
      case TRANSACTION_sayHi:
        this.sayHi();
	    reply.writeNoException();
       	return true;
      case TRANSACTION_add:
        int _arg0 = data.readInt();
        int _arg1 = data.readInt();
        int _result = this.add(_arg0, _arg1);
	    reply.writeNoException();
        reply.writeInt(_result);
        return true;
      // ...
    }
  }
}

Proxy即Client端的实现则通过指定transact的code来调用对应远程代码，如下：

private static class Proxy implements com.evilpan.IFooService {
  private android.os.IBinder mRemote;
	// ...
	public void sayHi() throws android.os.RemoteException {
    //...
  	boolean _status = mRemote.transact(Stub.TRANSACTION_sayHi, _data, _reply, 0);
    //...
	}
}

除了生成代码的特征，通常远程调用都会用到 Bound Service，因此在服务端的AndroidManifest.xml文件中必然会有导出的服务声明，这也可以作为分析的一个辅助验证。

示例

假设我们正在逆向分析上面编译好的APK，在找到某个关键函数(比如add)后Find Usage发现没有任何交叉引用，但实际上这个函数是被调用了的。那么这就有几种可能，比如这个函数是通过反射调用的，或者这个函数是在native代码中调用的。……当然这里实际上是父类中进行多态调用的，本质是Binder唤起的远程调用。

img-re

跨进程交叉引用的一个前提是需要知道是在哪个进程调用的。如果有权限在Server中进行调试或者代码注入，我们就可以在触发调用或者绑定时使用Binder.getCallingUid()函数获取调用者的UID，从而获取Client的包名。

单纯静态分析的话可以把系统中所有相关的进程pull下来，分别反编译后使用grep进行搜索。因为远程调用的接口是共享的，所以即便使用了proguard等混淆也不会影响到接口函数。

小结

本文主要是记录下最近遇到的一个Android智能设备的逆向，与以往单个APK不同，这类智能设备中通常以系统为整体，其中包含了多个业务部门内置或者安装的应用，在分析时发现许多应用间跳转和通信的场景。由于NDA的原因没有详细介绍，因此使用了我自己创建的Client/Server作为示例进行说明，但其中的方法都是类似的，即先从正向了解IPC的运行方式，然后通过代码特征去鉴别不同应用间的跳转。对于复杂的系统而言，先理清思路比头铁逆向也更为重要。

参考资料

]]> 漫谈逆向工程 https://evilpan.com/2020/03/08/reverse-engineering/ Sun, 08 Mar 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/03/08/reverse-engineering/ 谈谈我对逆向工程的一些理解和感悟。

引言

逆向工程，原名Reverse Engineering，简称RE。关于其书面介绍我就不复制粘贴百度百科了，简而言之就是从发布的产品中反向分析其程序逻辑和算法——基于各种目的。

准确地说，逆向工程包括软件逆向工程——即本文所讨论的，也包括硬件逆向工程。那么硬件逆向是怎么做的呢？据我所知，我国的芯片设计水平普遍比国外落后10年。当国外厂商已经成功流片量产X纳米的芯片时候，我们还在XX纳米的研发和难点攻关中挣扎。挣扎的过程之一就是芯片逆向。

一般从代理买到量产芯片后，第一步就是溶解外部封层，使用电子显微镜对电路进行拍摄，俗称拍片；第二步是使用特定工具软件（也是国外的）对照片进行切分，通过人力对自动生成的连线进行修复；第三步是将修复的连线还原成数字电路，再由IC逻辑工程师进行进一步修复；最后组合不同模块的门级电路，还原成硬件描述语言VHDL或者Verilog。之后就和正常的流程一样，开发、测试、模拟、仿真、流片……

ALU

扯远了，还是回到主题上来。硬件逆向的成本动辄成百上千万，没有纳税人的支持是玩不起的。但是软件逆向不同，只要一个智力正常的人，研究一两个月，也能上XX破解论坛上分享他们的破解成果了。

这也引出了一个问题，当我们在谈论逆向的时候，我们在谈论的是什么？

软件逆向

二进制逆向就是IDA-Pro + F5一把梭吗？Java逆向就是JADX一把梭吗？很多接触过逆向的新手都知道不是，他们会跳出来反驳，夹杂着一些X86/ARM/MIPS Assembly、Smali、XYZ IR等等让人不明觉厉的词汇。虽然听不懂，但我们也知道他们想表达什么：逆向是一门牵涉甚广的领域。

的确，如果HTML、CSS这些领域是“单关节运动”，那么逆向就是“多关节运动”。前段时间有些使用node写前后端的开发者喜欢自称“全栈工程师”，要按照我的说法，逆向工程师才是当之无愧的全栈。为什么？来看看一个逆向工程师所应该具备的部分技能：

  • 一定的软件开发能力，熟悉数据结构、算法
  • 了解各种编程语言，熟悉编译原理
  • 熟悉计算机基本原理、操作系统、编译器、链接器
  • 熟悉对应平台或者虚拟机的汇编语言(机器码)、中间语言(字节码）
  • …

一个好的逆向工程师，通常也是个不错的开发者。即便现在有各种收费或免费的反编译器，也需要逆向工程师对代码进行梳理、分析、审计。这就意味着逆向者需要站在比开发者更高的角度去审视，甚至比开发者更加理解他们的代码。……

关于初衷

搞逆向这么麻烦，要懂这个，要懂那个，直接劝退了很大一波人。但其实这些只是“术”而已，实际工作中只需要用到一部分子集，甚至只要学会使用商业工具也能干活儿了。在我看来，逆向工程师的核心还是——强烈的好奇心。

或者说，这是大部分网络安全人员(黑客)所具备的特质。因为好奇某个商业软件的功能，或者好奇某个病毒蠕虫的行为，才走向了这条逆向之路。

逆向的过程是枯燥的。与其说逆向是技术活，在我看来更多是体力活。尤其是在分析大型软件的时候，每天改变量名，改函数名，分析树状的调用路径，……很容易让人感到厌烦。

但是对于抱有好奇心的人而言，逆向应该是快乐的。每分析出一个软件或者函数的行为，就仿佛侦探找到关键线索或证据一样兴奋。隐藏的路径越深，知道的人就越少，那么被藏起来的东西也就越有价值。

关于快乐

逆向应该是快乐的，但很多人不想让你快乐。于是有了各种符号加壳、混淆、加密、解释执行(虚拟机)等应用增强方案，来提高逆向工程的难度。这通常是企业中端安全工程师的杰作，或者是使用了安全公司的通用安全加固方案。

所谓的逆向混淆，只有在别人不知道你的方法时才有价值。对于通用的加固，所面临的挑战者甚多，其内部实现很可能已经被扒了个底朝天；而对于企业自研的方案，又通常因为太low而被简单绕过。所以，想让逆向工程师不快乐的人有时候成功了，但是大部分时候还是在逆向工程师手下败下阵来。用一朋友的话来说就是：“程序在我的设备、我的环境里运行，难道它还能上天？”

关于现状

应用程序是不能上天，但是逆向工程师也很难上天。记得柯南里有一句话让我印象深刻——“如果怪盗是富有创造力的艺术家，那么侦探充其量只是吹毛求疵的评论家”。逆向工程做的大部分都是破坏性的工作，而不像开发者那样带来正面价值。

目前社区中做逆向的大多是出于解谜(CTF)、软件破解、游戏外挂等，即便是专门讨论逆向的安全论坛中，对技术细节的探讨也寥寥无几，更多是炫耀和分享自己的“成果”。天下熙熙，皆为利来，天下攘攘，皆为利往，除了闷声发大财地以搞逆向赚钱的工作室外，公开分享的也就只能是为名了。

那么职业做逆向的情况又如何呢？专门做逆向的正经岗位应该是恶意软件分析了，衍生出的团队在商业环境中突出PR宣传安全产品或者情报能力。其他小公司里招聘做逆向的人，要么是分析竞争对手，要么围绕高流量软件的去进行分析、破解、换皮、刷粉养号等等，是在违法犯罪的边缘来回试探。

专门做逆向的情况不多，但是将其作为一门技能去掌握的人也不少。我自己本身也不是专门做逆向的，因为工作需要才去对其进行了解。除了开源软件，也有越来越多闭源软件的漏洞被暴露出来，你不去挖别人自然会去挖。就拿安卓每个月的安全通告来说，带星号的漏洞简直不要太多。

cve

图：Android Security Bulletin—March 2020

正面价值

逆向也有作为正面案例出现。比如对于一些开发者不再维护的软件，出现各种原因无法使用时，通常就有正义的逆向工程师去尝试解决困难，之前就有这么一个例子：

help

还有比较经典的就是Linux系统中的著名的开源驱动nouveau部分功能就是通过逆向英伟达的驱动而开发的，因为英伟达出于各种保护的原因不愿意与开源社区合作而闹了诸多矛盾，这也是下面这张图片的根源。

Fuck Nvidia

总而言之，技术本身无对错好坏之分，关键是看使用的人以及使用的目的。

后记

回想起以前在研究高通可信执行环境时，被laginimaineb的那篇博客Exploring Qualcomm’s Secure Execution Environment给惊艳到了，大概那就是我心目中逆向大神该有的样子。那篇文章不是逆向某个特定的软件，也不是做了什么复杂的脱壳，而是将一种在未知环境中运行的未知格式程序就那么一字节一字节的分析出来。

qsee

要知道当时TEE尤其是高通的QSEE，在内部是被严密保护的，网上可以说几乎没有相关信息可以参考。甚至作为开发者都要以企业名义签署严格的NDA才能拿到开发工具。要在这种环境去逆向、调试、挖漏洞看似不可能，但laginimaineb接下了这个挑战，而且还超额完成了(userspace -> QSEE Kernel)。他自己的说法是“For Fun”，我也相信他是“Fun”的。就是这样的人，让安全行业充满激情和热忱。

最后：

Stay Curious, Stay Exploring && Happy Hacking!

]]> 免越狱调试与分析黑盒iOS应用 https://evilpan.com/2019/04/07/ios-reverse-basics/ Sun, 07 Apr 2019 22:40:00 +0800 evilpan https://evilpan.com/2019/04/07/ios-reverse-basics/ 上篇文章我们从开发者的角度介绍了如何建立iOS项目并且在真机上运行， 上上篇文章则介绍了Objective-C的基本概念和用法。而这一切，都是为了这次的铺垫。 今天，我们就要从攻击者的角度，尝试对黑盒iOS应用进行调试与动态跟踪(instrument)。

前言

为什么要执着于免越狱呢？因为随着iOS系统的不断更新，其安全性也越来越高， 挖掘越狱漏洞也越来越难，很多新版本都已经没有公开的越狱方案了。 近来苹果也会给提交越狱漏洞的白帽不菲的奖励， 加上越狱对于普通用户的好处也越来越少， 很多越狱工具的开发者也逐渐不再更新维护。因此，免越狱分析，很有可能是未来唯一的方法。

How

其实免越狱测试应用也不是什么新技术了，Android中也有类似免root测试的方法。 而这两个方法其实本质上都是一样的，那就是 —— 重打包。

对于Android来说，就是将安装包解压后注入字节码，使得应用在启动前加载我们准备的.so动态库， 从而实现在应用的上下文执行任意代码的目的；对于iOS也是一样，区别是所注入的动态库为.dylib。

获取目标

在上篇文章中其实有说了，开发者在编译iOS或者MacOS项目时，最终生成的应该是.app文件， 但在iOS中还需要对app文件进行打包，生成.ipa文件。AppStore下载的应用实际上是加密ipa， 一般而言可以使用下面的工具来进行还原，这一步俗称砸壳。

砸壳操作本质上是在运行时从内存里将原始文件导出，因此都需要有在源程序上下文中执行代码的能力， 也就是说，需要越狱。对于我们的场景而言，可以在第三方应用市场去下载已经解密的ipa文件， 比如AppCake或者PP助手（以及各种xx助手）等。

Tips：

对于PP助手，可以用下面的地址搜索对应应用：
    https://www.25pp.com/ios/search_app_0/关键词
在应用详情界面中，通过查看网页源代码即可看到base64编码的ipa的下载地址。

以2048小游戏为例，我们把下载的越狱程序保存为pp2048.ipa，前面也说过，ipa本质上是zip格式， 将其解压后目录结构如下：

$ unzip pp2048.ipa -d pp2048
$ tree -d 1 pp2048
1 [error opening dir]
pp2048
├── META-INF
└── Payload
    └── 2048.app
        ├── 2048
        ├── Frameworks
        ├── _CodeSignature
        ├── en.lproj
        ├── es.lproj
        ├── fr.lproj
        ├── ...
        └── zh-Hans.lproj

otool命令可以输出app的load commands，可通过查看cryptid标志位来判断app加密状态。 其中1代表加密，0代表已解密：

$ otool -l pp2048/Payload/2048.app/2048  | egrep 'LC_ENCRYPTION_INFO|cryptid'
          cmd LC_ENCRYPTION_INFO
      cryptid 0
          cmd LC_ENCRYPTION_INFO_64
      cryptid 0

这一步对于我们后续的分析是必须的，因为如果app没有解密，那么后面即使重打包安装了， 也依然无法运行。

签名与重打包

有了解密的应用程序，接下来要做的就是对其进行重打包从而注入我们的代码了。 在重打包之前，可以先查看一下原APP的签名信息。

解压后可以看到Payloads下有2048.app文件夹，这便是我们需要的应用程序。 可以用苹果自带的codesign工具验证和查看签名信息：

验证签名：

$ codesign --verify pp2048/Payload/2048.app
pp2048/Payload/2048.app: invalid signature (code or signature have been modified)
In architecture: armv7

可以看到签名验证失败，一般越狱应用都会去除掉签名信息，如下：

$ codesign -d -vv pp2048/Payload/2048.app
Executable=/reverse/iOS/pp2048/Payload/2048.app/2048
Identifier=com.ketchapp.2048
Format=app bundle with Mach-O universal (armv7 arm64)
CodeDirectory v=20200 size=68369 flags=0x0(none) hashes=2129+5 location=embedded
Signature size=4297
Authority=(unavailable)
Info.plist=not bound
TeamIdentifier=BB5K34ZCVK
Sealed Resources version=2 rules=11 files=95
Internal requirements count=1 size=100

这一步不是必须的，但是有助于我们了解目标应用程序。

在注入代码之前，我们可以先尝试修改应用内的资源文件来重新打包看是否能正常运行。 步步为营，这样排除由于注入代码而导致的错误。

要做的很简单，向app中添加一个文本文件：

echo "Leave Me" > pp2048/Payload/2048.app/evilpan.txt

然后重新打包：

cd pp2048 && zip -qry ../pp2048-repack.ipa Payload

这样就生成了新的pp2048-repack.ipa文件。这时候的ipa还不能用，需要对其进行签名。

苹果要求ipa需要经过签名才能部署，Xcode7后可以使用个人Apple ID来进行provision签名， 用于在自己的设备上对应用进行测试。值得一提的是，ipa的签名和app签名还不太一样， 后者是用codesign工具进行签名，而ipa则需要第三方工具的帮助。

可以用于给ipa（重）签名的工具有一大把，比如：

还有很多没列举到的，这里使用node-appsign来签名：

applesign -i $SIGNID -m /path/to/embedded.mobileprovision pp2048-repack.ipa -o pp2048-resign.ipa

其中SIGNID指定用于签名的私钥，可用security命令来查看当前可用于给代码签名的SIGNID：

$ security find-identity -v -p codesigning
  1) CDC7************************************ "iPhone Developer: evilpan (V2KHK9DD9)"
  2) A3BB************************************ "org.radare.radare2"
     2 valid identities found

实际测试中发现似乎只能用第一个也就是Apple ID生成的私钥来进行签名。

在签名的命令中，还有一个需要提供的文件就是embedded.mobileprovision， 即provision profiles，这个文件可以在我们自己的iOS项目生成文件中找到，比如：

/Users/Peter/Library/Developer/Xcode/DerivedData/HelloWorld-dnyjqrgxcjjobvfzytzhtzpmjlmx/Build/Products/Debug-iphoneos/HelloWorld.app/embedded.mobileprovision
# 或者
~/Library/MobileDevice/Provisioning Profiles/

provision profiles是将签名，授权和沙盒联系起来文件，每个iOS开发者应该都不会陌生。 关于iOS/OSX代码签名和授权机制的介绍，强烈推荐这篇文章，这里就不展开了。

签名完成后的ipa就可以部署到真机上了，比如用我们上一篇文章说到的ios-deploy：

ios-deploy -b pp2048-resign.ipa

安装成功！如果是第一次启动，会提示不受信任的开发者，安装提示允许即可正常运行。

注入代码灵魂

现在我们已经验证了重打包应用的可行性，接下来就要开始做点有用的事情了。 为了在应用中执行我们自己的代码，我们可以直接修改二进制的2048.app/2048文件， 毕竟，它只是一个运行于ARM平台的普通Mach-O文件而已：

$ file pp2048/Payload/2048.app/2048
pp2048/Payload/2048.app/2048: Mach-O universal binary with 2 architectures: [arm_v7:Mach-O executable arm_v7] [arm64]
pp2048/Payload/2048.app/2048 (for architecture armv7):	Mach-O executable arm_v7
pp2048/Payload/2048.app/2048 (for architecture arm64):	Mach-O 64-bit executable arm64

可以使用十六进制编辑器如radare2对其进行patch，不过这种方式太原始，做点简单修改还行， 不方便做太复杂的操作。所以，一般还是直接在Mach-O中注入少量指令，并使其在运行时加载我们的动态库， 这样就可以在动态库中实现复杂的操作了。

在给iOS注入动态库之前，我们先在Mac下面测试一下注入动态库的可行性，二者平台是比较类似的。 首先编译一个简单的Mach-O可执行文件，如下：

$ cat hello.m
#import <Foundation/Foundation.h>

int main (int argc, const char * argv[])
{
    @autoreleasepool {
        NSLog (@"Hello, World!");
    }
    return 0;
}

$ clang -framework Foundation hello.m -o hello
$ ./hello
2019-04-07 12:38:10.031 hello[17348:3859846] Hello, World!

然后准备一个动态库文件libtest.m：

#import <Foundation/Foundation.h>

__attribute__((constructor)) void dylibMain()
{
    @autoreleasepool {
        NSLog(@"libtest LOADED!!!!!!!");
    }

}

__attribute__((constructor))宏描述dylibMain为动态库的constructor，即入口。 编译动态库的方法为：

$ clang -framework Foundation libtest.m -shared -o libtest.dylib
$ file libtest.dylib
libtest.dylib: Mach-O 64-bit dynamically linked shared library x86_64

在Linux中注入动态库最简单的方法就是使用LD_LIBRARY环境变量， Mac下也有类似的环境变量，为DYLD_INSERT_LIBRARIES，如下：

$ DYLD_INSERT_LIBRARIES=libtest.dylib ./hello
2019-04-07 12:44:08.810 hello[17497:3861923] libtest LOADED!!!!!!!
2019-04-07 12:44:08.812 hello[17497:3861923] Hello, World!

可以看到动态库中的代码已经被调用了，而且是在main函数之前。

在没越狱的iOS中，我们无法轻易给目标进程添加环境变量。不过既然能修改文件， 我们也可以将其改成在启动是自己加载指定动态库。有很多自动化工具可以帮助我们完成这个操作：

这些工具的作用都是在Mach-O的Load Commands段中添加一条LC_LOAD_DYLIB。 关于Mach-O的详细文件格式可以参考PARSING MACH-O FILES。

以insert_dylib为例，注入dylib只需一条命令：

$ ./hello
2019-04-07 12:57:42.274 hello[17728:3865999] Hello, World!

$ insert_dylib libtest.dylib hello
Added LC_LOAD_DYLIB to hello_patched

$ ./hello_patched
2019-04-07 12:57:58.425 hello_patched[17752:3866077] libtest LOADED!!!!!!!
2019-04-07 12:57:58.425 hello_patched[17752:3866077] Hello, World!

现在我们已经（在Mac上）验证了向二进制文件中注入动态库的可行性，接下来就是iOS了。 和Mac不同的是，iOS应用一般是ARM/ARM64版本，因此在x86的笔记本上，就需要交叉编译。 通过clang和Xcode提供的SDK，我们可以很方便在Mac上交叉编译iOS的应用或动态库：

clang -framework Foundation libtest.m -shared -o libtest.dylib -arch armv7 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk -mios-simulator-version-min=6

和ELF不同的是，Mach-O支持多架构，也就是说我们可以指定多个arch，生成的文件如下：

$ file libtest.dylib
libtest.dylib: Mach-O universal binary with 2 architectures: [arm_v7:Mach-O dynamically linked shared library arm_v7] [arm64:Mach-O 64-bit dynamically linked shared library arm64]
libtest.dylib (for architecture armv7):	Mach-O dynamically linked shared library arm_v7
libtest.dylib (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

但是一般只需要支持armv7即可，因为iOS新的CPU会兼容老的架构，详见iOS Support Matrix。

新生成的libtest.dylib此时还不能直接添加到ipa中，要时刻记住在iOS中， 所有的代码都需要有合法的签名。

$ codesign -f -v -s $SIGNID libtest.dylib
libtest.dylib: signed Mach-O universal (armv7 arm64) [libtest]

将libtest.dylib拷贝到ipa，并注入到可执行文件中，参考上面简单重打包的方法， 对最后的ipa进行重新打包签名。这里为了看到标准输出，直接使用lldb调试启动：

$ unzip pp2048-resign.ipa -d pp2048-resign
$ ios-deploy -b pp2048-resign/Payload/2048.app --debug -W
(lldb)     connect
(lldb)     run
success
libtest LOADED!!!!!!!
2019-04-07 13:49:49.731657+0800 2048[14630:3523860] [Accessibility] ****************** Loading GAX Client Bundle ****************
2019-04-07 13:49:50.085734+0800 2048[14630:3523860] [aurioc] 1029: failed: '!pla' (enable 2, outf< 2 ch,  44100 Hz, Float32, non-inter> inf< 2 ch,      0 Hz, Float32, non-inter>)
2019-04-07 13:49:50.127830+0800 2048[14630:3523860] error loading sound: a004
Process 14630 exited with status = 1 (0x00000001)
(lldb)

可以看到，libtest已经成功加载并执行了！这里需要一提的是我把libtest.m中的NSLog改成了printf， 因为测试中发现前者在运行时根本没有打印，这问题也令我测试了好久。

动态调试

终于，我们成功在目标iOS应用中注入了我们自己的动态库！由于动态库的代码是我们自己写的， 因此可以编写复杂的插件，在应用上下文执行任意代码。

刚刚启动时我们使用了ios-deploy的--debug参数来启动lldbserver/client 并自动attach，lldb是LLVM中功能强大的调试器，功能与gdb类似，如下：

(lldb) process interrupt
Process 14675 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00000002230efea4 libsystem_kernel.dylib`mach_msg_trap + 8
libsystem_kernel.dylib`mach_msg_trap:
->  0x2230efea4 <+8>: ret

libsystem_kernel.dylib`mach_msg_overwrite_trap:
    0x2230efea8 <+0>: mov    x16, #-0x20
    0x2230efeac <+4>: svc    #0x80
    0x2230efeb0 <+8>: ret
Target 0: (2048) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00000002230efea4 libsystem_kernel.dylib`mach_msg_trap + 8
    frame #1: 0x00000002230ef37c libsystem_kernel.dylib`mach_msg + 72
    frame #2: 0x00000002234f5ad8 CoreFoundation`__CFRunLoopServiceMachPort + 236
    frame #3: 0x00000002234f0974 CoreFoundation`__CFRunLoopRun + 1396
    frame #4: 0x00000002234f00e0 CoreFoundation`CFRunLoopRunSpecific + 436
    frame #5: 0x0000000225769584 GraphicsServices`GSEventRunModal + 100
    frame #6: 0x0000000250740c00 UIKitCore`UIApplicationMain + 212
    frame #7: 0x000000010298ca20 2048`___lldb_unnamed_symbol49$$2048 + 88
    frame #8: 0x0000000222faebb4 libdyld.dylib`start + 4
(lldb)

例如，使用lldb来对抗ptrace反调试：

# 设置断点
b ptrace

# 继续执行
continue

# 触发断点后直接跳转到返回地址
register write pc `$lr`

# 绕开ptrace继续运行
continue

lldb还支持python扩展，从而实现更丰富的自定义功能，详见LLDB-Python。

除了使用调试器，我们还可以使用frida来进行动态的hook， 其ObjC 接口提供了许多针对ObjectiveC的封装，对于Objective-C项目， 可以使用frida很轻松地修改应用程序逻辑。

在非越狱场景使用frida主要是通过frida-gadget，即通过重打包注入 frida-gadget.dylib动态库，流程和注入我们自己编译的libtest.dylib一模一样。 关于frida的详细使用方法可以多看看其官方文档。

使用insert_dylib注入frida-gadget.dylib例子如下：

cp frida-gadget.dylib pp2048/Payload/2048.app/
insert_dylib --strip-codesig --inplace '@executable_path/frida-gadget.dylib' pp2048/Payload/2048.app/2048

小结

至此，免越狱对应用进行动态分析的部分已经介绍完毕，这对于真正分析一个iOS程序还不完整， 但却是最重要的部分。分析一个iOS应用和其他应用一样，无非就是逆向分析与动态调试， 对于静态分析来说，一般也是使用Reveal定位关键点， 然后把Mach-O拖进逆向分析工具如IDA/radare2/Ghidra进行分析，复杂点的需要面对混淆和对抗， 因此动态分析也能帮助理解静态代码。而动态分析除了用于分析还能用于持久化， 这对于日常工作生活而言，或许是更为实用的。

参考链接

]]> 一个色播APP逆向——初窥千万灰色直播产业 https://evilpan.com/2019/01/05/reverse-live-porn-app/ Sat, 05 Jan 2019 22:40:00 +0800 evilpan https://evilpan.com/2019/01/05/reverse-live-porn-app/ 当你凝视深渊的时候, 深渊也在凝视你 —— 尼采.

从大约13年开始, 各大直播平台就如雨后春笋般冒出来, 犹记得当初还经常在午休时看DOTA的直播下饭. 后来不知道什么时候开始不再只是游戏直播, 而是一度刮起了女主播打擦边球的歪风邪气, 再后来严厉整顿, 各个平台也才逐渐收敛野蛮的发展, 逐渐步入正轨. 然而, 在阳光照不到的地方, 依然暗流涌动…

前言

发现这一迹象的契机, 是在总部位于卢森堡的某联盟网站发现开始有大量中国人拍摄的视频, 这在国际网站中是比较少见的. 而这些视频有个共同特征, 都打有某某直播的水印. 当时并没有在意, 加上年底也比较忙没空深究. 直到今天闲下来, 才想起来一探究竟.

首先按照水印的logo去搜索, 发现一个网站:

webpage

主页倒是中规中矩, 一副文艺社交的样子, 但是看标题就知道不一般啊. SM是什么东西, 熟悉二次元的朋友应该都不会陌生. 尽管我也有所了解, 但随着深入探究还是被震惊到, 所以建议未成年的小兄弟三思而百度.

说到百度, 来看看百度对这个站的收录是如何的:

baidu

竟然没有收录! 果然藏得很深. 什么叫暗网? 不是洋葱才叫暗网, 这也是一种暗网. 回过头来, 这个网站显然只是一个下载站, 也没有web访问界面, 因此我们要深入的话需要下载其手机APP. 网站提供了安卓和iOS版本, 我们先选择前者来进行分析.

分析APP的第一步当然是使用了. 以防万一, 这种APP还是先放在沙盒里运行, 保不准有什么顽固木马. 意料之中的是不支持x86的模拟器, 换到arm环境中正常启动. 贵圈的画风是怎么样的的? 截了一张图大家感受下:

shot

里面大致分为直播和回放, 当然天下没有免费的午餐, 每个视频或者直播都只能免费播放8秒, 8秒之后自动弹出购买窗口, 平均购买价格为288-988金币不等, 金币价格如下, 支持微信支付哦:)

price

探索

大致玩了一遍这个APP, 基本功能都了解了, 接下来就从技术角度去探索下里面的实现. 一般来说逆向都要事先定下目标目标, 但是我们这次没有很明确的目标, 只是随便逛逛, 顺便复习下逆向技能.

首先在刚才的首页下载安卓apk, 用JADX看看大致的结构:

shell

看样子是使用了360的安全加固, 正好之前写了个脱壳脚本, 一键脱掉:

unpack

之后每个dex就可以正常使用jadx-gui来打开看了, 不过这里分享一个我比较喜欢的操作, 即用jadx命令行分别反编译各个dex, 然后用rsync合并到一处.

mkdir t380.jadx
for i in {1..4};do
    JAVA_OPTS="-Xmx8G" jadx -j 1 -r -d t380_${i}.jadx unpacked_classes${i}.dex
    rsync -a t380_${i}.jadx t380.jadx
done

为什么要这么做? 因为使用jadx-gui分别打开每个dex时候不论是查找函数还是查找引用都不太方便, 合并到一处可以直接用find/grep来查找. 这对于上百兆的巨型APK逆向还是很实用的.

虽然这个APK只有50多M, 但代码量也不小, 直接看有点无从下手, 就从收费的地方开始吧! 毕竟这是整个环境最核心的部分. 我们打开一个直播间, 等8秒后弹出付费窗口, 定位这个地方:

ui

当然, 还有个比较直接的方法, 直接使用adb来查看当前置顶的activity:

$ adb shell dumpsys window windows | grep Focus
  mCurrentFocus=Window{be2e8cd u0 com.zhuoyigou.dese/com.zhuoyigou.dese.ui.live.activity.PlayerLiveActivtiy}
  mFocusedApp=AppWindowToken{73e5eb8 token=Token{bfded1b ActivityRecord{2d0fb2a u0 com.zhuoyigou.dese/.ui.live.activity.PlayerLiveActivtiy t50}}}

这个直播软件有个独特的地方是里面除了直播, 还有大部分是视频回放, 观看视频回放同样是需要收费. 定位方法也是同样, 回放的activity为com.zhuoyigou.dese.ui.live.activity.PlayBackActivity.

这里再分享个小技巧, 逆向过程中经常会需要用编辑器打开某个文件, 定义个shell函数可以加速该流程:

function jopen() {
    p=`echo -n $1 | tr . /`
    file=$p.java
    gvim -R $file
}

这里以PlayBackActivity为例, 在jadx代码目录下, 可以直接这样打开文件:

jopen com.zhuoyigou.dese.ui.live.activity.PlayBackActivity

哈, 扯远了, 来看看弹窗付费的地方是如何实现的吧, 该类的部分代码风格如下:

code

做了一点对抗, 但是却没有完全混淆, 看来是不太了解木桶原理啊. 根据里面的方法名称, 发现一个比较有趣的函数:

private void showTimeOutDialog() {
    if (isMainActivityTop(GiftActivity.class)) {
        reflashGiftActivity("1", null);
    }
    if (!isFinishing()) {
        this.mLiveTimeOutDialog = new LiveTimeOutDialog(this, 2131493319);
        this.mLiveTimeOutDialog.show();
        this.mLiveTimeOutDialog.setGold(this.mPlayBackBean.getLiveRoom().getPayMoney());
        this.mLiveTimeOutDialog.setTitle("replay");
        this.mLiveTimeOutDialog.setCancelable(false);
        this.mLiveTimeOutDialog.setBuyOnClick(new 12(this));
        this.mLiveTimeOutDialog.setNoBuyOnClick(new 13(this));
    }
}

直接把这个dialog禁掉试试. 测试可以用一些hook框架如xposed或者frida, 这里选择后者, 因为可能会需要做native的分析(有没有发现这个Activity的onCreate函数是native的?). frida更新速度飞快, 而且很多用法和特性都没有写到文档里, 多看看别人写的脚本也许会有很多灵感.

劫持函数是常规操作了:

const PlayBackActivity = Java.use("com.zhuoyigou.dese.ui.live.activity.PlayBackActivity");
PlayBackActivity.showTimeOutDialog.implementation = function() {
    log("skip showTimeOutDialog()");
}

重新附加进程, 打开直播间, 发现确实不弹窗了, 但是过十几秒后视频窗口仍然会自己返回. 了解安卓开发的应该都知道, Activity返回一般是调用finish函数, 不过搜了一圈发现调用的地方太多了, 懒癌发作不想一个个检查, 于是祭出frida大法, 在finish函数中查看堆栈:

[+] skip showTimeOutDialog()
[+] skip finish()
[+] java.lang.Exception: printStackTrace here:
	at android.app.Activity.finish(Native Method)
	at com.zhuoyigou.dese.ui.live.activity.PlayBackActivity$11.handleMessage(PlayBackActivity.java:561)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loop(Looper.java:148)
	at android.app.ActivityThread.main(ActivityThread.java:5539)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
	at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:107)

根据finish的堆栈查看com.zhuoyigou.dese.ui.live.activity.PlayBackActivity$11类中的handleMessage函数来进行验证, 确实是有这个逻辑:

void handleMessage(Message msg) {
    switch(msg.what) {
        // ...
        case 1002:
            this.this$0.mPointProgressBar.setVisibility(8);
            PlayBackActivity.access$1400(this.this$0).onPause();
            if (PlayBackActivity.access$400(this.this$0)) {
                PlayBackActivity.access$1500(this.this$0);
            } else {
                PlayBackActivity.access$1600(this.this$0);
            }
            PlayBackActivity.access$600(this.this$0).sendEmptyMessageDelayed(AidConstants.EVENT_NETWORK_ERROR, 11000);
            return;
        case AidConstants.EVENT_NETWORK_ERROR /*1003*/:
            if (PlayBackActivity.access$400(this.this$0) && PlayBackActivity.access$900(this.this$0).isShowing()) {
                PlayBackActivity.access$900(this.this$0).dismiss();
            }
            this.this$0.finish();
            return;
        // ...
    }
}

在11秒后触发事件, 直接退出窗口. 在8秒的试看后还给你3秒选择是否购买哦:) 作为验证, 我们直接对finish函数下手, 发现禁用dialog的同时禁用finish函数, 就可以绕过金币购买的限制了, 想看多久看多久.

虽然现在可以无限制看片, 但正事还是要做的. 下一步看看是哪家对象存储提供了服务, 说不定还能找到硬编码的key. 在代码中瞎逛, 又(?)发现一个有趣的函数:

private void initPlay(String videoUrl, PlayBackBean playBackBean) {
    MyLogger.jLog().e("reVideoUrl:" + videoUrl);
    this.mVideoUrl = videoUrl;
    if (TextUtils.isEmpty(videoUrl)) {
        showError(getString(R.string.video_invalid));
        return;
    }
    if (this.mPLVideoTextureView == null) {
        this.mPLVideoTextureView = (PLVideoTextureView) findViewById(2131362384);
    }
    AVOptions options = new AVOptions();
    options.setInteger("timeout", StatusCodes.AUTH_DISABLED);
    options.setInteger("fast-open", 1);
    options.setInteger("mediacodec", 0);
    PLVideoTextureView pLVideoTextureView = this.mPLVideoTextureView;
    PLVideoTextureView pLVideoTextureView2 = this.mPLVideoTextureView;
    pLVideoTextureView.setDisplayAspectRatio(2);
    this.mPLVideoTextureView.setAVOptions(options);
    this.mCustomController = new CustomController(this);
    this.mPLVideoTextureView.setMediaController(this.mCustomController);
    this.mPLVideoTextureView.setVideoPath(videoUrl);
    this.mPLVideoTextureView.start();
    this.mPLVideoTextureView.setOnInfoListener(new 4(this, playBackBean));
    this.mPLVideoTextureView.setOnCompletionListener(new 5(this));
    this.mPLVideoTextureView.setOnErrorListener(new 6(this));
}

videoUrl? 劫持该函数并打印出来, url地址如下(已打码):

http://qiniuvod.xxxxx.com/recordings/z1.xxxxx.qn1546622961492A/0_1546635114.mp4?sign=b6c6587f1794a14c250e143f28e07620&t=5c303623

这个链接使用wget竟然可以直接下载, 下载结果就是mp4视频文件, 也就是播放的回放视频. 除了mp4还有m3u8格式的链接. m3u8链接可以直接用ffmpeg下载:

ffmpeg -i http://xxx.com/vid.m3u8 -c copy vid.mp4

言归正传, 从这里的url地址看到了熟悉的qiniu, 莫非是七牛云? 查看代码发现确实是用了七牛的安卓SDK. 一年前正好写了个七牛云的对象存储管理命令行工具qncli, 所以对七牛云还是有了解的. 七牛云本身有key和secret, 但是是使用token来对bucket进行访问. 对于客户端而言, 建议的安全做法也是使用服务器下发token的方式来操作.

通过查看代码, 发现该url也确实是服务端下发的. 一般来说, 七牛云的私有bucket会通过对超时与资源一起签名来控制对内容的访问, 格式为:

http://qiniu.example.com/resource.txt?e=1546686297&token=xxx

不知为何上述链接的格式却不是传统私有链接, 也许是其他产品也说不定, 有了解的朋友也可以留言同步一下.

除了云存储, 该直播软件与很多小众直播一样, 使用了三方直播SDK减少开发量, 如某拍SDK. 同时集成了多家厂商的地址定位, 猜测是为了做LBS社交, 而主页中出现的“同城”banner也部分印证了我们的想法. 至于同城见面是做什么, 那就自己想象吧.

该APP同时也做了分享赚金币的功能, 使用ShareSDK, 支持QQ、微信、微博、豆瓣等知名社交网站, 这也解释了为什么明明这个低调得都不进入百度收录的APP, 却拥有不少的用户量. 上面也说过, 不论直播还是回放, 都是需要金币付费访问的. 而里面还可以发布非直播的视频, 有偿提供下载, 俨然成长为了一个小视频交易社区.

根据平台提供的统计数据, 充值用户的“土豪榜”如下:

user

另外通过技术手段, 发现该APP的注册用户数在25万左右, 虽然量不多, 但都是实打实的付费用户啊! 按照金币的平均价格以及用户的付费情况估算, 排除部分托儿刷榜, 保守估计该平台在18年收入也是千万级. 这还只是单个APP明面上的数据, 实际上一个公司背后往往关联数十个平台, 拔出萝卜带出泥. 由于该平台本身并没有做什么伤天害理的事情, 就点到为止吧.

小结

本文出于无聊以及猎奇的心理, 加上手痒, 就跟这个灰色直播软件玩了半天. 顺便记录了一下Android逆向的一些常用操作, 有些技术写出来确实印象深刻一点. 俗话说, 猎人要随时保持自己的技能锋利, 这对于安全研究人员也是一样的. 安全技术也是日新月异, 闲时也要把握好各种实战机会.

后记

在使用该直播软件的过程中, 惊讶地发现里面有很部分用户竟还是在校学生, 包括用户和主播. 通过某种手段添加其中一个主播聊天得知, SM行业“水很深”, 除了直播间收礼物外, 主播一般还会将高质量用户引流到其他社交平台(刷“飞机”加微信). 然后私底下会视情况进行现实调教. 用该主播的话说, ”一天2个或者3个, 元旦那天最多, 一天有8个”, 这每一“个”的收费自然也是不低的, 内容大概有XX、XX和XX, 重口味一点的有XX、XX等…

对于该“圈子”的是非且不去谈, 这个公司游走在法律边缘, 还致未成年人的身心健康于无物, 老子动画片(进击的巨人)都看不了, 这种直播竟没有相关部门管束? 对于成年的观众, 大家都有辨别是非的能力, 就不多说了吧. 至于主播, 很多人就是作为工作或者兼职, 赚的也是辛苦钱, 也不多说了吧. 毕竟, 言多必失, 你懂的.

]]> IOLI-crackme0x06-0x09 writeup https://evilpan.com/2018/03/10/ioli-crackme6-9/ Sat, 10 Mar 2018 22:40:00 +0800 evilpan https://evilpan.com/2018/03/10/ioli-crackme6-9/

前几天写了使用Radare2并用3中方法来解决crackme0x00, 然后紧接着第二天 就写了另外5个writeup, 如果认真看会发现那几个crackme的分析也是一开始 走了很多弯路, 但玩多了也就熟悉了. 趁热打铁, 把最后几关也过一过.

本文所使用的crackmes都来自IOLI-crackme.

crackme0x06

虽然隔了几天, 但r2打开反汇编时还是发现结构和crackme0x05差不多, 先看main函数:

[0x08048607]> pdf @ sym.main
            ;-- main:
/ (fcn) sym.main 99
|   sym.main (int arg_10h);
|           ; var int local_78h @ ebp-0x78
|           ; arg int arg_10h @ ebp+0x10
|           ; var int local_4h @ esp+0x4
|              ; DATA XREF from 0x08048417 (entry0)
|           0x08048607      55             push ebp
|           0x08048608      89e5           mov ebp, esp
|           0x0804860a      81ec88000000   sub esp, 0x88
|           0x08048610      83e4f0         and esp, 0xfffffff0
|           0x08048613      b800000000     mov eax, 0
|           0x08048618      83c00f         add eax, 0xf
|           0x0804861b      83c00f         add eax, 0xf
|           0x0804861e      c1e804         shr eax, 4
|           0x08048621      c1e004         shl eax, 4
|           0x08048624      29c4           sub esp, eax
|           0x08048626      c70424638704.  mov dword [esp], str.IOLI_Crackme_Level_0x06 ; [0x8048763:4]=0x494c4f49 ; "IOLI Crackme Level 0x06\n"
|           0x0804862d      e886fdffff     call sym.imp.printf         ; int printf(const char *format)
|           0x08048632      c704247c8704.  mov dword [esp], str.Password: ; [0x804877c:4]=0x73736150 ; "Password: "
|           0x08048639      e87afdffff     call sym.imp.printf         ; int printf(const char *format)
|           0x0804863e      8d4588         lea eax, [local_78h]
|           0x08048641      89442404       mov dword [local_4h], eax
|           0x08048645      c70424878704.  mov dword [esp], 0x8048787  ; [0x8048787:4]=0x7325
|           0x0804864c      e847fdffff     call sym.imp.scanf          ; int scanf(const char *format)
|           0x08048651      8b4510         mov eax, dword [arg_10h]    ; [0x10:4]=-1 ; 16
|           0x08048654      89442404       mov dword [local_4h], eax
|           0x08048658      8d4588         lea eax, [local_78h]
|           0x0804865b      890424         mov dword [esp], eax
|           0x0804865e      e825ffffff     call sym.check
|           0x08048663      b800000000     mov eax, 0
|           0x08048668      c9             leave
\           0x08048669      c3             ret
:> ps @ 0x8048787
%s

local_4h还是scanf输入的用户密码, 但这里值得一提的是arg_10h这个地址(ebp+0x10), 我们知道main函数接受2个参数int main(int argc, char *argv[]), 其中argc对应ebp+8, argv对于ebp+12, 而返回地址在ebp+4, 那么ebp+16又是啥? 第三个参数? 其实这是GCC编译器的一个 特性, 第三个参数envp也是一个字符串指针, 表示的是环境变量的值, 所以这里main函数相当于 int main(int argc, char *argv[], char *envp[]), 只不过前两个参数并未用到.

接下来分析check函数. 对于流程比较复杂的程序, 我们可以在视图模式中按p键切换到极简试图, 然后按TAB,Shift+TAB键切换不同的代码块(Basic Block), 如下所示:

r2-view

check接受两个参数, 第一个为输入字符串, 第二个为字符串指针. 伪代码如下:

void check(char *input, char *envp[]) {
    int i;
    char local_dh[2];
    int local_8h = 0;
    for(i = 0; i < strlen(input); i++) {
        local_dh[0] = input[i];
        local_dh[1] = 0;
        sscanf(local_dh, "%d", local_4h);
        local_8h += local_4h;
        if (local_8h == 0x10) {
            parell(input, envp);
        }
    }
    printf("Password Incorrect!\n");
    return;
}

根据循环的跳转情况可知ebp-0xc为循环变量, 因此重命名为i, 其他尚未知具体作用的变量保留. 该函数的作用是将输入的每一字节都转成数字并累加, 当累加和为0x10时调用parell:

[0x08048588]> pdf @ sym.parell 
/ (fcn) sym.parell 110
|   sym.parell (int arg_8h, int arg_ch);
|           ; var int local_8h_2 @ ebp-0x8
|           ; var int local_4h @ ebp-0x4
|           ; arg int arg_8h @ ebp+0x8
|           ; arg int arg_ch @ ebp+0xc
|           ; var int local_4h_2 @ esp+0x4
|           ; var int local_8h @ esp+0x8
|              ; CALL XREF from 0x080485ed (sym.check)
|           0x0804851a      55             push ebp
|           0x0804851b      89e5           mov ebp, esp
|           0x0804851d      83ec18         sub esp, 0x18
|           0x08048520      8d45fc         lea eax, [local_4h]
|           0x08048523      89442408       mov dword [local_8h], eax
|           0x08048527      c74424043d87.  mov dword [local_4h_2], 0x804873d ; [0x804873d:4]=0x50006425
|           0x0804852f      8b4508         mov eax, dword [arg_8h]     ; [0x8:4]=-1 ; 8
|           0x08048532      890424         mov dword [esp], eax
|           0x08048535      e88efeffff     call sym.imp.sscanf         ; int sscanf(const char *s, const char *format,   ...)
|           0x0804853a      8b450c         mov eax, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|           0x0804853d      89442404       mov dword [local_4h_2], eax
|           0x08048541      8b45fc         mov eax, dword [local_4h]
|           0x08048544      890424         mov dword [esp], eax
|           0x08048547      e868ffffff     call sym.dummy
|           0x0804854c      85c0           test eax, eax
|       ,=< 0x0804854e      7436           je 0x8048586
|       |   0x08048550      c745f8000000.  mov dword [local_8h_2], 0
|       |      ; JMP XREF from 0x08048584 (sym.parell)
|      .--> 0x08048557      837df809       cmp dword [local_8h_2], 9   ; [0x9:4]=-1 ; 9
|     ,===< 0x0804855b      7f29           jg 0x8048586
|     |:|   0x0804855d      8b45fc         mov eax, dword [local_4h]
|     |:|   0x08048560      83e001         and eax, 1
|     |:|   0x08048563      85c0           test eax, eax
|    ,====< 0x08048565      7518           jne 0x804857f
|    ||:|   0x08048567      c70424408704.  mov dword [esp], str.Password_OK ; [0x8048740:4]=0x73736150 ; "Password OK!\n"
|    ||:|   0x0804856e      e845feffff     call sym.imp.printf         ; int printf(const char *format)
|    ||:|   0x08048573      c70424000000.  mov dword [esp], 0
|    ||:|   0x0804857a      e869feffff     call sym.imp.exit           ; void exit(int status)
|    `----> 0x0804857f      8d45f8         lea eax, [local_8h_2]
|     |:|   0x08048582      ff00           inc dword [eax]
|     |`==< 0x08048584      ebd1           jmp 0x8048557
|     `-`-> 0x08048586      c9             leave
\           0x08048587      c3             ret

parell接受2个参数, 伪代码如下:

void parell(char *input, char *envp[]) {
    sscanf(input, "%d", local_4h);
    if (dummy(local_4h, envp) == 0) {
        return;
    }
    for (int i = 0; i <= 9; i++) {
        if (local_4h & 1 == 0) {
            printf("Password OK!\n");
            exit(0);
        }
    }
    return;
}

作用就是判断输入数字的奇偶性, 不过增加了dummy函数返回不为0的限制. 而且这里的循环居然是个障眼法= =.

好吧, 再看看dummy函数:

[0x08048607]> pdf @ sym.dummy
/ (fcn) sym.dummy 102
|   sym.dummy (int arg_ch);
|           ; var int local_8h_2 @ ebp-0x8
|           ; var int local_4h @ ebp-0x4
|           ; arg int arg_ch @ ebp+0xc
|              ; CALL XREF from 0x08048547 (sym.parell)
|           0x080484b4      55             push ebp
|           0x080484b5      89e5           mov ebp, esp
|           0x080484b7      83ec18         sub esp, 0x18
|           0x080484ba      c745fc000000.  mov dword [local_4h], 0
|       .-> 0x080484c1      8b45fc         mov eax, dword [local_4h]
|       :   0x080484c4      8d1485000000.  lea edx, [eax*4]
|       :   0x080484cb      8b450c         mov eax, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|       :   0x080484ce      833c0200       cmp dword [edx + eax], 0
|      ,==< 0x080484d2      743a           je 0x804850e
|      |:   0x080484d4      8b45fc         mov eax, dword [local_4h]
|      |:   0x080484d7      8d0c85000000.  lea ecx, [eax*4]
|      |:   0x080484de      8b550c         mov edx, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|      |:   0x080484e1      8d45fc         lea eax, [local_4h]
|      |:   0x080484e4      ff00           inc dword [eax]
|      |:   0x080484e6      c74424080300.  mov dword [esp + 8], 3
|      |:   0x080484ee      c74424043887.  mov dword [esp + 4], str.LOLO ; [0x8048738:4]=0x4f4c4f4c ; "LOLO"
|      |:   0x080484f6      8b0411         mov eax, dword [ecx + edx]
|      |:   0x080484f9      890424         mov dword [esp], eax
|      |:   0x080484fc      e8d7feffff     call sym.imp.strncmp        ; int strncmp(const char *s1, const char *s2, size_t n)
|      |:   0x08048501      85c0           test eax, eax
|      |`=< 0x08048503      75bc           jne 0x80484c1
|      |    0x08048505      c745f8010000.  mov dword [local_8h_2], 1
|      |,=< 0x0804850c      eb07           jmp 0x8048515
|      `--> 0x0804850e      c745f8000000.  mov dword [local_8h_2], 0
|       |      ; JMP XREF from 0x0804850c (sym.dummy)
|       `-> 0x08048515      8b45f8         mov eax, dword [local_8h_2]
|           0x08048518      c9             leave
\           0x08048519      c3             ret

从汇编可以发现, dummy函数虽然传入了2个参数, 但只用到了第二个, 先写个粗略的伪代码:

int dummy(char *input, char *envp[]) {
    local_4h = 0;
    while(1) {
        if (envp[local_4h] == 0) {
            return 0;
        }
        char *s = envp[local_4h];
        local_4h++;
        if (strncmp(s, "LOLO", 3) != 0) {
            continue;
        } else {
            return 1;
        }
    }
}

作用就很明显了, 判断输入的环境变量前3字节是否为LOL, 若是则返回1. 所以我们只需要 传入环境变量, 并且输入一个前X为和为0x10的偶数即可:

$ env LOL=1 ./crackme0x06
IOLI Crackme Level 0x06
Password: 886
Password OK!

crackme0x07

先看主函数:

[0x0804867d]> pdf @ main
/ (fcn) main 99
|   main (int arg_10h);
|           ; var int local_78h @ ebp-0x78
|           ; arg int arg_10h @ ebp+0x10
|           ; var int local_4h @ esp+0x4
|              ; DATA XREF from 0x08048417 (entry0)
|           0x0804867d      55             push ebp
|           0x0804867e      89e5           mov ebp, esp
|           0x08048680      81ec88000000   sub esp, 0x88
|           0x08048686      83e4f0         and esp, 0xfffffff0
|           0x08048689      b800000000     mov eax, 0
|           0x0804868e      83c00f         add eax, 0xf
|           0x08048691      83c00f         add eax, 0xf
|           0x08048694      c1e804         shr eax, 4
|           0x08048697      c1e004         shl eax, 4
|           0x0804869a      29c4           sub esp, eax
|           0x0804869c      c70424d98704.  mov dword [esp], str.IOLI_Crackme_Level_0x07 ; [0x80487d9:4]=0x494c4f49 ; "IOLI Crackme Level 0x07\n"
|           0x080486a3      e810fdffff     call sym.imp.printf         ; int printf(const char *format)
|           0x080486a8      c70424f28704.  mov dword [esp], str.Password: ; [0x80487f2:4]=0x73736150 ; "Password: "
|           0x080486af      e804fdffff     call sym.imp.printf         ; int printf(const char *format)
|           0x080486b4      8d4588         lea eax, [local_78h]
|           0x080486b7      89442404       mov dword [local_4h], eax
|           0x080486bb      c70424fd8704.  mov dword [esp], 0x80487fd  ; [0x80487fd:4]=0x7325
|           0x080486c2      e8d1fcffff     call sym.imp.scanf          ; int scanf(const char *format)
|           0x080486c7      8b4510         mov eax, dword [arg_10h]    ; [0x10:4]=-1 ; 16
|           0x080486ca      89442404       mov dword [local_4h], eax
|           0x080486ce      8d4588         lea eax, [local_78h]
|           0x080486d1      890424         mov dword [esp], eax
|           0x080486d4      e8e0feffff     call fcn.080485b9
|           0x080486d9      b800000000     mov eax, 0
|           0x080486de      c9             leave
\           0x080486df      c3             ret
[0x0804867d]> ps @ 0x80487fd
%s

大意就是用户输入密码,然后调用fcn.080485b9函数,其中第一个参数为输入字符串,第二个参数为arg_10h, 即上节说过的envp. 再看看fcn.080485b9这个函数:

[0x080485b9]> pdf @ fcn.080485b9
/ (fcn) fcn.080485b9 196
|   fcn.080485b9 (int arg_8h, int arg_ch);
|           ; var int local_dh @ ebp-0xd
|           ; var int local_ch @ ebp-0xc
|           ; var int local_8h @ ebp-0x8
|           ; var int local_4h @ ebp-0x4
|           ; arg int arg_8h @ ebp+0x8
|           ; arg int arg_ch @ ebp+0xc
|           ; var int local_4h_2 @ esp+0x4
|           ; var int local_8h_2 @ esp+0x8
|              ; CALL XREF from 0x080486d4 (main)
|           0x080485b9      55             push ebp
|           0x080485ba      89e5           mov ebp, esp
|           0x080485bc      83ec28         sub esp, 0x28               ; '('
|           0x080485bf      c745f8000000.  mov dword [local_8h], 0
|           0x080485c6      c745f4000000.  mov dword [local_ch], 0
|              ; JMP XREF from 0x08048628 (fcn.080485b9)
|       .-> 0x080485cd      8b4508         mov eax, dword [arg_8h]     ; [0x8:4]=-1 ; 8
|       :   0x080485d0      890424         mov dword [esp], eax
|       :   0x080485d3      e8d0fdffff     call sym.imp.strlen         ; size_t strlen(const char *s)
|       :   0x080485d8      3945f4         cmp dword [local_ch], eax   ; [0x13:4]=-1 ; 19
|      ,==< 0x080485db      734d           jae 0x804862a
|      |:   0x080485dd      8b45f4         mov eax, dword [local_ch]
|      |:   0x080485e0      034508         add eax, dword [arg_8h]
|      |:   0x080485e3      0fb600         movzx eax, byte [eax]
|      |:   0x080485e6      8845f3         mov byte [local_dh], al
|      |:   0x080485e9      8d45fc         lea eax, [local_4h]
|      |:   0x080485ec      89442408       mov dword [local_8h_2], eax
|      |:   0x080485f0      c7442404c287.  mov dword [local_4h_2], 0x80487c2 ; [0x80487c2:4]=0x50006425
|      |:   0x080485f8      8d45f3         lea eax, [local_dh]
|      |:   0x080485fb      890424         mov dword [esp], eax
|      |:   0x080485fe      e8c5fdffff     call sym.imp.sscanf         ; int sscanf(const char *s, const char *format,   ...)
|      |:   0x08048603      8b55fc         mov edx, dword [local_4h]
|      |:   0x08048606      8d45f8         lea eax, [local_8h]
|      |:   0x08048609      0110           add dword [eax], edx
|      |:   0x0804860b      837df810       cmp dword [local_8h], 0x10  ; [0x10:4]=-1 ; 16
|     ,===< 0x0804860f      7512           jne 0x8048623
|     ||:   0x08048611      8b450c         mov eax, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|     ||:   0x08048614      89442404       mov dword [local_4h_2], eax
|     ||:   0x08048618      8b4508         mov eax, dword [arg_8h]     ; [0x8:4]=-1 ; 8
|     ||:   0x0804861b      890424         mov dword [esp], eax
|     ||:   0x0804861e      e81fffffff     call 0x8048542
|     `---> 0x08048623      8d45f4         lea eax, [local_ch]
|      |:   0x08048626      ff00           inc dword [eax]
|      |`=< 0x08048628      eba3           jmp 0x80485cd
|      `--> 0x0804862a      e8f5feffff     call 0x8048524
|           0x0804862f      8b450c         mov eax, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|           0x08048632      89442404       mov dword [local_4h_2], eax
|           0x08048636      8b45fc         mov eax, dword [local_4h]
|           0x08048639      890424         mov dword [esp], eax
|           0x0804863c      e873feffff     call 0x80484b4
|           0x08048641      85c0           test eax, eax
|       ,=< 0x08048643      7436           je 0x804867b
|       |   0x08048645      c745f4000000.  mov dword [local_ch], 0
|       |      ; JMP XREF from 0x08048679 (fcn.080485b9)
|      .--> 0x0804864c      837df409       cmp dword [local_ch], 9     ; [0x9:4]=-1 ; 9
|     ,===< 0x08048650      7f29           jg 0x804867b
|     |:|   0x08048652      8b45fc         mov eax, dword [local_4h]
|     |:|   0x08048655      83e001         and eax, 1
|     |:|   0x08048658      85c0           test eax, eax
|    ,====< 0x0804865a      7518           jne 0x8048674
|    ||:|   0x0804865c      c70424d38704.  mov dword [esp], str.wtf    ; [0x80487d3:4]=0x3f667477 ; "wtf?\n"
|    ||:|   0x08048663      e850fdffff     call sym.imp.printf         ; int printf(const char *format)
|    ||:|   0x08048668      c70424000000.  mov dword [esp], 0
|    ||:|   0x0804866f      e874fdffff     call sym.imp.exit           ; void exit(int status)
|    `----> 0x08048674      8d45f4         lea eax, [local_ch]
|     |:|   0x08048677      ff00           inc dword [eax]
|     |`==< 0x08048679      ebd1           jmp 0x804864c
|     `-`-> 0x0804867b      c9             leave
\           0x0804867c      c3             ret

有点小长,可以用视图模式去看有个比较直观的印象,这个函数也没个名字,就还是称之为check吧, 重命名一下函数:

[0x080485b9]> afn check fcn.080485b9

写个粗糙的伪代码:

void check(char *input, char *envp[]) {
    int i,j = 0;
    while(1) {
        if (i >= strlen(input)) {
            fcn.08048524();
        }
        local_dh = input[i];
        sscanf(local_dh, "%d", &local_4h);
        j += local_4h;
        if (j == 0x10) {
            fcn.8048542(input ,envp);
        }
        i++;
        continue;
    }
}

有几个无名的函数, 先看fcn.08048524:

[0x08048542]> pdf @ 0x08048524
/ (fcn) fail 30
|   fail (int arg_8h);
|           ; var int local_ch @ ebp-0xc
|           ; var int local_8h @ ebp-0x8
|           ; arg int arg_8h @ ebp+0x8
|              ; CALL XREF from 0x0804862a (check)
|           0x08048524      55             push ebp
|           0x08048525      89e5           mov ebp, esp
|           0x08048527      83ec08         sub esp, 8
|           0x0804852a      c70424ad8704.  mov dword [esp], str.Password_Incorrect ; [0x80487ad:4]=0x73736150 ; "Password Incorrect!\n"
|           0x08048531      e882feffff     call sym.imp.printf         ; int printf(const char *format)
|           0x08048536      c70424000000.  mov dword [esp], 0
\           0x0804853d      e8a6feffff     call sym.imp.exit           ; void exit(int status)

作用是打印密码出错信息然后退出, 所以我们将其重命名为fail了. 其实fail函数之后还有很多逻辑, 但我们都可以不用分析, 因为那部分逻辑是不会进入的. 再看函数fcn.8048542:

[0x08048542]> pdf @ 0x8048542
/ (fcn) fcn.08048542 119
|   fcn.08048542 (int arg_8h, int arg_9h, int arg_ch);
|           ; var int local_dh @ ebp-0xd
|           ; var int local_ch @ ebp-0xc
|           ; var int local_8h @ ebp-0x8
|           ; var int local_4h @ ebp-0x4
|           ; arg int arg_8h @ ebp+0x8
|           ; arg int arg_9h @ ebp+0x9
|           ; arg int arg_ch @ ebp+0xc
|           ; var int local_4h_2 @ esp+0x4
|           ; var int local_8h_2 @ esp+0x8
|              ; CALL XREF from 0x0804861e (check)
|           0x08048542      55             push ebp
|           0x08048543      89e5           mov ebp, esp
|           0x08048545      83ec18         sub esp, 0x18
|           0x08048548      8d45fc         lea eax, [local_4h]
|           0x0804854b      89442408       mov dword [local_8h_2], eax
|           0x0804854f      c7442404c287.  mov dword [local_4h_2], 0x80487c2 ; [0x80487c2:4]=0x50006425
|           0x08048557      8b4508         mov eax, dword [arg_8h]     ; [0x8:4]=-1 ; 8
|           0x0804855a      890424         mov dword [esp], eax
|           0x0804855d      e866feffff     call sym.imp.sscanf         ; int sscanf(const char *s, const char *format,   ...)
|           0x08048562      8b450c         mov eax, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|           0x08048565      89442404       mov dword [local_4h_2], eax
|           0x08048569      8b45fc         mov eax, dword [local_4h]
|           0x0804856c      890424         mov dword [esp], eax
|           0x0804856f      e840ffffff     call fcn.080484b4
|           0x08048574      85c0           test eax, eax
|       ,=< 0x08048576      743f           je 0x80485b7
|       |   0x08048578      c745f8000000.  mov dword [local_8h], 0
|       |      ; JMP XREF from 0x080485b5 (fcn.08048542)
|      .--> 0x0804857f      837df809       cmp dword [local_8h], 9     ; [0x9:4]=-1 ; 9
|     ,===< 0x08048583      7f32           jg 0x80485b7
|     |:|   0x08048585      8b45fc         mov eax, dword [local_4h]
|     |:|   0x08048588      83e001         and eax, 1
|     |:|   0x0804858b      85c0           test eax, eax
|    ,====< 0x0804858d      7521           jne 0x80485b0
|    ||:|   0x0804858f      833d2ca00408.  cmp dword [0x804a02c], 1    ; [0x1:4]=-1 ; 1
|   ,=====< 0x08048596      750c           jne 0x80485a4
|   |||:|   0x08048598      c70424c58704.  mov dword [esp], str.Password_OK ; [0x80487c5:4]=0x73736150 ; "Password OK!\n"
|   |||:|   0x0804859f      e814feffff     call sym.imp.printf         ; int printf(const char *format)
|   `-----> 0x080485a4      c70424000000.  mov dword [esp], 0
|    ||:|   0x080485ab      e838feffff     call sym.imp.exit           ; void exit(int status)
|    `----> 0x080485b0      8d45f8         lea eax, [local_8h]
|     |:|   0x080485b3      ff00           inc dword [eax]
|     |`==< 0x080485b5      ebc8           jmp 0x804857f
|     `-`-> 0x080485b7      c9             leave
\           0x080485b8      c3             ret

看来是做进一步的校验, 姑且命名为double_check吧, 不知道是不是r2的bug, 居然显示这个函数有3个参数, 但我们前面知道其实它只有两个, 所以不管什么原因, 先把arg_9h去掉再说, 然后两个参数改个像样的名字:

[0x08048542]> afv-arg_9h
[0x08048542]> afvn arg_8h input
[0x08048542]> afvn arg_ch envp

again, 写一下它的伪代码:

void double_check(char *input, char *envp[])
{
    int local_4h;
    int i;
    sscanf(input, "%d", &local_4h);
    if (0 == fcn.080484b4(local_4h, envp)) {
        return;
    }
    for (i = 0; i <= 9; i++) {
        if(local_4h & 1 != 0) {
            continue;
        }
        if ((int)*0x804a02c == 1) {
            printf("Password OK!\n");
        }
        exit(0);
    }
}

由代码可以得知要想进入正确分支, 必须要满足函数fcn.080484b4返回不为0, 而且输入的数字要是个偶数. 有意思的是还要额外判断一个硬编码的地址(0x804a02c) 里的值是否为1, 若为1才打印密码正确. dump这个地址出来看看:

:> px @ 0x804a02c
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x0804a02c  0000 0000 ffff ffff ffff ffff ffff ffff  ................
0x0804a03c  ffff ffff ffff ffff ffff ffff ffff ffff  ................

发现其默认值是0, 所以必然是运行时修改了这个地址, 那么在哪儿呢? 猜测是fcn.080484b4 这函数, 因为只有它没被分析过了, 当然r2也提供了查看引用的功能:

:> axt @ 0x804a02c 
fcn.080484b4 0x8048505 [data] mov dword [0x804a02c], 1

果然是你, 那就来看看这个检查环境变量和输入的函数吧:

[0x0804851f]> pdf @ fcn.080484b4
/ (fcn) fcn.080484b4 112
|   fcn.080484b4 (int arg_ch);
|           ; var int local_8h @ ebp-0x8
|           ; var int local_4h @ ebp-0x4
|           ; arg int arg_ch @ ebp+0xc
|              ; CALL XREF from 0x0804863c (check)
|              ; CALL XREF from 0x0804856f (double_check)
|           0x080484b4      55             push ebp
|           0x080484b5      89e5           mov ebp, esp
|           0x080484b7      83ec18         sub esp, 0x18
|           0x080484ba      c745fc000000.  mov dword [local_4h], 0
|       .-> 0x080484c1      8b45fc         mov eax, dword [local_4h]
|       :   0x080484c4      8d1485000000.  lea edx, [eax*4]
|       :   0x080484cb      8b450c         mov eax, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|       :   0x080484ce      833c0200       cmp dword [edx + eax], 0
|      ,==< 0x080484d2      7444           je 0x8048518
|      |:   0x080484d4      8b45fc         mov eax, dword [local_4h]
|      |:   0x080484d7      8d0c85000000.  lea ecx, [eax*4]
|      |:   0x080484de      8b550c         mov edx, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|      |:   0x080484e1      8d45fc         lea eax, [local_4h]
|      |:   0x080484e4      ff00           inc dword [eax]
|      |:   0x080484e6      c74424080300.  mov dword [esp + 8], 3
|      |:   0x080484ee      c7442404a887.  mov dword [esp + 4], str.LOLO ; [0x80487a8:4]=0x4f4c4f4c ; "LOLO"
|      |:   0x080484f6      8b0411         mov eax, dword [ecx + edx]
|      |:   0x080484f9      890424         mov dword [esp], eax
|      |:   0x080484fc      e8d7feffff     call sym.imp.strncmp        ; int strncmp(const char *s1, const char *s2, size_t n)
|      |:   0x08048501      85c0           test eax, eax
|      |`=< 0x08048503      75bc           jne 0x80484c1
|      |    0x08048505      c7052ca00408.  mov dword [0x804a02c], 1    ; [0x804a02c:4]=0
|      |    0x0804850f      c745f8010000.  mov dword [local_8h], 1
|      |,=< 0x08048516      eb07           jmp 0x804851f
|      `--> 0x08048518      c745f8000000.  mov dword [local_8h], 0
|       |      ; JMP XREF from 0x08048516 (fcn.080484b4)
|       `-> 0x0804851f      8b45f8         mov eax, dword [local_8h]
|           0x08048522      c9             leave
\           0x08048523      c3             ret

虽然调用时传了两个参数, 但实际上只用到了第二个即环境变量char *envp[]. 伪代码如下:

int check_env(char *input, char *envp[]) {
    int local_4h = 0;
    while(1) {
        if (0 == envp[local_4h * 4]) {
            local_8h = 0;
            break;
        }
        local_4h++;
        if (0 != strncmp(envp[local_4h * 4], "LOLO", 3))
            continue;
        *0x804a02c = 1;
        local_8h = 1;
        break;
    }
    return local_8h;
}

所以结果还是查看环境变量里的key前3位是不是LOL, 然后要求输入是个偶数, 并且前n位相加为16就行了, 所以基本上和上题一样, 只不过加了一大堆障眼法而已罢了. 验证结果:

$ LOL= ./crackme0x07 
IOLI Crackme Level 0x07
Password: 88
Password OK!

$ LOLO=1 ./crackme0x07 
IOLI Crackme Level 0x07
Password: 196110
Password OK!

crackme0x08

还是老样子, 从main开始分析:

[0x08048400]> pdf @ main
            ;-- main:
/ (fcn) sym.main 99
|   sym.main (int arg_10h);
|           ; var int local_78h @ ebp-0x78
|           ; arg int arg_10h @ ebp+0x10
|           ; var int local_4h @ esp+0x4
|              ; DATA XREF from 0x08048417 (entry0)
|           0x0804867d      55             push ebp
|           0x0804867e      89e5           mov ebp, esp
|           0x08048680      81ec88000000   sub esp, 0x88
|           0x08048686      83e4f0         and esp, 0xfffffff0
|           0x08048689      b800000000     mov eax, 0
|           0x0804868e      83c00f         add eax, 0xf
|           0x08048691      83c00f         add eax, 0xf
|           0x08048694      c1e804         shr eax, 4
|           0x08048697      c1e004         shl eax, 4
|           0x0804869a      29c4           sub esp, eax
|           0x0804869c      c70424d98704.  mov dword [esp], str.IOLI_Crackme_Level_0x08 ; [0x80487d9:4]=0x494c4f49 ; "IOLI Crackme Level 0x08\n"
|           0x080486a3      e810fdffff     call sym.imp.printf         ; int printf(const char *format)
|           0x080486a8      c70424f28704.  mov dword [esp], str.Password: ; [0x80487f2:4]=0x73736150 ; "Password: "
|           0x080486af      e804fdffff     call sym.imp.printf         ; int printf(const char *format)
|           0x080486b4      8d4588         lea eax, [local_78h]
|           0x080486b7      89442404       mov dword [local_4h], eax
|           0x080486bb      c70424fd8704.  mov dword [esp], 0x80487fd  ; [0x80487fd:4]=0x7325
|           0x080486c2      e8d1fcffff     call sym.imp.scanf          ; int scanf(const char *format)
|           0x080486c7      8b4510         mov eax, dword [arg_10h]    ; [0x10:4]=-1 ; 16
|           0x080486ca      89442404       mov dword [local_4h], eax
|           0x080486ce      8d4588         lea eax, [local_78h]
|           0x080486d1      890424         mov dword [esp], eax
|           0x080486d4      e8e0feffff     call sym.check
|           0x080486d9      b800000000     mov eax, 0
|           0x080486de      c9             leave
\           0x080486df      c3             ret

似曾相识? 再看看sym.check:

[0x08048400]> pdf @ sym.check
/ (fcn) sym.check 196
|   sym.check (int arg_8h, int arg_ch);
|           ; var int local_dh @ ebp-0xd
|           ; var int local_ch @ ebp-0xc
|           ; var int local_8h @ ebp-0x8
|           ; var int local_4h @ ebp-0x4
|           ; arg int arg_8h @ ebp+0x8
|           ; arg int arg_ch @ ebp+0xc
|           ; var int local_4h_2 @ esp+0x4
|           ; var int local_8h_2 @ esp+0x8
|              ; CALL XREF from 0x080486d4 (sym.main)
|           0x080485b9      55             push ebp
|           0x080485ba      89e5           mov ebp, esp
|           0x080485bc      83ec28         sub esp, 0x28               ; '('
|           0x080485bf      c745f8000000.  mov dword [local_8h], 0
|           0x080485c6      c745f4000000.  mov dword [local_ch], 0
|              ; JMP XREF from 0x08048628 (sym.check)
|       .-> 0x080485cd      8b4508         mov eax, dword [arg_8h]     ; [0x8:4]=-1 ; 8
|       :   0x080485d0      890424         mov dword [esp], eax
|       :   0x080485d3      e8d0fdffff     call sym.imp.strlen         ; size_t strlen(const char *s)
|       :   0x080485d8      3945f4         cmp dword [local_ch], eax   ; [0x13:4]=-1 ; 19
|      ,==< 0x080485db      734d           jae 0x804862a
|      |:   0x080485dd      8b45f4         mov eax, dword [local_ch]
|      |:   0x080485e0      034508         add eax, dword [arg_8h]
|      |:   0x080485e3      0fb600         movzx eax, byte [eax]
|      |:   0x080485e6      8845f3         mov byte [local_dh], al
|      |:   0x080485e9      8d45fc         lea eax, [local_4h]
|      |:   0x080485ec      89442408       mov dword [local_8h_2], eax
|      |:   0x080485f0      c7442404c287.  mov dword [local_4h_2], 0x80487c2 ; [0x80487c2:4]=0x50006425
|      |:   0x080485f8      8d45f3         lea eax, [local_dh]
|      |:   0x080485fb      890424         mov dword [esp], eax
|      |:   0x080485fe      e8c5fdffff     call sym.imp.sscanf         ; int sscanf(const char *s, const char *format,   ...)
|      |:   0x08048603      8b55fc         mov edx, dword [local_4h]
|      |:   0x08048606      8d45f8         lea eax, [local_8h]
|      |:   0x08048609      0110           add dword [eax], edx
|      |:   0x0804860b      837df810       cmp dword [local_8h], 0x10  ; [0x10:4]=-1 ; 16
|     ,===< 0x0804860f      7512           jne 0x8048623
|     ||:   0x08048611      8b450c         mov eax, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|     ||:   0x08048614      89442404       mov dword [local_4h_2], eax
|     ||:   0x08048618      8b4508         mov eax, dword [arg_8h]     ; [0x8:4]=-1 ; 8
|     ||:   0x0804861b      890424         mov dword [esp], eax
|     ||:   0x0804861e      e81fffffff     call sym.parell
|     ||:      ; JMP XREF from 0x0804860f (sym.check)
|     `---> 0x08048623      8d45f4         lea eax, [local_ch]
|      |:   0x08048626      ff00           inc dword [eax]
|      |`=< 0x08048628      eba3           jmp 0x80485cd
|      |       ; JMP XREF from 0x080485db (sym.check)
|      `--> 0x0804862a      e8f5feffff     call sym.che
|           0x0804862f      8b450c         mov eax, dword [arg_ch]     ; [0xc:4]=-1 ; 12
|           0x08048632      89442404       mov dword [local_4h_2], eax
|           0x08048636      8b45fc         mov eax, dword [local_4h]
|           0x08048639      890424         mov dword [esp], eax
|           0x0804863c      e873feffff     call sym.dummy
|           0x08048641      85c0           test eax, eax
|       ,=< 0x08048643      7436           je 0x804867b
|       |   0x08048645      c745f4000000.  mov dword [local_ch], 0
|       |      ; JMP XREF from 0x08048679 (sym.check)
|      .--> 0x0804864c      837df409       cmp dword [local_ch], 9     ; [0x9:4]=-1 ; 9
|     ,===< 0x08048650      7f29           jg 0x804867b
|     |:|   0x08048652      8b45fc         mov eax, dword [local_4h]
|     |:|   0x08048655      83e001         and eax, 1
|     |:|   0x08048658      85c0           test eax, eax
|    ,====< 0x0804865a      7518           jne 0x8048674
|    ||:|   0x0804865c      c70424d38704.  mov dword [esp], str.wtf    ; [0x80487d3:4]=0x3f667477 ; "wtf?\n"
|    ||:|   0x08048663      e850fdffff     call sym.imp.printf         ; int printf(const char *format)
|    ||:|   0x08048668      c70424000000.  mov dword [esp], 0
|    ||:|   0x0804866f      e874fdffff     call sym.imp.exit           ; void exit(int status)
|    ||:|      ; JMP XREF from 0x0804865a (sym.check)
|    `----> 0x08048674      8d45f4         lea eax, [local_ch]
|     |:|   0x08048677      ff00           inc dword [eax]
|     |`==< 0x08048679      ebd1           jmp 0x804864c
|     | |      ; JMP XREF from 0x08048643 (sym.check)
|     | |      ; JMP XREF from 0x08048650 (sym.check)
|     `-`-> 0x0804867b      c9             leave
\           0x0804867c      c3             ret

还是似层相识. 有了上一题的经历, 这次就不重新分析了, 直接用radiff2来看看和上一题的不同之处:

$ radiff2 -A -C ./crackme0x07 ./crackme0x08 
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze len bytes of instructions for references (aar)
[x] Analyze function calls (aac)
[x] Use -AA or aaaa to perform additional experimental analysis.
[x] Constructing a function name for fcn.* and sym.func.* functions (aan)
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze len bytes of instructions for references (aar)
[x] Analyze function calls (aac)
[x] Use -AA or aaaa to perform additional experimental analysis.
[x] Constructing a function name for fcn.* and sym.func.* functions (aan)
              fcn.08048360  23 0x8048360 |   MATCH  (1.000000) | 0x8048360   23 sym._init
 sym.imp.__libc_start_main   6 0x8048388 |   MATCH  (1.000000) | 0x8048388    6 sym.imp.__libc_start_main
             sym.imp.scanf   6 0x8048398 |   MATCH  (1.000000) | 0x8048398    6 sym.imp.scanf
            sym.imp.strlen   6 0x80483a8 |   MATCH  (1.000000) | 0x80483a8    6 sym.imp.strlen
            sym.imp.printf   6 0x80483b8 |   MATCH  (1.000000) | 0x80483b8    6 sym.imp.printf
            sym.imp.sscanf   6 0x80483c8 |   MATCH  (1.000000) | 0x80483c8    6 sym.imp.sscanf
           sym.imp.strncmp   6 0x80483d8 |   MATCH  (1.000000) | 0x80483d8    6 sym.imp.strncmp
              sym.imp.exit   6 0x80483e8 |   MATCH  (1.000000) | 0x80483e8    6 sym.imp.exit
                    entry0  33 0x8048400 |   MATCH  (1.000000) | 0x8048400   33 entry0
              fcn.08048424  33 0x8048424 |   MATCH  (1.000000) | 0x8048424   33 fcn.08048424
              fcn.08048450  47 0x8048450 |   MATCH  (1.000000) | 0x8048450   47 sym.__do_global_dtors_aux
              fcn.08048480  50 0x8048480 |   MATCH  (1.000000) | 0x8048480   50 sym.frame_dummy
              sub.LOLO_4b4 112 0x80484b4 |   MATCH  (1.000000) | 0x80484b4  112 sym.dummy
sub.Password_Incorrect_524  30 0x8048524 |   MATCH  (1.000000) | 0x8048524   30 sym.che
            sub.sscanf_542 119 0x8048542 |   MATCH  (1.000000) | 0x8048542  119 sym.parell
            sub.strlen_5b9 196 0x80485b9 |   MATCH  (1.000000) | 0x80485b9  196 sym.check
                      main  99 0x804867d |   MATCH  (1.000000) | 0x804867d   99 sym.main
              fcn.08048755   4 0x8048755 |   MATCH  (1.000000) | 0x8048755    4 sym.__i686.get_pc_thunk.bx
              fcn.08048760  35 0x8048760 |   MATCH  (1.000000) | 0x8048760   35 sym.__do_global_ctors_aux
              fcn.0804878d  17 0x804878d |     NEW  (0.000000)
       sym.__libc_csu_init  99 0x80486e0 |     NEW  (0.000000)
       sym.__libc_csu_fini   5 0x8048750 |     NEW  (0.000000)
                 sym._fini  26 0x8048784 |     NEW  (0.000000)

lucky! crackme0x08居然和crackme0x07几乎一样, 不同之处在于crackme0x08的符号没有去掉, 虽然crackme0x07有几个新的函数, 不过大多都在init, fini部分. 所以用上题的密码来验证下:

$ LOL= ./crackme0x08 
IOLI Crackme Level 0x08
Password: 88
Password OK!

$ LOLO=1 ./crackme0x08 
IOLI Crackme Level 0x08
Password: 196110
Password OK!

有同学就问了, 要是没有那么lucky怎么办? 那也没关系, 只要分析不同的函数, 也能达到事半功倍的效果, 或者重新分析, 那也比crackme0x07简单嘛, 至少不用重命名函数了.

crackme0x09

最后一关了, 还是从main开始:

[0x080486ee]> pdf @ main
/ (fcn) main 120
|   main (int arg_10h);
|           ; var int local_78h @ ebp-0x78
|           ; var int local_4h_2 @ ebp-0x4
|           ; arg int arg_10h @ ebp+0x10
|           ; var int local_4h @ esp+0x4
|              ; DATA XREF from 0x08048437 (entry0)
|           0x080486ee      55             push ebp
|           0x080486ef      89e5           mov ebp, esp
|           0x080486f1      53             push ebx
|           0x080486f2      81ec84000000   sub esp, 0x84
|           0x080486f8      e869000000     call fcn.08048766
|           0x080486fd      81c3f7180000   add ebx, 0x18f7
|           0x08048703      83e4f0         and esp, 0xfffffff0
|           0x08048706      b800000000     mov eax, 0
|           0x0804870b      83c00f         add eax, 0xf
|           0x0804870e      83c00f         add eax, 0xf
|           0x08048711      c1e804         shr eax, 4
|           0x08048714      c1e004         shl eax, 4
|           0x08048717      29c4           sub esp, eax
|           0x08048719      8d8375e8ffff   lea eax, [ebx - 0x178b]
|           0x0804871f      890424         mov dword [esp], eax
|           0x08048722      e8b9fcffff     call sym.imp.printf         ; int printf(const char *format)
|           0x08048727      8d838ee8ffff   lea eax, [ebx - 0x1772]
|           0x0804872d      890424         mov dword [esp], eax
|           0x08048730      e8abfcffff     call sym.imp.printf         ; int printf(const char *format)
|           0x08048735      8d4588         lea eax, [local_78h]
|           0x08048738      89442404       mov dword [local_4h], eax
|           0x0804873c      8d8399e8ffff   lea eax, [ebx - 0x1767]
|           0x08048742      890424         mov dword [esp], eax
|           0x08048745      e876fcffff     call sym.imp.scanf          ; int scanf(const char *format)
|           0x0804874a      8b4510         mov eax, dword [arg_10h]    ; [0x10:4]=-1 ; 16
|           0x0804874d      89442404       mov dword [local_4h], eax
|           0x08048751      8d4588         lea eax, [local_78h]
|           0x08048754      890424         mov dword [esp], eax
|           0x08048757      e8bafeffff     call sub.strlen_616         ; size_t strlen(const char *s)
|           0x0804875c      b800000000     mov eax, 0
|           0x08048761      8b5dfc         mov ebx, dword [local_4h_2]
|           0x08048764      c9             leave
\           0x08048765      c3             ret

上来就调用了函数fcn.08048766, 看看是干嘛用的呢:

[0x080486ee]> pdf @ fcn.08048766
/ (fcn) fcn.08048766 4
|   fcn.08048766 ();
|              ; XREFS: CALL 0x080486f8  CALL 0x0804861d  CALL 0x080484db  CALL 0x08048564  CALL 0x08048590  
|              ; XREFS: CALL 0x08048778  
|           0x08048766      8b1c24         mov ebx, dword [esp]
\           0x08048769      c3             ret

WOW, 好像引用的地方还不少, 作用似乎是把栈指针指向的值保存在ebx里然后返回, 值得一提的是, call xxx指令相当于:

push $EIP + sizof instruction
jmp xxx

所以该函数作用就是把下一条指令的地址保存在ebx中. 从main函数来看, 调用的一些函数传参似乎就用了ebx来做计算, 这是什么骚操作? 网上google了一下得知, 这种模式似乎是因为编译时指定了-fPIC参数, 即产生位置无关代码, 好处是这样程序可以加载到任意内存地址, 并且可以正常访问全局变量. 关于这种模式的介绍可以查看这个stackoverflow上的回答. 简而言之, 这样我们便将ebx作为PIC寄存器, 用以访问got.plt表. 以上面的main函数为例, 先把函数fcn.08048766改名为pic, 看到调用pic之后ebx应该等于0x080486fd, 然后加上0x18f7, 再减去0x178b, 最后的值作为第一个printf的参数:

[0x080486ee]> ps @ 0x080486fd+0x18f7-0x178b
IOLI Crackme Level 0x09

当然也可以通过r2分析的符号来计算:

[0x080486ee]> ps @ section_end..got - 0x178b
IOLI Crackme Level 0x09

虽然过程曲折了点, 但总算开了个头. 接下来就可以继续分析main函数了, 还是scanf输入一个 字符串, 然后调用sub.strlen_616, 接受2个参数, 分别是用户输入input和环境变量envp:

[0x080486ee]> pdf @ sub.strlen_616
/ (fcn) sub.strlen_616 216
|   sub.strlen_616 (int input, int envp);
|           ; var int local_11h @ ebp-0x11
|           ; var int local_10h @ ebp-0x10
|           ; var int local_ch @ ebp-0xc
|           ; var int local_8h @ ebp-0x8
|           ; arg int input @ ebp+0x8
|           ; arg int envp @ ebp+0xc
|           ; var int local_4h @ esp+0x4
|           ; var int local_8h_2 @ esp+0x8
|              ; CALL XREF from 0x08048757 (main)
|           0x08048616      55             push ebp
|           0x08048617      89e5           mov ebp, esp
|           0x08048619      53             push ebx
|           0x0804861a      83ec24         sub esp, 0x24               ; '$'
|           0x0804861d      e844010000     call pic
|           0x08048622      81c3d2190000   add ebx, 0x19d2
|           0x08048628      c745f4000000.  mov dword [local_ch], 0
|           0x0804862f      c745f0000000.  mov dword [local_10h], 0
|              ; JMP XREF from 0x08048693 (sub.strlen_616)
|       .-> 0x08048636      8b4508         mov eax, dword [input]      ; [0x8:4]=-1 ; 8
|       :   0x08048639      890424         mov dword [esp], eax
|       :   0x0804863c      e88ffdffff     call sym.imp.strlen         ; size_t strlen(const char *s)
|       :   0x08048641      3945f0         cmp dword [local_10h], eax  ; [0x13:4]=-1 ; 19
|      ,==< 0x08048644      734f           jae 0x8048695
|      |:   0x08048646      8b45f0         mov eax, dword [local_10h]
|      |:   0x08048649      034508         add eax, dword [input]
|      |:   0x0804864c      0fb600         movzx eax, byte [eax]
|      |:   0x0804864f      8845ef         mov byte [local_11h], al
|      |:   0x08048652      8d45f8         lea eax, [local_8h]
|      |:   0x08048655      89442408       mov dword [local_8h_2], eax
|      |:   0x08048659      8d835ee8ffff   lea eax, [ebx - 0x17a2]
|      |:   0x0804865f      89442404       mov dword [local_4h], eax
|      |:   0x08048663      8d45ef         lea eax, [local_11h]
|      |:   0x08048666      890424         mov dword [esp], eax
|      |:   0x08048669      e882fdffff     call sym.imp.sscanf         ; int sscanf(const char *s, const char *format,   ...)
|      |:   0x0804866e      8b55f8         mov edx, dword [local_8h]
|      |:   0x08048671      8d45f4         lea eax, [local_ch]
|      |:   0x08048674      0110           add dword [eax], edx
|      |:   0x08048676      837df410       cmp dword [local_ch], 0x10  ; [0x10:4]=-1 ; 16
|     ,===< 0x0804867a      7512           jne 0x804868e
|     ||:   0x0804867c      8b450c         mov eax, dword [envp]       ; [0xc:4]=-1 ; 12
|     ||:   0x0804867f      89442404       mov dword [local_4h], eax
|     ||:   0x08048683      8b4508         mov eax, dword [input]      ; [0x8:4]=-1 ; 8
|     ||:   0x08048686      890424         mov dword [esp], eax
|     ||:   0x08048689      e8fbfeffff     call sub.sscanf_589         ; int sscanf(const char *s, const char *format,   ...)
|     ||:      ; JMP XREF from 0x0804867a (sub.strlen_616)
|     `---> 0x0804868e      8d45f0         lea eax, [local_10h]
|      |:   0x08048691      ff00           inc dword [eax]
|      |`=< 0x08048693      eba1           jmp 0x8048636
|      |       ; JMP XREF from 0x08048644 (sub.strlen_616)
|      `--> 0x08048695      e8c3feffff     call sub.printf_55d         ; int printf(const char *format)
|           0x0804869a      8b450c         mov eax, dword [envp]       ; [0xc:4]=-1 ; 12
|           0x0804869d      89442404       mov dword [local_4h], eax
|           0x080486a1      8b45f8         mov eax, dword [local_8h]
|           0x080486a4      890424         mov dword [esp], eax
|           0x080486a7      e828feffff     call sub.strncmp_4d4        ; int strncmp(const char *s1, const char *s2, size_t n)
|           0x080486ac      85c0           test eax, eax
|       ,=< 0x080486ae      7438           je 0x80486e8
|       |   0x080486b0      c745f0000000.  mov dword [local_10h], 0
|       |      ; JMP XREF from 0x080486e6 (sub.strlen_616)
|      .--> 0x080486b7      837df009       cmp dword [local_10h], 9    ; [0x9:4]=-1 ; 9
|     ,===< 0x080486bb      7f2b           jg 0x80486e8
|     |:|   0x080486bd      8b45f8         mov eax, dword [local_8h]
|     |:|   0x080486c0      83e001         and eax, 1
|     |:|   0x080486c3      85c0           test eax, eax
|    ,====< 0x080486c5      751a           jne 0x80486e1
|    ||:|   0x080486c7      8d836fe8ffff   lea eax, [ebx - 0x1791]
|    ||:|   0x080486cd      890424         mov dword [esp], eax
|    ||:|   0x080486d0      e80bfdffff     call sym.imp.printf         ; int printf(const char *format)
|    ||:|   0x080486d5      c70424000000.  mov dword [esp], 0
|    ||:|   0x080486dc      e82ffdffff     call sym.imp.exit           ; void exit(int status)
|    ||:|      ; JMP XREF from 0x080486c5 (sub.strlen_616)
|    `----> 0x080486e1      8d45f0         lea eax, [local_10h]
|     |:|   0x080486e4      ff00           inc dword [eax]
|     |`==< 0x080486e6      ebcf           jmp 0x80486b7
|     | |      ; JMP XREF from 0x080486ae (sub.strlen_616)
|     | |      ; JMP XREF from 0x080486bb (sub.strlen_616)
|     `-`-> 0x080486e8      83c424         add esp, 0x24               ; '$'
|           0x080486eb      5b             pop ebx
|           0x080486ec      5d             pop ebp
\           0x080486ed      c3             ret

由于启用了位置无关代码, 一眼看不出来哪个分支是我们要去的, 所以还是按照顺序来, 首先计算出GOT(末尾)地址是0x08048622 + 0x19d2 = 0x8049ff4 (= section_end..got), 写伪代码:

void strlen_616(char *input, char *envp[]) {
    int local_ch = 0;
    int local_8h;
    char c[2];
    for(i=0; i<strlen(input); i++) {
        c[0] = input[i];
        c[1] = 0;
        sscanf(c, "%d", &local_8h);
        local_ch += local_8h;
        if (local_ch == 0x10) {
            sscanf_589(input, envp);
        }
    }
    printf_55d();
    // junk codes
}

printf_55d的代码如下, 作用是打印密码错误信息并且调用exit退出, 所以其后的代码基本上 都是垃圾代码, 就不分析了.

:> pdf @ sub.printf_55d
/ (fcn) sub.printf_55d 44
|   sub.printf_55d ();
|           0x0804855d      55             push ebp
|           0x0804855e      89e5           mov ebp, esp
|           0x08048560      53             push ebx
|           0x08048561      83ec04         sub esp, 4
|           0x08048564      e8fd010000     call pic
|           0x08048569      81c38b1a0000   add ebx, 0x1a8b
|           0x0804856f      8d8349e8ffff   lea eax, [ebx - 0x17b7]
|           0x08048575      890424         mov dword [esp], eax
|           0x08048578      e863feffff     call sym.imp.printf
|           0x0804857d      c70424000000.  mov dword [esp], 0
\           0x08048584      e887feffff     call sym.imp.exit
:> ps @ section_end..got - 0x17b7
Password Incorrect!

而循环里的逻辑和之前差不多, 也是检测每一位输入的累加和, 等于0x10时调用sscanf_589:

:> pdf @ sub.sscanf_589
/ (fcn) sub.sscanf_589 141
|   sub.sscanf_589 (int arg_8h, int arg_9h, int arg_ch);
|           ; var int local_ch @ ebp-0xc
|           ; var int local_8h @ ebp-0x8
|           ; arg int arg_8h @ ebp+0x8
|           ; arg int arg_9h @ ebp+0x9
|           ; arg int arg_ch @ ebp+0xc
|           0x08048589      55             push ebp
|           0x0804858a      89e5           mov ebp, esp
|           0x0804858c      53             push ebx
|           0x0804858d      83ec14         sub esp, 0x14
|           0x08048590      e8d1010000     call pic
|           0x08048595      81c35f1a0000   add ebx, 0x1a5f
|           0x0804859b      8d45f8         lea eax, [local_8h]
|           0x0804859e      89442408       mov dword [esp + 8], eax
|           0x080485a2      8d835ee8ffff   lea eax, [ebx - 0x17a2]
|           0x080485a8      89442404       mov dword [esp + 4], eax
|           0x080485ac      8b4508         mov eax, dword [arg_8h]
|           0x080485af      890424         mov dword [esp], eax
|           0x080485b2      e839feffff     call sym.imp.sscanf
|           0x080485b7      8b450c         mov eax, dword [arg_ch]
|           0x080485ba      89442404       mov dword [esp + 4], eax
|           0x080485be      8b45f8         mov eax, dword [local_8h]
|           0x080485c1      890424         mov dword [esp], eax
|           0x080485c4      e80bffffff     call sub.strncmp_4d4
|           0x080485c9      85c0           test eax, eax
|       ,=< 0x080485cb      7443           je 0x8048610
|       |   0x080485cd      c745f4000000.  mov dword [local_ch], 0
|      .--> 0x080485d4      837df409       cmp dword [local_ch], 9
|     ,===< 0x080485d8      7f36           jg 0x8048610
|     |:|   0x080485da      8b45f8         mov eax, dword [local_8h]
|     |:|   0x080485dd      83e001         and eax, 1
|     |:|   0x080485e0      85c0           test eax, eax
|    ,====< 0x080485e2      7525           jne 0x8048609
|    ||:|   0x080485e4      8b83fcffffff   mov eax, dword [ebx - 4]
|    ||:|   0x080485ea      833801         cmp dword [eax], 1
|   ,=====< 0x080485ed      750e           jne 0x80485fd
|   |||:|   0x080485ef      8d8361e8ffff   lea eax, [ebx - 0x179f]
|   |||:|   0x080485f5      890424         mov dword [esp], eax
|   |||:|   0x080485f8      e8e3fdffff     call sym.imp.printf
|   `-----> 0x080485fd      c70424000000.  mov dword [esp], 0
|    ||:|   0x08048604      e807feffff     call sym.imp.exit
|    `----> 0x08048609      8d45f4         lea eax, [local_ch]
|     |:|   0x0804860c      ff00           inc dword [eax]
|     |`==< 0x0804860e      ebc4           jmp 0x80485d4
|     `-`-> 0x08048610      83c414         add esp, 0x14
|           0x08048613      5b             pop ebx
|           0x08048614      5d             pop ebp
\           0x08048615      c3             ret

同样, arg_9h也是不存在的, 应该先去掉, 然后再写下伪代码:

void sscanf_589(char *input, char *envp[]) {
    int local_8h;
    int local_ch;
    sscanf(input, "%d", &local_8h);
    if (0 == strncmp_4d4(local_8h, envp)){
        return;
    }
    for (local_ch = 0; local_ch < 9; local_ch++) {
        if (local_8h & 1 == 0) {
            if((int)*0x08049ff0 == 1) {
                printf("Password OK!\n");
            }
            exit(0);
        }
    }
}

最后看下strncmp_4d4:

:> pdf @ sub.strncmp_4d4
/ (fcn) sub.strncmp_4d4 137
|   sub.strncmp_4d4 (int arg_ch);
|           ; var int local_ch @ ebp-0xc
|           ; var int local_8h @ ebp-0x8
|           ; arg int arg_ch @ ebp+0xc
|           0x080484d4      55             push ebp
|           0x080484d5      89e5           mov ebp, esp
|           0x080484d7      53             push ebx
|           0x080484d8      83ec14         sub esp, 0x14
|           0x080484db      e886020000     call pic
|           0x080484e0      81c3141b0000   add ebx, 0x1b14
|           0x080484e6      c745f8000000.  mov dword [local_8h], 0
|       .-> 0x080484ed      8b45f8         mov eax, dword [local_8h]
|       :   0x080484f0      8d1485000000.  lea edx, [eax*4]
|       :   0x080484f7      8b450c         mov eax, dword [arg_ch]
|       :   0x080484fa      833c0200       cmp dword [edx + eax], 0
|      ,==< 0x080484fe      7448           je 0x8048548
|      |:   0x08048500      8b45f8         mov eax, dword [local_8h]
|      |:   0x08048503      8d1485000000.  lea edx, [eax*4]
|      |:   0x0804850a      8b4d0c         mov ecx, dword [arg_ch]
|      |:   0x0804850d      8d45f8         lea eax, [local_8h]
|      |:   0x08048510      ff00           inc dword [eax]
|      |:   0x08048512      8d8344e8ffff   lea eax, [ebx - 0x17bc]
|      |:   0x08048518      c74424080300.  mov dword [esp + 8], 3
|      |:   0x08048520      89442404       mov dword [esp + 4], eax
|      |:   0x08048524      8b040a         mov eax, dword [edx + ecx]
|      |:   0x08048527      890424         mov dword [esp], eax
|      |:   0x0804852a      e8d1feffff     call sym.imp.strncmp
|      |:   0x0804852f      85c0           test eax, eax
|      |`=< 0x08048531      75ba           jne 0x80484ed
|      |    0x08048533      8b83fcffffff   mov eax, dword [ebx - 4]
|      |    0x08048539      c70001000000   mov dword [eax], 1
|      |    0x0804853f      c745f4010000.  mov dword [local_ch], 1
|      |,=< 0x08048546      eb0c           jmp 0x8048554
|      `--> 0x08048548      c70424ffffff.  mov dword [esp], 0xffffffff
|       |   0x0804854f      e8bcfeffff     call sym.imp.exit
|       `-> 0x08048554      8b45f4         mov eax, dword [local_ch]
|           0x08048557      83c414         add esp, 0x14
|           0x0804855a      5b             pop ebx
|           0x0804855b      5d             pop ebp
\           0x0804855c      c3             ret
:> ps @ section_end..got - 0x17bc
LOLO

伪代码:

int strncmp_4d4(char *input, char *envp[]) {
    int i; //local_8h
    int local_ch;
    for (i=0;;i++) {
        if (envp[i * 4] == 0) {
            exit(0);
        }
        if (0 == strncmp(3, "LOLO", envp[i * 4])) {
            *0x08049ff0 = 1;
            local_ch = 1;
            break;
        }
    }
    return local_ch;
}

还是检测和之前类似, 所以综上所述, 要想密码正确, 则需满足以下输入条件:

  1. 输入的前X位(数字)之和为16, X为任意值.
  2. 输入的环境变量中要有一个key的前3字节为LOL.
  3. 输入的必须是个合法的数字而且为偶数.

验证:

$ LOL= ./crackme0x09 
IOLI Crackme Level 0x09
Password: 88
Password OK!
$ LOLTHATSFUN=1 ./crackme0x09 
IOLI Crackme Level 0x09
Password: 19621234
Password OK!

大功告成! 其实这题除了PIC之外和前一题依旧是类似的.

后记

由于这篇writeup写的时间跨度比较长, 所以前面逆了一个到后面不知不觉又当成是新的程序来分析, 其实他们之间有很多相似的地方. 不过从练习的角度来说这也算好事, 汇编代码看多了之后发现一些 原来要花很多时间分析的地方再遇到类似的模式时就能很快反应过来, 也算是熟能生巧吧.

这两篇也算是我使用radare2做静态分析的一个笔记, 因为程序都比较简单所以就没有进行调试. 一般来说遇到现实生活中的样本(比如病毒或者木马), 进行分析时还需要进行动态调试分析才能对其 功能有个整体了解, 此外也衍生出了一些反分析(加花, 加壳)以及反调试手段. 所以做安全还是 要不断学习和挑战, 切忌在自己的舒适区里止步不前啊.

]]>